Simplifying Enterprise Architecture (EA) - An Overview
Let me start by briefly explaining what Enterprise Architecture (EA) is, its purpose and benefits, why an organization needs EA and who should practice it. I use the noun ‘practice’, in a hope that it is apparent that EA is incremental and iterative. I will also be using more nouns alongside EA.
Though I admire Gartner’s definition for its vocabulary, in my opinion, it gives the readers an impression that it is a very complex process (need not be) and is a herculean task (not really) to accomplish it.
As this article’s intention is to keep things simple, I’d like to quote the simplest definition of EA I’ve come across till date, as given by Dustin Hudson (EA, Seaboard Foods) in a recent Kansas City Developer Conference. In his words, “EA is about Strategic technical direction”. That sums it all.
EA is a field that essentially (and formally) started in 1987 with a journal from John A. Zachman. For a field that’s almost 3 decades old, the adoption has only increased in the last decade, a period that coincides with the peak of Information Revolution.
Even with a handful of methodologies and frameworks, the understanding and expectations for EA are quite different. Each organization is unique and so EA has to be tailored. There is no one size fits all. There are pitfalls in all the existing approaches. Common pitfalls among the organizations that had adopted EA, before and after, aren’t few. It makes one wonder, “Well…wait… pitfalls ‘after’ adopting EA? Doesn’t feel right?” Yes, that’s indeed the case. The reasons as stated by Gartner are very obvious and make a lot of sense. It is a must to avoid these prior to starting on the EA journey.
Even with a handful of methodologies and frameworks, the understanding and expectations for EA are quite different
Now that we have arrived at a common ground for what EA means and are ready to talk about the journey, let see who should take part. Who needs EA? Again, ‘who’? That sounds like an oxymoron as no organization needs one new, they all have one already. Well, if they have one already, why are we here?
In reality, IT systems are becoming complex and do not cope with either meeting business demands or increasing business efficiency. That’s why we’re here. As Scott Wambler describes in his Enterprise Unified Process, an agile approach can be applied to the EA transformation for organizations regardless of their size, culture, landscape and available budget. Common reasons we hear often are:
1. We’re not ‘big’ – Certainly, a common misconception is that an organization needs to be a particular size before it can practice EA. Even smaller startups with less than 20 people are known to have practiced agile EA and reaped benefits. Actually speaking, it is even more critical for smaller organizations to make sure their IT and business teams are aligned.
2. We’re not ‘mature’ – that is a sign when an organization should start their EA journey.
The EA field has been established to really streamline IT with business. By streamlining, not only IT should meet the needs for current business but also the future. And it should do so with reducing complexity and thereby reducing the costs. Simply put, any system that is complex not only becomes difficult to maintain but also becomes too challenging to integrate with other systems. In any organization, with increasing number of diverse IT systems, the overall complexity increases proportionately. By being diverse, systems could be one or more of:
1. home grown system, running for decades, possibly written in technologies unbeknownst to developers you can find in 5–10 years from now
2. a Commercial system that has been heavily customized beyond recognition, even upgrading it to a more recent version becomes a nightmare
3. a SaaS system that was subscribed with a lot of hope of getting things back in order
Though these decisions would’ve been done at that point with all good intentions, in retrospective, we still wonder “Who made that decision?”!
When IT is looked as the business enabler, it can eventually become the disabler, although unintentionally, by being a roadblock. Where IT complexity increases, business efficiency is impacted adversely. That’s the last thing IT wants to do to the business! You just can’t run the business the same way, with the same systems, that don’t talk to each other.
Let’s see if these illustrations would make things any simpler. Fig. A represents an ideal state where a reduction in IT complexity helps with the business efficiency. In reality, we all know it might be just the inverse. Fig. A looks good on paper, isn’t it? It can look good in real life too. Is that even possible? Yes it is. To what extent, depends on a variety of factors. How can an organization get there? Answer is EA. But don’t they all have one already? Yes, they do. Hold that thought for a few more seconds, we’ll get there.
EA can help an organization transform from their current state to the expected state, as close as possible to Fig.A. We’re going to assume that the common pitfalls have been understood and will be avoided.
How much should an organization practice EA? I’d say how much ever the business wants to succeed. Though, there isn’t an exact prescribed effort for the level of success required, with more focus, comes better outcomes. It is a transformation. And transformations do not happen overnight but can be planned.
Fig. B represents how a typical EA Transformation would look like.
The EA Lifecycle begins with a Systems Stabilization phase. I use the term ‘stabilization’ loosely here but it includes everything done to establish some form of a controlled growth. Only effective solutions that are both elegant and efficient are implemented. Solutions that are low hanging fruits are implemented sooner, to start reaping some of the benefits. This is the most critical of the phases where the longevity of the success is determined. At any cost, business should keep moving. None of the solutions put forth should do any harm to the business. Never. Ever.
The biggest drawback I still see today is the lack of a simple way to represent the ROI for the EA efforts. This is by far the single most success factor that makes almost every stakeholder think twice before investing in the EA transformation. Once they realize a real ROI is there and can be proven, who doesn’t want to make their business more efficient and that too by reducing IT costs!
The success of any EA Transformation is with the EA team (that includes both IT and Business) and who drives it. Keep it small, simple yet effective.