The difficulty often times is that the role of enterprise architect is defined quite broadly with respect to their responsibilities and project assignments. This leads to over-allocated architects and creates bottlenecks in the flow of ideas to solutions. They essentially become gatekeepers to getting real business value delivered.
A few problems I have seen with the enterprise architecture team role. First, if an architect is only working at an abstract level, products will often drift from the actual manifestation of their suggested architecture. Second, if an architect is assigned too many projects, their task switching limits their effectiveness, productivity and quality of any one project. Third, if architects are working too far ahead of the actual development of the solutions – analysing, architecting and designing whole systems – delays and handoffs to the development teams and business communication begin to break down and the solution misses the mark (often sighted as root problems in a traditional waterfall approach). Last, many architects do not have the requisite skill set to effectively facilitate across the business and IT development.
The key is to balance two organizational architecture patterns (more on organizational patterns from the book – Organizational Patterns of Agile Software Development by James Coplien and Neil Harrison)
- Architect Controls Product
- Architect Also Implements
The first organizational pattern essentially mimics the finding of this study – allow the enterprise architects to drive the product implementation in close relationship to the business domain. This is not a dictatorial control of the product, but rather more inspirational guiding and leadership.
The second pattern helps keep the architecture aligned to the implementation. This is an agile “whole team” approach to assuring the consistency of the architectural principles to the actual manifestation of the business needs. Coplien and Harrison indicate that “too many software architects limit their thinking and direction to abstractions, and abstraction is a disciplined form of ignorance. Too many projects fail on “details” of performance, subtleties of APIs, and interworking of components–or, at best, they discover such problems late.”
So, while I agree with the general principle of this study (and article), I have seen a number of pitfalls in the execution of this strategy. Some things to consider as you set up your enterprise architect innovation team…
- Promote enterprise architects based on both their technical expertise AND their facilitation capabilities. Avoid dictatorial personalities.
- Align your enterprise architects with projects they can drill into – guiding IT development teams in the architectural principles and facilitating the business collaboration and alignment.
- Do not assign too many projects to your enterprise architects – task switching will kill the effectiveness of even your best people.
- Quickly begin to implement thin vertical slices through your architectural solution in short time boxes (Sprints or Iterations) to capture early feedback from technical issues and business needs alignment. Take an agile approach.
- Matrix all enterprise architects together to assure alignment to corporate goals and shared/integrated services that may be missed within individual projects.
- Communicate to all of IT (enterprise architects and development teams) that they have an equal responsibility to contribute to innovation with the business leaders.
I would be interested in hearing your feedback on this approach and whether you have any experiences that differ from my own.