AT#7: Collaborate! Or: beware of Ivory Tower Architects!

Enterprise Architecture has a long tradition of mighty architectural gurus drawing fancy diagrams that never reach the reality of solution development.

In his article on the ‘Agile Modeling’ approach, Scott Ambler states:

‘An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).The mighty architectural guru(s) go off and develop one or more models describing the architecture that the minions on your team is to build to for the architect(s) know best. Ivory tower architectures are often beautiful things, usually well-documented with lots of fancy diagrams and wonderful vision statements proclaiming them to be your salvation.

In theory, which is typically what your architect(s) bases their work on, ivory tower architectures work perfectly. However, experience shows that ivory tower architectures suffer from significant problems. First, the “minion developers” are unlikely to accept the architecture because they had no say in its development. Second, ivory tower architectures are often unproven, ivory tower architects rarely dirty their hands writing code, and as a result are a significant risk to your project until you know they actually work through the concrete feedback provided by a technical prototype. Third, ivory tower architectures will be incomplete if the architects did nothing else other than model because you can never think through everything your system needs.’

What you should do

In the Architectural Thinking Framework, 80 percent of architectural work is carried out by many people, for example, by autonomous, cross-functional teams. Thus, everybody becomes an architect on a micro level contributing to the overall big picture of the company. Dedicated architect roles are used in order to ensure conceptual integrity on capability and enterprise-wide levels only.

Collaboration is fostered by easy to understand, lean models and maps, and by using Web 2.0 features (such as wikis) as central architecture repositories, where everybody can contribute and comment.

An ‘Architecture Owner – Solution’ is responsible for the conceptual integrity of the solution, which means that the micro-architectures of each team member fit together.

Previous Posts:

AT#5: Architectural Thinking – the iPhone of Enterprise Architecture Management

AT#1: Regain Control – make Business People accountable for Architecture