www.flickr.com
This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace
« Get out there! | Main | The Purpose of Enterprise Architecture »
Saturday
Aug052006

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 savvy 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 organization doesn’t have them then organize them!)
The TOGAF ADM will do!

Get some artifacts
In this case, we had more artifacts 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 well endowed you are with architectural artifacts, there will always be a job to identify what is appropriate for your audience and to create or customize 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.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>