The responsibility of architecture is to create an architecture of responsibility

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.

Comments

• Anonymous
  March 09, 2011
  Hi Nick,    I have a feeling that currently your are documenting my recent experience. Thanks, I don't have to do it:) To be more concrete, I decided to put down my own case on responsibilities topic: ondrejgalik.wordpress.com/.../architecture-of-responsibility-case-study cheers O.

• Anonymous
  March 10, 2011
  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).

• Anonymous
  March 12, 2011
  You might want to take a look at: hjvantil.amplify.com/.../an-architecture-of-be-having Follow - if you want - the link to meet my thoughts on the subject.

• Anonymous
  March 15, 2011
  The comment has been removed

• Anonymous
  March 15, 2011
  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