"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.

Comments

[Colin Wheeler]

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.