• 2008
• 2007
• 2006
• 2005
• 2004
• 2003
• 2002

• Related items:
• Management
• Content Server
• Customer Overview
• Services Partners

AS APPLICATION DEVELOPMENT becomes more complex, a slew of development frameworks and methodologies -- patterns, Rational Unified Process (RUP), UML, and STRUTS to name a few -- have emerged to help IT architects translate business needs into technology solutions. But, what happens if the pattern doesn't fit? What if UML gets unwieldy? I asked several ADVISOR contributors if it's possible to "over-architect" a development project. I'll give you the highlights here; you can check out the details at http://Advisor.com/Article/COLEC171.

...

TONY HIGHAM, Chief Solution Officer, FatWire Corporation

A typical example of "over-architecting" was the mass rush to implement EJB a few years back. Over time, it became apparent EJB couldn't fulfill its original promise (because of the complexity of the underlying software).

It comes back to the KISS principle. We sometimes over-architect projects because we think a certain technology is required -- without any scientific data to support that decision. In the case of EJB, people tend to throw in a bunch of major components because they want to use cool, new technology, it's key resume material, or they think it will save their hide in the event of increased volume.

However, you can't can't truly determine the performance of an application in advance. It's best to make it work and then tweak performance through architectural choices as necessary. As long you adhere to good OOAD practices, any rework required to deal with volume should only minimally impact the design.