Finishing 2022 in Enterprise Architecture

Finishing 2022 in #Enterprise #Architecture (EA), I’d like to review the observation of #EA conducted by the Enterprise Architecture Center of Excellence (EACOE). This observation is set around the long-time question, “Why do Enterprise Architecture efforts fail?” The old wisdom states that a properly asked question is half of the answer. To ask a proper question, we need to know what we are asking about.

Based on years of debates on LinkedIn about Enterprise Architecture, I can conclude that EA is not about architecture but about the practice of implementation of architectural ideas as concepts, first of all, and about enabling realisation of business goals, objectives, strategies and tasks by technology means. As a result, if technology goals, objectives, strategies, principles and policies are set strictly in line with the business ones, enterprise technology practice can survive; otherwise, it will fail.

I stress enterprise technology practice because this is the best reflection of what modern EA is. Some people argue that EA is about the architecture of the entire enterprise, i.e. its business and technology parts. However, it is a delusion – In the dominant majority of enterprises worldwide EA situates and reports to #CIO who plays not more than an enablement role in the Enterprise Boards being accountable just for the technology. Thus Enterprise Architects may count only on personal influence on the realisation/delivery practice while decisions about where to aim the enterprise’s strategy and how to split it into Business Capabilities and its technology resources (programmes, projects, systems, platforms, infrastructure) are made outside of EA realm.

This is why #EACOE attributes the EA failures to, “… the misunderstanding or use of the wrong Enterprise Framework, the method used is not focused on enabling business strategy, and the resulting Enterprise Architecture is not "human consumable.” In other words, the EA outcomes are not oriented on the business consumers. At least, orientation on the business consumer’s needs should be the driver while organisation and management of the technology resources, i.e. system health catalogues, data lineage, service repositories, enterprise data models and alike, is the second part of EA duties.

At the same time, we cannot fully agree with another EACOE’s statement, “Enterprise Architects need to understand both business and technology requirements.?They also need a balanced approach?that provides a near-term return on investment (ROI) while recognizing long-term benefits. The resulting architecture needs to define a series of initiatives, programs, and projects that improve the organization's long-term strategic position.” Indeed, understanding of business and technology requirements, but operation at the enterprise level asks for understanding of the business needs first, then – requirements. This task is almost impossible because EA is not invited to the business discussions about the business directions and related needs. EA does not manage enterprise delivery resources and, therefore, cannot “balanced approach” to the “near-term return on investment (ROI) ” and “recognizing long-term benefits” anywhere but in technology driven by business objectives. EA may, in the best case, recommend, not define “a series of initiatives, programs, and projects that improve the organization's long-term strategic position”. All subjects in the discussed statement are more applicable to the EA Christmas or New Year “wish list” due to the position EA currently occupies in the enterprise structure.

We think that EACOE just very well spotted another aspect of enterprise technology practice (EA) failure: “… most people trying to develop Enterprise Architectures were trained to fix technology problems.?They may even be the organization's best "firefighters." So why is it surprising that these information technology people grapple with the idea of Enterprise Architecture that enables strategic plans without really knowing what to deliver?” Our 2 p. to this aspect are: 1) fixing is reactive and regressive while successful enterprise technology practice requires proactive and progressive/preventive vision and set of mind; 2) business plans, strategies and objectives are bout business functionality that consumes data. A company may become data-driven only if its business functionality is automated/robotised; otherwise, a data-driven enterprise is either boxed in technology only or appears as another “wish” or marketing buss-word. That is, business can and frequently does ignore technology recommendation on subjective and objective basis.

Let us ask why ESCOE believes that “Enterprise Architecture efforts also fail due to a lack of planning, time, and/or money”? Why such a lack takes place so widely in many different types of enterprises? In our opinion, the reason for this is a discrepancy between the EA ambitions and reality. This is a chicken-egg situation: business does not finance technology for the enterprise technology practice because does not see a business value in it (only a cheaper or more expensive “cost centre”) while technology cannot properly invest the money and deliver extra business value rather than ambitious promises of new and new technologies). For example, not everything in IT should be in cloud for 1 or two years like Sainsbury’s plans because all financial benefits of Cloud can be “eaten” by the increasing Cost of Clous in this recession.

At the end, here are a few targeting questions and conclusions.

Question 1: should EA deal with projects and programmes that are in the progress already? Why Solution Architecture is not enough for them?

Question 2: Can EA improve ROI in the “near-term” investments, which are usually financed, planned and scheduled already without EA involvement?

Question 3: May EA propose engagement of new technology without getting strong business cases approved?

Question 4: What management power should be granted to EA if delivery of a project /programme deviates from the currently working principles, policies, standards and technology selection? If EA is tasked with improving ROI, shouldn’t EA have rights to control (review and stop) the development that does not obey architectural enterprise rules?

Suggestion 1: EA under CIO should be focused on the enterprise #technology #household including cataloging and health-checking of the systems, applications, services, standards, technology sources, etc.

Suggestion 2: ?EA under CIO should be accountable and responsible for #compliance of the programmes with the enterprise strategy and #integrity of projects with the programme’s objectives

Suggestion 2: ?EA under CIO should be responsible for “#proof of #concepts” of #capabilities of new technologies and #innovations to support and enable #business #tasks derived from the corporate #strategy.

With the count on the magic of New Year night, we wish you a peaceful, healthy and prosperous #2023!