Traditional EA Frameworks- Are They Keeping Pace with Today's Disruption?
The velocity and magnitude of change occurring in today’s enterprise is nearly unparalleled. One could argue that not since the advent of the digital age have we seen such uptake in disruptive, sometimes dissipative, change in the way business is conducted; and by natural extension, the manner in which IT delivers critically needed services to the business.
In previous decades, architecture was all-encompassing. Lines were blurred between architecture and integration. There was limited need to consider the agility of a framework. The pace of change simply didn’t dictate this paradigm. In recent years, though the ever increasing pace of disruption, driven primarily by consumer expectation is highlighting the existing divergent objectives; challenges, agility and adaptability limits of current frameworks, and by extension the EA discipline as a whole.
How Did We Get Here?
Much debate can (and probably should) be undertaken regarding the health of EA as discipline. Guided and informed by its governing frameworks, EA had largely kept pace until the early to middle of the last decade. However, these frameworks, intended as enduring ‘guardrails’, put in place to guide us down EA’s ‘yellow brick road’, somehow became almost intractable monoliths.
The EA tooling landscape has been a mixed bag of goods. While there are many solid, feature rich, well adapted tools in the market, there is really no clear cut leader that brings a comprehensive approach to tooling with, and for EA. They each bring individual strengths, targeted to their respective verticals. Yet, most tooling experts, even the vendors themselves, will readily admit that there is no one size fits all with respect to tooling.
We’ve established that today’s business leaders are moving at lightning speed to meet the demands of their respective consumer segments. It’s quite difficult to find an environment where the so called ‘Architecture’ budgets are rising. If we’re completely honest, Architecture is rarely even formally funded. The result? With the exception of those environments mandated by law for compliance purposes, the previously accepted cost of implementing EA (framework adoption, teams of practitioners, expensive proprietary tools) is not sustainable in today’s business climate.
Additionally, nearly ubiquitous adoption of Agile methods and continuous development is rendering the as-is/to-be model obsolete. Short of a full frontal assault, the time necessary to document complex environments, train stakeholders (who already have a day job), plan and deliver the communications, artifacts and metrics is almost always deemed prohibitive. We most often end up with a watered down ‘EA light’. We’re told to show immediate value, ‘Prove the case’, time and time again, when the entire premise of EA is strategic positioning for disruption, both short and long term.
Long Live the Capability/Services/EcoSystem Model
There seems to be a growing consensus that the capability/ business services/ecosystem model is better positioned to sustain relevancy as enterprises evolve. After all, aren’t enterprises a set of business ecosystems that ideally synergize to reach beyond the business itself? Mature organizations are simply dropping the term ‘applications’ in favor of terms like ‘business services’ or ‘business application services’. One thing seems quite evident, though. The type of capability modeling being undertaken by skilled practitioners in organizations with mature approach to Business Architecture are being recognized as valuable and are often serving as the basis for decisions about how the ‘future ready’ businesses are transformed.
What does this mean for EA as a practice? We’ll see more alignment with the business units, which was the intent all along. It is becoming more common for EA’s (or their newly titled equivalents) to report to the SVP of Transformation or even the CMO.
Cue the Next Generation of Frameworks
NextGen frameworks have their work cut out for them. Frameworks can no longer yield static artifacts that change only when pain is felt. A partial list of requirements becomes fairly daunting:
• They must be contextual to the need and ‘meta’ level in their granularity.
• They must serve as bridge, carrying each stakeholder, like a passenger, across the full lifecycle of Agile.
• They must yield architectures that are living, readily evolving, sets of carefully defined deliverables which provide ease of implementation and supportability.
• They must remain focused on the dependencies between the capabilities and increasingly providing ease of management.
• They need to account for automation at some level such that they may become as near real time as possible.
• They must account for the way we compute our costs to run the business.
• They must be federated, enabling snapping in of services from multiple sources.
This list is neither all-inclusive or a moderate in its scope, to be sure. NextGen frameworks, like their traditional predecessors will very likely be recognized as ‘valuable’ rather than ‘exact’.
Are Monolithic Frameworks Impacting EA’s Ability to Deliver on its Promise?
In a word, I’d say ‘Yes’. As a practicing IT professional for over 23 years, an architect for nearly 20, and an EA over 12, I would like to believe I have made a few meaningful observations about the state of IT and the businesses it supports.
"If business leaders truly lack understanding of EA’s core mission, value and vision, we must hold ourselves accountable"
First, Enterprise Architecture, though a well-intended and previously proven method to managing disruptive change, is largely misunderstood. As a practitioner who has been embedded in some of world’s largest, most high profile, enterprises in national defense, telecom, healthcare, banking, petrochemicals and manufacturing I can’t help but be amazed at how few business, and IT, leaders can properly define EA. Even fewer can articulate the value of a robust EA program. Over thirty years into its life EA, as an enterprise initiative, remains poorly planned, funded, executed and measured. Yes, the business has business to conduct, yet nearly every business leader can articulate the value of the EPMO, Risk and Compliance or Enterprise Security. Why is this not true of EA? If we’re honest, the EA community owns the responsibility for this, not those it supports.
So while the weight of traditional frameworks has contributed to the challenge, as leaders and practitioners of EA, we must own the responsibility for our profession. We must take the messaging seriously. We must recognize the need for a better, more cohesive and meaningful narrative around the value of EA, as well as how we as a community deliver on that value. If business leaders truly lack understanding of EA’s core mission, value and vision, we must hold ourselves accountable.