Cart 0
Workshop Attendee Details and Dates EACOE Enterprise Architect Certifications Register And Attend A Training and Certification Workshop Workshop Attendee Testimonials
All Solutions and Services On-Demand Services Enterprise Architecture Health Assessment Executive Briefings Application Portfolio Optimization and Rationalization Process Visualization Masterclass AI Data Modeling Masterclass
Compare Enterprise Architecture Approaches Case Studies: What are enterprises doing? TOGAF® Certified? What is next? About EACOE FAQ
Public Resources Definition of Enterprise Architecture Comparing Enterprise Architecture Approaches Enterprise Architect Job Description Enterprise Architecture Framework Podcast Episodes Upcoming LIVE Webinars Our Book: A Pragmatic Guide For Practitioners & Stakeholders TOGAF® Falls Short in Practice Enterprise Architect vs Solution Architect: Key Differences Explained
Cart 0
For Practitioners by Practitioners. Baseline for addressing and managing change.

Enterprise Architecture Frameworks: A Practitioner's Comparative Guide

Many organizations that pioneered Enterprise Architecture efforts rightly recognized that the status quo had to change and set out to build something better. However, they did so without a clear understanding of fundamental elements such as frameworks, methodologies, architecture models, and implementation models, which made it difficult to achieve consistent, repeatable results.

The first very misunderstood word is “framework.” A phrase that may be more useful is a “frame of reference.”

Article Summary: This article answers frequently asked questions about Enterprise Architecture Frameworks based on logic, sound practices, and principles based on over 4,500 of field engagements and five decades of Realistic, Enabling, Actionable, Logical (R.E.A.L.) Enterprise Architecture Results.

The Article answers:

Why is an Enterprise Framework Important?

Summary: Organizations are adding complexity by mapping different frameworks, languages, and notations to an environment that is already too complex to understand. As human beings, we are naturally "visually" oriented. We cannot "see" the essence of a problem or solution in 400 pages of text. What pages and pages of text on a company’s performance cannot achieve, EACOE Enterprise Architecture can, with its visual and graphic impact.

 

  • As an analogy, the major value of a blueprint, if it is constructed using a universally understood “language,” is that the same meaning is obtained no matter who is interpreting the blueprint.

  • A blueprint’s value is severely limited if the author is the only person who can consistently interpret the representation. Using a frame of reference that everyone understands is imperative.

  • To make explicit representations easier to understand, the organization should work with a consistent set of diagrams and symbols that everyone understands. This is what EACOE Enterprise Architecture provides.

 

What is a Framework (Frame of Reference)?

 

Framework Defined:

A framework is a structure that organizes a set of related artifacts. It shows the relationships among the artifacts of a chosen subject area and brings a totality perspective to otherwise individual ideas.

A framework, therefore, makes the unorganized organized, and coherent.

  • It is simply a thinking tool. And as a thinking tool, a "true" framework will never have an "output."

  • Framework elements must be mutually exclusive and collectively exhaustive.

Framework Requirements:

Three requirements of a complete Framework are:

  • consistent naming of the components and artifacts of the Framework,

  • fully defined and consistent- templated terms for the components and artifacts of a Framework, and

  • consistent and expressive set of graphical representations for each component and artifact.

 
 

What are examples of frameworks?

Frames of reference are fundamental to any profession or discipline (engineering, chemistry, physics, linguistics, music—anything).

Three classic examples of a Framework that resulted in professions include

(1) Mendeleev Periodic table of the elements,

(2) the notes in music,

(3) the English alphabet. 

There would be no “profession” without agreed-to stable Frameworks – Frames of Reference.

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

Framework Examples (Notes of Music, Periodic Table of Elements, Alphabet)

Do Frameworks have Version Numbers?

A framework that is in constant update and versioning is troubling. If it is, it is not (or was not) complete. If we are using Version 4 of a so-called "framework" and now a new Version 9 has been released…. What does that say about the work we did with Version 4?

  • Can you imagine the English alphabet starting with fifteen letters (Version 1), then going to twenty-one (Version 2), and then twenty- six (version 3), with more proposed arrangements yet to come? How useful would that be?

  • Can you imagine the periodic table of chemical elements having multiple versions? Chemistry would be alchemy.

  • Can you imagine the notes of music being in continuous versioning? (It would be enjoyable to play in an orchestra.)

 

What is a Methodology? That’s just another word for “framework,” right?

 

No. 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 (at least not in the physical world. We can’t see how it could be different in the Enterprise Architecture world).

 
 
 

Methodology Defined:

A methodology is a set of practices and procedures applied to a specific branch of knowledge. A methodology contains proven processes to follow in planning, defining, analyzing, designing, building, testing, and implementing the area under consideration.

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

Methodology Examples (Songs, Chemical Compounds, Words)
 
 

Methodology Misconceptions:

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 this:

Plan, Analyze, Design, Construct, Implement.

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

Guidelines or principles are not methodologies either. A guideline might tell you what operations you can do or provide suggestions on deliverables.

Methodologies should provide a predefined path or paths – a "roadmap" or a "recipe."

A methodology should allow you to do something "Monday morning"—you shouldn't have to figure out how to take a guideline and turn it into a path. How can a beginning practitioner be expected to "modify" or "customize" a methodology if they have not actually done Architecture?

What makes an Outstanding Methodology?

An outstanding methodology simplifies and standardizes the process; it can be customized to meet an organization's specific standards and practices.

An outstanding methodology is correct, up-to-date, complete, and concise; it defines deliverables; it has methods, techniques, standards, practices, roles, and responsibilities; it has suggested timings and sequences and dependencies; and it has associated education.

A successful methodology:

  • guides a process,

  • simplifies a process,

  • standardizes a process,

  • can be customized to meet specific standards and practices of the using organization,

  • is accurate as demonstrated through repeated practice,

  • is up to date,

  • is complete,

  • is concise,

  • defines deliverables and metrics, and

  • has methods, techniques, standards, practices, roles, deliverables, and associated education.

 

 What is a Framework for Enterprise Architecture?

Summary: Methodologies and Frameworks are not the same things. A Framework is a single frame of reference that is required for Enterprise Architecture and is applicable in any profession or domain, including those other than information technology organizations. A methodology is any one of several possible approaches to Enterprise Architecture: they are approaches to enable a Framework. An enterprise-wide, shared understanding of a Framework must be conveyed, and how it should be used as a frame of reference for developing and implementing an effective Enterprise Architecture must be articulated.

  • The EACOE Frameworks For Enterprise Architecture organize architecture (and architect roles) into different "views" and "transformations" that make sense to various stakeholders.

 
 
 

Frequently Asked Questions (FAQ) About Enterprise Architecture Frameworks:

Answers to these questions are shown using the drop-down arrow next to each question.

  • A framework is a structure that organizes related artifacts and their relationships for a chosen subject area, giving a total, coherent view. It is a thinking tool, not an output generator.

  • A framework defines elements and how they are organized. A methodology defines how to build, change, and implement within that structure. One stable framework can support many methodologies; a methodology is always dependent on a specific frame of reference.

  • Constantly versioned “frameworks” suggest that earlier versions were incomplete. For true frames of reference - like the periodic table, musical notes, or the alphabet - version churn would destroy the professions that rely on them.

  • DoDAF, MODAF, and TOGAF® are often labeled as enterprise architecture “frameworks,” but they do not operate as true frameworks in the strict, frame‑of‑reference sense. A genuine framework provides a, stable, and non‑overlapping set of categories that defines exactly how all architectural descriptions are organized and related, independent of any particular project or organization.

    By contrast, TOGAF® is primarily a broad body of guidance and a method shell (ADM) that leaves the choice of models, notations, and deliverables to the user, so it functions more as a customizable toolkit than a fixed organizing frame.

    DoDAF and MODAF, meanwhile, offer extensive catalogs of views and products, but these are large, evolving sets rather than a minimal, invariant classification structure; they tell you what kinds of diagrams and artifacts you might produce, but they do not give a concise, universal schema for structuring all enterprise descriptions.

    As a result, all three are reference resources, yet they fall short of being true enterprise architecture frameworks in the sense of providing a definitive, rigorous frame of reference for how to describe any enterprise.

  • There really is no such thing as an “agile enterprise architecture framework” because agility is a property of how an organization behaves over time, not of the static frame of reference it uses to describe itself.

    A true enterprise architecture framework is deliberately stable: it provides a consistent set of categories, viewpoints, and relationships so that strategy, capabilities, processes, information, and technology can be described in a uniform way, regardless of how fast the business is changing.

    If the framework itself were continually “agile” in the sense of constantly changing its structure, language, and organizing principles, it would undermine comparability, traceability, and learning across increments and releases; teams would be trying to hit a moving target instead of using a reliable reference.

    What does enable agility is a well‑designed enterprise architecture used in an agile way: lean, human‑consumable models; short feedback cycles; and just enough constraints to guide local decisions without over‑specifying them.

    When enterprise architecture clearly articulates principles, guardrails, and target future states - and then allows cross‑functional, iterative teams to experiment within that space - it actually accelerates change by giving agile teams a shared direction and simplifying decisions about what to build, reuse, or retire.

    In that sense, a great enterprise architecture does not need to be “agile” itself; instead, it provides a stable backbone that makes the enterprise as a whole more agile in how it responds to new opportunities, risks, and technologies.

    Watch the full video.

  • An enterprise security architecture framework is the strategic blueprint that shows how the organization will protect its critical information, services, and operations in direct support of business goals.

    It defines clear principles, guardrails, and responsibilities so that security is designed into capabilities, processes, and technologies from the outset - not added later as extra controls.

    When used within the EACOE-Enterprise Architecture, security is therefore not a bolt‑on or an afterthought; it is one of the core lenses through which investments, transformations, and innovations are evaluated.

    This means executives can pursue growth, digitization, and AI initiatives with greater confidence, knowing that risk, compliance, and trust are being managed consistently across the entire enterprise instead of through isolated, tactical fixes.

  • The EACOE Enterprise Framework™ is a definitive, two‑dimensional frame of reference that defines how to organize the structures and components of any enterprise architecture so leaders and architects can describe the organization’s current, future, and gap states in a consistent way.

    Based on and extending the work of Zachman and Sowa, it uses the six fundamental interrogatives (What, How, Where, Who, When, Why) as one dimension and a set of ordered perspectives/transformations (from enterprise scope and business relationships through technology‑neutral, technology‑specific, solutions, to the functioning enterprise) as the other, yielding a coherent grid of “cells” that together identify everything that needs to be understood about an enterprise.

    Each cell in the EACOE Enterprise Framework™ represents an enterprise‑wide view that can be detailed as needed, allowing organizations to start with a small number of critical cells and expand over time while maintaining alignment between business and technology.

    Used with the EACOE Enterprise Architecture Methodology, the framework becomes the organizing backbone for explicit, human‑consumable representations that support strategy realization, investment decisions, risk analysis, and project and program prioritization, effectively moving enterprise architecture from theory into action and implementation.

    The EACOE Enterprise Framework™ is the strategic blueprint leaders use to “see” their entire organization clearly and move from PowerPoint strategy to executable change. By giving executives and architects a common language and structure, it turns complex transformation into a managed, step‑by‑step journey: you can pinpoint where you are today, define where you need to go, and prioritize the investments and initiatives that will get you there with less risk, less rework, and more measurable business value.

  • One Enterprise Architecture framework is needed to build a true profession because professions are grounded in shared, stable bodies of knowledge and practice - not in a patchwork of competing structures and vocabularies.

    When everyone works from a single, coherent frame of reference, education, certification, tools, and methods can all align, making skills portable, results comparable, and outcomes measurable across companies and industries.

    Multiple competing “frameworks” fragment the discipline: they create confusion about what Enterprise Architecture actually is, make it hard to train and hire consistently, and prevent the accumulation of reusable knowledge and patterns over time. A single, robust Enterprise Architecture framework becomes the common foundation on which a profession can standardize terminology, codify best practices, and demonstrate value in a way that is repeatable, teachable, and trusted by executives and practitioners alike.

    Other mature professions demonstrate why a single frame of reference is essential.

    • Doctors, for example, share a common body of anatomy, physiology, and diagnostic classifications; this means that a diagnosis or procedure code means the same thing in every hospital, enabling consistent training, licensure, and patient care.

    • Accountants use standardized charts of accounts and codified industry standards such as GAAP or IFRS, so financial statements prepared in different organizations can be understood, audited, and compared in a uniform way.

    • Lawyers are trained against common legal doctrines, procedural rules, and citation standards, which make legal reasoning and precedent portable across firms and courts.

    In each case, one widely accepted frame of reference underpins education, certification, tools, and daily practice, turning a collection of individual experts into a true profession; an Enterprise Architecture practice needs the same kind of shared framework to achieve that level of cohesion, trust, and repeatable value.

  • Yes. Methodologies can and should evolve as practices improve, while a single, coherent framework ensures that all those methodologies operate within the same shared understanding of the enterprise.

  • The EACOE methodology is explicitly based on The Enterprise Framework™, providing a step‑by‑step approach to design, analyze, and implement architecture using this universal frame of reference.

  • The EACOE Workshop is where all of this becomes real; it is the hands‑on environment in which architects actually learn to use the EACOE Enterprise Framework and Methodology to build working Enterprise Architectures, not just talk about them. Instead of memorizing terms for a multiple‑choice exam, participants practice the full, step‑by‑step Quick Start Enterprise Architecture Methodology against the Framework, creating explicit models, implementation roadmaps, and “what‑if” analyses that are reviewed and refined during the workshop.

    This practitioner focus turns the single frame of reference and common method from abstract ideas into concrete skills: attendees leave with artifacts, templates, and a repeatable way of working that they can apply “next Monday morning,” which is the foundation of a real profession.

    In that sense, the EACOE Workshop is both a training ground and a quality gate for the profession. It aligns education, practice, and certification around one coherent framework and methodology, so that the title “EACOE‑certified Enterprise Architect” signals more than theoretical knowledge - it indicates that someone has actually done the work of developing an Enterprise Architecture using the shared frame of reference that the profession needs.

The Universal Architecture Framework (for Anything and Everything)

The Enterprise Framework™

Summary: Based on the work of John Zachman and John Sowa from IBM and elaborations thereof, The Enterprise Framework™ leverages artifacts, diagrams, and abstractions widely recognized by business and technology professionals. The strong point of The Enterprise Framework™ is that it represents the only complete, non-redundant, and detailed coverage of an organization.

The Enterprise Framework™ is not just "enterprise architecture" - it describes the twelve fundamental architecture domains in an enterprise (the 12 Architectures and Architect Roles in an Enterprise):

  • Enterprise Architecture,

  • Business Architecture,

  • Process Architecture,

  • Data Architecture,

  • Policy/Rule Architecture,

  • Role Architecture,

  • Logistic Architecture,

  • Event/Sequence Architecture,

  • Rule Assertion Architecture,

  • Workflow Architecture,

  • Technology Architecture,

  • and Event State Architecture.

The Enterprise Framework™ (EACOE)
Download The Enterprise Framework™
 
Jon Myklebust

Jon Myklebust

MIS Business Intelligence and Data Warehousing Competency

Warner Brothers Entertainment Inc.

“The Enterprise Framework represents a shift in thinking. To me it was one of those “light bulb” moments where you realize this is the way to do it. The Enterprise Framework isn’t difficult to understand, it is not difficult to practice and it is cheap!

No need to make expensive investment in software to be able to apply it to your organization or processes. The challenge is to get people to see the simplicity and be willing to change how we have been doing it for years.”

Tony Scott

Tony Scott

Former Corporate VP and CIO

Microsoft Corporation

“The Enterprise Architecture process presented is both theoretically sound and actual-practice refined.

Nothing is wasted – no “architecture for architectures” sake, just architecture for helping the business run better.”

Mike Boeselager

Mike Boeselager

Lead Enterprise Architect

Briggs and Stratton

“I have personally utilized Sam’s approach to EA during my career as a practicing EA professional. Sam’s process provides practitioners with a clear and actionable planning process utilizing the Enterprise Framework. At several large organizations I’ve been a part of, this methodology allowed us to clearly define the as-is and three year to-be architecture that was driven by business strategy.

Sam’s Quick Start Methodology uses the Enterprise Framework, helping you understand which cells to focus your efforts on.”

Download The Enterprise Framework™

The Enterprise Framework™ identifies everything that needs to be understood about an enterprise; it is the collection of all the perspectives/transformations that represent the functioning enterprise. At the same time, not all thirty architectural views are required before an enterprise gets started. As a matter of fact, most organizations’ architectures and strategies can initially be defined by only a handful of cells, as the EACOE Quick Start Enterprise Architecture Methodology defines; different types of artifacts will be used in different situations.

However, you need to understand that every perspective and transformation is important, and each exists whether or not it is explicitly represented. Having explicit representations for each cell facilitates reuse and makes it possible to associate cells with each other: this is the ultimate in flexibility and agility, and may take some time to effect fully.

The associations make it possible to identify gaps and overlaps. Just as not all of the letters of the alphabet are required to make a word or sentence, or not all of the elements in Mendeleev’s Periodic Table are required to make a chemical compound, not all of the cells are required for a given area of analysis in an Enterprise, initially.

The Enterprise Framework, when used with the EACOE Enterprise Architecture Quick Start methodology, will produce a clear, verifiable, understandable, and effective business and technology strategy. Practitioners have found The Enterprise Framework to be easy to explain and understand. The Enterprise Framework is human consumable.

Enterprise architecture, defined in terms of the framework, leads to the acknowledgment that there is more to an organization than mere data models and functions. There are numerous other issues, multiple locations, and timing factors to consider while planning its development.

What are the types of Enterprise Architecture frameworks?

Summary: For an organization desirous of developing an Enterprise Architecture, there are various self-described frameworks to choose. Depending on the complexity and scale of the enterprise, they can select from commercial, defense industry, and government frameworks, however, TOGAF®, DoDAF, MODAF, and Federal EA “Frameworks” are neither a true Framework or Methodology.

  • Frameworks such as The Open Group Architecture Framework (TOGAF®), Department of Defense Architecture Framework (DoDAF), and Ministry of Defense Architecture Framework (MODAF), and other Federal Enterprise Architecture Frameworks are classified as Implementation Frameworks and/or methodologies in combination with a framework.

  • DoDAF, MODAF, and TOGAF®'s "frameworks" are continuously modified and altered. If you were using Version 8.9 of the framework and we now have Version 10, what does that say about the foundation and knowledge we got from Version 8.9?

 

TOGAF®, is often described as both a framework and a methodology for enterprise architecture (EA). However, this dual characterization creates confusion, as TOGAF® does not fit neatly into either category. It is best understood as a hybrid approach that combines elements of both frameworks and methodologies but without fully embodying the strengths of either.

 
 

Architecture Framework Characteristics
A framework typically provides a structured set of tools, templates, and guidelines to create architectures. TOGAF® includes such elements, such as its Enterprise Continuum and Architecture Repository, which offer reusable assets and classification systems. However, unlike purely structural frameworks like the Zachman Framework (Ontology), TOGAF® lacks the rigid modularity and universal applicability expected of a standalone framework. Rigidity of a Framework is one of its features and benefits. Imagine the alternative in the English language – a “flexible” framework where change occurs periodically – a continuing changing alphabet would result, and language would be at a standstill.

Architecture Methodology Characteristics
A methodology outlines a step-by-step process or approach to achieve specific outcomes. TOGAF® incorporates the Architecture Development Method (ADM), which provides iterative phases and general guidance for developing EA. While ADM is methodological in nature, it is not prescriptive enough to be considered a complete methodology on its own. It leaves significant room for interpretation and tailoring, which can lead to inconsistent implementations.

It is a strong recommendation that, in order to utilize TOGAF®, it should be customized/modified before its use. A question that needs to be asked, is, if someone has not done Enterprise Architecture, how can they be asked to modify something they have never done. EACOE prides itself in providing explicit guidance to get going “Monday morning.”

The Hybrid Nature of TOGAF®
TOGAF® attempts to blend these two paradigms by offering high-level guidance (framework) alongside process-oriented phases (methodology). However, this hybrid nature can be problematic:

  • It lacks the precision of a formal framework.

  • Its methodological components are generalized and require extensive customization to be practical in real-world scenarios.

The Resulting Confusion

  • Ambiguity in Application: Organizations often struggle to determine whether they should treat TOGAF® as a rigid framework or a flexible methodology. This ambiguity can result in inconsistent EA practices across teams.

  • Overwhelming Complexity: With 52 chapters covering everything from governance to risk management, TOGAF®’s breadth can overwhelm practitioners who are unsure how to prioritize its components.

  • Misaligned Expectations: Stakeholders may expect TOGAF® to provide either detailed instructions (like a methodology) or universal templates (like a framework), only to find that it does neither comprehensively.

In conclusion, TOGAF® hybrid nature as neither fully a framework nor a methodology necessitates careful interpretation and application. Understanding its limitations often leads organizations to a more robust and consistent approach – as an example, EACOE’s Enterprise Framework™.

Why Is It Imperative for Enterprise Architects and the Enterprise to have One Framework?

Summary: The imperative for a unified EA framework lies in its ability to streamline operations, enhance governance, improve decision-making, and align IT with business goals. The foundation of any successful EA initiative must rest on a single coherent framework that provides clarity, consistency, and scalability. Organizations should embrace this common approach to ensure their architecture efforts yield meaningful and lasting results.

It is important to realize that without standardized representations, businesses are running off individualized, personal interpretations and networks.

  • Imagine what it would be like if every organization had its own version of the English alphabet—some with sixteen letters, some with twenty-six, and some with a hundred and forty-three! Communication would be impossible. So it is without a Framework that is universal for Enterprise Architecture.

  • There are many ways (methodologies) to use the Framework, but only a single, definite Framework should be used.

 
 

Clarity and Consistency
A standardized EA framework ensures clarity in business processes, terminology, consistent meta-model, and methodologies. It eliminates the ambiguity associated with multiple frameworks and provides a common language for stakeholders, fostering better communication and collaboration.

Alignment with Organizational Goals
A unified framework aligns business with IT systems and processes and business objectives. This alignment reduces inefficiencies and ensures that every architectural decision supports the organization's overarching mission.

 

Improved Governance
Standardized frameworks provide robust governance structures, including clear policies, processes, and procedures. This governance harmonizes architectural requirements with business needs, ensuring compliance and consistency across the enterprise.

Scalability and Adaptability
While organizations vary in size and complexity, a single Enterprise Architecture Framework is agnostic to organization size. This adaptability makes it suitable for diverse industries, from retail to aerospace.

 

Enhanced Decision-Making
By offering data-driven insights and visualizations, a unified framework empowers leaders to make informed decisions quickly. It provides transparency into the organization's architecture, reducing bottlenecks and enabling agile responses to change.

The Case for Formal Modeling

For industries requiring precision - such as aerospace or defense - a formal specification of notation, modeling languages, and metamodels is non-negotiable. These technical elements ensure accuracy in design and execution while maintaining rigorous standards. Even in less technical industries, formal modeling adds value by offering structured understanding that aids in long-term planning and sustainability.

The Role of Methodologies

Methodologies guide architects through phases of development. These methodologies are not optional; they are foundational to creating actionable deliverables that drive real-world results. The integration of methodologies with one EA framework ensures that EA efforts remain focused on producing tangible benefits for the organization.  Methodologies are all based on a specific framework, whether explicitly stated or not.  Methodologies can and often do “evolve” over time. An example of an Enterprise Architecture Methodology that meets these criteria is the Enterprise Architecture Center Of Excellence (EACOE) Methodology for Enterprise Architecture.

How to move from theoretical frameworks to Outcome Driven Enterprise Architecture

 

It is time to move from theory into practice and action.

For organizations seeking to modernize their Enterprise Architect practice, the imperative is clear: stop treating EA as a static, documentation function, and start building a continuous, information‑centric, outcome‑oriented capability that can evolve into the EA 5.0 model. In doing so, EA can finally fulfill its promise as the discipline that designs, directs, and continuously refines the enterprise in an increasingly dynamic and competitive world.

The EACOE Quick Start Enterprise Architecture Methodology demystifies the process of designing the architecture of the enterprise. It provides a step-by-step approach to Enterprise Architecture, ensuring the organization meets the goals and objectives established by management.

The Methodology enables organizations to use Enterprise Architecture as a decision-making tool for business strategy, information technology development and alignment, risk analysis, and project and program prioritization. By leveraging these techniques, organizations can thoroughly analyze and prepare for the effects of change initiatives, increasing their chances of successful implementation and achieving desired outcomes.

Practice and Train in EACOE Enterprise Architecture
EACOE Enterprise Architecture Practitioner Guide
 

References and Citations:

Author: Sam Holcman and ©Enterprise Architecture Center Of Excellence™ (EACOE™) Team. 

Author biography (overview): For over five decades, Sam Holcman has been considered the practitioner’s practitioner in Enterprise Architecture, and the world’s leading implementer, educator, and trainer in Enterprise Architecture methodologies and techniques. As the Managing Director of the Enterprise Architecture Center Of Excellence (EACOE) since 1972, he has over 4,500 field engagements with organizations globally, in addition to coaching and certifying over 160,000 professionals in the discipline of EACOE™ Enterprise Architecture.

Originally Published: July 20, 2019 | Last Updated: May 21, 2026