ImageIasa works with organizations regularly that are working under a false presumption. They regularly hire the wrong number of architects based on flawed assumptions. This leaves the teams over-whelmed with requests, requires they function only as rubber-stamp approvers, and puts the entire architecture initiative at risk. Why is that? Because architecture value, like all professional value, is pro-active not re-active. Think of it this way. What if you went to see a building architect and paid him $50,000 and he said, “Great! Now go off and do designs and I will review them and tell you if they are any good on a milestone basis.” You would likely immediately ask for your money back. This is the situation most architecture teams find themselves in. They have 3-50 projects to review and approve but do not have time to work directly on any of them.
So how many architects should you have then? Let’s dig into this a bit. The optimum situation would be to have a full-time architect per concurrent project. So if your organization runs 2000 concurrent projects you would have 2000 architects! Probably not too realistic for any organization I am aware of. Fortunately, there a number of ways to reduce this number drastically while still showing extreme business value as an EA team.

  1. Break your portfolio into 5 levels of importance
  2. Decide how many architects you need for the top 1-3 tiers
  3. Train an extended team to handle the lower tiers
  4. Evaluate how many ‘models’ of the enterprise are needed
  5. Select key projects for pro-active vs re-active engagement
  6. Reduce the number of projects through the PMO
  7. Publish smaller releases more often – the Agile Approach

Let’s take these 1 by 1. Items 1-3 are all related and are easily the most common approach I have seen to redesigning architect engagement in a formal capacity.
Step 1 and 2: The first step in redesigning for proactive engagement is to determine what you should be proactive on. This means that you should look at your current project portfolio. How many different projects (items with an assigned staff, timeline and budget) does your organization work on concurrently? Most very large companies have between 500-2000 concurrent projects across the enterprise based on my experience. These projects can be grouped based on what we call architectural priority. Priority means the degree of proactive engagement necessary to optimize the technology strategy. In general, the easiest way to prioritize these in the architecture team is to have the team rate each project on the following prioritization areas:

  1. Strategic importance – how much will this impact the companies bottom line revenue (not just cost savings)?
  2. Technical complexity – how hard, new, complex, risky is the technology element?
  3. Business complexity – how complicated is the domain (DNA splicing vs retail sales)?
  4. Innovation opportunities – how much can the architect team contribute to driving value?
  5. Risk – how risky is the project?
  6. Budget – how large is the budget?
  7. Project complexity – how complex is the project team, environment, etc?

After ranking these on a scale of 1-5 for the entire team you can average out the responses. This will give your team a very solid grasp of how to rank the projects in terms of priority on a scale of 1-5. Number 1 projects (highest priority) should always have a pro-active architect. In my experience this will be between 5-10% of the total portfolio. Level 5 projects almost never need a full time architect as they are often akin to the old anecdote about building a dog house. They should account for around 20% of the portfolio. The rest will fall somewhere in between and this is where your team size comes in.
Step 3: I will be doing an extended post about Extended Architecture Teams seperate from this post but it boils down to doing architecture work with non-architects. Development leads do the designs, PMs do the scoping and impact analysis, business analysts do the value management pieces, etc. Using an extended team is the most common means that organizations have today in dealing with large project portfolios. The problem is that most organization do not give the extended team the skills they need to be successful. Architectural thinking and skills are not in-born, they must be learned. (WARNING: Iasa Sales Pitch!!) If you are using an extended team to do signficant architecture work, you can drastically increase project success and individual success by training them to do it. Iasa offers non-architect extended team training for just this reason. (END Sales Pitch).
Step 4: This is a new area we are evaluating. Expect to see some surveys coming your way on estimation mechanisms for this activity. Basically this describes what. If part of the architecture team’s responsibility is to maintain the future state architecture repository, then it should be possible to understand how big that repository is supposed to be based on business domain and company size. This would include technical, business, information and software models. Many of these would be updated as a part of the project load but some would need to be maintained outside of that. The only issue with this is that it would increase team size instead of decreasing it. We are looking to run some research on what model repositories would look like for different types of businesses and sizes.
Step 5: This method is extremely important and can be related to Steps 1-3 but is somewhat less rigorous. Easiest way to manage team size and understand how many architects you need is to understand the business capabilities of your organization and then apply architects to the most important elements for the business.
Step 6: Good enterprise architecture and a good PMO go hand in hand. Build a solid relationship with the PMO and begin influencing the sizing of projects to better match with your team size and skill set.
Step 7: This method is a full couple of posts on its own. In some ways it increases the number of launches per quarter but it also allows for more creative assignments and ownership by role. Keep your eyes out for a post on Agile EA here.
So there it is, some actionable steps to better align your engagement model with pro-active architecture development. Organizations that use these steps will achieve a much greater value proposition, quicker turn around on projects and more satisfied partners. The program of objective engagement models will allow your team to demonstrate value instead of being a roadblock to success.