top of page

Elevating your EA

Enterprise Architecture [EA] is an underutilized discipline.  Today, most organizations are either mandated to adopt it (i.e. the US federal government) or feel that they need adopt it to impress key stakeholders.  Once adopted, few organizations leverage EA to its full potential as an enterprise tool.  In the first of a three-part blog post, I will offer an informal definition of EA and a case study showing why it is vitally needed.   

What is True Enterprise Architecture [EA]? 

Nearly all executives use financial / managerial accounting as a means to manage the financial health of your enterprise. Business leaders at all levels are familiar with accounting methods and understand their importance to the organization. The term “health” includes the current health of your organization and whether your organization has the financial resources it needs to deliver its strategic change.  Accounting provides two types of models to help executives assess financial health: One perspective examines the organizational condition at a particular point in time (i.e. a balance sheet); the other is used to understand the financial impacts of business change (i.e. income statements, financial forecasting).  

Enterprise Architecture [EA] provides another critical perspective to inform enterprise strategy – the ability to manage the operational health of your organization.  Like accounting, EA provides a view of enterprise operations at a particular point of time.  It does this by examining the current capabilities of your organization to deliver its mission and business support objectives.  Each capability relies on assets - people, processes, technology, and organizations which are needed to deliver the capability.  Like a balance sheet, EA dashboards are designed to show the disposition of these operational assets, along with how they work to deliver operational outcomes.  EA models are also powerful tools to understand the impact of potential change on enterprise assets by envisioning a target or “to-be” state of the operational assets once a strategic objective has been satisfied.   

When Enterprise Architecture is merged with Architecture-Based Analysis, architecture evolves further to become the mechanism to support organizational transformation.  It does this by managing how your organization will move from its current state to the target state using end-to-end requirements management.  Because requirements can be linked, it becomes possible to know exactly how the strategic objective (a requirement type) can be linked to the myriad of project, stakeholder and technical requirements which must be satisfied in order to satisfy the strategic objective. Once in place, your organization is able to identify and mitigate risks that would otherwise reduce the operational health of your organization. 

Despite being around for over 3 decades, it is uncommon to see true enterprise level use of EA. Rather EA is relegated to being a tool for IT or technical operations.  When used this way, EA there really is no “E” in EA. 

Case Study:  U.S. Telecommunications Merger 

An example of “EA in name only” involved a U.S. telecommunication merger where the larger company sought to acquire the innovative aspects of a slightly smaller company.  While both companies had architecture disciplines, the use of architecture was confined to IT and telco network operations. Our team was brought in to assess the relative operational health of each partner’s business functions, while they used a financial consultancy to provide an enterprise health assessment of the prospective partnership and develop assimilation plan.  Obviously, accounting models were created.  From a financial perspective, the merger seemed to make sense, especially if the market share projections were met – assuming the combined organization remained in good operational health. 

But our operational health assessment, which used Architecture-Based Analysis methods, uncovered serious challenges.  In fact, our change impact assessment revealed significant health issues in all four of the asset classifications listed above.  Our team used architectural models to show exactly where the pitfalls were (current state pain points), a target vision of fully integrated operations, and requirements which were needed to address the pitfalls and ensure successful integration. 

Sounds like the company did its due diligence.  However, that was anything but the case.  Because the analysis was confined to the operational level rather than being utilized across the enterprise, the operational health issues were not completely captured, nor could they be reconciled with the financial health projections.  And as a result, the full cost of a merger was well below the projections. 

At the operational and technical levels, most mergers and acquisitions involve making choices between the business capabilities of each legacy company.  While the official message might have been a “merger of equals”, the truth was closer to acquiring the business agility of the smaller company and making it the way the new organization will operate.  Once again, from a financial health perspective it seems relatively straightforward.  But because EA was not used effectively, integration efforts were guided by politics rather than requirements linked to performance outcomes (subjective vs. objective).  The result is that the business capabilities were, for the most part, those of the acquiring organization imposed on (the more innovative) acquired company.  Overall business agility became worse than it was when each of the legacy organizations operated independently. 

It has been well over a decade since the merger described above took place.  Today, EA tools create powerful, visual models to depict the operational health of large, complex organizations.  These tools are designed to be used by operational teams for business outcomes rather than as technical tools requiring specific IT knowledge.  

Methodologies have also evolved so all operational changes must align to enterprise strategy, ensuring a “do no harm” approach for any proposed business change.  Requirements are considered to be the intellectual capital to depict how your enterprise operates as well as describing what needs to be done to ensure / improve the operational health of your enterprise. 

In our next post, we look at 8 questions to ask in order to elevate the role of EA in your organization.   The final post will propose how EA can be elevated to manage the operational health of the entire enterprise.   

19 views0 comments


bottom of page