What is an Architect?
November 25, 2006 . Posted in software.
When we begin our journey we have this guy: the architect, and another bunch of guys: the team. What I want to tell you is what I think the relationship between our architect and his team should be…
Everything I am about to tell you takes place in an imaginary world called "the world of IT". Strange things happen in this world and unexpected turns are always possible.
To my mind, the architect is a story teller and his team is made up by a bunch of highly evolved and demanding scribes and laborers… They all work together to create a "miraculous tool" to save their world from an invisible danger.
The architect is the mature, well-informed and completely impartial individual who goes out in the world (of IT, remember?) and talks to other characters and gathers information (almost like a B.A. would) and doesn’t stop asking questions until he gets a clear picture of what the tool needs be. This usually proves to be more complicated than it sounds because when the characters from our story sit at a "round table" and look at a prototype of this tool they all see it from different angles and they all have drivers as to how this tool should look like, how soon it is needed, for how long it will be needed, how much it should costs and, of course, what color it should be!
Our architect then comes back to his team and lays out a wonderful, flawless blueprint of the tool… He tells the team everything they need to know about this tool and protects them from the endless discussions that he had attended beforehand, he makes the tool look simple and clear, he removes all the confusion and the blur from the original picture; he makes look so simple!
Being so tired after so much work, he now delegates to one of the loudest scribes the responsibility of coordinating the building of the tool. Now there could be architects out there that are descendants of Hercules so they could very well take this job and do it themselves, but they should not be expected to do it. The architect knows what the Tool (System) should be built with to fit in the environment (Enterprise) so that it can save the world (Solution). And since the technology is made clear to the team by our storyteller there are very few arguments. Of course there will be scribes who will advocate for various instruments, and if they have valid arguments then those instruments will be used.
The team proceeds to build the tool and, on the way, they often realize that they still have questions. But the storyteller is there to help. He knows the answers almost all the time and when he doesn’t he rushes to the "round table" to get them. He never sends the scribe to ask the question and he never comes back without an answer…
We do not look at how the tool is built because we have complete faith in the skills and the methodologies that our team uses. We might delve into it some other time…
When the tool is completed we find our characters happy: the storyteller has finished his book and the scribes and laborers have build a miraculous tool that will surely save the world.
The end.
Cheers…
Notes:
My comments apply to Software Architects (regardless of whether they are Solution Architects, Enterprise Architects or "just" System Architects) … I like you all!
Post a comment