Defining the Enterprise Architect

Loraine Lawson

A while back, I wrote about how enterprise architects are struggling with SOA and how it fits into their discipline. Frank Millar, executive director of Millar Consulants, LLC, pointed out that I assumed everyone knows what the term "enterprise architect" means, noting that, in his experience, the term is defined differently in different enterprises.

He's right. There are a lot of different definitions for "enterprise architect." It can get really confusing, particularly if you follow a lot of blogs written by enterprise architects -- and I did.

Millar noted there are two extremes used in defining enterprise architect:

  1. At the one extreme, it's defined as a purely a business function, "chartered to translate strategic goals into proposals for organizational charts and track implementation results so that operations are optimized without immediate considerations of technology."
  2. At the other extreme, enterprise architect can refer to individuals who focus on reducing costs and "integrating and improving the efficiencies of disparate enterprise IT organizations and their respective resources."

"Surely," Millar writes, "These two roles are very different jobs."

As it turns out, no, not really.

I decided to do a little digging into the enterprise architect role. Here's what I learned.

  • You'll often read that enterprise architecture is a new discipline. But it's really not -- at least for technology time lines. The first EA framework was created by John Zachman of IBM in 1987, according to this whitepaper on the "MEGA & the Zachman Framework."
  • One common driver for enterprise architecture -- as a discipline -- is the the quest for IT/business alignment. According to a recent CXO Today article, a study by the Infosys Technologies revealed that 36 percent of enterprise architect teams actively participate in their company's strategic business planning.
  • But that's not the only job of the enterprise architect. Zachman is quoted as saying, "There are four reasons why you do Architecture: 'Alignment,' 'Integration,' 'Change,' and 'Reduced Time-to-Market.'" Likewise, the Infosys Technologies survey found that integration and information integrity are the key concerns of enterprise architecture, followed by customer data integration. I think this speaks to Millar's confusion and why it's so hard to pin down a job description for the enterprise architect. That's a wide range of tasks.
  • The Zachman Framework is the oldest of the enterprise architecture frameworks, and, if Wikipedia is the be trusted at all, it's the most widely used framework. Wikipedia also identifies the following primary frameworks for enterprise architecture: The Open Group Architecture Framework; the Department of Defense Architecture Framework (DoDAF), which is used by the U.S. government; the Federal Enterprise Architecture (FEA), which comes out of the U.S. Office of Management and Budget; and the UK Ministry of Defence Architectural Framework (MODAF).
  • I often see enterprise architect bloggers compare their jobs to building architects. But this analogy breaks down quickly. Steve Nunn, vice president and COO of the Open Group, and other sources recommend instead that enterprise architects are more aptly compared to the role of a city planner. In a recent Q&A with IT Business Edge, Nunn explained:
"...enterprise architecture is not necessarily a direct correlation with a building architect. An enterprise architect is more like a city planner. It's looking at not just the building, but what facilities are needed, what the likely through-put is going to be, the demands on the system, all the things a city planner would look at if he were building a city from scratch or an infrastructure project in a city."

Nunn notes that there are a lot of people right now throwing around the term "enterprise architect." He suspects few of them are actually doing the job functions of an enterprise architect. And likewise, there may be people handling the enterprise architecture functions without the title.

 

So, how can you separate the wheat from the chafe?

 

One way is to make sure the enterprise architect is using a recognized framework. You can learn more about the Zachman Framework at the group's web site.

 

The Open Group also offers an IT architect certification program, which Nunn says is evolving into an enterprise architect certification program.


 

For more information about the general definition of enterprise architect, check out the first and second parts of our interview with Nunn.



Add Comment      Leave a comment on this blog post
Sep 24, 2007 12:58 PM Managing Offshore IT Managing Offshore IT  says:
continued ... Enterprise Architecture Offshoring In an offshored context, there is no reason one cannot leverage offshore architects for required architectural inputs, review and governance. Thanks to pervasiveness of information about technology building blocks, base frameworks and body of kno... Reply
Oct 2, 2007 11:33 AM Frank Millar Frank Millar  says:
Good job doing your homework! And, thanks for highlighting Zachman's precedent-setting framework. I use Zachman as a starting point for my own engagements. And more thanks for choosing to highlight my response to your earlier blog. Of course, it's a little disconcerting that you refer to my words as expressing "confusion". Let me respond to that point by saying:You've acknowledged above that the term EA itself "can get really confusing", and that of course is the core of my communication. As for understanding the role of an Enterprise Architect (my field) I'm very clear about that. Others not so clear, and the relevance to that earlier blog post, were reasons for my communication. You have served many of my present and future customers well with this latest post. Thank you! Keep up the good work!Frank MillarExecutive DirectorMillar Consultants, LLCMillarConsultants.com Reply
Sep 25, 2008 12:46 PM Kirk Rheinlander Kirk Rheinlander  says:
Actually, Dr. Charles Banning at GE (now TAM Group) created enterprise architecture and the supporting frameworks before Zachman. His work on principles driven architecture has led to this process quietly being deployed at a half dozen Fortune 100 companies, and nearly 10% of the Fortune 1000's. - a success rate unrivaled among other EA approaches. On the definition front........Architecture (ANSI/IEEE Std 1471-2000)the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.Enterprise Architecture fundamentally results in a "system of systems" view of the environment, solving a business and management problem. This typically spans everything under the CIOs control, including technology, skills, process and organization, all aligned with business strategy. The software, network, platform, security, etc. TECHNOLOGY architects fit under this next definition. Technology architectures are a "system of components" (where systems produce stand-alone value, and components have to be composed into a system to produce value) - solving a technical set of issues.To use an analogy that I have presented many times (got a great diagram to go with!), if the CIO is the conductor of an orchestra, where the woodwinds are the software, brass is the databases, percussion is the operations/data center, strings are the network communications, etc. the enterprise architect is the composer - the person that figures out how to make all these instruments (organizations) work together to effectively make great music, ideally matched to the movie (company strategy business-IT alignment). PRAGMATIC enterprise architecture.....It is NOT a technology effort; it is a business management approach to delivery business value through technologyIt starts with strategy - and the supporting things IT must enable effectively to drive business growthFrom an I/T management perspective, EA is everything that it takes to manage the complete I/T environmentCurrent Typical Industry StateMost current EA efforts are actually software design, and should be called Application Architecture or high level software designSome more mature / larger scope software oriented EA efforts actually take into account data or software product relationships across the enterprise. The Problem - Relatively low dollar (software / data driven) architecture efforts typically drive the bigger dollar I/T infrastructure investments often not the best approach. This bottom up approach adds risk thru Silos of Automation, driving big dollar technology investments from small dollar project perspective.Former TAM Group principal and practitioner.Kirk Rheinlanderwww.ExecutiveIntent.com Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 
Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data