This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace
« Cutter Report - How to Measure Success: Use EA to Define Architecture | Main | Eduardo Jezierski: Architecture, Mobiles, and Health: 10 Pitfalls »

The over-reaction architecture governance anti-pattern

There are a couple of avoidable behaviors that architects sometimes adopt that generally annoy project teams. 

The first is “nick picking” – identifying an apparent issue and then drilling down into it to minute detail.  It appears to be an exercise in demonstrating how clever the architect is and how dumb the project team is.  The effect often is the reverse.  It tends to destroy the credibility of the architect as a business steward that is safeguarding the interests of the enterprise.

Architects do develop a set of useful instincts that allow them to “sniff out” issues embedded in designs.  But unfortunately, some architects act like the dog in the park that gets a whiff of food and very shortly afterwards is seen tucking into a stranger’s picnic hamper. 

The second behavior is "panicking about nothing” – hearing a rumor of non-compliance and initiating large scale projects reviews, post-mortems and escalations.  Often the scale of the intervention is excessive leaving the architect having to justify why it was so important to “cry wolf”. 

This behavior is a symptom of architects being disconnected from delivery.   The solution architecture will be wrong because it is based on limited information, the project will discover awkward facts that change the original solution.  Formal and informal feedback are necessary.

A disciplined approach is necessary to avoid these anti-patterns…

The first rule is focus on what is important – architectural governance must begin with a triage process that identifies high risk activities.  Restrict governance to those activities.  Yes, you will miss stuff but it is the less important stuff.

The second rule is advise.  You have seen the issue coming through the triage process, so give the project the right advice up front so they don’t make the mistake.

The third rule is support.  When the project team gets to the critical activity, be there!  Make sure they understand your advice and, equally important, that your advice is still fit for purpose.  From a process perspective, there needs to be a mechanism for projects to provide feedback on their decisions.

The fourth rule is communicateWrite it down - an architect’s instinct should be captured as a principle, a policy, a guideline or  a standard.  The triage process should be documented.  You must get the knowledge out there, continually – do you have an ongoing communications plan?

The fifth rule is be humble!  There is never a need for arrogance.  The project team are the people that give architecture worth because they are the ones that deliver.  You have succeeded when you have helped them deliver business value.  You need their goodwill.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (4)

I agree with you. I just add one thing: A enterprise architect helps the project team to work on the information system (IS). IS is a tool to construct a service for the project team's clients.

June 29, 2010 | Unregistered CommenterLDU

Why do you use the title 'architect'? I dont see any architect here. I only see computer programmers and business communications. Architecture has been a profession for a very long time. It seems like you could come up with a new word for what you do? I understand the statements like "the architect of an idea or business model, or such" but, that is metaphor: 'architect is creator' . Using the term architect as a job title is simply incorrect unless you have a degree in architecture and pass the exams after the required years of internship.

August 14, 2010 | Unregistered Commenterheather

Yes, "architect" is not a synonym of "creator." Architecture is domain dependent--"building architect," "city architect," "transportation architect." Nor is Architect is the same as "planner" or "engineer." Neither is an Architect a hands-on doer. All these roles seem to surround something that almost cannot be described with precision but surely exists since buildings, bridges, and transportation systems "behave" in characteristic ways that one can identify as a "style." Architecture decisions occur at a nexus of alternatives that determine not only the way functionality can be used but cost, safety, and opportunity to use innovative methods and materials. The exact same business functionality can be "created" in radically different ways due to key differences in key constraints and principles followed. Then the actual outcome of design and implementation may be "functionally equivalent" to the business depending on environmental factors -- "fitness for use." The Architects vision must therefore span both business and technical consideration. As Zachman points out, this is as it has been for thousands of years in various domains. But each domain has materials and methods and styles and patterns that must be discovered and mastered. In Enterprise Architecture we are at the beginning of that learning curve. Yes, it has been going on in the business world implicitly for many decades, maybe centuries. But the role of technology is just now being understood.

May 2, 2011 | Unregistered CommenterDan

A good real estate development starts with the right architect. An architect is concerned not only with the concept but also the planning as well as designing of a building or any real estate development.

Mountford Pigott

August 26, 2011 | Unregistered CommenterRobin Kit

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>