382.aspx

The Holy Title of Software Architect

The To Software Architects: Serve End Users, Not Your Egos article on DevX is something to keep in mind for all software architects.

At one organization, they had a diagram on one wall that was 14 feet long and 4 feet high with tiny print. The architect was so proud of his masterpiece, his brilliance, his grand work. Minor amounts of investigation revealed that none of the team leads had the slightest clue what this massive diagram really meant, but it sure looked cool and impressed the executives when they visited the development area.

Individual developers had received smaller diagrams, filled with blocks and arrows, that told them exactly how to build their piece of the application. While attempting to interpret the diagrams, they had to resort to Googling the obscure patterns referenced and were made to feel incompetent for not knowing what a "Grafter" pattern was. Diagramming is about communicating what you're building, not about conveying your ability to memorize obscure names for common solutions.

I'm sad to admit that I see this behavior at work as well (I guess you better stop reading if you work with me:-) What do you tell a developer that proudly brings you the latest creation: a UML diagram that implements that latest and greatest patterns for something that can easily be done single class? Most of them do it to seek approval and show how much better they are than the other developers. Others suffer from the beta syndrome: the need to use the latest and greatest technologies and software.

I do my best to KISS every day as long as it doesn't hurt performance too much.  Keeping it simple has several benefits:

• It contains less bugs


• It is easier to maintain


• It is easier to explain the design to the developers.

Or in the words of David Talbot:

If you're in charge of the software architecture, whether or not you've been bestowed the holy title, keep the focus on designing a system that works. Keep your diagrams simple and understandable. Don't pay too much attention to whether or not it is a proper Booch diagram or whether it utilizes GoF patterns. Don't try to micro-design every developer's piece of the whole, just where it integrates into the whole. Build the system to do what it needs to do, don't gold plate what the users will never see nor care about.

Just build good software on time and within budget.