Not having blogged for sometime it feels a bit strange to do so again. Last few months has been hectic between the birth of our second son, and a few projects coming off the boil simultaneously (one of sensitive nature restricting what I can blog about).
Someone recently asked me what do I look for if I am hiring architect, the question caught me off guard as I had never given it much thought. In the past I have interviewed lots of Solution Architects, hired a few good ones and a few not ok ones. The problem with interviews is it is such a luck of the draw, despite the best intentions there are no guarantee of outcomes. Having said that I wanted to pen down what I thought made a good enterprise/solution/software/architect.
Architects in our information age have a unique position they sit between the business and technology acting as a bridge between competing domains. This role has become even more important as role of IT has changed from being Automating Business to Information Management and finally Business Transforming (Information Paradox). The other paradox with architects role is even though they play such a crucial role very often they have no power to direct things, other than to influence from the sidelines. Often when IT projects turn bad CIO have been know to turn to their Architects (Enterprise or Solution) and ask them where were you when the rot started (on the sidelines watching the project go downhill).
From my personal experience and what I have seen in others to be successfully architects one need to have equal parts of following professional traits.
Salesman: to be able to sell the concept to other members of the team and stakeholders. Basic sales skills are important to firstly empathize with others and understanding what they are truly looking for.
Preacher: As an architect one needs to believe in something and have the ability to appeal to others emotional core. When things don't go as planned every one in a software project team have a tendency to turn to the architect who had initially articulated the vision. During such trying times faith in ones ability should be unfaltering. The down side of being too much of a preacher are the flame wars we are so often familiar with "Linux is better than Windows", "RUP is better than SCRUM", "UML is the only modeling language the world needs".
Thinker: This is perhaps the most important ability of an architect, the ability to solve complex problems either by abstraction or separation of concern. This is the trait which gets discussed the most when talking about architects so I wont waste any more time or space.
Dana Bredemeyer and Ruth Malan in their article "What It Takes to Be a Great Enterprise Architect" describe US Constitution as a form of Enterprise Architecture and James Madison the first Enterprise Architect. They outline similar skills I have outlined above and include a few more (domain expertise, political acuity, strategic ability, and leadership skills).
Having said all this an architects job is never easy they have to often juggle multiple dimensions and competing priorities with the responsibility to articulate a solution which balances all these dimensions and then communicate it to diverse group of stakeholders. James M Butler in his book Technology Blueprints: Technology Foundations for High Performance Companies defines a form of psychosis that afflicts architects when these forces goes out of balance. Following are his list.
"Dimensional Myopia: Focusing too tightly on resolving certain dimensions of the problem space while being unaware of or choosing to ignore others
Evolutionary Vertigo: Refusing to ever commit to an approach, tactical or strategic, based on a perception that the solution spaces are changing too rapidly, thus resulting in a lack of traction
Molecular Paranoia: Working 23 hours a day to mentally maintain for real-time access all details along all dimensions and scanning all news sources for any external influence for fear of missing any single detail, relevant or not
Reverse Acrophobia: Clinging only to the highest levels of abstraction and avoiding reality-based grounding while apathetically assuming that the engineers can and will do all the heavy lifting"
I have seen Dimensional Myopia especially among architects who come from a specific stream background (I.e. Data Architects tend to see the whole world as a database). As an software architect it is important to have well rounded experience, preferably some in non IT space (manufacturing, finance and so on). Recently reviewing someone's architecture I came across Reverse Acrophobia; in this particular case solution was at a level of abstraction where reality was a problem. I am not going to comment on Molecular Paranoia as sometimes I suffer from that affliction :-).
Recently I came across a beautifully quote from Chris Bangle Chief Designer at BMW where he says "Engineers make the world happen. The role of the designer is to give them focus." In the world of IT Architects play the role of designers and software developers, hardware engineers, network engineers make it happen.
As a final word have a look at this article http://www.cio.com/archive/030105/blueprint_sidebar_five.html
