Architectural Accountability

In various discussions on LinkedIn Groups – in Enterprise Architecture Network (EAN) and in Enterprise-Modeling (E-M) – and in commentary on a couple of my articles, there has been disagreement about the nature and scope of the accountability held by those architecting enterprises (AEs).

The most common line of thinking which is expressed is that AEs undertake design activities and that they must be accountable for the design that they develop (and recommend).  This is usually prompted by references that I might have made to the role of AE largely being one of facilitator and collaborator.

In a different discussion, there has also been debate over whether AEs should be accountable for business outcomes.  This discussion has troubled me because identification and agreement on business outcomes is an intrinsic part of my approach to AE.  

This article explores these issues and outlines the accountabilities that I would recommend should be applied to any AE.

Enterprise design

Executives and managers undertake enterprise design and will always be accountable for the design of the enterprise in which they are engaged.  It does not make sense to me to suggest that an AE “takes over” this accountability.

The founder of any enterprise is the initial architect of that enterprise.  As they engage others in their enterprise, and delegate various responsibilities, they continue to design their enterprise and engage others in this activity.  At the end of the day, the CEO will always be accountable for the architecture of the enterprise.

Imagine what any CEO or Executive might think when an AE approaches them and suggests that the AE will now be accountable for enterprise design!  They must wonder what sort of “upstart” would presume to know better or to take over an activity and responsibility that they would see as critical to their own role and responsibilities.

This is one of the reasons why I advocate an approach which recognises that enterprise design is a collaborative activity, to which an AE can make a contribution, but which is simply never likely to be “handed over” to another party.

Business outcomes

The comment which first caught my attention was “we must resist tying EA to business outcomes”.  Subsequent discussion brought out some different distinctions in relation to:

• accountability for business outcomes
• driving business outcomes
• delivering business outcomes
• linking to business outcomes

This seems to me to warrant some further exploration and some greater clarity about the activities and accountabilities of AEs.

Understanding the outputs and outcomes which an enterprise seeks to realise is critical to the design of the enterprise.  This is intrinsic to the activity of design.  If I am designing a car, I need to determine the characteristics of the cars that will be manufactured, and the intended use of the car.  Comfort, safety and other factors which are important to its use will influence the design (and construction of the car).  The same applies to enterprises.

One line of argument has been that business strategy determines the business outcomes.  If the business strategy is poor, then the business outcomes may not be achieved, and this would reflect on the AE if they have linked their work to business outcomes.

In fact, the discipline of making the business model and operating model explicit may well make flaws in the business strategy evident and prompt those who have developed the business strategy to review and revise it.  A common point at which this can occur is through the exploration of the operating model, determining the business capabilities required to realise the intended business outcomes.  This may make evident that particular business capabilities are missing or that more is required to strengthen particular business capabilities that are critical to the successful execution of the business strategy.

Other architectural domains

Some of the debates that I have encountered go back several years, and revolve around the understandings that we have of “architecture” and “architect”, particularly in relation to building architects.  For example, statements are made about:

• the requirement for registration of architects
• the accountability that a building architect holds for the building design

The inference made is that these are fundamental to the definition of architect and architecture, failing (imo) to appreciate that there are fundamental differences between the entities being designed, and thereby, the processes associated with their activities and responsibilities.

Regulation is required as a direct result of community need for safety – communities do not want buildings to collapse due to design faults, and require a range of processes to manage the risks associated with building design and construction.

Enterprises entail a fundamental difference – they are composed of people, each of whom can act in accord (or not) with the enterprise design, and each of whom have the autonomy to act in response to circumstances which might present adverse outcomes so as to avoid such outcomes.  The components of a building have no capacity to act autonomously and to respond to the unexpected or the unplanned.

AE accountability

If an AE is not accountable for the design of an enterprise, for what could or should they be accountable?  For what can an AE be appropriately and effectively held accountable, in an environment where Executives and Managers undertake activities associated with:

• enterprise design
• enterprise transformation (design realisation)

An AE deals with:

• enterprise integration 
• enterprise completeness
• distributed design

This involves the AE in:

• identifying gaps and weaknesses in the enterprise design
• identifying and recommending (but not approving) improvements to the enterprise design
• identifying and exploring options in relation to critical design decisions which may compromise the realisation of enterprise goals and aspirations and execution of business strategy

In all aspects of architecture and design, there are downstream realisation and operation activities which may compromise the outcomes which formed the basis of developing the architecture and design.  Where faults occur, there is always a need to determine whether the fault lies in the design, construction or operation.  For any participant, this entails consideration as to whether the faulty outputs are associated with faulty inputs (eg. poor business strategy), in which case there may not be any fault on the part of the particular participant.

The primary aspects of the architecture and design that an AE should be accountable for include:

• identification of enterprise architecture deficiencies
• outline of enterprise architecture improvement options
• establishment of processes which can offer greater assurance of enterprise design integrity and enterprise integration

This is one of a number of articles in the series “Enterprise architecture – digging deeper”.

Other series and articles can be found using the following index.

Arrange a Conversation