Architectural Attributes

Hard to believe I am still working my way through posting great log entries from folks in the Spring term. This log entry from Deborah Ford in my Software Architecture and Design Class at Stevens lists great attributes for a software architect. I like that she emphasizes domain knowledge, breadth of experience, communication skills and mutual respect (architect should respect designers and developers; designers and developers and designers should respect the architect). In many ways that is a great formula for any leadership role but it is especially the case for the architect. I would like to thank Deborah for letting me share these with you. The key excerpt from Deborah's log entry:

Out of this (my experience) I’ve concluded that there are certain keys to success for architecture teams:

1. This isn’t necessarily a job for the most creative designer or best technician. It is more important to get someone who understands the big picture and can bring differing views to consensus or make a judgment when the situation calls for it.
2. Don’t farm out architecture roles to outside contractors – you are investing your knowledge capital in people who don’t have such a compelling reason to stay and can be at the whim of budgetary fluctuations. You are also giving lots of domain knowledge that your competitors may be able to take advantage of further down the line.
3. Team members should have a wide exposure and not be too wed to any particular technology or internal organization. I am wary of people who have spent their entire working career in a single organization.
4. They must be people who have the respect of the teams that they work with.
5. They must have a good grasp of the business domain.
6. They must not be seen as too allied with any single development organization

Hopefully, I will increase my volume of posts in the next few weeks since I have some backlog and a fresh stack of 30 logbooks to read from my summer classes! Later!

Comments

[John Palanca]

The recipe for success definitely provides a highly collaborative work environment. Successful teams are often measured by the quality of input/output and the timeframe spent in the delivery. Software Engineers can be practically classified as virtual Civil Engineers. Like their physical construction worker counterparts, Software Engineers also build highways and infrastructures that house data collection and information processing. Is it high time now for building codes? Is waste management applicable in this environment?

[Jack Allison]

We had an excellant discussion about this today in class. I would add to this that the person should have the technical and business big picture firmly under control. If not the very people they need to influence will just ignore their designs. If the person has these skills and attributes it won't matter if they report to I/T or the LOB. They will then need to walk this balance for the rest of their Architectural life.

[David Hong]

Good comment Jack. I'm taking a rather different approach. I think that there should be a committee that governs the overall communication between IT and LOB. The ITIL has established a set of best practice/standard (for a lack of better words) IT Governance that does just that. It has proven to be quite successful and Gartner and others for example IBM GBS (Global Business Services) has say and demonstrated that IT Governance works to merge the two distinctive business units together to formulate governance policies, leadership and methodologies to aid the software engineering projects efforts.