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

Search ...

Powered by Squarespace
« B to A or A to B | Main | Architecture as diagrams is an anti-pattern! »

"Correct" is a contextual thing...

Nick Malik in his blog "Correct" is a point of view makes the critical point that when we state that enterprise architecture is about "doing the right thing" we must not gold plate the process, we must aim to do a good job rather than a perfect job.

Enterprise architects often complain about the business direction being unclear.  As I stated in my blog, The Absence of Strategy, this should never be an excuse.  You can always derive sufficient context for any architectural decision to to be good enough.

In hindsight, many decisions seem wrong and have created a legacy.  But at the time they may well have been right.  The alternative of delay or do nothing may have been much worse.  Failing to meet regulation, delaying product release or missing peak trading could have much greater costs than unpicking the legacy of hasty actions.

Enterprise architecture does not need to be what Nick Malik calls the "ultimate BDUF exercise".  There are a range of enterprise architecture management styles that suit different organizational contexts

Sometimes these decisions could have been made better.  Why weren't they?  Absence of information is usually the answer.  We need to be out there listening, learning and informing for our point of view to be heard.  Decision processes exist, we need to be part of them rather than create new ones, we need to be part of the context of business decision making.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    Response: Blog Carnival #9
    Alot interesting posts this week - I collected the ones that I liked (and read their blog) the most.

Reader Comments (1)

Absence of information is generally the key to this situation. Architecture of any sort, be it business architecture, technical architecture or building architecture is inherently an exercise in context, relationships and metrics. Formalisation of this information gathering process is crucial to determine the correct answers to those questions.
Only through a process of being able to accurately define problems into structures such as “building blocks” and then being able to define those building blocks context, relationships and metrics are we able to achieve the aims of Enterprise Architecture. This enables us to be more pragmatic in our approach to Enterprise Architecture and avoid the fatal “Paralysis through Analysis” syndrome. This syndrome is often the reason that we fail as enterprise architects. We need to understand more clearly the correct level of information that need to be gathered to make decisions that are of value to the business goals.
Each building block should be defined in the breadth and depth of information that needs to be gathered, following a philosophy that identification of information is the first and most important step and that they describing, outlining and detailing of building blocks should be weighed against the cost of that work and the risk of not knowing the details.
Again for each building block defining the core context, relationships and metrics are they key activities and any more detail again needs to be carefully examined through cost/benefit analysis.
It is only through formalised methods can we manage this process correctly and as Enterprise Architects we now firmly find ourselves in a position where we are expected to take our own medicine.

October 12, 2008 | Unregistered CommenterColin Wheeler

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>