Thursday, October 22, 2009
"I see little point in replacing a poor architecture with a worse one." Ouch! A pretty biting assessment to be sure, made worse only by the fact that yours truly is the credited author of the poor one. I recently found myself in a three-way conversation regarding a proposed change to an existing system. I had designed the original solution several years ago, but the current support team had proposed a change. A third architect and I were discussing the proposal when he provided his opinion of both my original and the new designs. Ouch!
My poor architecture uses a well-known well-supported product for corporate content management - augmented with some in-house development to implement a limited set of features found in much higher-end WCM products. This back end is accessed via web services by a J2EE front end that can be easily adapted for style and function through JSPs and CSS. The front end was also developed to take advantage of clustering and caching to accommodate performance and scale considerations. As you might guess, I'm a little perplexed as to the exact nature of this architecture's poorness.
To be fair to the original critique - the newest proposed architecture is not as good as the current one, so the notion that the solution is stepping backwards is shared by both of us. I'll also stipulate that the assessment of "poor" was not done after a careful review of the facts, rather it was an intuitive comment given in response to the names of products used in the original design.
The conversation, however biting, raised an interesting question - how do seasoned architects with varying backgrounds and experience find objective agreement on sound architecture? Having been in conversations with other IT professionals for over 25 years (as well as conversations with um, er a few non-professionals), I can can relay unequivocally that architecture assessments of good, better, and best are often in the eye of the beholder.
I ask three questions when reviewing an architecture, and while the answers can be admittedly subjective; these have held up over the years.
Are the components used as intended?
This could be a book in and of itself, but the gist is that relational databases should be used for relational data. Queue based solutions ought to be used asynchronously. This is the fit-to-function element of architecture. While it may be possible to screen scrape your web-based email for a real-time, transactional update, it should be considered (by definition) a poor architecture.
Are the components appropriately cohesive (tight) and coupled (loose)?
Long standing tenants of object oriented design, each component of a design should only perform functions related to each other (cohesion) and be sufficiently stupid about the internal working of other components (loosely coupled). This becomes the foundation for modular design.
Does the form (design) follow the function (requirements)?
Of course, a design that does not afford its intended use and / or fails to meet the requirements should be considered a poor architecture.
Lastly, the proof is in the pudding, right? So when I come across something that curls my teeth, I ask if the solution been found to be stable, lightweight, and flexible? It's hard to argue with success.