Jiri’s Notepad

This is a second post in a series on project architecture governance. 

Single, individual responsibility for identification and agreement of the key aspects of the solution is important within a project but also at its interface to the rest of the world outside a project. Large projects need to be very clear at separation of accountability for various roles:

• Architecture authority is responsible for the solution,
• Business authority is responsible for business design and identification of business requirements, which is effectively representing interests of business users and 
• Live support authority is responsible for identification of support requirements and represents interests of the operational community.

Accountability and separation of roles simplifies conflict resolution that is inevitably be necessary sometimes during the project.

What sounds simple can be surprising difficult expected in an organisational context. The number of people involved in requirements, architecture definition and delivery phases of a large programme can be big. Often they will be coming from different business units, sometimes from different organisations, which can easily lead to gaps, overlaps and disagreements about the scope and responsibility.

Architects often then get into a tricky position they advise other parts of the organisation. In a way even if their scope of accountability is the solution, the scope within which they work is much broader.

Because architects are natural ‘integrators’, they talk a lot with people in other parts of the organisation. In this role, it is important for architects to be helpful for various parts of the organisation.  One of the trickiest parts of the job is how to balance the amount of work they do for individual communities they deal with – business, project, support. This is probably one of those things that can be explained, but which are very difficult to teach and come from variety of experience.