“All the guys who can paint great big pictures can paint great small ones.” – Ernest Hemingway
Even Hemingway had thoughts on architects. In many conversations about the requirements of an architect I usually here people say that architects are big picture IT people. I do agree that architects need to carry a vision for and a roadmap to get to a big picture. Architects should be able to do the same for small pictures. Additionally, the architect better be able to single-handedly build small pictures. When an architect lays out a complicated design or use case the architect should be able to produce some runnable, usable, understandable documentation and code. If the architect doesn’t understand how to produce the micro level artifacts than I think that that architect may be an IT manager disguised as an IT architect.
There are many articles (opinions) on what an IT architect is and does. Here are two recent articles about what is an architect. I wrote about it in the IASA Newsletter. I like this article about enterprise architects and if you’d like to read more try Google.
I would like to agree with my colleague; I have witnessed too many “architects” who feel it is their role to not know anything about the micro-level artifacts. While this is true to some extent, in that the architecture model itself should not be hamstrung too much be the target implementation technology, there are nonetheless other limits that necessarily must be taken into account at the architecture level.
By way of an example of how implementation technology and language features can impact software architecture, I recently had several days worth of meethings with a room full of designers. The scenario is this: there is a Class A, and B inherits from A (the first subsystem knows only about A’s, and the second knows about A’s and B’s). Some part of the subsystem makes an A object and hands it off to another subsystem. This other thread of execution needs to add some behaviour to the base class type (which is why we need a B type), but we cannot require the folks who make an A to make a B instead, as this would introduce an undesirable dependency between the two subsystems. We also don’t have the cycles to devote to any deep copy either, as we have to keep things lean and mean.
Besides the fundamentally disturbing fact that everyone in the room maintained, for more than two days, that one could have the best of both worlds and simply make an A, hand it off, and make a B out of it *by simple typecasting* (as in B b = (B) a), the implications on the architecture itself was completely missed.
This was solved simply by changing the semantic that a B ‘isa’ A to B ‘hasa’ A, and in fact, being a little more strict, making it a true composition. The point is, the target language was Java, and the two requirements for the design were that the first subsystem had to be as loosely bound to the second subsystem, and that we didn’t have the spare clock cycles for deep copies, etc. While other OO languages do provide mechanisms to handle this better (ObjectiveC, Smalltalk, etc.), in this case, since the implementation language was also a requirement, and not optional, its language features therefore directly impacted what we could or could not do in terms of architecture (in this case compostion instead of inheritance).
So I discovered that I have a bunch of IT managers around me … ;-]