In a word, unlikely. 

Today, I continue the series on IT organizational structure.  So far, I’ve talked about Operations (with three sub-areas: Infrastructure, Production Operations, and Risk Management) and Development.  Today’s topic is Enterprise Architecture, and it will be natural along the way to discuss the Enterprise Architecture Oversight Committee (from the article on Governance).  The final article in the series will be Portfolio Management and two related Governance committees: Project Governance and Strategic Planning.

So: Why don’t Enterprise Architects Architect the Enterprise?  Because almost always, the Enterprise is already built (smile).  At best, they’re blueprinting the remodeling effort.  Unfortunately, in too many cases, they’re re-arranging the nick-nacks on the shelves.  The challenge for the leader is to keep the organization relevant by solving business problems without resorting to ivory tower ideology.

Today, everyone calls themselves an architect.  Apparently, development and analysis titles are too boring or do not pay enough.  Anyone who can string three programs together is an architect.  For the purposes of the Enterprise Architecture group, I plan to focus on four types of architects: Application (domain expert), Solution (cross-application focus on single business problem), Infrastructure (hardware), and Enterprise – along with their boss, the Chief Technology Officer.

An Application Architect focuses on a single (or a few related) application domains (Provisioning or Fulfillment are examples).  This role is a subject matter expert in the business domain.  The individual has knowledge of all the technology used to solve the problem space – applications, servers, databases, middleware, hardware and business processes.  Application Architecture strongly overlaps with the Portfolio Management Systems Analysts for that business area so that you can use the strengths in one to manage the weaknesses of the other.  This area also includes the architect responsible for the middleware layer (e.g. Enterprise Service Bus, Business Process Modeling, etc. – sometimes referred to as a Technical Architect).

A Solutions Architect takes a single business problem from idea to reality across all applications and infrastructure.  Solution Architects often overlap with Project Managers.  They lead cross-functional teams and do joint design sessions, integration walkthroughs, etc.  The Solution Architect is a guided missile who is aimed at the target of the strategic business problem to be solved and who brings every resource necessary to bear on the problem until it is solved.

The infrastructure architect is busily trying to figure out the best configuration of hardware elements will most effectively support all the needs of the enterprise. Many organizations place this responsibility in the Infrastructure Operations organization, but it truly belongs in EA.  This role is responsible for everything from the composition of the data center, integrating cloud processes (internal and external), to what type of equipment goes into the networking closets at all the remote offices.

The Chief Technology Officer is the leader of this organization, whether tasked with management responsibilities or not.  In some cases, the CTO has incredible talent to solve massive strategic business problems between breaths, but would drive all the design talent screaming out of the organization.  While this is regrettable, sometimes the talent is too strong to give up and must be supplemented by a manager to take day to day supervision tasks off that person’s shoulders.  But even in that case, the CTO sets the direction for the EA group by defining the right problems to solve and the principles to which the group will aspire to in solving them (principles based architecture).  It is best if the CTO directly leads the group, but even if that is not feasible, the CTO is the spiritual leader of the team.

Shortly, I plan to discuss the differences between the CIO and the CTO.  The two are like a matched pair complementing each other’s weaknesses with their strengths. The compatibility of the CIO and the CTO is far more important than the actual job definitions for each, as they can fluctuate to take advantage of each one’s superior skill set.  But I will talk about what the roles should be in theory.

The CTO is the chair of the Enterprise Architecture Oversight Committee (EAOC) in the governance role.  Does that mean that the CTO is dictating architectural decisions to the rest of the organization?  If so, that person should not be the CTO.  The EAOC decides issues by consensus, and the CTO is the chief salesman within the group, advocating for the vision.  If the CTO cannot convince the operating majority of the group, it is likely that the idea is not good enough or the CTO lacks persuasive ability, which is a key component of the job description.  As described earlier, the EAOC is charged with maintaining the list of approved technologies and ensuring that any newly proposed technology or major architectural component has been fully vetted before being acquired.

One organization used the EAOC to enforce its technological will on the development directors (because the leader was dominated by the “bright shiny object” syndrome – adopting technology simply because it is “cool”) or as constraining leash on the architecture group (because it was lead by the risk-averse Operations group).  Properly run, it is balanced and focused only on what is healthy for the whole enterprise.

Please share your stories of how EA helped or hindered your organization in the quest for strategic growth.