Arno Nel asked the question on his blog “What is Architecture?” This is my response…
I have a whole series on the various roles in software development on Developer.com, the software architect one is at http://www.developer.com/mgmt/article.php/3504496.
However, my thoughts on your statements are …
- On Architecture is 50% business, 50% tech — I’d say that architecture is one part art (elegance, simplicity), one part facilitated visioning (getting a common idea of what is going on), and one part conversion (converting requirements into design). While it’s true that business and technology are both required, I’d say that the important aspects are not well respected with this point of view. Knowing how to facilitate people coming together, knowing how to convert requirements into design, and knowing how to maintain simplicity in the face of complexity are a much more important perspective.
- On The Architected doesn’t decide w[h]ether or not to use DataGrids – I don’t know that I can agree to this statement in every case. It depends upon what the solution is and what is necessary. She may decide that DataGrids are critical to some reusability that is desired and could specify them. However, in most cases, you’re right. In most cases shouldn’t be any reason why an architect would specify the use of DataGrids or not. Think of it this way, a traditional building architect doesn’t generally specify the supplier for a bolt – only how strong it must be.
- On The architect doesn[‘]t care about coding standards – I heartily disagree here. He doesn’t care WHAT is in the coding standards but he does that they exist. In the same way that a building architect doesn’t care what kind of light fixtures are used in the building but does care that they all match (consistency) or coordinate (complimentary).
- On The architect doesn[‘]t care about reading UML – Here to I heartily disagree. I don’t disagree that the architect won’t read all the UML, however, I believe the architect should do “drive bys” of what is being constructed. That includes reviews of the UML and any other supporting documentation being used to construct the actual solution. If the point is that they don’t care whether it’s UML or something else – I disagree again. The architect’s time is overcommitted. If the architect understands UML then UML should be used to facilitate communication (reduce the cost) and to make communications more effective.
- On The architect doesn[‘]t care about Agile/RUP/MSF etc. – Again, I disagree. The architect needs to understand the process being used to know how to insert themselves into the process in a way that is both timely and respectful of the process. Choosing an approach that they are familiar with is important. Also, they may decide that to achieve the objectives one may work better than another. For instance, an agile approach will work better with poorly understood requirements. RUP will work better with risky components to the project, etc.
- On The Architect translates IT to Business – While I agree that the statement is true I believe it misses the fundamental truth that an architect guides a conversion process from raw data into a solution. Also, I’d argue that the statement even in it’s form here should be reversed. They help to translate the business problems into IT solutions (not IT into business.)
I think an interesting question is how does a solutions architect differ from a building architect?
No comment yet, add your voice below!