I cannot take credit for that aphorism… credit goes to Jan Van Til.  He coined the term after reading Tom Graves’ excellent post on the architecture of responsibility.  Tom’s post details the philosophical challenges of a responsibility-based economy.  However, I’d like to get a little more tactical in the Enterprise Architecture space, and discuss more of the “intra-company” and “intra-solution” aspects of “The Architecture of Responsibility.” 

One of the key accountabilities of Enterprise Architecture is to provide a mechanism to govern the development of corporate business capabilities. In other words, we want to make sure that specific capabilities are developed, in a principled manner, prioritized on the strategy of the business. 

When making that governance mechanism work, I find myself routinely dealing with the same issues that Tom outlines.  We do not select a system because of it’s technical prowess or smart operators.  We look at the capabilities needed by the business, and assign responsibility to the business team that is willing, able, positioned, and passionate about taking on the responsibility for that capability: shepherding and improving it, operating it effectively, remaining agile, while keeping a keen eye on both risk management and cost efficiencies. 

I’d like to point out a key aspect of governance.  It is not about assigning responsibility to a system or system component.  No one can govern the assignment of a responsibility to a system.  What can be governed, effectively, is the assignment of responsibility to a business unit.  That business unit can own information and the systems that manage it.  You need people to make governance work… not just to govern, but to be vested in the success of the “optimal architecture.”

Hence, the architecture of responsibility is the mapping of capabilities and business processes to people.  Sometimes that means consolidation to common processes, but not always.  That depends on the operating model of the business.  But always it is a problem if a particular capability within a business model has no owner.  Identifying the businesses within an enterprise, the capabilities within the business, and the owners of the capabilities… that is a key deliverable of Enterprise Architecture.

One that is not often discussed… but in the end, extraordinarily important.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

5 thoughts on “The responsibility of architecture is to create an architecture of responsibility”
  1. I think you made a very good point here, that is, the realisation of EA values. It is not only a cultural issue of an organisation and change of business and management practice, but also a problem of current architetcure practice, including EA, which often focusses on development of architetcure but is lacking interests or efforts to ensure successful applications of EA.

    As pointed out in  your previous post on the difference between Selling EA and Performing EA,  the concept of "architecture of responsibility" is to explicitly enforce the new practice of business and management. In fact, it is not new since, I believe, it has been implied in many EA frameworks or taught in their training courses.  

    Culture resistence and qaulity of EA are two main factors that jointly determine how the architetcure of responsibility works within an organisation.  Poorly developed EA is unlikely to be acceptable by business and management community.

    Architecture-driven or model-based planning and development is a common and well-known practice for IT community but not for business and management. To make the architecture of responsibility work, on the other hand,  EA and its frameworks or practice need to entend further into areas of handling business processes and complexity, and supporting environments, rather than only production of so-called various architectures (views, diagrams or models).

  2. Nick – great post. Especially, I strongly agree with this: "Hence, the architecture of responsibility is the mapping of capabilities and business processes to people" – because without that responsibility and commitment, not much will happen. 🙂

    One point I would quibble about: "We look at the capabilities needed by the business, and _assign responsibility to the business team_" [your emphasis]. In principle I agree that this is what it looks like on the surface, but there's a really subtle yet really serious booby-trap in there. This is where the overall operating-philosophy becomes quite critical. In an hierarchical model, responsibility is assigned to others downward within the hierarchy-tree: the act of assignment is assumed to create the drive and the responsibility to complete the assigned task. Very Taylorist: the magnanimous manager supposedly 'empowers' the 'workers' to do the task – and, as you suggest, often with a dangerous blurring of accountability and responsibility.

    But the key point is that empowerment doesn't work that way: instead, as Deming and others have shown us for decades, the power actually comes _from_ the 'worker', and the main task of the manager is to create conditions under which work _can_ happen, and then largely get out of the way. Similarly, responsibility cannot actually be 'assigned': instead, to be successful, is has to be taken up as a _personal_ commitment by the person to whom the responsibility is 'assigned' – otherwise what we get is a gloss of responsibility without much (if any) of the commitment and drive that are needed to make things happen. (Arbitrary 'assignment' of supposed responsibility without actual take-up is what drives 'presenteeism', for example.)

    Another useful key here is to split the word 'responsibility' into its two component parts: 'response-ability' – the ability to _choose_ appropriate responses in the context. So on its own, 'assigning' responsibility  will never be enough: we need to ensure that the person assigned the task has the _ability_ to do the assigned task, and _also_ has the commitment to complete it.

    So in practice, in enterprise-architectures, it will never be enough just to map out resources and capabilities and change-projects and the like: we need to ensure that the culture will support a take-up of personal responsibility. And that, as you say, is where governance comes in: but a governance of engagement rather than of arbitrary demand and 'assignment'.

  3. Hi Tom,

    Your answer is 100% correct.  This distinction is essential, and my post is incomplete without it.  I am in your debt for adding this critical clarification.

    — Nick

Leave a Reply

Your email address will not be published. Required fields are marked *

20 − 11 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.