Architecture Readiness? What is that?

Recently I saw a question posted on a popular EA forum, asking about detecting the “architecture readiness” of the poster’s organization.   That got me to thinking about what we mean about “readiness” and is it that relevant anymore.  I admit that in the mid-90’s we would discuss the notion of an organizations readiness to embrace EA, but my perspective has changed drastically.  I think that the question is no longer “Is my organization ready to embrace and support EA?” but rather “How can I be effective in utilizing an EA approach in my organization?”  Clearly, the issues demanding EA support are still prevalent and the maturity of EA as a discipline has increased during the time since the mid-90’s.

I do not believe that any EA function can be diagnosed quickly, as most of the issues regarding “readiness” are probably a unique combination within a company.  It starts with identifying the leverageable strengths, obstacles to overcome, and methods of mitigating those obstacles – including awareness at the executive level.  I don’t believe that any organization is completely “unready” for EA, but there are certain factors that are a quick read into how long it will take for EA to be a valuable, recognized formal method of helping the organization plan, rather than just a glorified design standards group.  Key among those factors is the understanding of and desire for EA as a strategic planning discipline by the CIO first, and the rest of EA management, second.  Many times, it helps to build some of the context level artifacts BEFORE you attempt to build executive awareness as those artifacts can be a very powerful part of the argument.  There are other activities (communication, collaboration, process integration, separating and defining roles and responsibilities among different architecture levels, and governance to name the most important) that all work together to establish a culture of EA – which is really what we are talking about here.