Can there really be Chaotic Architecture?
- Summary:
- Are we about to enter the next disruptive trend - "chaotic architecture"? Charlie Bess certainly hopes not. Bess contrasts the benefits of agile architecture with the problematic idea of chaos.
I am not sure why they used the term chaotic -- other than for impact, since chaos usually signifies lack of controlled, confusion and randomness. Unless you’re a fan of Maxwell Smart but that’s a whole other issue.
What is described in the article appears to be more of a dynamic or agile architecture, which has been spoken and blogged about for at least a decade. I think the last time I wrote a post about agile architecture was in March of this year.
Gartner has been on a real kick for the last year about having a bifurcated architectural approach (they call it bimodal IT). Traditional architecture is for the areas where you are turning the crank and focused on operational excellence. A more agile approach is for those dynamic solutions where traditional architectural techniques are too heavy, and really only capable of producing shelf ware. That means moving away from more rigid governance structures that just add latency to a process that needs to be flexible.
Gartner claims “Forty-five percent of CIOs state they currently have a fast mode of operation, and we predict that 75 percent of IT organizations will be bi-modal in some way by 2017.”
So maybe it is not surprising that the word chaos is used, since there are many situation where the advances in the business and in IT are taking place so quickly that it may seem out of control. I did find it odd that the article seemed to mix the concepts of Enterprise and Solution architecture, when the team was talking about what they had tried over the years – things that might also have contributed to their chaos.
For an organization, there should be a single overarching enterprise view (the enterprise architecture) that embraces the range of solutions delivered. Hopefully no one would think that a single solution approach covers all the basis.
Though I do remember some CASE tools (back in the '80s) whose perspective was: “We’ve done the architecture, and it's up to you to get your application to fit within it.” Those were the days dominated by mainframes though, not in the polyglot we call IT today.
In any case, the point made at the end of the article is that an architecture is created to be used to facilitate decision making. Architecture is not a list to facilitate box-checkers, but a framework for identifying and optimizing value generation. Sometimes that is well understood, other times, not so much.
Architects need to use their heads and apply the right tool for the right job. It needs to be flexible to expand, contract or shift in this age where an organization is more of a ecosystem than an entity. You could call it chaos, but that seems like surrender before you’ve fought the first battle. Chaos is the enemy.
“No plan survives contact with the enemy.” -- Usually attributed to Dwight David Eisenhower, the quote actually originated with Helmuth Von Moltke in the mid-nineteenth century.