Jiri’s Notepad

What is the appropriate level of architecture team resourcing? The answer to this question depends on few factors. Unsurprisingly, I have found out the number of architects required will fluctuate depending on the nature of the project but it will also vary between individual stages within in a project lifecycle.

Firstly, who is an architect

There is a serious confusion about the use of the term ‘architect’. As the title has become quite fashionable, it is improtant to baseline the definition of the term architect for the analysis to be meaningful. You may consider the musings below as elitist nit-picking, but without some clarity on the scope of the role, the numbers of project architects would be pretty meaningless.

Few people tried to standardise the expectation for the IT architect role but perhaps the best attempt I came across is the one by The Open Group. So my criteria for who is an architect from the core skill set required for OpenGroup IT architect certification. The architect skill set is rather broad ranging, so to make the distinction easier, I identified the key job responsibilities that based on my experience most frequently divide architects from other technology folks.

So for me, the architect is someone whose main responsibility or accountability is:

• To elicit strategic or functional requirements and
• Identify and agree non-functional requirements and
• Identify strategic or high-level design options and their cost implications or
• Provide assurance over the activities above

This distinguishes architect from other technology staff, who are:

• Solely responsible for managing development, test and deployment (technical manager)
• Primarily responsible for producing detailed design, component configuration or development (designer, developer or engineer).

Secondly, what development lifecycle am I talking about

For the sake of the argument, let us base the lifecycle used based on the model used by RUP. At the macro level most system lifecycles are similar, so this really should be translateable to other development methods too.

• Individual RUP phases cover roughly the following architecture activities
• Inception: Scope the project, define the business case and key requirements. In addition to the out of the box RUP, this model includes development of conceptual and logical architecture in the scope of this phase
• Elaboration: Refine requirements, establish an architecture, mitigate most technical risk
• Construction: Complete the system up to a point where it can be deployed in a limited context (pilot)
• Transition: Finish the product and reach its final release

So what is the right number of architects for a project?

The below is based on analysis of data from few large scale (£200m+) design&build application and infrastructure programmes. The sample is probably not statistically significant, but I believe it still gives some good indication of what is reasonable.

During architecture and inception phases when the work focuses primarily on the shaping the context and development of conceptual and logical architecture, the ‘right’ number of architects is commensurate to the expected scale of the target programme being scoped out. In practice this number will be influenced by the timebox within which scoping activities need to take place. Although there is no lower limit to the number of architects involved at this stage, the evidence seem to suggest that in practice, there is an upper limit of 15 staff at which an architects can effectively function as a cohesive team.

During elaboration to construction stages, the scope for pure enterprise architecture diminishes and as the project proceeds through the life-cycle, architects take on more and more technical management responsibility. During delivery, the number of architects is primarily driven by the overall volume of engineering effort, which can be with some simplification correlated with a number of new or significantly re-designed conceptual services (solution areas) under active development. In these project stages, architects get divided between delivery and assurance functions, with the delivery function primarily driving the size of the virtual team. Data indicate a delivery architect will be on average addressing five conceptual services during elaboration and two conceptual services during construction phases. A programme with 50 conceptual services can therefore have up to 10 key delivery architects during elaboration and 25 architects during construction. Data also indicates that there is a correlation between also have a partial technical management responsibilities; a typical ratio of an architect to development staff is 1 to 7.

Secondly, there is more to the successful architecture contribution to programme delivery than the total number of delivery architects. Architects often fulfil both delivery and assurance or governance role within a project and to ensure sufficient checks and balances, architecture assurance and governance functions need to get adequate staffing. What is it? The diagram below illustrates an illustrative split of resource levels for various architect roles in a large scale programme.

Adding up assurance and governance resources (security, enterprise architecture and technical assurance) and delivery resources (project and environments architecture) and comparing these two reveals there is an ideal ratio for assurance / governance and delivery architecture functions, but that it is not static during the lifecycle of the project. During the architecture and inception phases the ideal ratio of assurance/governance and delivery architects is 1:1, during elaboration to transition it changes to 1:3.

Obviously the ratios above represent resource levels that are to an extent ideal. In practice, there will be budgetary constraints on the number of staff possible to recruit, resolution of which will require creative strategies including delegation of architecture effort to suppliers, increasing the utilisation of available resources or changing timescales of the project to fit with the lower resource numbers.

Also the above does not address the quality of the staff that is IMHO absolute key to the success of an architecture engagement. But about that some other time.