Jiri’s Notepad

This is the third part in the series on project architecture governance. The first part introduces the subject and the second part outlines accountability as the principle on which the governance is built. In this part I am finally getting to organisation arrangements that you need to put in place for governance to be successful.

Organisation structure
To exercise accountability, you need some kind of organisation structure. There are few places in the organisation structure of an IT department where the most people responsible for architecture governance can be sit: When most of the projects are relatively small, architecture governance can be run on the corporate level, in which case, projects are responsible for the design & build. Large programmes may be on the other hand need constant care and attention, and so federating the governance function into the programme is a good option.

Architecture governance is very much about roles and responsibilities. A picture says often more than a thousand words, and so I include a picture that shows a rather typical organisation structure for a large programme from an architecture governance perspective.

Architecture board
Architecture board approves and owns the vision for the overall solution. In addition to that, it is the ultimate decision maker. It advises the programme director and the programme board on solution-related aspects. It is chaired by the lead project architect and to ensure balanced view of the overall solution it needs to have members from all key communities:

• Business community will be represented by a representative of the business requirements authority. In most cases this will be either a business ’super-user’ or or business design authority.
• Service support community will typically be represented by a receiving manager or service manager responsible for the ongoing delivery of live support for the solutions in scope.

Programme architecture team
Programme architectects are the permanent team that supports the architecture board. It develops the future vision responding to the customer needs and identifies how the key elements underpinning the vision will be achieved through delivery activities and projects. It will typically identify the scope of solutions, relevant design principles and guidelines and key architecture-relevant functional and non-functional requirements.

If the programme architects team proves helpful to the programme, it can carry out a number of additional secondary activities, such as  

• Scope and requirements management,
• Leading changes to the vision and shaping solutions to significant new requirements;
• Approval of product selection undertaken by the programme from fit-for-purpose perspective;
• Interviewing and vetting key project architects and lead developers;
• Key contributor to the identification and resolution of programme risk & issues;
• Technical assurance including review and sign-off of key project architectures and designs.

Project architects
Whereas smaller projects you may have only one or two architects responsible for defining the overall solution, in large programmes, there may have architects associated with every project team. Project architects on large programme will be responsible for quite a few things, including product selection, identification of technical requirements or definition of the solution. Project architects will typically oversee the delivery of the solutions they define through the later phases of project lifecycle and do a fair bit of technical management.

Design steering group
On large programmes, tightly-coupled solution components often get delivered by different projects or delivery streams. Design steering group serves as a cross-project forum to discuss and resolve these technical inter-project dependencies.

Setting up your own structures
The roles and responsibilities mentioned in this post are just an example. Each IT organisation and every project are slightly different. Therefore it is quite possible that the roles you will have on your project will be slightly different. If that is the case, you may not want to just replicate the organisation I described above, but rather check that you apply the accountability and participation principles I outlined last time.