Architecture of Business and IT Enterprise Architecture: an architecture from the Business perspectives

The first time published on AUGUST 15, 2017

Intrinsic Architecture exists because the of business organisation exists, not because someone has decided to establish such a function. Some business executives intuitively know about this architecture and try managing their companies in line with it; others do not think about the systems of their companies and rely only on their personal understanding of what will or will not work with the companies. It has been noted that if managerial directives contradict Intrinsic Architecture, their implementations either fail or appear very difficult. When this happens, the company gets delayed to adapting market changes and risks serious troubles going forward.

Since we are aware of AoB, a reasonable question is how AoB relates to an Enterprise Architecture (EA) concept and discipline known and used in the IT departments of many companies. At the time of writing this article, we are aware of very rare cases where EA is taken away from IT and placed between Operations and Marketing though still reporting into the CIO. These cases are rather exceptions from a common rule – EA is in IT.

The bigger a company is, the less visible to business the EA becomes. Unfortunately, this is a common situation regardless years and years of efforts EA applies to elevate its role in the corporate structure and spread its power over the whole enterprise. We assume that TOG TOGAF is the most popular framework that defines the practice and positions of the EA in the company (there are other popular frameworks exist as well).  And even TOGAF accepts that business requirements and business principles to be used in its ADM’s phase B “Business Architecture” come from “somewhere” outside IT. This framework prefers to avoid discussing whether those requirements real ones or they are just wishes of individual executives, how these requirements relate to the corporate strategy, what the value they are supposed to bring to the company and so on.

One of the most popular driving motivations for EA existence and operations is the view-based descriptions of an architecture and EA particularly. This means that CFO, COO, CSO and other C-level and top-management level executives may have subjective opinions on EA and EA must provide for them despite some parts of these opinions can contradict each other. This clearly demonstrates a subordinate role of EA, which what maximum can do is to advise management. This means that Enterprise Architects, as they exist today, do not architect their enterprises – management does this. All observed aspects define, constrain and limit the role and value of EA from the corporate business viewpoint.

We frequently hear and read a lot of publications about how to convince business decision-makers to pay for establishing an EA practice in the company. We always curious how that company existed before without the EA practice? Yes, in many cases, EA brings some value to the company as well as EA is the first candidate for cuts when the company experiences financial difficulties. Does this mean that “value for money” delivered by EA is not that significant? Certainly, this is not a rule and many EA are just great. However, there are way too many cases in industries where EA’s “value for money” is not feasible.

People are getting an impression that thanks to modern wave of global digitalisation, technology penetrates in all ‘far and dark corners’ of the enterprise. This is true, but, so far, this effect has not changed the business perception about technology and EA in particular. The fundamental difference between EA/technology and business is still in that the former thinks and operates with concrete entities and values while the former deals with uncertainty, ambiguity, and try-and-see matters. For example, we know and work with Cloud for about a decade and practice Agile and DevOps a few years also. It seems that business has had enough time to form an opinion about these technology innovations (especially against given promises). One resent representative research (and we have heard the same from different executives practicing these innovations) states, “IT departments and their CIO miss out on their BU [M.P. – Business Unit] expectations… In general, business unit leaders have the feeling that their IT department and their CIO don’t understand the business challenges associated with the ongoing digital disruptions.

We think that the EA and its practice have contributed a big deal to this situation. We suggest that “somewhere outside IT”, which TOGAF uses for its “Business Architecture” design, has to be much more particular and strict in order to drive IT in line with business needs and expectations. TOGAF’s ADM cycles are not enough – there has to be a continuous business control over what IT is doing. Such form of control is known under the name of ‘delivery gateways’, but it requires an enhancement. The AoB’s Architectural Governance has to have an authoritative word to say in the reviews of intermediary and final deliverables at the ‘delivery gateways’. For example, an EA comes with an idea to move expensive corporate e-mail system in Cloud and CIO supports this. CIO allocates funds, the transition starts and lasts a few months (it is not a small company).

Finally, it is finished and works! Should business pay a bonus to IT for this? Well, it depends. In the early stages of this project, Business Architects of AoB would ask a few “non-technical” questions like these: “If the Cloud provider starts violating the SLA, what we will do?”, “If something going wrong with access to the Cloud network, will the company lose its electronic communication capability and what mitigation plan IT has in this case?” (as we know, Amazon had a global failure of its Cloud several times last year), “If we would need to move the e-mail system back into the company or to another provider, how much time it might take and for what cost? And, BTW, will we be able to use it then or the data format might be unreadable to us?”  Enough? Now, consider how many EAs would ask those questions and get answers before proposing described transition.

We do not confront AoB to EA – everyone has to conduct the business it does the best. We question the competence of EA in solving business challenges appearing and moving in the business environment. One of possible solutions to this problem is admitting the reality that we have Enterprise IT Architecture and positioning it in the right and controllable place in the enterprise system. The AoB does this.

AoB Business Architects, working in the Practice of Architecture of Business, transform corporate strategy into the structure of business capabilities required to realise the strategy and, at the same time, to adapt accelerating changes in the market. The outcome of this work is the architected TOM. This practice is the only instrument in an enterprise, which is dedicated and shaped for architecting business, regardless who does this work – executives or special professionals. A business capability 1) comprises business functionality and all resources needed for the realisation and execution of this functionality, and 2) couples with continuous control/monitoring of the availability of these resources inside and/or outside the enterprise.

The IT with EA and all other technology architectures (application, data, infrastructure, etc.) is one of the capability’s resources. EA is definitely needed for administrating technology assets and IT capabilities, which will be used for the resource planning, updates, improvements and adaption of related innovations. Thus, there is no contradiction between AoB and EA. Instead, we have an organic composition of professional decisioning at the corporate level about what the business should do and what the technology means have to support the organisation in its strategic movement in the market.

Return to AoB