6 years, 7 months ago

7 Practices for Growing a High Performance Architecture Team

A-teamThat’s A-Team team to you, sucka! 

With the disruptions in the tech industry caused by the cloud, social, data, mobility, and security, the demand for architecture is increasing. Gartner predicts that the number of architecture practitioners under the age of 30 will triple by 2017 but 70% of large organizations will struggle to attract and retain their architects. (subscription required)

My immediate reaction is ‘where will they get all the architects?’ Anyone who’s tried to hire for one of these roles knows that there are many people who have architects in their title or claim to have architected a project with very little understanding of what architecture is about. The last time I hired for a role, I went through a legion of candidates who couldn’t answer even a basic question, such as “which architecture deliverable have you found provides the most value?”

With the shortage of experienced architects in the industry, it almost goes without saying that you will have to grow your architecture team. If you’re like me, you may find yourself inheriting a motley crew of former business analysts, project managers, and engineers who’ve been unceremoniously told that they’re now “architects.”

I’ve seen organizations try to grow their architects by developing extensive training materials, send them to training programs, there’s even degree programs now. The challenge, of course, is that architecture is a somewhat abstract discipline and each problem space is different. The art of architecture is largely developed through experience. I’ve found that if you can put in place the right, structured approach you can overcome the challenge of lack of experience and help grow a high performing team.  

Below are practices which have helped me to develop high performance architecture teams.

  1. Position Architecture Within IT Delivery

Whether your architecture group is responsible for articulating IT strategy and influencing the portfolio or developing solution designs, architecture needs to be placed within the context of the IT delivery process. Many architecture groups consider themselves “consultants,” where their engagement can be optional. In general, this is a recipe for being bypassed since many IT projects will not want to be bogged down with extra costs and delay from engaging architects. There is a risk, of course, that the volume of work may exceed the capacity of the architecture team but this can be mitigated by setting criteria for what projects the team will work on, focusing on those that carry the most business impact or risk.

  1. Pick a Framework

There are religious debates in the architecture community about the value of frameworks in general or which frameworks are superior to others. Ignore the noise and look for the framework that resonates best for your organization. A framework is essentially your architectural toolbox – you want to pick one that breaks down complexity into simpler aspects and prescribes tools for understanding that aspect. A good framework should be agnostic of a process. Understand that frameworks are just toolboxes and they have limitations – you may need to customize or tweak it to make it work with your organization. That’s okay – just stay consistent through your execution. I personally am a fan of the Integrated Architecture Framework (IAF) developed by Cap Gemini which meets the criteria I’ve outlined above.

  1. Define Your Architecture Process

Like frameworks, there is no right or wrong answer except for picking something that works for your organization. TOGAF provides a very robust process but you may want to go with something more lightweight. Like all analytical processes, it will probably look something like this:


The initiation phase is where you define the problem you’re trying to solve and its scope; the approach that you will use and the deliverables that will get produced.

Just as it sounds, the data collection phase will be where your architects are gathering the data necessary for their analysis. This might be understanding current state, dependencies, future state roadmaps, and other information important to the analysis.

Analysis and Synthesis is where the data is pulled together and the solution design is developed.

Readout and Recommendations phase is where you provide your analysis to your stakeholders and agree to a move forward plan.

This is a simplistic linear view. In execution, this may be far more iterative between phases.

  1. Run Architecture Engagements Like Projects

Treat architecture engagements like other IT projects where the focus is delivery of architecture deliverables. This means for each engagement, there is a plan with defined resources, deliverables and budget and there is reporting on a regular basis of how the engagement is faring with respect to budget, timeline, and resources. This allows architecture to more closely resemble other IT delivery activities and provides a structure for making architecture delivery more predictable and consistent.

  1. Coach Architects Through Initiation and Analysis

Inexperienced architects will struggle the most with initiation and analysis phases, where the art of architecture plays a significant role in the success of the project. This is where you will want to have experienced architects work closely to help define the approach to the engagement, demonstrating how the framework can be used to identify the appropriate deliverables. This helps tremendously because it’s rare for inexperienced architects to struggle with developing deliverables once they are clearly defined. Similarly, experienced architects can help provide the appropriate perspective in the analysis phase, where inexperienced architects may lean towards tactical instead of strategic solutions.

If you find yourself in a situation without any experienced architects, including yourself, then make these coaching exercises a group one where you can leverage the collective wisdom of the team. This allows the group to mature together in their understanding.

  1. Embrace Architecture Principles

At the beginning of an architecture journey, there is not a lot by way of reference architecture and standards to draw from. In this environment, principles become a critical factor in driving early direction, providing a set of guidelines to the team to make the right decisions in line with your architectural direction.

  1. Make Post-Project Reviews Part of Your DNA

Each architecture project will be different but the more you can expose your team to the choices made during the engagement, the faster they can mature their understanding of what to do. After each project, have the architect report back to the team:

  • What was the problem that they were trying to solve?
  • What approach did they follow? Which deliverables were used?
  • Was the approach successful? What did they learn? What would they change?

Archive these sessions in a repository so that the team can leverage them to inform future projects.

Developing a successful team isn’t easy but providing structure, you can grow an “A-Team” of architects.