Chief Architect

I have posted a link to Serge Thorn's excellent enterprise architecture discussion group in the Enterprise Architecture Resources.  The following toics are a snapshot of the type of content typically discussed:

• EA and MBA
• Training opportunities in India
• Building an EA Practice from scratch
• Where should the Enterprise Architect's focus?
• Government Interoperability Framework (GIF) and National Enterprise Architecture (NEA)
• Location of the architect in the organization
• The Big Eleplant of Enterprise Architecture 

There is also a good list of enterprise architecture blogs on the site which are well worth browsing.

Recently, I was working with Steve Ross-Talbot for a new client. We received a large number of documents describing the architecture that was to be implemented.

I noticed that, in order to assimilate this information, he took the same approach that I did which was to abstract the information upwards into a single simple diagram that captured the entire architecture in about seven blobs. He then took each blob and exploded this into further diagrams each with about seven blobs until he had an understanding of the problem area.  The result was a concise and easily comprehensible story at increasing levels of detail that was easier to follow and understand than the original.

We had a discussion about this and noted that in our experience we rarely see architects develop simple sequences of structured diagrams that tell a comprehensible and compelling story.  Instead we see diagrams with confusing inconsistencies in style and far too much information.  A set of diagrams should tell a story - there should be an obvious start, middle and end.  They should stand alone without the need for a narrator - a picture should not require a thousand words to explain it.

Rather than put my own tips for diagramming, I have deferred to an expert and added a link on the site to "Whiteboards that Work” by Bill Branson which contains a range of communication best practices.

When you encounter something that feels wrong, what do you do? Do you think, the guy that did it must know what he is doing? Do you think, it's none of my business? Do you think, I'm not getting involved in those politics? Do you think, I'll let him hang himself? Do you think, I'm busy right now?

Or do you think to yourself, that looks wrong, I'm going to take some time out and investigate. When you find there is a problem, do you then get involved and try to resolve the situation?

When you join an organization, you sign up to its objectives. If anything contradicts those objectives then your duty is to take responsibility, get involved and do what you can to get a resolution. You don't need permission to do the right thing.

This behavior is a particular requirement for an architect. A good architect will see the big picture when others will not. The architect will see the unintended consequences of decisions and actions. What is important is the action that follows. The knowledge, the contacts, the courage and the influencing skills are critical to getting people to change direction and correct mistakes.

This is the expectation that I have had of the architects that have worked for me. When an issue arises, my question is, what is the right thing to do? And that is what we try to do. Sometimes we fail and we make an new entry in the “I told you so book” or perhaps it should be called the “I failed to convinced you book”.

You don't need permission to do the right thing but you may need friends and political skills.

A good architect will engage in a thinking process that generates creative synergies, brilliant shortcuts and identifies the serious issues well ahead of time. This process also produces spurious ideas and seemingly irrelevant issues. You can't have one without the other.

Most people have to resort to special thinking techniques to think laterally, it doesn't come naturally. An architect understands the broad context, an architect sees connections, an architect has a quick brain that will automatically explore the connections and context. An architect sees the bigger picture.

This attribute means that an architect will find routes to a solution that other will not. The architect will also find interesting sidetracks that may be time-consuming distractions or effective shortcuts. Sometimes an architect will find a route particularly interesting and forget the destimation.

The problem for an architecture manager in this situation is not how to generate creativity but how to harness it. There are some simple disciplines that need to be taught:

• Periodically remind yourself of the business goals
• Periodically ask yourself if you are off track
• In front of stakeholders, engage brain then open mouth

Enterprise architects are often accused of “living in ivory towers”. They complain that there work is ignored. Architecture teams have their numbers cut, they are abolished, their staff are scattered around the IT function to “where their skills can be applied usefully”, and architects can be seen as an expensive luxury that adds little value. A good concept that fails to deliver!

A good enterprise architect invariably has significant practical experience at the sharp end of systems development, service delivery, or in the business. Good architects maintain contact with their roots and they develop new ones. This is critical to the delivery of architecture – and we must always remember “architecture is pointless without delivery”.

An enterprise architect must have a range of practical skills covering data, applications, infrastructure and the business that they deliver to. The key here is practical. An architect achieves delivery through others. Those others must understand and respect the architectural guidance. This means that architects must have credibility when they advise on implementation.

The foundations for achieving this are experience, sound understanding of the principles, up to date knowledge, well worked through advice and good communication skills.

However, there are other key activities that we have to work at continually:

• Get out there in the business – I am out at the sharp end of the business at least once a month and I encourage my team to do the same. We need to see the reality of the people who make the money or deliver the service. We need to talk to them and understand their day to day problems. We need to understand the opportunities for improving performance where it counts. We need to observe the reality of the IT service that we have architected. We need to see how we have succeeded or failed. Our conversations with business managers and in IT will have more credibility.


• Get out there in IT – What is good for the business is good for IT. But here the opportunities to get involved and help are much greater. As architects, we have information, skills, knowledge and tools that can help in development and service delivery. We can take complex problems away and let development and service delivery team focus on their core tasks. If we offer to take a problem away then we must deliver, we must deliver on time, we must deliver a solution that is easy to take on. If we fail then we lose credibility. If succeed then we have people willing to follow our guidance. We also have advocates.


• Get out there amongst the managers – I want my architects talking to the Head of Internal Audit about business continuity. I want my architects talking to board directors about process improvement. I want my architects talking to the Strategy Director about business intelligence. I could take the credit; I could be in the meetings. But it is my team that deliver; it is my team that need the day to day relationships to be more effective. My team has a lot more bandwidth and capability than I have. My role is to facilitate their involvement, build their business and interpersonal skills, back them strongly when the going gets tough, help them to understand the politics, make sure that the whole team is coordinated, and to support and mentor them so they are effective.


• Follow through to delivery – Don’t walk away when the concept or the high level design has been communicated. If you do it will be corrupted, its integrity will be violated, or it will be discarded. However well you communicate, no one understands your ideas better than you do, and no one is more committed than you are. When you walk away and your advice falls apart, it is not because it was bad advice. It is usually because it lacked interpretation in the light of reality; it lacked a nuance that you could not have foretold. You needed to be there to make a small adjustment. You needed to be there to say “not in this situation”. You needed to be there to make sure that the job was completed properly. When your advice has been delivered to the business and is achieving benefits then you can move on.


• Be available – You can schedule yourself into meetings, and take a formal part in projects to get you out there. But you also need to be available when other people want you. There needs to be slack in the schedules to allow informal contact, there needs to be a service culture amongst the architects. We have 30 minute “surgeries” every morning for anyone who wants to turn up and talk.


• Be flexible – In order to get out there, we need to be flexible. Architects needs to cover for each other, architects need to shuffle the workload amongst themselves as a natural way of working. It is critical for me that the team is a self managing team. I set priorities, the team organise the workload to meet the needs without heavy planning.


• No silos - I got rid of job titles such as “project architect”, “data architect”, “infrastructure architect”, we only have enterprise architects. Everyone has a focus and I try to align this with aptitudes, interests and capabilities. But I expect everyone in my team to be credible cover for everyone else, my role is to grow the skills to accomplish this.