Infographic: 10 Characteristics for Evaluating an Architecture Programs

Infographic: 10 Characteristics for Evaluating Enterprise Architect Certification Programs

Use this Infographic to help you evaluate if the Enterprise Architecture or Business Architecture program you are looking to take, meets these 10 characteristics.

To learn even more about these evaluation criteria, you can read more here.

On Enterprise Architecture

On Enterprise Architecture

By Samuel Holcman, The Enterprise Architecture Center Of Excellence (EACOE)

People interested in Enterprise Architecture are in a difficult spot;  it is our belief it has become more difficult than ever to separate Enterprise Architecture facts from beliefs, experiences from opinions, and sound practices from declarations.  This situation has risen as consultants, practitioners, academics, and publications present Enterprise Architecture in a disarrayed voice of multiple approaches, multiple meanings, and multiple sets of expectations – some based on experience, some based on conjecture, and some based on opinion.  With blogs, forums, dozens of enterprise architecture organizations of various types, and the internet itself, how do you sort things out?

One principle criteria is

“Does this make sense?”

We look at “physical analogies” and relate them to what we hear about Enterprise Architecture, and if it does not make sense in the physical world, it probably is not true in the Enterprise or Enterprise Architecture world.

That is, we suggest we favor logic over “what I want to believe.”

Another criterion is

“Is this just a statement?”

Unfortunately, saying something one thousand times does not make it so.

A third criterion is

“Who is saying this, and what is their background?”

Have they verifiably actually ever done Enterprise Architecture (whatever their definition)?

There are many more criteria we are sure we can all think of!

An excerpt from one enterprise architecture forum is enlightening;  the suggestion from a respondent on where to get Enterprise Architecture information:

“Do a Google search; there is plenty of information available about Enterprise Architecture. Wikipedia has a concise description of it.”

The response from one of the readers of this forum:

“This is good advice.  Every neurosurgeon, before operating, should quickly do a few Google searches, consult Wikipedia, or pop out and canvas ten or so passers-by in the street to get a “grassroots” feel about thoughts on the latest developments in his/her field!”

We have nothing against Google or Wikipedia (or any other sources of this kind), but point well taken!

What follows is a compilation of the most common questions from attendees at the Enterprise Architecture Center Of Excellence (EACOE) Certification Workshops, and our responses.  Our hope is that the reader will find the responses to these questions logical, fact based, and sound practices and principles-based.  We can assure you these responses are definitively based on decades practice experiences.  Hopefully our credentials are known to you.

What is Enterprise Architecture?

Enterprise Architecture Defined from an information and technology perspective

Enterprise Architecture is explicitly describing an organization through a set of independent, non-redundant artifacts, defining how these artifacts interrelate with each other, and developing a set of prioritized, aligned initiatives and roadmaps to understand the organization, communicate this understanding to stakeholders, and move the organization forward to its desired state.

Enterprise Architecture Defined from a business perspective

Enterprise Architecture illuminates how an organization and all of its members can achieve its objectives, through the creation of a series of engineered models and project initiatives, that can be easily understood by all of the people associated with the organization.

How do you view the term 'Enterprise' within this definition?
A definition of “Enterprise” in this context is any collection of “organizations/people” and related things, that has a common set of goals/principles, and/or single bottom line. In that sense, an Enterprise can be a whole corporation, a division of a corporation, a government organization, a single department, or a network of geographically distant organizations linked together by common objectives, a project, a team, etc. The “wider” the definition of the term “enterprise”, the more opportunity there is for “integration”. A “narrow” definition of enterprise leads to more “interfacing”.
How do you view the term “Architecture” within this definition?
Architecture is the art and science of “building (construction)” representations, and the manner in which components and artifacts are organized, related, and integrated.
Is Enterprise Architecture about information technology (IT) or is it about the entire enterprise?
The answer for Enterprise Architecture is, it is not “or”. It is about both the enterprise (business understanding), and the technology enablement (IT) of the enterprise. This follows from the definition of Enterprise Architecture above. As a note, “technology” can include paper and pencil. Within this question is an underlying question – “what does the Enterprise Architect do”? The Enterprise Architect does not do everything in the field of Enterprise Architecture – this is a fundamental confusion. Doctors do not do everything in the medical profession; electrical engineers do not do everything in the engineering profession, etc. The EACOE defined twelve Architecture Modeling Roles, which are mutually exclusive – providing clear role responsibility, and complete – no loose ends or unassigned gray areas to be overlooked, or to be a source of concern, in Enterprise Architecture. These roles are: Enterprise Architect, Business Architect, Process Architect, Data Architect, Policy / Rule Architect, Role Architect, Logistic Architect, Event / Sequence Architect, Rule Assertion Architect, Workflow Architect, Technology Architect, and Event State Architect. Of course, this requires a “frame of reference”.
I guess I do enterprise information technology architecture – that is good, isn’t it?
We are not really sure what is meant by the phrase enterprise information technology architecture. If it means the current layout and inventory of technology assets, then it should be called technology assets and logistics layout. If it means the connectivity of various technology assets, it can be called the technology blueprint. Architecture and implementation are different. You may be able to “architect” the current assets of information technology, but without the “enterprise architecture” desired state, architecting the desired state technology architecture has little value (we did not say it has no value.). Questions need to be asked. What are you architecting against? How do you know if the technology has anything to do with the business and its future intent? Going back to the definition of Enterprise Architecture, Enterprise Architecture is about understanding the business intent, and the technology to achieve the business intent. Setting up an enterprise information technology architecture out of context from the enterprise architecture is not desirable, and may be one root of the belief that Enterprise Architecture is about information technology only.
I can use any framework – there are many out there - correct?
A framework is a structure that organizes a set of related artifacts. The framework shows the relationships of the artifacts of the chosen subject area and brings a totality perspective to otherwise individual ideas. A framework, therefore, makes the unorganized organized and coherent, and is fundamental to any profession or discipline – engineering, chemistry, physics, language, music, etc. Framework elements must be mutually exclusive and collectively exhaustive. A framework that is in constant update and versioning is troubling. It means that it is/was not complete. If we used version 4 of the framework, and we now have version 9, what does that say about the work we did with version 4? Can you imagine the English alphabet starting off with 15 letters (version 1), the going to 21 letters (version 2), and then going to 26 letters (version 3), and someone suggesting xy letters (version g)? How useful would that be? Can you imagine the periodic table of elements in chemistry having multiple versions? Chemistry would be alchemy. Can you imagine the notes in music to be in continuous versioning? It would really fun playing in an orchestra. A framework is fundamental to Enterprise Architecture. The Enterprise Framework TM, and the framework defined by John Zachman, meets the criteria for an Enterprise Architecture framework.
And a methodology?
A framework is not a methodology, and a methodology is not a framework. A framework can possibly accommodate many methodologies, but we have not seen a methodology work across multiple frameworks (not in the physical world, so we cannot believe it will be different in the enterprise architecture world). A methodology has practices and procedures applied to a specific branch of knowledge. A methodology has proven processes followed in planning, defining, analyzing, designing, building, testing, and implementing the area under consideration. An outstanding methodology guides the process, simplifies the process, standardizes the process, can be customized to meet specific standards and practices of the using organization, is correct, is up to date, is complete, is concise, defines deliverables, has methods, has techniques, has standards, has practices, has roles and responsibilities, has suggested timings, has suggested sequences and dependencies, and has associated education. Guidelines are not methodologies. Saying you can do this, or that, or that and this – are guidelines. Providing suggestions on deliverables are guidelines. Methodologies should provide a path, or provide predefined paths. You should be able to do something “Monday morning” with a methodology – not start trying to figure out how to take a guideline and turn it into a path to follow. The Pinnacle Business Group, Inc. Quick Start Methodology meets the criteria for an Enterprise Architecture Methodology.
I need my Enterprise Architecture to fit on one page – after all, it only has to be at a high level.
We are not sure what you are actually trying to do in one page, but it is not an Enterprise Architecture. If you have had the privilege, or frustration of ever building a house, you know you get a “scroll” of diagrams (blueprints) with the house. If something as simple as a house needs a scroll of drawings, an Enterprise Architecture will, at a minimum, require a scroll of drawings. There is also a hint we can get from this analogy. There is no one “picture” that solves all constituents or stakeholders needs in building a house. There is, therefore, no one drawing that will solve all needs for Enterprise Architecture stakeholders – complexity is much greater. We suggest there are thirty possible Architectural model representations that may be of interest to various enterprise stakeholders, and 684 possible Implementation model representations that may be of interest to various enterprise stakeholders. We can calculate this census of models because we have a frame of reference. We have not said that we have to develop all of these representations today. However, anything that is not made explicit does not mean it does not exist – it is just implicit, and we are making a value judgment to not have that specific representation made explicit. We are sure glad we can understand what we know and are making explicit, and also know what we are making assumptions about (what remains implicit). This is due to the frame of reference – the Framework.

Our primary criteria for business-facing models is

Are they “human consumable”?

Our primary criteria for technology and implementation facing models is

Are they transformable into solutions?

Different audiences require different criteria.

Enterprises are different and don’t need the level of specificity of buildings, or airplanes, or ocean liners, or other physical items – correct?
In two words – why not? What is the basis of this belief? We truly wish this was correct. We believe that enterprises are much more complex than any of these physical items. If you are building a rowboat, you probably do not need much architecture. If you are building an ocean liner, you need extensive architecture, at great detail. If you are building a model airplane, you probably do not need much architecture. If you are building a Boeing 747, that flies over water, at night (with us in it!), you need extensive architecture, at great detail. If you are building a log cabin, you probably do not need much architecture. If you are building a 100 story building, you need extensive architecture. Ask the people that recently completed the Trump International Hotel and Tower in Chicago how much time they spent on architecture and how much time they spent on implementation. You may be surprised. We do not think you will be surprised at the level of detail for the hotel and tower. So therefore, if you have an enterprise that is the corner store, you probably do not need much enterprise architecture. If you are building an enterprise, around the world, with thousands of employees, undergoing constant change, you need extensive architecture. Architecture is the baseline for managing complexity and change. If it is not, what will be used to address complexity and change, and what are you going to do to avoid unintended (no details in your architecture) consequences? Architecture is about planning, analyzing, designing, and constructing, and hopefully we can stop using a different, presently more common lifecycle – constructing, maintaining, maintaining, maintaining. What is your approach to managing complexity and change, if is not Enterprise Architecture? This does not mean we have to do everything at once. Enterprise Architecture is a continuous process, with greater granularity of its artifacts over time as the enterprise changes, and more of the enterprise is “mechanized” or “automated”. Architecture occurs prior to making a change. Documentation occurs after the change is made. This is the only logical and practical way to do this in a cost effective manner. Our objective is to continually reduce the risk of unintended consequences, and “inappropriate” changes.
What abilities are required for Enterprise Architecture?
The abilities and skills change for the twelve Roles defined for Enterprise Architecture. The skills mix changes as you move from the “top” of the Enterprise Framework to other Roles in the Enterprise Framework. Generally, more soft skills (facilitation, meeting dynamics, communications, etc.) are required at the business layer roles than at the other layers. More hard skills (modeling, technology transformations, etc.) are required at the technology transformation layers of the Enterprise Framework. We would suggest that both hard and soft abilities and skills, to different degrees, are required for all Architect Roles in an Enterprise Architecture.
An analogy you often use is Engineering and Manufacturing – can you elaborate?
First, it is an analogy. We do not really know if, eventually, we will be able to engineer and/or manufacture an enterprise. We have seen the continual movement from “hand crafting” things to “manufacturing” things in almost every discipline that we can think of. Let’s see what the future holds for enterprises. The study of enterprises is only about sixty years old. More importantly, the analogy is to suggest two separate but linked disciplines exist in the physical world, and Enterprises need to take notice of this. These disciplines are Engineering (Architecture), and Manufacturing (Implementation). In the beginning of each new discipline, we tend to begin in manufacturing (Implementation). Think hand crafting automobiles 150 years ago. Once there is a body of knowledge about a discipline that is codified (engineering), this codified knowledge is used to produce better engineered products (better implementations). So the sequence is manufacturing to engineering to better manufactured products. This analogy fits perfectly in Enterprises today. Most of what is done in Enterprises can be considered to be Implementations (manufacturing). We are now codifying this enterprise understanding (Architecture), and eventually we will be able to produce better enterprise Implementations. So the sequence in Enterprises will be implementations to architecture to better implemented solutions and products.

EACOE & The Open Group Comparison

Comparing Two Leading Enterprise Architecture Methodologies and Frameworks:
The Open Group (TOGAF) and The Enterprise Architecture Center Of Excellence (EACOE)

Authored by Bernard Baillargeon
TOGAF ® and EACOE Certified Enterprise Architect
Email: [email protected]

Enterprise Architecture (EA) represents the drivers and blueprints of all enterprise business concerns, including those of Information Technology (IT). Enterprise Architecture places emphasis upon a consistent understanding of the Business’ problem domains, goals, opportunities, and priority solutions, for all business functions, in human consumable terms and models. IT architectures should neither direct, nor constrain Enterprise Architecture; true Enterprise Architecture actually governs the direction of IT architectures.

Enterprise Architecture Frameworks and Methodologies should provide:

  • Business Initiatives (Projects): Initiatives should address cross-business or individual concerns, consistently and equitably prioritized to the Business’ future state intent and values.
  • Directed Guidance: Enterprise Architecture practitioners should have access to explicit methods, tools, and directed startup sets of fully contained and human consumable artifacts, to quickly establish a working, productive Enterprise Architecture foundation.
  • Consistency and Simplicity: One frame of reference, one consistent representation, recognizing a thinking tool for this area of study, which is thought of as “Business Problem Solving” or “Business Strategic Thinking.”
  • Structured, Precise Definitions for Human Communication and Understanding, Leading to Technology Enablement: Architecture models should follow structured templates to ensure completeness and consistency, and terms, acronyms, and phrases of business interest are uniquely defined in a normative business facing glossary.
  • Clarity and Reason in Modeling: Two distinct model sets – Architecture Models and Implementation Models – should parallel the descriptive representations of all things – engineering “design” models and manufacturing “build” models.
  • Value in the Transformations from Model to Model: There are different models and transformations between them – not mappings – to understand each aspect of the business. A single model will not suffice. Each effort in Enterprise Architecture should be tightly integrated with other efforts – this is traceability, transparency, and governance. Why develop artifacts that do not lead anywhere?
  • Skills Acquisition: Recognize that Enterprise Architecture skills are acquired through practice and experience; they are not acquired through simply passing a once-and-done multiple choice exam.
  • Business’ Multiple Architect Roles: Recognize the interrelations between the many architect roles in contemporary business, and understand each role’s scope of expertise and influence within the enterprise frame of reference to optimize each person’s contribution.

The Open Group Architecture Framework (TOGAF ®) and its Architecture Development Method (ADM) is influenced by, and focused on, Information Technology problem and solution spaces. TOGAF and ADM suggest business’ guidance and impact by embedding ‘business architecture’ as a peer of the IT oriented domains of application, information and technology architectures, possibly eroding the true guidance and influence that must be granted to the business’ intent. While TOGAF presents Business Architecture (BA) as a prerequisite to IT architecture, the subsequent method and phases do not reflect a direct dependency upon BA as one – there is limited artifact traceability; TOGAF and ADM inputs and process refer to composite documents rather than specific items defined within or listed as outputs or suggested outputs of the Business Architecture, such as the catalogs. This masks the traceability behind a composite, where such independence disengages the IT architectures from the directing influence of the Business’ intent, thus Business Architecture within the ADM cycle is actually a lesser peer. TOGAF and ADM may be considered an Enterprise IT (EIT) Architecture method and framework; EIT Architecture is not Enterprise Architecture.

The Open Group Architecture Framework (TOGAF) and its Architecture Development Method (ADM) inherited its baseline content (circa 1995); this baseline was provided to The Open Group by the US Department of Defense (through their Technical Architecture Framework for Information Management, the TAFIM). Additionally, various government agencies have been engaged in TOGAF ADM evolution intermittently since its transition to The Open Group. The evolution since that original baseline has been driven by IT focused organizations, and represents the modeling and methodology based upon complex, composite IT models and IT-oriented models, foregoing the architectural foundation models that would enable a concise understanding of the contributing parts of these complex models. The ADM has added ‘capability-based planning’ as an option to facilitate a business-driven and business-led strategy; this option still does not require the development of architectural models.

The Enterprise Architecture Center Of Excellence (EACOE) framework and methodology focus is on developing the architectural understanding of the entire organization, fully encompassing the scope of Enterprise Architecture. EACOE records, in human consumable artifacts, the discovered unique values of the business with respect to a single frame of reference, the Enterprise Framework, which is an “elaboration” of the work of John Zachman. EACOE believes it is imperative and fundamental to define the architectural elements of the enterprise before attempting to develop complex implementation models, or to envision solutions, without first understanding these architecture elements.

The focus of the Enterprise Architecture Center Of Excellence (EACOE) methodology and its framework, The Enterprise Framework, represents the business as-is and desired interim and future states as they impact all areas of the business’ endeavors, and presents cross-business initiatives to attain these envisioned futures. EACOE emphasizes developing and presenting business-aligned initiatives that drive the enterprise – not just IT – to its “desired” business-goal aligned state. The EACOE-developed models define the business initiatives in a human-consumable format – the emphasis is business understanding first, then technology transformations. EACOE’s The Enterprise Framework defines this understanding and transformation, and guides the EACOE Quick Start Enterprise Architecture Methodology. EACOE recognizes there is not one set of representations serving all stakeholders. There are multiple sets of representations: these five strata of “reification” – how humans treat abstract things as though they were real and tangible objects – are the five strata reflected in The Enterprise Framework.

Comparing The Open Group and EACOE on these points

Business InitiativesDirected GuidanceConsistency and SimplicityStructured, Precise Definitions for Human Communication and UnderstandingClarity and Reason in ModelingDiscover Value in the Transformations from Model to ModelAcquiring Skills, not Passing Multiple Choice Tests:Identify Contemporary Business’ Multiple Architect Roles

EACOE defines a Business Initiative as an integrated composite of goals, processes, materials or data, roles, locations, and events that are organized to drive a company’s strategies to a specific desired outcome.

TOGAF ADM presents to the business many Information Technology models from which the enterprise architects select models they believe will be useful, and IT projects derived from those models. TOGAF ADM (inclusive of version 9.1) does not consider business drivers, goals and objectives to be “core” to their content meta-model. While phase A Vision and phase B Business Architecture list the goals, business drivers and objectives as inputs, the meta-model presents these as an extension. This extension to include business focus elements belies the true IT core of the ADM. TOGAF does provide “empty” templates of ‘catalogs’, one being “Driver/Goal/Objective”, yet the ADM Content Meta Model which the ADM navigates and references inextricably, considers the “Driver/Goal/Objective” element not as core, but as an extension. The TOGAF ADM training and website do not provide meaningful, completed examples of these catalogs, nor is any guidance provided on how to achieve a useful consistent set of models using these templates; they are simply offered as a download of empty template files. TOGAF’s Business Architecture Phase B suggests supporting diagrams, such as functional decomposition and organizational decomposition diagrams; architecture is about classification, not decomposition – a fundamental issue; decomposition is an IT or implementation oriented tool to break complex items into contributing implementation parts. Classification is not about parts, it is about “types-of”, and is an understanding tool that must be in place before the complex items can be intelligently combined into diagrams or assessed.

TOGAF architectural phases build upon a ‘Vision’ phase (A), in which TOGAF suggests that practitioners use the systems-requirement process of “business scenario” as the vision foundation. This is fine if the problem to be solved is clear and well defined, and if it really is an IT system needed as the solution, but it doesn’t help to discover or refine and define the full enterprise problem space: What are the many areas of improvement, the many hot spots that the enterprise can address to improve its abilities and state of health? The “business scenario” essentially starts with a directed and assumptive “build this IT solution” mentality, and the traceability is only to this assumed scenario – there are no prior, traceable architectural elements to draw upon, the Vision phase is the start of TOGAF’s approach to define the architecture.

EACOE starts “far to the left” of this point in time in the strategy timeline, meaning that the business opportunity or issue is represented without making an assumption that the solution has to be or actually is technology based – in fact the resulting EACOE initiatives may well offer sets of “business scenarios” that IT might choose to drive through an IT – TOGAF cycle. EACOE builds up the actual architectural elements, models important relationships among them – all traceable to authoritative, verifiable enterprise directives and intent statements – and the discovered realities this unveils helps strategists to “see” the problems, to “see” if there is a solution that must be, should be, or could be pursued. While some of the realized and prioritized EACOE initiatives may lead to IT and perhaps TOGAF or other managed technology implementations, many other initiatives may be high level business value initiatives outside of IT and integrating across multiple business functions.

EACOE Initiatives are one of the key differentiators of its methodology and address cross-business concerns, consistently and equitably prioritized to the Business’ future state intent. The emphasis is to do things of greatest value to the business – what the business needs to be able to ‘see’ and achieve from an analysis of their Enterprise Architecture. EACOE methodology yields to the business a future state series of business goal-prioritized strategic initiatives and a roadmap from the existing state to the desired state. Furthermore, within each initiative, the business will find multiple candidate projects the enterprise architects discovered as they investigated, represented, modeled, and analyzed the discovered and rationalized business artifacts.

EACOE methodology further assesses each initiative and project for additional executive decision points. Enterprise Architects may perform risk analyses over these initiatives and projects for cost, existing project and operational impacts, market gaps or exposure, security, global data influences, and other key issues to assist executives as they select and finalize their next planning phase.

TOGAF ADM presents a non-directed selection of IT models and methods each architect needs to assess, select, and then modify to their organization before beginning any architecture efforts. TOGAF ADM does not provide guidance on how to select these models, how to modify the methods or how to tailor the models and methods to the organization. Advanced architects may be able to assess, select and prepare these models, know the methods they need to apply and how to tailor the various parts to the organization, but advanced architects are a small subset of the architects who need to be able to ‘get their efforts rolling.’ The most important concept for the business is likely to be its goals the business is trying to achieve, yet goals are not considered core to TOGAF ADM. TOGAF does provide to its members two files that contain templates that describe several ADM phase artifacts and document deliverables, generally as very simple, empty skeleton outlines or grids. Furthermore, TOGAF Phase B lists the fundamental architectural lists, the ‘catalogs’, as ‘should be considered for development’. Simply listing a catalog as ‘should be considered for development’ does not measure up to considering something as an essential component. The ADM content meta-model explicitly states that the goals are an extension (motivation extension), that they are not part of the core. Furthermore and more importantly, is the issue of traceability and agility. Something should be either in or out – if it is in, we should say so, and show how it contributes to the overall Enterprise Architecture. In “real architecture”, there are only facts, not opinions or options.

TOGAF does not provide tools beyond the template artifacts and deliverables; automated tooling of any EA efforts is left to relevant vendors which sell tools to support various models and methods as they see fit. These tools are IT architect facing, not business facing.

EACOE provides explicit methods, tools, and directed startup sets of fully contained and human consumable artifacts, to quickly establish a working, productive Enterprise Architecture foundation.

Enterprise Architecture is a new experience for many businesses, especially if the business had attempted to use IT methods alone to define their business. EACOE offers – based on numerous Enterprise Architecture engagements and experience tracing back to efforts begun in 1972 – explicit methods for architects to apply, and specific tools for architects and business interests to use in building, analyzing, and moving their enterprise and enterprise architecture forward to the business goal-aligned desired states.

Each aspect within The Enterprise Framework and Quick Start ™ methodology conveys its content to business decision makers as consistent, business useable and understandable architectural models, described using the business decision makers’ terminology and representations, “in their language.” EACOE refers to this quality as “being human consumable”. This focus helps Enterprise Architects to keep modeling focused on its business owners, not applications, systems, or existing vendor contracts. EACOE’s Quick Start methodology offers a set of fully contained, directed “start up next Monday morning” Architecture Models and Implementation Models with “macro-enhanced”, concise templates to guide enterprise architects to build this common structure. The Quick Start Methodology provides full transformations from business understanding through implementation, providing full and complete traceability from business understanding to system implementation (if desired). The methodology fully emphasizes and supports the required transformations, traceability, and diagrammatic representations to convey in business language the intent of the enterprise.

Common definition structure helps architects and business users of Architecture Models get into a “rhythm of recognition” where the proper descriptive form becomes the expected form, easing the recognition of missing key elements. This is an important achievement when classifying the multitude of items businesses will define and classify, leading to consistently defined Goals, Processes, Materials (which includes information about items of interest to the business), Roles, Locations, and Events. Having consistent definition structure also propels the quick and successful development of the more complex, implementation-oriented relationship models of composite business objects – which EACOE calls Implementation Models, and improves model understanding and business executives’ ability to quickly assess business initiatives.

TOGAF ADM states that it works with multiple frameworks, and with multiple methodologies.

No combination of true frameworks and methodologies has been identified, outside of this TOGAF declaration, in any profession we are aware of, where a methodology can “serve” multiple frameworks. The ADM does have a complex “content meta-model” as part of the TOGAF Architecture Content Framework, which TOGAF considers similar to the efforts of John Zachman and his framework. The content meta-model is where TOGAF declares core items interspersed with those that are considered non-core extensions, including the ‘motivation extension’, as an example, if the organization might be interested in Goals. A practitioner with a clear understanding of John Zachman’s work will question this comparison of this complex, data-entity relationship diagram content meta-model to John Zachman’s concise foundational framework, and will find probably find it difficult to understand a useful relationship between the two.

The TOGAF ADM states that its ‘framework’ – as defined by the content meta-model – is a fully usable tool; I suggest this to not be the case for Enterprise Architecture. The TOGAF 9 specification states:

“The content framework provided here is intended to allow TOGAF to be used as a stand-alone framework for architecture within an enterprise. However, other content frameworks exist (such as the Zachman Framework) and it is anticipated that some enterprises may opt to use an external framework in conjunction with TOGAF. In these cases, the content framework provides a useful reference and starting point for TOGAF content to be mapped to other frameworks.” -TOGAF 9.1

First, to be accurate, I believe TOGAF could be more correct if the statement were constrained to IT: “…used as a stand-alone framework for IT architecture within an enterprise,” I find TOGAF to not address Enterprise Architecture fundamentals well.

Neither do I recognize such a complex model as the ADM content meta-model as a useful tool to map to architectural, singular element models that form the foundation of an Enterprise Architecture; this is a cart-before-the-horse assertion. An enterprise framework, the single frame of reference, is not a swappable item, in my opinion; there is one framework within any area of study in human knowledge, and John A. Zachman’s foundational work still remains the single best representation of the reification that people use to drive abstract ideas into real, concrete instances of those ideas. Map the ADM into John Zachman’s work, or The EACOE Enterprise Framework, and you will see a significant amount of redundancy (some Framework cells are “addressed” 17 times or so within the ADM) showing that the ADM is not based on an agile non-redundant framework/architectural platform – it isn’t mutually exclusive, and collectively exhaustive in its representation.

With respect to other mappings, TOGAF presents a “mixed” message, presenting methodologies, standards, libraries, tools, and frameworks, as ‘frameworks’ that can be mapped to TOGAF ADM:

  • ITIL
  • SDLC
  • Agile Development
  • XP
  • RUP
  • OUM
  • PMI
  • DSDM
  • FEA
  • DoDAF
  • Zachman
  • MDA

“In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP.” – TOGAF 9.1

TOGAF has several whitepapers that discuss some of these; each comparison is IT oriented and does not offer enterprise architecture assessment; most pre-date the TOGAF V9 wherein ‘enterprise’ had been ‘added’ to the ADM.

  • TOGAF™ and ITIL®, Document No.: W071
    • ITIL: IT Infrastructure Library
  • A Practical Guide to FEA (2001)
    • FEA: Federal Enterprise Architecture
  • TOGAF™ 9 and ArchiMate® 1.0, Document No.: W191
    • ArchiMate is an IT-oriented modeling tool from The Open Group
  • TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP (IBM 2007)
    • RUP: Rational’s Unified Process, an iterative software development process
  • TOGAF and GERAM (2008)
    • GERAM: Generalized Enterprise Reference Architecture and Methodology, for enterprise integration and engineering
  • TOGAF and COBIT (2007)
    • COBIT: Control Objectives for Information and Related Technologies
  • TOGAF and MDA (2007)
    • MDA: Model Driven Architecture, a software design approach that defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language (DSL); the PIM is translated through a given platform model (CORBA, Web services, .NET, etc.) to one or more platform-specific models (PSMs) that computers can run.
  • The Open Group Architecture Framework (TOGAF) and the US Department of Defense Architecture Framework (DoDAF), Document No.: W061
  • The Open Group Architecture Framework (TOGAF™ 9) and the US Department of Defense Architecture Framework 2.0 (DoDAF 2.0), Document No.: W105

My assessment of the ADM is that it is developed with the content meta-model in mind, and it is focused on IT. The content meta-model is central to the definition of the ADM, and neither provides for, nor informs the required enterprise architectural models. The content meta-model is an IT core data-entity-relationship diagram of significant complexity and cannot be used to derive alignment to a true enterprise architecture frame of reference. When viewed, it is clearly “implementation”, and not “architecture”. I consider that there is only one reference (one ‘content framework’) in this problem space; that is John Zachman’s framework and its elaborations – such as EACOE’s The Enterprise Framework.

EACOE recognizes and emphasizes the fact there is just one “Frame of Reference,” The Enterprise Framework™, as an approach to “Business Problem Solving” or “Business Strategic Thinking,” as the one consistent representational and thinking tool for this area of human study. This one frame of reference parallels the consistency required for every known professional profession (medicine, music, chemistry, language, etc.). The EACOE methodology is set to build upon this singular frame of reference, and helps ensure the practicing architect has the methods and tools to apply their work, and to achieve an explicit and clear statement of their architectures. This keeps the models consistent, and helps simplify the frame of understanding needed by the business.

The Enterprise Framework is a non-arbitrary frame of reference that reflects how humans approach problem solving and move conceptual solutions forward to a realized, implemented reality. As such, there cannot be “versions” of the frame of reference; it exists, and always has existed; Einstein and Hawking didn’t release Time v2.0 and Time v4.5 – their contributions advanced human understanding of time itself. They did not create a new version of time.

Content and scope of the frame of reference is not up for a popularity vote: the content is correct within the field of study or it is not. There is no changing a frame of reference to bow to a consensus. A committee of hundreds who are uncomfortable with the constraints of the field of study cannot vote to change what is correct with respect to the field of study, or to redefine what that field of study is, to conform to their desires or to their businesses’ advantage. We cannot change the periodic table of the elements in chemistry to make gold a noble gas; it is what it is, a transition metal.

Methodologies, of course, can evolve over time, as experiences accumulate. I suggest that TOGAF is not an enterprise framework, even though The Open Group asserts this, nor is it a methodology; however the ADM is the TOGAF methodology, but ADM is not a framework; therefore “versioning” TOGAF ADM as “V9.1” may make sense, while simply “TOGAF 9.1” does not. Considering TOGAF without the ADM is difficult to assign value to, with respect to the practice of architecture.

TOGAF defines some architecture terms, seventy to eighty in its introduction section, others in several disperse locations. Many important critical definitions are deferred to IT standards, with multiple non-related versions presented, and many important concepts are not defined at all. The content meta-model of the TOGAF Architecture Content Framework contains 41 entities, 180 attributes, and 160 relationships presented in an IT logical data-entity-relationship diagram to represent a data centric definition of the ‘enterprise architecture’ concept; we suggest that few business people will even look at or beyond this type of complex representation. TOGAF defines briefly each entity and attribute in a table following the diagram.

In this attribute table, TOGAF declares a goal as

“A high-level statement of intent or direction for an organization…”

“… Typically used to measure success of an organization.”

TOGAF does describe in another section how to define goals by referring to SMART characteristics of Specific, Measurable, Actionable, Realistic, and Time-bound. Again this is suggested, but no strategies to arrive at these characteristics.

EACOE suggests clarity of intent and purpose is paramount in achieving business goals and provides guidance and templates to ensure structured, consistent and concise definitions of architecture elements. EACOE also emphasizes an enterprise level normative glossary to enable business terms, key phrases and acronyms have a single point of authority for business communication and terminology understanding. EACOE promotes using specific templates; as an example, the EACOE Goal template embeds the “SMART” characteristics in a repeatable, consistent fashion that enables all to see immediately where goal definitions need attention to address missing items. Each EACOE Goal, for the Goal model, is defined consistently to meet this template:

Goal Name strives to strategic description, resulting in business value, and will be measured by measurements, by no later than timeframe.

Each element of The Enterprise Framework is fully defined in the Enterprise Framework Practitioner’s Guide.

TOGAF offers complex IT models relating many different things – not architecture models – for architects to select from. Architects must select which TOGAF models to utilize as none are proposed as an experientially good starting set. While such complex IT models might work to effectively represent the current understanding – within the current context of a constrained or well-known domain – this compound composite model can neither articulately represent the important atomic business items, nor those items’ classification within their like-peer representations. TOGAF does refer to some ‘lists’ (catalogs) but they do not reflect these aspects of definition, classification, and leverage across the enterprise. As there is not an atomic set of architectural models promoted as the foundation, none of these varied complex models can be presented as a single source of authority and definition.

TOGAF lists several IT-oriented models as suggestions to the Business architects when determining what they should model. These are meant to extend the Phase (A) Vision business scenarios – a technique to discover and document business system requirements, and include activity models – suggesting the use of IDEF (Integrated Computer Aided Manufacturing (ICAM) DEFinition) modeling technique or The Object Management Group (OMG) Business Process Modeling Notation (BPMN), class diagrams, use case models, node connectivity diagrams, and information exchange matrix. While activity/business process models and use case models can be developed without explicit IT orientation, they usually do so, and are always complex models.

EACOE considers Business Architecture quite differently than does The Open Group, which is detailed in a separate discussion. Regardless, the IT models presented as “business models” clearly show information technology thinking that TOGAF ADM embeds. The ADM discussion within the Business Architecture phase does not provide business models, other than the aforementioned list of ‘to be considered for development’ catalogs, and shows no business level, architectural model techniques. Their examples are IT and complex models.

EACOE stresses two distinct model sets –

  • Architecture Models representing individual, things of interest to the business and technologists, [Engineering ‘design’ models] and
  • Implementation Models representing the varying complexities of relationships amongst those things [Manufacturing ‘build’ models].

Engineering ‘design’ models – which focus on the atomic elements, are different than Manufacturing ‘build’ models – which focus on composites of these engineered elements.

While executives might assume their business team and supporting technologists understand and promote this clarity of purpose in modeling the business future state, it is often missing in existing architectures and Enterprise Architecture practices. This clear separation of modeling focus is very important to enable true understanding of the business and modeled representations. These two distinct, yet tightly related and coupled sets of models are consistent with all know representations of “complex things” in professions outside of information technology. We strongly suggest enterprises and their technology implementations will require these same two sets of models and representations.

EACOE Architecture Models contain ontological representations classifying items of interest to the business. Architects define each of these items using a simple yet detailed template to correctly classify the item with relation to its peers. Each business aspect of strategic thinking represented in the Enterprise Framework has a template and ontology modeled as an Architecture Model. These models become a definitive single source, a controllable authority, and are highly reusable and very effective at quickly promulgating updates across the architecture.

Architecture Models promote clear and consistent communication between business participants, technology participants, and business to technologist communications.

EACOE Implementation Models build upon Architecture Models by presenting the most relevant relationships between items of the Architecture Models in a prescribed, directed set of annotated models. Architects can always develop more complex models and additional relationships; though EACOE realizes a focused set of straightforward models provide high value relationships that efficiently and effectively present, to business owners, the key discoveries that propel their strategic plans. Further progress to build out additional models is a good candidate parallel activity in subsequent iterations of the EACOE strategic initiative “evergreening” cycle.

EACOE suggests significant time be spent on modeling – however, the only end is not models – the end is a series of business aligned initiatives that move the organization to its desired state, derived from these models.

TOGAF ADM holds a perspective of four architecture domains as representing enterprise architecture – Business, Application, Information, and Technology (most notably based on the work of Stephen Spewak’s “BAIT” model) which TOGAF leaders acknowledge as an “IT stack”. Each domain stands on its own for its own purposes, and does not transform its understanding into any of the other domains; each must be interpreted within the other. The ADM cycle visually infers or asserts that the Application and Data architectures are derived from the business architecture, and the technology architecture from these two; this is a natural inference from the circular presentation and asserted “phase sequences,” however the ADM definition of each of these architectures’ and phases’ inputs shows no such waterfall or cyclic feed, no dependency, nor acknowledgement of prior phase models.

Such a heavy IT focus misses significant business opportunity in both problem and solution domains. Architects must map from each domain to the other without guiding transformations, and the resultant mapping may not be consistent without the guiding transformation.

EACOE’s Enterprise Framework assists in discovering value in the transformations from model to model. There are different models and transformations between them – not “decompositions” of details or mappings – to understand for each aspect of the business. A single model does not suffice.

Each of the six aspect models across the Enterprise Framework, therefore, holds a relationship to the models of that same aspect. This relationship is a transformation not a mapping. Mappings suggest one-to-one points within each model that restate the concept in a different perspective. The transformation and separation from one modeled level of abstraction to the next is one of the keys to enterprise agility/flexibility – the separation of independent variables, and “binding” to a solution as “late as possible”. Agility and flexibility cannot possibly come from continuing to “hand-craft” solutions smaller or faster – no matter what the methodology or technical solution suggests.

As one example, Materials (data) of interest to the business (one aspect) is transformed from five stratifications of abstraction:

  1. Described as a business understanding of the Material
  2. Described with relationships of one Material to another Material
  3. Described without constraint to any specific technology neutrality
  4. Described with a specific technology (or technologies), and
  5. Described within a specific solution (or solutions) using specific technology.

TOGAF seems to begin at the 3rd stratification, or targeting a technology at stratification 4.

In practice, architects build up the breadth and depth of each model in an iterative fashion, and would rarely reach absolute full definition in the first iteration. The intent of the models is to get the important information captured for the area of interest being modeled, to reduce risk through explicit understandings, and clearly communicated in the breadth and depth of detail of greatest value to each business decision maker. The ongoing change within and surrounding the various aspects of the enterprise clearly place a need for prioritization and reason across the organization, with respect to expectations upon and use of the architecture.

TOGAF certification is a test-center administered task of two parts, level 1 and level 2. Each level of the test consists of multiple-choice questions. If a candidate answers 70% of the level 1 ‘statement’ questions correctly, they have passed that level and are certified at level 1. If the candidate further acquires 24 of 40 points on the level 2 “scenario” questions, they have passed and are certified at level 2. Note that level 2 “scenario” questions yield points for all answers except the one explicitly wrong answer; correct answers get full points, and the other 2 “somewhat correct” answers get less than full points. Once you are certified, you are certified in “TOGAF v9 level 1 (or 2)”. There is no experiential component to be proven, maintained, and improved upon. It is somewhat concerning that the passing percentage is as low as it is stated. If the “exam” for a brain surgeon was based on this percentage, I would sure like to know what 30% was wrong.

TOGAF has used IBM’s “IT Architect Certification” (ITAC) as a basis for advanced “experiential” certification, beyond the basic level 1 and level 2 certification, through several of its versions (since 2005). Currently called Open CA, it remains an IT assessment (IT centric) and Open CA is not an enterprise architect certification. TOGAF had been planning a change and focal shift to Open CA, in order to address Enterprise Architecture.

EACOE emphasizes demonstrated and acquired skills, not one passing of a multiple-choice administered test. The emphasis is on recognizing that Enterprise Architecture skills are acquired through practice and experience, beginning in the EACOE Enterprise Architect Certification Workshop itself.

EACOE provides Enterprise Architecture education and certification on the Framework and Methodology described, consisting of the foundational concepts, developing Architecture Models, Implementation Models, and move-ahead business aligned initiatives.

Upon completion of the workshop, participants receive a two year title of “EACOE Certified Enterprise Architect.” Maintaining this Certification, after the initial two year period requires submission of Enterprise Architecture artifacts that are reviewed by EACOE Enterprise Architect Fellows. This approach is consistent with most certifications offered by professional organizations outside of information technology: engineering, medicine, law, accounting, etc.

Progressive levels of EACOE Architect Certifications require advanced levels of experiential work and broadening influence, levels that are granted by EACOE upon explicit presentation of the resultant works and their influence upon the architect’s business.

TOGAF refers indirectly to the architects as “architecture professionals” within the Architecture Capability Framework component, with the set of supporting concepts that underlie the ADM. Most references to those participating in the ADM are referred to as architects, but there is no concise definition of the responsibilities other than statements suggesting “roles and responsibilities should be defined”.

EACOE recognizes, defines and relates to one another the multiple roles within Enterprise Architecture.

EACOE identified and defined these architect roles and their interrelations, to identify where roles likely interact. The types of activities each is involved with are also defined to improve the overall understanding of architect responsibilities across the enterprise. These roles’ scopes of expertise and influence within the Enterprise Framework are shown below:
8. Identify Contemporary Business’ Multiple Architect Roles

These roles include:

  • Rule Assertion Architect,
  • Process Architect,
  • Data Architect,
  • Enterprise Architect,
  • Business Architect,
  • Policy Rule Architect,
  • Roles Architect,
  • Workflow Architect,
  • Logistics Architect,
  • Technology Architect,
  • Event Sequence Architect, and
  • Event States Architect.

EACOE recognizes that following each phase of architecture modeling, additional implementation modeling roles are required to produce a complete Enterprise Architecture. Implementation modeling role titles may appear more recognizable, as they have been highly visible as responsible for knitting together the many complex objects of the enterprise into “whole cloth” solutions, often times, unfortunately, without the aid of Architectural Model foundations.

Enterprise Architecture requires both Architecture Models and Implementation Models; thus, there is a unique need for specific implementation modeling roles.

Since there is a much larger number of possible implementation modeling roles than architecture modeling roles (many possible implementation modeling roles have been identified – e.g. Solution Architect, Information Architect, Application Architect, Service Oriented Architect, etc.), EACOE is working to delineate a consistent, effective workable set of roles and scopes for these Implementation Modeling “Architect” roles in a complementary chart and supporting document.

Implementation modelers can assess their specific role’s interactions with architecture modeling roles, set interaction responsibilities, training, and performance expectations to clarify their implementation modeling roles. This sequence of modeling is the key to agility, reuse, reduced time to market of solutions, and flexibility. The difficulty, of course, is that in most organizations, these roles have been defined without a common frame of reference, or without an exact understanding of what is to be produced by each role. This “randomness” is truly an unnecessary waste of resources. Adopting the Enterprise Framework as the reference frame of reference, allows for definitions of any role precisely, and unambiguously.


TOGAF and the ADM present information technology focused solutions, framed upon information technology focused prescriptive scenarios, and complex implementation models, and not developing true architectural elements, as defined herein. A stated strength of TOGAF lies within its large number of contributing members, over 300 IT vendors and IT clients. This strength is however muted by the overt emphasis on IT, and the sheer number needed to gain consensus on matters of importance makes valuable change slow to evolve. The resulting method and interpretation of Enterprise Architecture reflects a heavy IT presentation and flow. The ADM contains valuable guidance for IT project managers, project leaders, and IT architects to heed when addressing IT projects, and following this guidance with adept personnel should present stable deployments. However, it does not, in the author’s opinion, present an architecture or an architecture development approach; it does present a gathered cache of capable IT implementation approaches and advice accumulated over years of IT experience.

EACOE defines an understanding of Enterprise Architecture where architects use business language to develop human consumable and understandable artifacts and define a platform of knowledge, built by comparison and discovery, by investigation and refinement, all initially without specific IT demands, roots or ties. EACOE approaches Enterprise Architecture as first, how to envision and represent the enterprise business, and not as an IT thing, but as a fuller, more human consumable living and changing spectrum of discovery. This approach evolves to a more complete picture of the envisioned ever-changing enterprise as it meets the demands and challenges in the chosen market spaces. Enterprise agility and flexibility result from Enterprise Architecture and its enabled “make to order” technology implementations; enterprise agility and flexibility does not come from “handcrafting” applications and programs smaller and faster.

The intent of this White Paper is to bring a perspective and understanding to those that are interested in these popular Enterprise Architecture approaches. The author, Bernard Baillargeon, is a practicing and certified Enterprise Architect by both EACOE and The Open Group. He can be reached at [email protected].

Four Pillars of Enterprise Architecture

Four Pillars of Enterprise Architecture Driving Efficiency and Innovation by Consistently Managing Complexity and Change

By Samuel B. (Sam) Holcman

Summary: This article describes the four pillars of a holistic enterprise architecture: architectural models, framework, methodology, and solution models. It also explains the business and technology gains and demystifies the practice of implementing a successful holistic enterprise architecture.


It is only within the past 20 years that we have begun to develop an art and science for identifying and defining the graphical and textual descriptions of whole enterprises. Until this time, any art or science that we had related to this endeavor pertained to parts of enterprises—for example, organizational design and/or systems development. Because the focus of this article is on enterprise architecture, have there been successful enterprises that were never architected?

Yes. However, they were successful in relation to other non-architected enterprises. Moreover, the pace of change was slower in the industrial age, compared with the information age of today. Contemporary enterprises have to be able to adjust much more rapidly to meet changing demands in the face of global competition. This makes it critical to have readily available descriptive representations of one’s enterprise to use as a basis for making change.

The age-old question now arises in enterprises: How can one change something that one cannot “see”? How does one “see” an enterprise?

Benefits of a Holistic Enterprise Architecture

There are many benefits for both the business and technology areas of holistic enterprise architecture, but the following are a few of the greatest gains that have been observed.

Business Benefits

  • Developing and communicating a broad understanding of your business—a confirming enterprise-self realization that is clear and concise.
  • Identifying and mitigating potential risk in your selected paths of action or investment—thereby, reducing unintended consequences.
  • Clarifying your business priorities and identifying your core competencies—enabling you to assign key resources to projects confidently, and leveraging top talent for critical needs.

Technology Benefits

  • Creating a practical and efficient means to manage your information-technology portfolios, rationalizing your existing systems and projects to gain significant cost reductions, and helping you remove waste and redundancy in your information-system deployments.
  • Aligning your technology investments and assets to project initiatives that demonstrate direct support of priority business goals, competencies, and needs.
  • Identifying, classifying, representing, developing, and accumulating in an accessible portfolio your architected, highly reusable technology assets.
  • Identifying and mitigating potential impacts of your proposed solutions, services, or changes—thereby, addressing all areas that are affected in the design and negotiation of new or updated solutions, and reducing your exposure to the risk of unintended impacts and degradation.

There is much confusion today in the terminology that surrounds enterprise architecture. Let us attempt to demystify these terms and concepts.

Demystifying Enterprise

An enterprise is any purposeful undertaking, commonly used in connection with undertakings that have ongoing operations. Mowing your personal lawn is an undertaking, but you probably would not refer to it as an enterprise. A company that mows lawns for profit is an enterprise.

All enterprises have architecture simply by virtue of their existence, whether they are explicitly represented or not. Unfortunately, this does not mean that all enterprises have been explicitly architected, for that would imply that deliberate and disciplined thinking went into their design and implementation. Most enterprises “evolve” and grow or shrink over time, without much attention being given to identifying and defining their fundamental components; so that (among other things) decisions can be made to reuse existing components to satisfy new requirements, eliminate redundancies, or eliminate activities that do not align with strategic business planning.

Enterprises are complicated, because they are composed of not only fixed, physical components, but also behavioral components such as people and business processes.

Demystifying Architecture

The architecture of anything is:

  • Its fundamental organization—embodied in its components and their relationships to each other and their environment.
  • The principles that govern its design and evolution.

Everything that exists has architecture, whether it has been written down or not. That is the fundamental problem: Each person in an enterprise has an implicit representation of what they think the enterprise is all about. Architecture is an attribute and cannot exist by itself. A blueprint of a house is not its architecture; instead, it is one description of its architecture.

People built things for thousands of years without needing to be concerned about describing the architecture of the things they were building. As civilization evolved, however, large and complex construction projects—for example, temples, palaces, aqueducts, coliseums, and fortresses—that involved tradespeople of many skills, huge quantities of building materials of different kinds, and many years to complete, required a much more disciplined approach to building things.

Consequently, “building things” evolved into the art and science that we call architecture. As things get more complex, architecture becomes an imperative. When things are simple, you generally do not need architecture. Our complex enterprises of today need architecture.

Observations on Architecture

Architecture of Queen Anne Furniture

Architecture’s value is in its consistency across years of reuse. Queen Anne furniture is a particular architecture of centuries ago; the architecture has not changed since the early 1700s, and many items of antiquity and reproduction have been built to that design point (the Queen Anne furniture architecture). Furniture makers do not redesign the Queen Anne architecture; they build a Queen Anne desk. The design was done over 300 years ago, yet today it continues to communicate accurately the architects’ intent!

That is the beauty of architecture: When the initial investments have been made to articulate the business intent and direction within a holistic enterprise architecture, the follow-on changes and maintenance are much less costly, and the impact can be centuries of successful solution implementations!

LEGO® Blocks

Another effective analogy involves LEGO blocks. Imagine two individuals being given the task of building a play house. One has a set of LEGO blocks, and the other has to figure out what materials they are going to use and how they are going to be produced. Which one is likely to finish first? Which finished product is more likely to be changed faster to meet new requirements?

The architecture models in this example include the descriptive representations of the set of LEGO blocks, without any reference to any implementation.

The solution models include the descriptive representations of the various combinations of LEGO blocks.

Demystifying Enterprise Architecture

Enterprise architecture, as a discipline, is the art and science of building enterprises.

Enterprise architecture products are the graphical and textual descriptions that are used in the planning, design and implementation of, and ongoing changes to enterprises.

Architecture is the object—the end “product” that is to be achieved via an enterprise-architecture planning-and-design methodology (represented as a set of up-to-date, consistent, artifacts [written, drawn, recorded—communicated in persistent fashion]). Artifacts are statements of the enterprise’s intended state of being—its essence.

Holistic Enterprise Architecture

A holistic enterprise architecture is an invaluable communications vehicle that consistently conveys in a precise, accurate fashion, business items of importance, including assets, direction, and intent, to all stakeholders of the enterprise. Holistic enterprise architecture is “consumable” (usable) by both business and technology stakeholders. Successfully capturing the value of a holistic enterprise architecture is very achievable, if you approach the task in a thoughtful, guided fashion. This article shares the four significant components, or four “pillars,” of any successful holistic enterprise architecture effort.

Figure 1. Generic Four Pillars Model Click image to open large version



Your Goal: To Realize and Deliver Consistent Value
Survive. Grow. Thrive. Exceed expectations. Enjoy your efforts!

Successful leaders must prepare for opportunities and risks. They must endure difficult economies, surviving to seize emerging opportunities in the economic recovery, growing their business. These forward thinking leaders will exceed expectations by linking productive initiatives to desired goals and results; they will foster working conditions that are consistent and predictable in delivering true value. Workers enjoy their efforts when they know that there is a reasonable, thoughtful plan that the organization is following, and that their input is valued and recognized in defining and achieving the next level of success.

A tall order? Bold optimism? No, not at all! This is attainable, if the leaders recognize the need for, support, and advocate the consistent use of a practical, tailored, holistic enterprise architecture as a competitive differentiator. Holistic enterprise architecture is about understanding your enterprise. Writing more computer code just will not get you there. Holistic enterprise architecture—a concept that is about two decades old—is the linchpin to delivering consistent value every time.

We have begun to discover through thoughtful practice, the process of successfully achieving a practical holistic enterprise architecture. Through many real-world holistic enterprise architecture engagements, our experience reveals several consistent and key “pillars” of success in achieving usable architecture—the design for your enterprise. Your architecture will become the business solution engine.

Note the Difficulties in Achieving a Successful Enterprise Architecture

There are unfortunate cases of enterprise architecture efforts that stall or fail to deliver the envisioned value. At the core of such experiences lie confusion, expensive investments, and unbounded, unmet expectations. Some experts, vendors, approaches, and authors hype beyond reason, and they overuse and misuse the “enterprise architecture” phrase itself. Some improper uses include that it engulfs many business skills such as planning, forecasting, budgeting and project selection; these are separate, important skills that benefit from an enterprise architecture, but they themselves are not part of an enterprise architecture. The enterprise architecture participants becomes confused, “architecture paralysis” sets in, and may set misdirected expectations on the value and scope of an enterprise architecture.

Designing an enterprise architecture is a people-oriented analysis and solution, not one only of technology. The business knowledge of people forms your enterprise foundation.

Where to Begin?

We recognized in many actual holistic enterprise architecture engagements, a consistent set of required components for success; these four “pillars” are:

  • Architectural models.
  • Framework.
  • Methodology
  • Solution models.

The outputs of the holistic enterprise architecture effort are the architectural and solution models. Why both architectural models and solution models? Simply stated, beginning with architectural models simplifies the effort, while beginning with solution models leads to undue complexity, as will be elaborated.

Defining Key Terms

It is very important to define accurately and consistently use terms in order for them to be meaningful or useful in any context. This article strives to use accepted grammatical forms, to avoid later confusion and miscommunication.

Refer to the Key Term Definitions section for definitions.

The Four Pillars of Success

Pillar 1: Architectural ModelsPillar 2: FrameworkPillar 3: MethodologyPillar 4: Solution Models
Architecture is about identifying and understanding the “independent” artifacts (architectural elements); therefore an architectural model is a representation of one artifact from the perspective of one business view.

Observations on Architectural Models

From a business perspective, tremendous value has been obtained by providing graphical representations and textual descriptions of the six architectural artifact types. If no more than this amount of holistic enterprise architecture is completed, never-before-realized understandings and insights will be obtained. We call this “quick-strike” architecture—a common way of beginning holistic enterprise architecture.

In total, there are 30 possible architectural models: six artifact classifications, across five perspectives; two business-role perspectives; and three technology-role perspectives.

A framework is a logical structure that organizes for a specific subject, a set of related artifacts, shows the relationships of the artifacts of the chosen subject area, and brings a totality perspective to otherwise individual ideas. A framework, therefore, makes the unorganized both organized and coherent.

Three requirements of a complete framework are:
1. Consistent naming of the components and artifacts of the framework.
2. Fully defined and consistently templated terms for the components and artifacts of a framework.
3. A consistent and expressive set of graphical representations for each component and artifact.

Five Business Views of an Enterprise

We recognize two primary “types” of people who must understand the holistic enterprise architecture: business people and technology people. Each of these types has multiple views of how they understand the enterprise; each view covers the entire enterprise, yet describes it from a differing perspective or value understanding. Moving from one perspective to the next represents a transformation of understanding of the enterprise—from business understanding to potential solutions.

Business people (and some technology people) will want to have at least a view of the:

  • Business-understanding view.
  • Business-interactions view (between business artifacts).

Technology people (and some business people) will want to understand at least three other views of the enterprise—specifically, the:

  • Technology-neutral view.
  • Technology-oriented view.
  • Selected-technology view.

Assign each architectural artifact to one business view, which will result in a nonredundant understanding.

Six Artifact-Classification Types: The Classic Language Interrogative Abstractions

  • Why—Classifies goals and motivations of the enterprise
  • How—Classifies processes and functions that are important to the enterprise
  • What—Classifies things and data groups that are important to the enterprise
  • Who—Classifies people and organizations that are important to the enterprise
  • Where—Classifies locations and networks that are important to the enterprise
  • When—Classifies events and times that are important to the enterprise

Assign each architectural artifact to one interrogative classification type, which will result in a nonredundant understanding.

If we look at chemistry, music, language, electrical engineering, civil engineering, and chemical engineering, all of their unique frameworks have these requirements and characteristics.

Observations on Frameworks

Classic examples of a “framework” are the following:

  • The periodic table of the chemical elements
  • Musical notes and “structures.”
  • The 26 letters of the English alphabet

These are all “architectural frameworks,” as they contain only “elements” (architecture) and not “compounds” (implementations).
There is nothing in these frameworks that tell you how to build anything, whether top-down, bottom-up, or middle-out.

A methodology consists of practices and procedures applied to a specific branch of knowledge. A methodology tells you how to build a particular type of thing. The methodology is, therefore, dependent on the selected framework. For example, the methodology to “make music”, is much different than that to “make water” (chemistry framework), and is much different than that to “make words or sentences” (alphabet framework).

A methodology has proven processes that can be followed in planning, defining, analyzing, designing, building, testing, and implementing the chosen artifacts.

Observations on Methodology

The concept of a methodology that is “framework-neutral” would be so abstract and arbitrary that it would have limited value. A “framework-neutral” methodology would look something like the following:

Plan, analyze, design, construct, implement

This “methodology” could be used in any domain to do anything (of questionable quality).

Test your enterprise-architecture methodology to see if it can be used to bake a cake (seriously!).

The author suggests that we can all agree that this “methodology” would have limited value.

A successful methodology:

  • Guides a process.
  • Simplifies a process.
  • Standardizes a process.
  • Can be customized to meet specific standards and practices of the organization that is using it.
  • Is accurate, as demonstrated through repeated practice.
  • Is up to date.
  • Is complete.
  • Is concise.
  • Defines deliverables and metrics.
  • Has methods, techniques, standards, practices, roles, deliverables, and associated education.
Solution models are about understanding and combining “independent” architectural elements to begin to build something. Each solution model focuses on a single solution description, and each is chosen to perform or contribute a given thing of value.

Solution models and their implementations achieve the realization, application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy.

Examples of typical solution models would include the following:

Solution-Model Interrelations

There are 57 interrelations between the six artifact-classification types that can be defined, for each business view:

  • 15 possible two-dimensional interactions
  • 20 possible three-dimensional interactions
  • 15 possible four-dimensional interactions
  • 6 possible five-dimensional interactions
  • 1 possible six-dimensional interaction

Thus, there are 285 possible solution models: five business-view perspectives, each of which holds the set of 57 artifact interactions.

You certainly need not build all of these models. It is suggested only that these are all of the possibilities, and our “profession” has been looking at only a very few of the possible solution models, without understanding all of the possibilities for solution models. Furthermore, this could be why all of the desirable features of any specific technique have not led to the consistent benefits that we are seeking: portability, interoperability, reusability, scalability, reduced time to market, reuse, simplification, and so on.

This fundamentally incomplete model might be leading us to believe that we are designing our “architecture,” when actually we are performing the design phase of our “implementation.”

  • “Object model”—Relates data (what) to methods (how) to actors (who)
  • “Dataflow diagram”—Relates data (what) to processes (how)

Architecture models are engineering models; solution models are manufacturing models. Both are required in the “physical world”; both are required in the “information world.”

This article does not suggest that solution models are bad, but that architecture models are different from solution models. It also suggests that architecture (engineering) models come first (as in any profession that is known to humankind, to date), and we should derive the required solution (manufacturing) models from the architecture models.

Implementation of the definitions of these solution models consists of two primary parts: construction and delivery.

For a technology solution, construction includes the:

  • Selection of hardware, software, and vendors for the implementation.
  • Planning and preparation of risk mitigation (disaster recovery, data backup, distributed and clustered processing, hot-swap, and so on).
  • Building and testing of the network-communication systems.
  • Building and testing of the data stores.
  • Writing and testing of the new program modifications, including iterative business-user test feedback.
  • Installing and testing of the total system from a technical standpoint, and so on.
  • Planning, preparing, documenting self-service helpdesk resources, and training staff for providing warm-body helpdesk services.

For a technology solution, delivery is the process of:

  • Conducting final system and user-acceptance testing.
  • Preparing the conversion plan.
  • Installing the production data stores.
  • Providing training or training materials to new users, including helpdesk services.
  • Converting all relevant operations to the new services.

Meta-Methodology to a Holistic Enterprise Architecture

We can demonstrate the context of the pillars through a “meta-methodology.” While some of the described steps might be one-time, initial preparation, most are applicable to each phase or pass through the holistic enterprise architecture activities. (See Figure 1.)

Briefly, we could simply define our required meta-methodology to be the following:

  • Develop architectural (engineering) models.
  • Develop solution (manufacturing) models by drawing upon architecture models and architecture elements.
  • Assemble implementations from these solution models.

This is too brief to be really useful, so let us elaborate with more detail.

Partition the Scope: Establish Bounds of Coverage Click image to open large version

Set clear and attainable bounds upon the area of the enterprise to be investigated as the area of interest to be architected and designed. For example, boundaries could be corporate strategic planning, human resources, a subsidiary, or a large department. Of course, the whole enterprise (or more than just one enterprise) could be the bounds of coverage. See Figure 2 below.

Select a Dedicated Team of Key Individuals

It is desirable to have the business area of the enterprise being exercised dedicated to discovering and defining the key business artifacts for their scope of influence. However, proven techniques are available to begin holistic enterprise architecture without strong business support (of course, not as desirable). It is better to represent the best understanding available than to move directly to implementation.

Define and Represent Your Architecture

You will place the initial focus on the architecture “designers’” domain for understanding, and later focus on the “builders’” domain of implementation.

  • Step 1: Select and prioritize architectural models that are of value to the enterprise. See Figure 3 below. Click image to open large version

    Figure 3. Pillar 1: Architectural Models
  • Step 2: Organize the architectural models, as defined in the architectural framework. See Figure 4 below. Click image to open large version

Figure 4. Pillar 2: Framework

  • Step 3: Follow a lean and proven methodology that supports the framework to develop architectural models. See Figure 5 below. Click image to open large version

Figure 5. Pillar 3: Methodology

  • Step 4: Describe and represent the enterprise within the architectural models.

Execute Your Architecture Design

The “builders’” domain hopefully will contain an ever-accumulating and reusable set of solution models. Here, you use the architectural models to derive and develop solution models. See figure 6 below. Click image to open large version

  • Step 1: Select an implementation domain team of key individuals from both business- and technology-perspective groups.
  • Step 2: Educate the Implementation domain team on the architectural models, framework, and methodology.
  • Step 3: Select and prioritize solution models that are of value to the enterprise.

Figure 6. Pillar 4: Solution Models

  • Step 4: Describe and represent the solution models to exercise the architecture in defining viable candidate solutions and services.
  • Step 5: Educate the architectural-domain, business-project, and information-technology project teams on the solution models. Share the wealth!

Expand Your Holistic Enterprise Architecture Coverage

  • Step 1: Select the next “slice” of the enterprise to address, expanding upon the work that is already completed. Adjust the coverage of the models to reflect discovered value. See Figure 7 below. Click image to open large version

Figure 7. Complete Four Pillars Model

  • Step 2: At this time, both the business- and information-technology project teams can begin to implement priority candidate solutions and services, based upon the solution models.

Demystifying the Practice of Holistic Enterprise Architecture

We are now at a point in the maturity of holistic enterprise architecture where all of the required “pillars” are becoming consistently achievable. All of them—architectural models, framework, methodology, and solution models—are required for success. “Best of breed” will not work; it has not worked in other disciplines outside of information technology, and it is doubtful whether it will work for enterprise understanding and information technology.

When your enterprise has a consistent body of knowledge through these pillars, the resulting intellectual capital will define a complete and executable set of consistent practices and designs that will provide measurable (and immeasurable) value to your enterprise. Your enterprise will dramatically increase its success rate for delivery of valued business solutions, as all parties will understand your enterprise through its up-to-date holistic enterprise architecture, and all implemented solutions will derive from your architecture. That day is very near in some organizations.


Any article of this length can just provide an overview for understanding these pillars. It is hoped the reading audience will understand that this is just a high-level summary. At least four years (and many books!) are required to get a bachelor’s degree (a substantial but not exhaustive level of understanding) in all of the fields of precision, such as electrical engineering, music, and chemistry.

It is hoped also that this article provides a beginning for those in our profession pursuing their “bachelor’s degree in holistic enterprise architecture,” an understanding for those who are responsible for enterprise architecture activities, an understanding of the enterprise architecture for the “receiving” community, and a wider understanding of these pillars for holistic enterprise architecture success!

It is time to move from the hype stage of enterprise architecture to holistic enterprise architecture. It is time to move from theory into practice and action. Holistic enterprise architecture drives enterprise efficiently and innovation by consistently managing complexity and change.

Key Term Definitions

Architectural elements: Each instance of an architectural model is an architectural element of the architecture. Note that this is a subset of “artifact,” in that not all artifacts are architectural elements.

Architectural models: Each model is a representation of one artifact from the perspective of one view.

Architecture: The art and science of building something, and the manner in which its components and artifacts are organized and related. The Greek root of architecture means “master builder.”

Artifact: Each artifact uniquely and non-redundantly defines a “thing” of interest to the enterprise, and each can be classified with one artifact-classification type, and with one view.

Artifact-classification types: Classify each architectural artifact as answering one of the six classic language interrogatives: Why? How? What? Who? Where? When?

This classification helps organize ideas and concepts into logically common groups. This classification helps discover overlaps, gaps, and opportunities.

Business views of an enterprise: Five views that gather artifacts across all six artifact-classification types, where all such grouped artifacts help to define the enterprise perspectives. Each view represents a transformation of understanding of the same architectural artifacts:

  1. Business-understanding view:
    This view represents models of the architectural elements.
  2. Business-interactions view:
    This view represents models of interactions between each artifact, models of their relations, and constraints.
  3. Technology-neutral view:
    This view represents architectural models to reflect an architectural element in a robust yet non-technology-dependent manner.
  4. Technology-oriented view:
    This view represents the manner in which architectural models reflect existing or proposed technologies, including alternatives.
  5. Selected-technology view:
    This view identifies choices of technology, and the manner in which architectural models are to take advantage of those selected technologies.

Enterprise: Any collection of organization-related or people-related things, all of which have a common set of interests (such as goals, principles, or a single bottom line). In this sense, an enterprise can be a whole corporation, a division of a corporation, a government organization, a government agency, a single department, or a network of geographically distant organizations that are linked together by common objectives, a project, a team, and so on.

Enterprise architecture: Enterprise architecture is about understanding the enterprise through:

  • A set of independent and non-redundant artifacts.
  • The interrelations between these artifacts.
  • Communicating these understandings to the numerous people who make up the enterprise.

Framework: A logical structure that organizes, for a specific subject, a set of related artifacts, shows the relationships of the artifacts of the chosen subject area, and brings a totality perspective to otherwise individual ideas. A comprehensive framework has a consistent naming of the components and elements of the framework, all terms for the components and elements fully defined, and a consistent and expressive set of graphical representations for each component and element.

Holistic enterprise architecture: An enterprise architecture that is developed and maintained by using the full complement of the four pillars of successful architectures: architecture models, framework, methodology, and solution models.

Interrelations: These are the relationships, interactions, and constraints that individual elements and artifacts have to each other. A reflective relationship is an artifact of one classification type being related to other artifacts of that same type.

Examples of architectural-model reflective interrelations would be a:

  • Process (how) relates to another process (how).
  • Data group (what) relates to another data group (what).

Examples of solution-model non-reflective interrelations would be a(n):

  • “Object model”—Data (what) relates to a method (how) relates to an actor (who).
  • “Dataflow diagram”—Data (what) relates to a process (how).

Methodology: Consists of practices and procedures that are applied to a specific branch of knowledge.

People: We recognize two primary “types” of people who need to understand the holistic enterprise architecture: business-focused people and technology-focused people.

Solution models: Each solution model is about being able to understand and combine “independent” architectural elements. Each focuses on a single solution description; each is chosen to contribute a given specific entity of business value.

About the author

Samuel B. (Sam) Holcman is the Managing Director of the Enterprise Architecture Center Of Excellence (EACOE), the Business Architecture Center Of Excellence (BACOE), the Chairman of Pinnacle Business Group, Inc., and the President of the Zachman Institute for Framework Advancement (ZIFA). He is considered the practitioners’ practitioner in enterprise architecture, and a leading implementer of and worldwide educator in enterprise architecture methodologies and techniques. Sam can be reached via e-mail at [email protected], or via telephone at (810) 231-0531.

Measuring an Organizations Capability Ability

Measuring an Organizations Capability Ability

By Samuel B Holcman

Capability Defined:

A capability is an integrated composite of goals, processes, data, roles, locations, and events that are organized to drive a company’s strategies to a specific desired outcome. Examples of names of capabilities includes development of products, management of vendors, protection of intellectual capital, development of web sites, management of logistics, buying of merchandise, management of customer relationships, innovation of technologies, marketing to international locations, management of brands, extensions of brands, innovation in manufacturing techniques, etc. The list of names of capabilities is endless! Of course, to completely and definitely understand a capability, an explicit definition of each capability is required. At a minimum, the definition of a capability must include the names and definitions of the goals, processes, data, roles, locations, and events that represent that capability.

An example of capability is shown below. Click image to open large version:

Capability Ability:

We often see an organization’s capability ability measured by only one number or measure. Since a capability contains a number of attributes or artifacts that the organization has various competencies within, a measure such as this is quite misleading. This is like telling someone that the average height of building in New York City is seven stories – quite limited in usefulness!

To accurately gauge an organization’s ability/competency of a capability, a truer picture of each “artifact’s” competency is required. As an example, an organization may be good at doing the process “Outfit Sailboats”, but has difficulties with the process “Prepare Charters”. Or, an organization may be good at achieving the goal “Achieve Zero Sailboat Complaints” but the organization’s “Charter Operations” roles are poorly defined and executed.

In order to accurately provide organizational guidance for increasing a specific competency, we have developed the Competency Radar TM – an easy to understand visual that precisely provides an organization with this guidance. An example of a Competency Radar is shown below:

Click image to open large version:

If 100% of the Preparation of Boat Charters competency was being achieved, the six measures would all indicate “100”. This Competency Radar map would indicate that the organization was meeting approximately 50% of its Goals objective, 30% of its Process objective, 80% of its Data objective, 10% of its Roles objective, 70% of its Locations objective, and 60% of its Events objective. Further details can be displayed for each of these attributes, as shown below:

Click image to open large version:

This Competency Radar, related just to the Data objective, shows 50% of the Sailboats data objective, 30% of the Suppliers data objective, 80% of the Maintenance data objective, 20% of the Customers data objective, 70% of the Preferences data objective, 60% of the Charter Data objective, and 40% of the Sales data objective being achieved, from a desired score of 100 from the Preparation of Boat Charters competency. An organization can quickly, and precisely, determine the path to capability competency by addressing areas of improvement identified by these Competency Radar maps.

If you are using analyzing capabilities in your organization, Competency Radar maps are essential!

The Value of Enterprise Architecture

The Value of Enterprise Architecture

by Tony Brown


I am sometimes asked to help people justify the cost of establishing an enterprise architecture (EA) program as a “return on investment.” This is a tall order. I liken it to trying to justify the cost of an activity such as strategic planning. How do you quantify the value of activities that create knowledge, clarify thinking, aid in analysis and decision-making? Many don’t even try, accepting that such activities can perhaps be carried out more efficiently but not eliminated entirely. So why is it so difficult for people to view EA in the same light?

One reason could be that most existing organizations were not architected formally to begin with, and they can probably continue to exist as they always have, at least in the short term. In other words, the urgency or the benefits of implementing an EA program may not be very evident. Another reason may be that most EA programs originate in IT organizations. If there is little or no understanding of EA by the enterprise’s business executives then, as with IT projects, there is a natural tendency to ask for a business case analysis including an indication of savings or increased profit that might be expected from such an endeavor.

In his article, “You Can’t ‘Cost-Justify’ Architecture,” John Zachman makes the point that cost-justification for increased automation is an Industrial Age notion when computers were employed to do the same old things faster and cheaper than people could. That age is gone forever. Information Age concepts stimulate thinking about using automation technologies to do things that never could be done before, and enterprises that adapt to this reality will outperform (and outlive) those that don’t. In this environment, architecture must be thought of not as a way of reducing other costs but as a strategic information asset to be used to shape and re-shape the enterprise at will.

In the same article and in his presentations John describes how architecture is used to achieve enterprise alignment and integration, to manage change, and to reduce “time-to-market.” 1 These benefits, he says, comprise the value of EA. I have found the logic behind John’s approach to be compelling and have often recommended his article to others. The approach I would like to take in this article is to examine some other stated benefits of EA and to flesh them out with case study success stories that I have personally been involved in or have heard of. I have selected six commonly reported EA benefits for review, namely:

  1. Readily available documentation of the enterprise;
  2. Ability to unify and integrate business processes across the enterprise;
  3. Ability to unify and integrate data across the enterprise and to link with external partners;
  4. Increased agility by lowering the “complexity barrier”
  5. Reduced solution delivery time and development costs by maximizing reuse of enterprise models; and
  6. Ability to create and maintain a common vision of the future shared by both the business and IT communities, driving continuous business/IT

As will be seen, although the primary intention for implementing EA may not be to reduce costs, it can in fact provide some stunning returns on investment.


EA Value to Enterprises

(1) Readily available documentation of the enterprise

I first became aware of the importance of enterprise documentation when I worked in a headquarters organization that was responsible for the engineering and maintenance of military air traffic control systems in Canada and overseas. The documentation for every remote site included not only information about all of the electronic equipment, circuit diagrams, etc., but also “as-built” drawings and photographs of each installation. For any given site, we could pull out the drawings and see exactly where components were placed in any room. All air traffic control sites were under “configuration control,” meaning no changes could be made to any installation without their going through a formal approval process. The “as-built” drawings were amended as changes were approved and implemented. Such tight management of the configuration of the air traffic control systems and documentation about them reduced the risk of unauthorized changes that might have safety implications. It also greatly reduced the time it took to make the authorized changes, as the engineers back at headquarters didn’t have to start from scratch. A similar “configuration control” concept was applied to air traffic control policies and procedures.

The same disciplined approach to managing documentation may be found in all enterprises where influence over decisions and control of behaviour are considered essential to the safety, security and execution of the enterprise’s mission. They wouldn’t stay in business very long if they didn’t take such an interest in recording “how things ought to be.” (Think nuclear power plant.)

The benefits of enterprise documentation, or architecture, are not limited to cases where safety and security are on the line. They apply to any enterprise where stakeholders need to be able to “see” the enterprise not only as it is and but as it is envisioned to be, assuming its owners wish to bring about changes and need to communicate a common understanding of them to stakeholders who are not only affected by the changes but are also expected to participate in bringing them about. The value of EA in this regard is usually expressed in terms of its ability to serve as a thinking and communications tool, and as a tool for knowledge management and change management.

(2) Ability to unify and integrate business processes across the enterprise

This benefit is sometimes likened to putting marbles into a bucket to weed out the duplicate ones. In the same way that marbles of the same colour can be easily

identified and removed once collected together, so too can duplicate processes in different parts of an organization be identified by EA. You may not want to eliminate all duplicate processes, but you certainly should wish to integrate them by using common infrastructure to carry them out.

Case Study – NORAD2: At North American Aerospace Defense Command’s underground combat operations centre at Cheyenne Mountain in Colorado Springs, Colorado, there were three aging legacy systems, each built and maintained by different program offices and using different equipment and software. After defining the processes involved it was then possible to do a side-by-side comparison, and a significant amount of overlap was found in the processes of each system. Each system involved monitoring the situation, assessing the situation, planning operations and executing operations. The legacy systems involved approximately 370 individual processes. After the redesign effort, which was enabled by the EA endeavour, the number of unique processes was lowered to about 80.

(3) Ability to unify and integrate data across the enterprise and to link with external partners

This benefit is often spoken of in terms of the ability to capture data once and to reuse it, as required, throughout the enterprise in different processes and applications. This saves time and money and greatly improves the ability of different applications to interoperate. Another benefit relates to workers being able to derive knowledge by relating sources of information in different parts of the enterprise, e.g., to answer a question such as which business processes are carried out by which people?

Achieving such an “integrated information environment” within and across enterprises, and eventually across extended enterprises, requires a top-down, disciplined approach to ensure consistent meaning of concepts across all of these jurisdictions. There is increasing pressure for government and commercial enterprises to consolidate or harmonize their services as much as possible. Some government interjurisdictional initiatives have already been undertaken to provide “one-stop-shop” service to meet the needs of citizens who don’t care which level of government is providing which service. Architecting such “extended enterprises” by creating and maintaining descriptive representations of them helps not only in their initial design but also in the ability of the contributing partners to make any necessary changes as required. The impacts resulting from any change in one area are more readily discerned when a whole “extended business” is available for analysis.

Wal-Mart is the textbook success story on the commercial side of the coin with suppliers being kept informed through cash register transactions as to the shelf inventories on hand so that they know directly when to ship replacement items.

(4) Increased agility by lowering the “complexity barrier,” an inhibitor of change

Some have described the enterprise as the most complex of concepts to understand fully. Other areas of knowledge typically are restricted to one kind of object, e.g., plants in the case of botany. Enterprises comprise, people, organizations, things, processes, goals, policies, rules, events, locations, and so on. For large organizations, it is impossible for people to retain and work with so many variables to bring about meaningful change unless information about them is documented through EA.

I had a discussion recently with an individual who works for a company that provides an online service for printing books, greeting cards, T-shirts, coffee mugs, etc. You send in what you want printed in the desired form and quantity; they carry out the order. The business was started by one man in 1999 and has grown to well over 100 employees by 2004. Very little knowledge about this highly automated enterprise has been made explicit. Most of it is locked in the owner’s head, making it very hard for the staff to make changes to order entry and accounting rules, to add new product lines, to increase the capacity of the system to meet an exploding demand, etc. When the system is changed to meet a new requirement, errors often occur in unexpected places, greatly increasing the time to make changes. This company, which almost collapsed under the strain of online shopping last Christmas, is in dire need of architecture to help it become more agile and to help it survive.


(5) Reduced solution delivery time and development costs by maximizing reuse of enterprise models (descriptive representations of enterprise elements that are meant to be shared or standardized across the enterprise)

In the past, information systems have traditionally been designed and implemented, from scratch, on a case-by-case basis. In the absence of reference models for data, processes, technology, etc., designers on these projects would have to create their own models to meet specific business requirements. This in turn has resulted in “stovepipe” solutions that are not interoperable and are relatively expensive to maintain. Systems developed in an EA environment, on the other hand, tend to avoid these difficulties.

Over the longer term, monetary savings from the effective use of EA should greatly exceed the costs of an architecture program for the same reasons that standardized interchangeable parts have brought down the costs of building and maintaining automobiles. Intuitively there are bound to be economics-of-scale benefits of using well-designed, standardized, reusable parts (both logical and physical) on an enterprise-wide basis. Increasingly over time the EA fosters benefits such as reductions in development time, fewer project failures, and tighter linkage of applications to business needs.

Case Study – Ohio Bureau of Workers’ Compensation3: Case studies illustrating this benefit are rare because, to be convincing, one must compare the time and cost to deliver the same IT solution under two different conditions: (1) architected from the top down; and (2) classical system design method. However, the State of Ohio’s experience with the design and development of an information system to support its workers’ compensation program in comparison with another (unnamed) state has been documented. This system makes payments for medical treatment, supplies and services rendered to an injured worker when such treatment is necessary.

3 From “Enterprise Architecture: Value Proposition,” a presentation by John Zachman. Original data from Doug Erickson. Additional information provided by Janet Domrose, Assistant Director, Ohio Bureau of Workers’ Compensation IT Applications.

The Ohio Bureau of Workers’ Compensation information system was architected with reuse in mind. In the course of developing the original application, a Rates System, which was implemented in the fall of 2000, 594 entity types were created, many of which were reused in the development of the subsequent following systems:

  • Payment System – 690 entity types (reused 294)
  • Retroactive Billing System – 228 entity types (reused 218)
  • Health Care Provider System – 320 entity types (reused 179)4Total number of times original entity types were reused – 691

The same application was developed for another state using the same CASE tool5. In this case, however, a rigorous, top-down enterprise architecture method was not followed. Teams began development work using traditional systems analysis techniques (vs. enterprise analysis). The experiences of the two cases is summarized in the following table:

State of Ohio Different State
Original Application Workers’ Compensation Rates System Workers’ Compensation Rates System
CASE Tool IEF/CoolGen IEF/CoolGen
Methodology Architected Classic
Entity Types 594 300
Elapsed Time 3 years6 12 years
Development Costs $3.5 million $42 million
Cost per Entity Type $5000 $140,000

It is interesting to note that in the case of Ohio, the 691 times that entity types that were reused in the follow-on systems amounted to a cost avoidance of $3,455,000 (691 x $5000).

In addition, the Ohio State’s Rates System includes 115 procedures (programs) and 1177 modules (callable actions from the programs). The 1177 modules are used 3112 times in the various procedures, giving a reuse factor of 2.64 (3112 ¸ 1177). This is attributed to the granularity and precision of the architected data model, with many processes being able to use the same data.

(6) Ability to create and maintain a common vision of the future shared by both the business and IT communities, driving continuous business/IT alignment

Aligning IT investments with business direction has long been recognized as an important principle in enterprise architecture. Before the Information Age, the motivation for business and IT alignment may have been primarily associated with reducing unnecessary expenditures. Today, however, the issue has a much greater significance because information systems can no longer be thought of just in terms of an enterprise’s supporting technology, they define the enterprise. In other words, the System is the Enterprise.

The value of EA in this regard is that it forces the harmonious linking of strategic and business planning to business architecture, from business architecture to IT architecture, and from IT architecture to IT implementation. EA forces this because EA discipline requires all this knowledge to be made explicitly visible and to be used as a basis for approving IT investments.

Case Study – U.S. Federal Government: The U.S. Information Technology Management Reform Act of 1996, often referred to as the Clinger-Cohen Act, made it mandatory for all 116 of the U.S. federal departments and agencies to develop and use EA for IT investment planning and decision making. The most recent formal survey7 found that five agencies — the Environmental Protection Agency, the Labor Department, the National Science Foundation, the Office of Personnel Management, and the Federal Emergency Management Agency — had fully working architectures in place. The Environmental Protection Agency (EPA) now uses their EA to drive all IT investments and even includes unclassified versions of it on CD in contracts with vendors8 so that they may be better able to align their efforts with the envisioned future state for EPA.

Case Study – Volkswagen of America9: Volkswagen of America, following the Enterprise Architecture approach developed by Samuel Holcman of the Pinnacle Business Group, Inc. – EACOE – Enterprise Architecture Center Of Excellence, is a company of 2500 employees that imports VW, Audi and Bentley automobiles for the U.S. and Canadian markets. This company has been successful in implementing a top-down, business driven enterprise architecture that has led to:

  • Business support at the CEO level;
  • EA as being the recognized approach that drives both the business and technology strategies (corporate wide);
  • Business defining clear goals for the next five years and assigned business owners;
  • Alignment of budget planning and allocations with business goals;
  • Reorganization of people and departments based on EA analysis of functions and organizations;
  • The launch of a technology strategy and a related program of IT initiatives;
  • The creation of a three year system retirement plan, providing the company with savings in operational expenses; and
  • The ability to prioritize technology projects based on business



Six benefits of EA have been highlighted in this article in terms of the value they bring to specific enterprises. In some cases, EA value is financially quantifiable. The Ohio Workers’ Compensation Bureau case study is a prime example of that, although it may be questioned based on the information provided if that is an example of excellent systems development rather than EA per se. In any event, it certainly is a good example of an “architected approach to systems development” in that system elements were designed from the start with re-use in mind.

Without doubt, the Volkswagen of America example is a model EA success story, reflecting the full, top-down value of EA to the enterprise. The specific points cited in the case study could perhaps serve as a benchmark for a fully mature EA program.


  1. Government personnel should not dismiss “time-to-market” as being only a commercial concern. The concept of “market” includes citizen requirements and expectations with regards to government services.
  2. Article, “Serious About Enterprise Architecture,” by Joab Jackson, published in Washington Technology, February 18, 2002.
  3. From “Enterprise Architecture: Value Proposition,” a presentation by John Zachman. Original data from Doug Erickson. Additional information provided by Janet Domrose, Assistant Director, Ohio Bureau of Workers’ Compensation IT Applications.
  4. At the time of writing this system is not yet in production – only modeled.
  5. Short for Computer Aided Software Engineering tool. CASE tools help automate, manage and simplify the system development process. This has been mentioned to indicate that the conditions for the two cases were virtually identical.
  6. One year for start up/requirements/modeling sessions, etc., and two years for actual development.
  7. U.S. General Accounting Office Report to Congressional Committees, “Enterprise Architecture Use Across the Federal Government Can Be Improved,” February 2002.
  8. Article, “EPA puts architecture info in contracts,” Sara Michael, Federal Computer Week, September 24, 2003.
  9. Source: A presentation made at the Zachman Institute for Framework Advancement Forum by Edward Rybicki, November 2003.

Welcome to the EACOE

Sam Holcman, our Founder and President, introduces you to the Enterprise Architecture Center of Excellence and gives you more insight into what we do.

Enterprise Architect 3.0 Certification

Using Enterprise Architecture, we can move organizations from the Industrial Age, through the Internet Age, enabling them in the Information Age.

Webinar: Addressing Coding -Your Highest Security Concern

Every day we hear about new breaches into our computer network and systems.  And who knows what we are not hearing about!

The reactions are always the same:  it’s the opposition political party, it’s foreign governments, it’s “professional hackers”, it’s our competitors, it’s, it’s, it’s them!!

Perhaps instead of looking outside for the culprit and at the symptom, it is time to look in the mirror, and at the cause.

Cloud Sales Are Booming: So Why Are Adoption Rates Down?

Cloud sales are booming but why are adoption rates slowing? via the Wall Street Journal