It’s not about numbers

Some years ago I was appointed as an interim manager to be Head of Architecture for a FTSE 100 company. The scope of my role was applications and infrastructure – business and data architecture was under another manager.

I had a team of 16 architects who had over the last nine months produced numerous architectural artifacts. They were very clever documents explaining all the options that had been evaluated, the evaluation process, the decisions made, and the reasons for each decision.

The team had lost its direction; it had done a lot of abstract architecting but nothing (zero, ziltch, nada, nix, diddly, zip) had been delivered. There was no plan to achieve delivery. Now was the time to get active and use this stuff to shape the IT service delivered to the business. We needed to get the application and infrastructure implementation teams to deliver the architectural vision that had been so painstakingly developed.

How did we get there?

  1. Get the right people
  2. Understand your customer
  3. Get a process
  4. Get some architectural artifacts to support the process

The Right People
I wanted architects who had the following traits:

  • Understanding of the business
  • Rapport with managers, users, developers and infrastructure staff
  • Verbal and written communications skills
  • Technical knowledge
  • Pragmatism
  • Bravery
  • Ability to operate with minimal supervision

I interviewed the team and I moved 12 out of 16 out of the team. Yes, that’s right I was left with 4 team members. I now had a strong core team capable of being a high performance self managing team.

Who is the customer?
As enterprise architects we have a complex customer base. Our aim, like all people working for the organization, is to help achieve the aims of the board of directors. An effective architecture team is visible at this level and has to be mindful of the impressions created at this level. For example, expensive resource that cause delay to business change will not last very long.

The business middle management implement change, applications are just a part of the change they are delivering. Sometimes they are parochial, narrowly focused, and often highly political. They have the ear of the directors and can make or break architecture and architects. You have to play the long game, sometimes compromising on minor details to ensure that the major gains from architecture are not lost.

The users experience the results of architecture. They have the ear of their management, they too can make or break architecture. It is absolutely essential that solutions are usable when they get into the hands of users. You cannot blame the developers for poor implementation, you cannot blame managers for cutting the budget. If the solution doesn’t deliver for the users then the architect is to blame.

Architects don’t implement, other IT staff or contractors or consultants or outsource partners do that. They consume architecture and deliver applications and infrastructure solutions that should meet the needs of the business. Get architecture right and delivery is quicker, cheaper and higher quality.

Get a process
The keys to the process are:

  • Put the most effort where there is the most risk to the business – you need a triage procedure.
  • Get in at the beginning (or before that if you can) of a project
  • Understand project requirements
  • Ensure that the project is aligned to business goals (if you don’t do this then you are not an enterprise architect)
  • Guide the design so that it fits as best it can with the enterprise IT direction – make rational compromises, make sure that IT and business management understand the compromises (this also builds credibility as business aware pragmatists)
  • Keep tabs on delivery in a non intrusive, non obstructive, non policing way e.g. be available to give advice throughout delivery, be a “free” additional project resource
  • Be present at the post implementation review and benefits review (if your organisation doesn’t have them then organise them!)

Get some artefacts
In this case, we had more artefacts than we needed. We had to make them digestible, intelligible and interesting to our customers who were not architects. A three inch thick document making technical recommendations can be reduced to a single page with the decisions. Our work was finding the relevant facts for each of our customers at each stage of the process.

In other organizations, I have started with no artifacts. That didn’t stop us working with projects, we just delivered the key artifacts that we needed as we went along. You may have to work long hours but you don’t waste your time producing superfluous documents.

However many architectural artefacts you have there will always be a job to identify what is appropriate for your audience and to create or customise a deliverable to meet their needs.

How did we do?
We moved from academia to providing value to projects and securing service delivery inside 2 months. Five of the right architects were delivering more value than a team of 17 had previously. It’s not about numbers; it’s about the right people doing the right thing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s