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
« TOGAF Certification | Main | Two Headed Beast »
Saturday
Nov042006

Enterprise Architecture Reporting Lines

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.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

Alan,

I agree that the head of EA should report into the top IT executive position, it must to get the visibility in IT as well as business operations.

On Soap Box:

My observations over the years have always convinced me the best architects are leaders and usually do not come up through the management ranks. The head of EA/Chief Architect (whatever the flavor of title we want to put here) can't be a "general executive,” they have to come from the technical ranks. This is where great enterprise architects put the final plank in the bridge to the management ranks. Without that background there is no credability with the working class of IT, and they also have to obtain the same credibility from the executive management team. The Chief Architect should have been interacting at the executive and senior management level for many years as a Senior Enterprise Architect to obtain that credibility before stepping up to the management role. If not, then I suspect that it was more solution or other specialist architecture role in the enterprise, and not enterprise architecture activities. So in that respect, when we say “techie”, I would only include those at this level.

Also, IT strategy should be part of enterprise architecture, and in most organizations it’s not, because the enterprise architects are too far down in the dirt doing solution architecture to deal with the business of IT and defining its strategic direction. The senior enterprise architects should start taking on more of the strategy and management duties, letting the enterprise architects deal with most of the “how”, while they transition to deal with more of the “what.” Otherwise, the IT Strategy created is of limited use since it’s going in a direction that makes little sense to anyone executing the tactical initiatives that move an organization in the strategic direction. Those senior enterprise architects are now being groomed to move into the executive management roles of IT. Expect your senior enterprise architects to move up or out to the top IT executive positions in other companies. However, while they are there, they are creating a world class IT organization that will not only enable the business, but transition IT to a full partner driving revenues and growth in the company.

Off Soap Box:

Best Regards,

Tom

(from the original blog site)

February 15, 2007 | Unregistered CommenterAlan Inglis

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>