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

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

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

3 Comments

efthimiades Posted on 6:43 pm - May 4, 2021

efthimiades

adidas yeezy boost 350 low red cheap all gray nike magistax nike magista obra wolf grey cheap billig

bitestats Posted on 4:04 pm - Jul 19, 2021

bitestats

nike air max sort with hvid spots mens 2018 nike free rn noir penny hardaway shoes green and black for cheap girls gold sequin dress nike elastico discontinued news game kyle fuller womens jersey chicago bears 23 drift fashion orange nfl

trump investment in hydroxychloroquine Posted on 12:51 am - Jul 29, 2021

stock for hydroxychloroquine

landscape fundoplication chemical

Comments are closed.