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.

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 ...

...or how to make scarce resources go further.

Good enterprise architects are rare. Building a high performing team of twenty is difficult, building a focused and effective team of fifty is near impossible. But you could probably build teams of 5 or 12. Larger? ... it's not architecture.

The key is the vast free resource that is available and willing to be used. First you have to make a mental conversion. Your team will set objectives for architecture and assure that they are met by your free architecture resource but they will not create architecture and you will not control the resource. Are you prepared to give up control? Are you prepared to trust someone else? Are your architects prepared to watch and criticize? Are they prepared to substitute depth of knowledge for breadth?

If you are about to embark on a major implementation then you will be spending large amounts of money with suppliers on hardware, licenses and consultancy. The suppliers have funds to invest in winning this business – for low margin business such as consultancy, it is normally a few percent of the deal value, for higher margin business such as software the percentages will be higher. The suppliers have teams of people just for the task of helping you buy their products. Why then would you do their job for them?

There is one external resource that you will need to pay for, but you probably are already. You will need access to a major analyst company to identify the right suppliers, to tell you where the markets are going, to help you evaluate supplier responses, to identify good reference sites, make calls on risk, etc.

Your architecture team is your staff, your existing major suppliers, your analyst, and the vendors bidding for the next piece of work. If you can manage this lot, why would need a larger team?

It is mainstream to have an architecture function in IT but its reporting line has not been finalized. I have seen most possible options and I have some views on what works and what doesn’t.

First, why do reporting lines matter? The enterprise architecture is an influencing, guiding and control function for IT. Its remit covers the delivery of applications, data and infrastructure. Enterprise architects need to avoid a conflict of interest with their boss otherwise their advice and decisions may be skewed by political considerations. Additionally, such a conflict of interest can result in information to and from the enterprise architecture team being filtered by the boss. Suppliers, business areas and projects may choose to take their guidance from the boss who is not an enterprise architect and not qualified to give the advice. The position of enterprise architecture gives a message of its importance to IT and the organization.

Let's forget putting EA in the Business. While the business gets benefits from EA, they are most visible in IT and IT hurts the most when it is not there.

A fairly common practice is to make EA report into development. In my opinion, this is worst practice. The head of development will have an objective that says “to deliver projects on time, on budget, that meet requirements and that conform to the architecture”. If EA is part of development, the architecture constraint is under the direct control of the head of development. The other objectives are not, which one is easiest to flex?

Reporting to service delivery has similar problems since service delivery will be changing the infrastructure. Its objective is “to deliver services that meet SLAs within budget and that conform to the architecture”.

IT strategy is about determining the business objectives for IT, putting together a high level IT change plan, and getting this funded. This is about what IT should deliver to the business. EA is about finding solutions to these requirements. “What” and “how are naturally in tension. This tension needs to be managed objectively. Sometimes objectives need to give, other times solutions. If EA reports into IT strategy then IT strategy becomes dominant. The likelihood is that considerations such as TCO will be lost to short termism. IT strategy and EA should be peers.

The ideal reporting line for EA managers is to report into the CIO. This gives influence and gives the EA manager a shot at the top job. Is it right for the CIO? Only if the EA manager can take a broad business view and contribute to the general running of IT. If the EA manager is a purist, a pendant, or a techie rather than a good general manager then the EA manager will soon lose influence and subsequently position.

The alternative to reporting to the CIO is to report into a more general control function which may include functions such as the program office, commercial management, IT strategy, risk and compliance. This gives the less experienced EA manager the opportunity to develop political and general management skills before butting heads with the big beasts at the CIO’s table.