Chief Architect

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.

Joe McKendrick asked why Europe seems to be ahead of North America in EA. John Michelsen asks is Europe ahead in SOA. Ronald Schmelzer thinks that the USA is not behind but its not ahead either.

From my European perspective, this is an odd debate. I have the impression that a lot more money has gone in to enterprise architecture over the last 10 years in the USA particularly from government. Obviously, this has not been the case across the board but the struggling American architecture manager has not had a very high profile.

If you have millions of dollars and years to deliver then what pressure is there to be pragmatic? This has meant that the dominant approaches to Enterprise Architecture are Big Architecture Up Front approaches. Where architecture has had less acceptance and less money, we have had to evolve alternative ways of achieving our goals. We have had to develop creative approaches to making our money go further.

If I am right then, what we may be seeing in action is natural selection. Perhaps the reason that we can move ahead more quickly with SOA is that we are more focused on delivering benefits, we have had to be more pragmatic, and we have had to work out how to move incrementally down a strategic path. Because we have been under greater environmental stress, we have evolved enhanced capabilities to manage architecture effectively, to demonstrate its direct business benefits and now our SOA initiatives are reaping the benefits.

One of the readers of this blog wrote ... "I'm a Technical Architect for a software/services organisation and have recently begun an MBA at a top business school, ideally I'd like to move into an EA role soon, but I'm unsure about the next step do you have any advice?"

I do a lot of recruiting and I find it very difficult to find the right balance of depth of breadth.  My guess is that as a technical architect, you will have depth in some technical domain.  The first piece of advice is don't lose this.

The MBA is a good move.  It looks good on the resume, it gives broader business and management skills.  Make sure you network with other people from the course.  Talking to a marketeer makes marketing theory more real.  A note of caution - a standard interview question for MBA graduates - "you have an MBA, what makes you think we can satisfy your potential?"

Build the breadth - you need to get some experience and knowledge of the business, information, application and infrastructure domains.

I would suggest joining an end user company.  There is often more flexibility to expand experience and take repsonsibility in new areas.  It also gives a different perspective on organisational politics.  Having end user is valuable if you want to go back into consulting.

Build the people skills.  You need to be able to stand up in front of senior management and clients with confidence.  You can get the techniques and tips from courses and books.  The real learning is by doing - if this area is difficult then start small with unthreatening audiences and move up over time.

So, to pass my interview process for an EA...

1. technical depth in one area eg integration or data architecture, I expect multiple products
2. some experience of all the EA domains
3. business understanding in at least one industry (I don't care which, I just expect you to be able to talk credibly to business people)
4. people skills
5. commercial and financial skills are a bonus.
   

You probably know why I find it tough to recruit now!

You have delivered the business, information and systems architecture for a $100M change program, led the design authority and seen your organization through a step change in its operations on an enterprise scale. You have led major business change affecting 10,000s of employees. This is the third time you have done it. You know what you are doing. The head-hunters keep calling asking you do it again some place else. What do you do?

Chief Architect

Do you want more of the same? If the answer is “yes” then you have to evaluate whether your organization can give it. Often, an organization will pause for a couple of years after a major change before engaging on the next round. What will your role be during this “steady state” period? Will you be positioned correctly when the change kicks off? Your experience will tell you that those discussions are already happening – are you involved in them now or can you get involved? If you don’t shape the change from its inception then the chief architect next time around may be a consultant or an “outsider”.

Alternatively, you talk to the head-hunters. You follow up on some of their opportunities. Invariably, the roles are smaller, your compensation expectations are too high, you don’t believe in your potential new boss, moving away from home doesn't suit, or the role just doesn't excite you.

You are in a box as a “chief architect”. But, as an experienced chief architect, you have a huge amount of senior level business and IT experience that looks like it is about to go to waste. Maybe, you should look at alternatives…

Head of Architecture

Sometimes, the Head of Architecture and the chief architect are different people. The difference is that the chief architect is “responsible” and the Head of Architecture is “accountable”. The chief architect reports to the Head of Architecture who is typically on the senior management team of IT and sometimes of the organization.

The Head of Architecture is a manager (and hopefully a leader). They should be a business person first and an architect second. The Head of Architecture faces outwards into the business and into the management organization. They drive architecture to deliver for the business. They create the space for architecture to be effective. It is a political role.

The extensive knowledge of architecture that being a chief architect provides is vital knowledge. But the key capabilities are the business, management, leadership and political skills that will have been developed in driving through successful organizational change.

If you want to make the switch, then you need to have your eyes open to the different emphasis of your role. Not all your staff or management team peers or even your boss may understand the difference in the roles. There may be pressure for you to be the chief architect and also the head of architecture. I don’t believe that this is sustainable; I have talked about architecture being led by a two headed monster elsewhere. It is a balancing act.

CTO

What is a CTO?

Anton Chuvakin uses this definition …

"the great CTOs usually can’t manage their way out of a paper bag, but

• have huge vision,
• the ability to pull an all-nighter and crank out a rough prototype of the thing they are thinking about,
• have the unique ability to translate complex / abstract thoughts into simple English that a non-technical end-user can understand, and
• a willingness (or even desire) to get up in front of 1,000 people and talk about the latest greatest thing they are working on / thinking about."

The paper "The Role of the CTO: Four Models for Success" by Tom Berray and Raj Sampath identifies these types...

• Big Thinker - there are low levels of business change and information does not form a major component of products and services - the aim is to identify big opportunities before the competition and to ensure that IT is bullet proof
• Infrastructure Manager - there is large scale business change but information is not a major component of the organization's products or services - the focus is on cost reduction
• External Facing Technologist - low rate of business change but products and services are highly dependent on information - the focus is external support and identifying new opportunities
• Technology Visionary and Operations Manager - technology is critical in a fast changing organization - the CTO is a change leader helping shape the business vision ensuring that the technology works and delivers the business goals
  

Each of these roles may be a valid direction for a chief architect. They each exercise different aspects of the talents of a chief architect. The roles have a level of management and politics that may deter some architects. The move should be quite easy. It is important to understand what is required and whether you can adapt and are a good fit to the requirement.

CIO

The CIO is typically the head of IT for an organization and will the normal management responsibilities that a head of function will have. The IT leadership role that ensures that the IT function delivers the needs of the organization.

The leadership role has four key dimensions:

• operational delivery - you get fired if you fail to deliver day to day operations
• project delivery - you must deliver "business-as-usual" incremental projects and large step change projects - you have a few more "lives" to get this right but if you consistently fail then you will be fired
• function management - simply this is about adhering to policy and meeting budget
  
• business change - the CIO will be expected to support business change through systems and also through IT organization change eg headcount, location, pay changes
  

A chief architect moving into a CIO position has to be aware of that these four dimensions have been listed in priority order. If you find operational delivery or maintenance issues tedious then don't do this job. It doesn't matter whether the head-hunter or advert stated that a change agent was required - fail on operations and you get fired.

An astute organization recruiting for a CIO will ensure that the new CIO can cover all the bases. This can be a problem for a chief architect since often they don't have strong operational experience and may have moved out of project delivery management some time ago. Moving sideways may be an option...

Head of Development

How many people have you managed? What was the value of the projects that you managed? How many projects in your portfolio? Tell me about your project management experience?

The normal route to head of development would be through project management and technology resource management rather than architecture. Do you have a good story?

In some organizations, the architects are the enemy. Can you overcome the potential prejudice?

This can be a very good move. You get the delivery management, you get a large part of the function management, and you continue to be involved in business change. If you are sensible you get close to operations, you ensure successful transition, you take operational failure as your failure, you ensure exception processes and procedures are implemented to deliver operational success.

Program Management

For some architects, a sideways move to program management can be attractive. Work on large programs as design authority, project management experience and significant business stakeholder engagement are prerequisites for this to be a realistic option.

To make the move, add a program management certification. It is useful to have shadowed a program manager or program director on a major change program to get credible hands on experience. This can be coupled with a design authority role.

The first role may not be that challenging unless you can be seen as the successor to an existing program manager or director. But being seen as delivering major business change successfully will open lucrative doors.

Business Change Management

If you are a more business focused architect and have concentrate on business processes, operating models, and requirements rather than technology then business change management may be an option.

You will need to have worked your models through to implementation and be comfortable working with real end users - e.g. are you comfortable in a call center or at a checkout.  Have you "walked the floor" on go live day?  Have trained end users in their new ERP?  Have you worked through the issues of instilling the process disciplines necessary to to operate an enterprise application successfully.

You will also need to be comfortable working at all levels of management from VP to supervisor.  Can you convince a VP committed to multi million dollar savings that a systems change cannot be implemented in a call centre just by shouting loudly?  Can you identify the detail that breaks that concept, work out a solution that works on floor and delivers the benefits?

Architecture Consultancy

Most consultancies are in need of good architects and are seeing a lot of people in their efforts to recruit.  If they like you then you are in a strong position.  But you must ensure there is a good fit. Is the role right? Can you work with these people? Is what you like doing what is being sold?  Can you find a way of working that fits your personal life?

The consultancies very often split enterprise architecture into different practices.  Business architecture will often fall into a general business strategy practice and domain based consulting.  IT architecture is also often split into IT Strategy and technology architecture.  This can pose a problem for the enterprise architect who wishes to link business and IT.

You will need to understand the practice structure, how the practices work together and how they engage with clients both pre and post sales.  It is important to understand what areas of architecture interest and motivate you.   You must make it clear to your interviewers what these are and how your interests work effectively with the way the consultancy operates.  If you can't work this out, walk away.  If you are not convinced that the interviewer understands and can make it happen, walk away.

If you are convinced that you can make it work then you have to get into the practice that positions you best.  You will have to build relationships with the other architecture related practices, the delivery practices and the sales people in order to create success for yourself.

Or a complete change...

Alternatively, you may wish to get out completely and become a priest, a lawyer, a day trader, a farmer, a property developer, or anything else that appeals. If you want a complete change then I wish you well ...

I agree with Andy Blumenthal in his blog IT Governance and Enterprise Architecture that EA governance (and all forms of IT governance) should be integrated into a unified structure that ultimately reports into an overall business controlled IT board that controls all “think”, “build” and “run” investment.

There is a key point is that all communication from the EA board must be in business terms i.e. relevant, easy to understand and accessible - "user centric"  to use Andy's definition. The EA board will lose credibility if it is seen as a technical control body or worse a talking shop. It must be seen as a vital business control function that ensures IT supports the business mission, vision, strategy, and goals.

In the minds of many business people, data management, interoperability, technology standardization, security, and other issues that architects look at are arcane and possibly irrelevant distractions that IT should look after under the covers. In presenting EA issues and recommendations to the IT board, we need to bring these items to life by using business language and explain how we are supporting business goals.