Are any of these questions familiar? 

How can:

My team support projects using agile delivery practises and respond to the organisation’s need to implement IT solutions quickly?

My small team become more efficient and address high workloads without having to hire a large numbers of contractors?

My team ensure vendors align to the organisation’s strategic direction?

The quality of our solutions be improved or increased?

In my experience, these questions are typical of some of the concerns that keep Architecture Managers and Chief Architects up at night. Particularly so if the architecture team or function is relatively new to an organisation.

 

Here are several tactics that I’ve found useful to address these concerns:

 

Being agile, harvest what you have

Most organisations can’t sit around waiting for the completion of a Big Up Front Design (BUFD) architecture exercise, particularly if they are responding to business pressures and demands using agile practises. One way for an architecture team to address this demand is by establishing an architectural baseline. 

 

An architectural baseline is a pragmatic way of bootstrapping the process to develop a more complete organisation-specific reference architecture. You can do this by using your existing current state as a springboard, while you continue to deliver projects and not wait for the completion of a BUFD. This will help reduce the number of decisions an architect faces whilst giving them the head space so they can focus on the real business problems. This is not a replacement for the definition of a future state or transition planning, and what it looks like depends on your needs and current state of maturity.

 

How do you establish an architectural baseline? Organisations typically have a wealth of architectural and solution investments that successive projects have deployed. These can be a treasure trove of architectural and solution building blocks. The blocks you select can be harvested and combined with available architecture reference models e.g. TOGAF SOA architecture, patterns and common technology standards to form the beginnings of an organisation-specific reference architecture. The key is to take an incremental approach whilst balancing the need to build a usable architectural baseline quickly. You need to be careful to assess the quality of the available building blocks. Following this approach takes time, but is also a lower risk and cost alternative, especially if you can’t afford the expense and the time of a top-down architectural assessment and development exercise as it builds on what is successful in the organisation.

 

Answer the ‘who cares’ question

It’s not uncommon for architecture and the role of the architect to be poorly understood within an organisation (both in the business and IT). It can be seen as an irrelevance, a box ticking exercise, a bureaucratic roadblock or as a technology janitorial service.

 

The key to getting past this is assessing two aspects of your practise. First take a critical look at your current engagement style. When you boil it down there are three basic engagement styles that you see an architecture team following. At a high level, these are:

 

1. Helping to build IT stuff

This is the most rudimentary level of architectural engagement and a very common technology focused operating model for architecture teams. Here you are competing with vendors and contract architects for the right to do your job.

 

2. Helping to build the right IT stuff in the right way

This is an advance on just building IT stuff, the team brings value to a business with standards and structure around the architectural efforts of a team.

 

3. Helping to plan for the future

This is where the architecture team is fully engaged in assisting the business with preparing for the future and is seen as a valuable partner to the business.

 

Each level requires an increasing amount of trust and co-operation between the architecture team and business management and one level builds on the next.

 

The second aspect to assess is your depth of understanding of the business. You need to have a good hard look at whether your understanding is just about the IT systems a business operates, or the business itself. Knowing about the systems isn’t a substitute for understanding a business. You have to work actively to improve your understanding of the business, the concerns of your key stakeholders, the business operating model(s) and the unique business capabilities a business has. When you have some understanding of these it’s easier to have a meaningful discussion with a business owner about the value of architecture, as you are able to frame architecture in a context they’ll understand and will be talking in their language.

 

Letting others help

Another tactic is to bring in experienced, outside assistance. Some teams don’t like this approach as they perceive this to be a sign that they aren’t seen to be up to scratch. This is the wrong way to look at it. Many businesses hire specialist external assistance to review a business or business unit’s functional capability, structure, performance and recommend improvements. An architecture team will benefit in exactly the same way. An experienced outsider will provide valuable mentorship and an independent perspective. They will have a proven architectural and managerial track record, be pragmatic and have the credibility and experience to make a real difference. In comparison, sending a team on a TOGAF course or giving them designations such as ‘Domain Architect’, or arming the team with a document template is largely window dressing if it’s not followed up with a clear strategy and business plan. The strategy and plan must take into account:

 

  • current and future resource demands,
  • resourcing and funding models,
  • business and vendor relationships,
  • team structure,
  • experience levels within the team,
  • the range of architectural services provided,
  • maturity and value of practices and processes,
  • toolsets, architectural collateral etc.

 

The strategy and business plan must be broken down into realistic, incremental steps. To be truly effective, it must start from an understanding of what architecture means to the business as a whole and the business expectations and demands of architecture.

 

- Matt