Definition of Enterprise Architecture
Essential Elements of Enterprise Architecture
Essential Elements of Enterprise Architecture
The key aspects in this definition of enterprise architecture: (If an enterprise architecture delivers on these points it would've met its obligation and become a tool for creating and communicating the value in an organization. The process that builds it is called enterprise architecture planning and that includes its use in IT Governance and its own governance.)
- Enterprise Architecture is holistic: the scope of enterprise architecture planning is top to bottom, and left to right i.e. it spans the entire organization and all of its dimensions. However, that does not mean "here and now" i.e. an enterprise architecture can - should and MUST - be built piece - domain - by piece not all at once.
- Enterprise Architecture is hierarchical: enterprise architecture is layered in levels or degrees of generalizations - from logical to physical and everything in between.
- Enterprise Architecture is abstract: enterprise architecture describes the logic of an enterprise i.e. it is a logical representation of an organization. Through layers, this logical description is translated into a physical - people, systems, networks etc. - components that must be built to support the operations of the enterprise. Another way of looking at this is that enterprise architecture translates organizational strategy into operations.
- Enterprise Architecture is descriptive: enterprise architecture is a written representation of the organization. It communicates the essence of the organization by detailing its parts and their relationship with each other
- Enterprise Architecture covers the essential: simply put: enterprise architecture stays away from the merely interesting and focuses on the pertinent. The purpose of enterprise architecture is to help understand the lay of the land - not cover every blade of grass - so one can navigate it effectively. Essential to what? Essential to create value for the business. Essential so one creates the biggest bang for the IT buck.
- Enterprise Architecture describes elements of an organization: enterprise architecture describes parts or aspects that are characteristic of the organization - together they describe the essence of the organization. These descriptions are specific, therefore, they help communications, eliminate redundancy and create standards that must be followed.
- Enterprise Architecture is about an organization: enterprise architecture describes an organization - a body of people, processes, and technology formed for a purpose or objective.
- Enterprise Architecture delivers shareholder value: Enterprise architecture has a purpose - sad, but true! - and that is to deliver business value. Enterprise architects lose when they forget that it is all about business value - pretty charts and graphs can keep you busy for years but your paycheck is for delivering value to shareholders.
- Enterprise Architecture is iterative: Enterprise architecture is built over time piece by piece - one domain at a time. Enterprise Architecture's layers also develop over time. Enterprise architecture needs continuous refinement because no business operates in a stationary environment.
- Enterprise Architecture describes the organization over time: Enterprise Architecture maps the organization's journey over time from where it is to where it needs to be to deliver maximum business value. By definition, it is an endless journey.
Enterprise Architecture Definitions
Enterprise Architecture Definitions
Here are a few examples of enterprise architecture definitions. Each has elements that help understand enterprise architecture but do they miss critical aspects to completely answer the question: What is Enterprise Architecture? You decide based on the above
- 1. ANSI/IEEE Std 1471-2000: “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
- 2. Cap Gemini: “Enterprise Architecture is the description and visualization of the structure of a given area of contemplation, its elements and their collaborations and interrelations links vision, strategy and feasibility, focusing on usability durability and effectiveness. Architecture enables construction, defining principles, rules, standards and guidelines, expressing and communicating a vision”
- 3. Forrester, Gene Leganza, 2001: “Enterprise architecture consists of the vision, principles and standards that guide the purchase and deployment of technology within an enterprise”
- 4. Gartner Group: “Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution.”
- 5. Gartner Group, Philip Allega: “Enterprise architecture is the process that interweaves business and IT together”
- 6. Institute for Enterprise Architecture Development: “Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate”
- 7.MIT Center for Information Systems Research: “Enterprise Architecture is the organizing logic for key business processes and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.”
- 8.The ArchiMate Foundation: “A coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure ”
- 9.The Open Group: “By being inclusive with all other management frameworks, EA is a discipline that helps the Enterprise define , develop and exploit the boundaryless information flow (BIF*) capabilities in order to achieve the Enterprise’s Strategic Intent.” *Boundaryless Information Flow is a Trademark of The Open Group
- 10.US Federal Enterprise Architecture Framework (FEAF): “Enterprise architecture is a management practice to maximize the contribution of an agency’s resources, IT investments, and system development activities to achieve its performance goals. Architecture describes clear relationships from strategic goals and objectives through investments to measurable performance improvements for the entire enterprise or a portion (or segment) of the enterprise”
Context Diagram for Enterprise Architecture
Figure 1. source: EITBOK Wiki
Evolution of Enterprise Architecture
Evolution of Enterprise Architecture
The need for EA arose for two reasons:
- The first reason was driven by technology. The arrival of distributed computing in the 1980s resulted in increased EIT complexity due to additional scale, diversity, and connectivity in the computing environment. This additional complexity lead to significantly higher EIT development, support, and operational costs. With rising costs came pressure from management to slow the growth of EIT budgets and increase the business effectiveness of EIT support. Directives to "do more with less" and unrelenting pressure to increase efficiency and effectiveness required new approaches to EIT strategy. To some extent, consolidation, standardization, and commoditization worked as EIT expense reduction strategies; however, there were limits to their effectiveness, because they still lacked a holistic and systematic understanding of the connectedness between business roles and processes, information data elements and flows, supporting application systems, and underlying technology infrastructure.
- The second motivation for EA was business-driven, due to the ever-increasing pace of external change combined with the difficulty for many organizations to successfully execute their business strategies. Michael Porter estimates that more than 80 percent of organizations fail to execute their business strategies, and ineffective execution was the reason for failure for more than 70 percent of them. The principles and practices in EA help enterprise managers move their organizations from where they are to where they want them to be.
Based on whether one views EA solely for technology-based or business strategy-based reasons, the scope of EA varies, including its concerns, assumptions, and limitations. One of the most cogent analyses of the range of EA definitions was presented by James Lapalme, who describes three schools of thoughts on EA:
- Enterprise-wide IT platform—Effective enterprise strategy execution and operation through EIT - business alignment)
- Enterprise—Effective enterprise strategy implementation through execution coherency
- Enterprise-in-environment—Innovation and adaptation through organizational learning
Nick Malik builds on Lapalme's three schools, and describes three categories of EA application:
- Enterprise IT architecting — Designing EIT services and creating EIT systems that address the enterprise's needs
- Enterprise integrating — Aligning the business with all of its capabilities, including EIT; using capability analysis to understand the impacts of strategy on the business processes and systems, and helping to frame the initiatives that should be created, and insures that investments are made in the right place
- Enterprise ecological adaptation — Analyzing the movements of the market, and working closely with business leaders to develop strategies based on the capabilities and positioning of the company that are likely to generate new revenue, improve market position, improve customer loyalty, and reduce costs
EA can serve a number of different goals (the vertical axis of Figure 3) and can provide direction and support for a range of time horizons and enterprise value (the horizontal axis). It is important to distinguish the type of EA that an organization needs and wants to establish. By doing so, the boundaries and handoffs between EA and business executives in the execution of their business strategy become clear. Without that clarity, ongoing confusion and issues with collaboration and alignment will likely be created. EA practitioners have three base-level assumptions:
- The alignment of the business and EIT is achieved by aligning EIT with the business.
- The agility of the enterprise is a consequence of the agility of the EIT function.
- The transformative value of EA is typically delivered by transforming the application and technology architectures. The amount of change engendered by an EA initiative might be small at the business layer, but it typically increases as the design progresses closer to the details of the applications and systems.
The Scope of Enterprise Architecture
The Scope of Enterprise Architecture
The scope of an enterprise architecture establishes the range or extent that it needs to address. There are several dimensions to scope.
- The enterprise architecture time extent identifies the planning time horizon. Typically, this is three to five years and coincides with the budget planning cycle in large organizations.
- The enterprise architecture organizational scope includes those parts of the organization and their business processes, data, and IT to be covered in the effort. Ideally, the entire organization is addressed. In some cases, the architecture involves partnerships of multiple organizations to fulfill a common mission. An EA effort may emphasize different parts of an organization in different enterprise architecture phases depending on resources available and changing business strategy and investment needs.
- The level of detail scope determines how much detail needs to be included in the enterprise architecture. There are several factors to consider. The enterprise architecture should contain enough detail to formulate major investments and their lifecycles and projected costs. The enterprise architecture should include enough detail to demonstrate that the enterprise strategy is supported by the enterprise architecture in the timeframe needed. The enterprise architecture should show enough detail to ensure that needed interfaces between organizations and between IT systems are adequately specified. The enterprise architecture should provide enough guidance to systems engineers who are developing designs and specifications for implementing specific investments. On the other hand, the EA should not be so detailed that it over-constrains an enterprise. It should be sufficiently general to provide latitude in system design decisions and be responsive to technology changes. In sum, the enterprise architecture should be sufficiently detailed and specific to constrain and guide strategic decisions, while not over-constraining tactical decisions.
Enterprise Architecture Components
Enterprise Architecture Components
Enterprise Architecture components include:
- Business Information Systems: A Business Information System is a computer-based business information system that is being managed through the Metabase. It is known by its characteristics, its operation cycles (business and calendar), subordinate business information systems, employed databases, views, and associated Resource Life Cycle nodes.
- Database Domains: A Database Domain is a hierarchically organized set of noun-intensive descriptions associated with a mission leaf. Analyzed database domains lead to the identification of Database Object Classes, enterprise data elements, and property classes. Property classes, in turn, often become tables in databases.
- Database Object Classes: A Database Object Class is a large collection of data and processes that are tied together for business-based reasons, and when instantiated, proceeds through well defined states. A database object can exist in two forms: a collection of interrelated database tables, or the set of a column based nested structures within a table. The rows that comprise an object are transformed from one valid state to another via database object table processes and database object information systems. Database objects are related to one or more database domains.
- Database Object Information Systems: A Database Object Information System is a collection of processes defined within the domain of the DBMS usually as a stored procedure that transforms one or more rows of a database object from one valid state to another. A database object information system accomplishes one or more database object table processes.
- Management Level: Management level is a named and defined level of bureaucratic management within an organizational setting. Examples could be executive, senior, mid-level, and first-level.
- Missions: Missions are hierarchically organized textual descriptions that define the very existence of the enterprise, and that are the ultimate goals and objectives that measure enterprise accomplishment from within different business functions and organizations. An enterprise is incomplete if one of its missions is not defined. Not all enterprises accomplish their missions simultaneously or in an ideal state. Missions are accomplished over time and are subject to revisions.
- Organizations Performing Missions: An Organization Performing Missions, that is, a Mission-Organization is the association of an organization with a mission. There can be multiple organizations associated with a mission and an organization can be associated with multiple missions. The description contained within the Mission-Organization may be more refined than the description contained in either the mission or the organization.
- Organizations Accomplishing Functions: An organization accomplishing a function in support of a mission, that is, a Mission-Organization-Function is the association of a mission organization with a function. A mission-organization can be associated with multiple functions and a function can be associated with multiple mission-organizations. One or more mission-organization-functions may be associated with a business information system. When they are, business events are created.
- Positions: A Position is a named and defined collection of work tasks that can be performed by or more persons. Positions are often assigned to one or more organizations.
- Positions performing missions: A Mission Organization Function Position Role is the assignment of a position to a particular function within an organization as it accomplishes a mission. Once a position is assigned, its role can be described.
- Resource Life Cycle Analysis Node: A Resource Life Cycle Node is a life cycle state within the resource. If the resource is employee, the life cycle node may be employee requisition, employee candidate, employee new hire, assigned employee, reviewed employee, and separated employee.
- Resources: A Resource is an enduring asset of value to the enterprise. Included for example are facilities, assets, staffs, money, even abstract concepts like reputation. If a resource is missing then the enterprise is incomplete.
Enterprise Architecture Domains
Enterprise Architecture Domains (Figure 2.)
In the 1980s, a four-layer division of system architecture came into use by system designers. The architecture was split into technology, applications, information, and business domains. The domains higher in the stack were built on top of and depended upon the lower layers. Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or "domains" (also called viewpoints, layers or aspects). The dividing of the practice into a number of domains allows enterprise architects to describe an enterprise from a number of important perspectives, dividing the descriptive task between many participants and allowing the practice as a whole to make good use of individual domain-specific expertise and knowledge. By taking this approach, enterprise architects can ensure a holistic description of the design of the enterprise is produced.
- There are at least two domains, "Business Modeling" and "Current Systems and Technology", which can be further broken down into "Data Architecture", "Applications Architecture" and "Technology Architecture".
- The popular TOGAF framework divides the practice into three domains, "Business Architecture", "Information Systems Architecture" and "Technology Architecture" and then subdivides the information systems architecture into "Information Architecture" and "Applications Architecture".
- The Strategic Architecture Model allows for a flexible division into up to ten domains covering many aspects of an enterprise from its objectives and goals through its projects and programs to its software applications and technology.
Figure 2. source: Modeliosoft
Enterprise Architecture Principles
Enterprise Architecture Principles
Enterprise Architecture Principles are high level statements of the fundamental values that guide Business Information Management, Information Technology (IT) decision-making and activities, and are the foundation for both business and IT architectures, standards, and policy development. These principles are general rules and guidelines that may be subject to adjustments as the enterprise refocuses its objectives and mission. However, they are intended to be enduring and not prone to frequent amendments. Decisions and business cases are strengthened by compliance with these principles. Where there are conflicts of interest between, for example, two solution development projects, then these principles should guide the decision making. If proposed changes do not comply with these principles then the changes should be realigned with the principles. Principles are established on all Enterprise Architecture Domains:
- Business Principles – provide a basis for decision making throughout the business
Principle 1 – Primacy of Principles
Principle 2 – Compliance with Statutory Obligations
Principle 3 – Maximise Benefit to the Enterprise
Principle 4 – Information Management is Everybody’s Business
Principle 5 – Business Continuity
Principle 6 – Common Use Applications
Principle 7 – IT Responsibility
- Data Principles - provide guidance of data use within the enterprise
Principle 8 – Data Security
Principle 9 – Data is an Asset
Principle 10 – Data is Shared
Principle 11 – Data is Accessible
Principle 12 – Data Trustee
Principle 17 – Data will be Analysable
- Application Principles - provide guidance on the use and development od all IT applications
Principle 13 – Technology Independence
Principle 14 – Ease of Use
Principle 18 – Purchase rather than Develop
- Technology Principles - provide guidance on the use and development of all IT technologies
Principle 15 – Requirements-Based Change
Principle 16 – Control Technical Diversity
Enterprise Architecture Frameworks
Enterprise Architecture Frameworks (Figure 3.)
An Enterprise Architecture Framework (EAF) maps all of the software development processes within the enterprise and how they relate and interact to fulfill the enterprise’s mission. It provides organizations with the ability to understand and analyze weaknesses or inconsistencies to be identified and addressed. There are a number of already established EAF in use today; some of these frameworks were developed for very specific areas, whereas others have broader functionality. There are a number of architectures and architectural frameworks in use today. Though they may overlap or address similar views, frameworks also have been designed to address specific needs or concerns. The following are concise descriptions of five EAFs that are most commonly used:
- Zachman Framework for Enterprise Architecture: John Zachman published the Zachman Framework for Enterprise Architecture in 1987 and is considered to be one of the pioneers in this domain. According to Zachman, “the increased scope of design and levels of complexity of information systems implementations are forcing the use of some logical construct (or architecture).” The Zachman Framework is based around the principles of classical architecture that establish a common vocabulary and set of perspectives for describing complex enterprise systems. The Zachman Framework has six perspectives or views: Planner, Owner, Designer, Builder, Subcontractor, and User. The second dimension of Zachman’s Framework deals with the six basic questions: what, how, where, who, when and why. The framework does not provide guidance on sequence, process, or implementation, but rather focuses on ensuring that all views are well established, ensuring a complete system regardless of the order in which they were established. The Zachman Framework has no explicit compliance rules since it is not a standard written by or for a professional organization. However, compliance can be assumed if it is used in its entirety and all the relationship rules are followed.
- Department of Defense Architecture Framework (DoDAF): The Department of Defense Architecture Framework (DoDAF) builds on three sets of “views”: Operational, System, and Technical Standards. A fourth view, ‘All View,’ augments the other views by providing the linkage between the views by means of a dictionary to define terms and by providing context, summary, or overview level information. This framework provides descriptions of final products as well as guidance and rules for consistency. This ensures a “common denominator for comparing, and integrating Families of Systems, Systems of Systems, and interoperating and interacting architectures”.
- Federal Enterprise Architecture Framework (FEA): The Federal Enterprise Architecture Framework was developed and published by the US Federal Chief Information Officers (CIO) Council. Government was following the industry trend of defining architectural frameworks to guide in the development of large, complex systems development. FEAF was in response to the Clinger-Cohen Act 1996, which required Federal Agency CIOs to develop, maintain, and facilitate integrated systems architectures. The overriding goal of FEAF is to organize and promote sharing of Federal information for the entire Federal Government. The architectural segments are developed individually, within structured guidelines, with each segment considered to be its own enterprise within the Federal Enterprise. FEA allows for flexibility in the use of methods, work products, and tools to be used by the individual federal agencies.
- Treasury Enterprise Architecture Framework (TEAF): The Department of the Treasury published the Treasury Enterprise Architecture Framework (TEAF) in July 2000. The Department of the Treasury is comprised of a number of offices that function as individual enterprises. Therefore, its enterprise architecture needs to map the interrelationships among the organizations in order to manage IT resources. The TEAF aims at facilitating “integration, information sharing, and exploitation of common requirements across the department”. Similar to DoDAF, TEAF includes descriptions of work products for documenting and modeling enterprise architectures. TEAF also explicitly states that these work products align with FEAF models and DoDAF products.
- The Open Group Architecture Framework (TOGAF): The Open Group Architectural Framework (TOGAF) was first developed in 1995 and was based on the Department of Defense’s Technical Architecture Framework for Information Management. TOGAF focuses on missioncritical business applications that use open systems building blocks. “A key element of TOGAF is Architecture Development Method (ADM) that specifies a process for developing enterprise architecture”. TOGAF explains rules for developing good principles, rather than providing a set of architecture principles. The three levels of principles support decision making across the entire enterprise; provide guidance of IT resources; and support architecture principles for development and implementation.
Enterprise Architecture Frameworks - Comparison by Views/Perspectives
Figure 3. source: Eastern Michigan University
Benefits of Enterprise Architecture
Benefits of Enterprise Architecture
The benefits of enterprise architecture are achieved through its direct and indirect contributions to organizational goals. It has been found that the most notable benefits of enterprise architecture can be observed in the following areas:
- Organizational design - Enterprise architecture provides support in the areas related to design and re-design of the organizational structures during mergers, acquisitions or during general organizational change.
- Organizational processes and process standards - Enterprise architecture helps enforce discipline and standardization of business processes, and enable process consolidation, reuse, and integration.
- Project Portfolio Management (PPM) - Enterprise architecture supports investment decision-making and work prioritization.
- Project Management - Enterprise architecture enhances the collaboration and communication between project stakeholders. Enterprise architecture contributes to efficient project scoping, and to defining more complete and consistent project deliverables.
- Requirements Engineering - Enterprise architecture increases the speed of requirement elicitation and the accuracy of requirement definitions, through publishing of the enterprise architecture documentation.
- System development - Enterprise architecture contributes to optimal system designs and efficient resource allocation during system development and testing.
- IT management and decision making - Enterprise architecture is found to help enforce discipline and standardization of IT planning activities and to contribute to a reduction in time for technology-related decision making.
- IT_Value - Enterprise architecture helps reduce the system's implementation and operational costs, and minimize replication of IT infrastructure services across business units.
- IT complexity - Enterprise architecture contributes to a reduction in IT complexity, consolidation of data and applications, and to better interoperability of the systems.
- IT openness - Enterprise architecture contributes to more open and responsive IT as reflected through increased accessibility of data for regulatory compliance, and increased transparency of infrastructure changes.
- IT risk management - Enterprise architecture contributes to the reduction of business risks from system failures and security breaches. Enterprise architecture helps reduce risks of project delivery.
Enterprise Architecture Challenges
Enterprise Architecture Challenges
- Fitness for purpose. Consistent definition and understanding of EA as a discipline adds to challenges. Most organizations stand up EA to "fix" an organization without giving it any purpose. Often, consultants/contractors try to sell the Titanic of EA before they can prove a sailboat which can float. This is what often results in annoying the clients and has lead to the view of EA being shelf-ware.
- Senior executives buy-in and continuous focus and support upon the EA program. This is like a chicken and egg issue. Executives would have continuous support if EA can deliver value, but EA need continuous executive supports to show value. EA is in a domain where you don’t find too many quick wins. In addition, a successful EA would often lead to corporate culture change. Without strong senior executives’ commitments, corporate culture change just won’t happen. Many feel that time and money is being wasted till they start seeing in the results.
- Understand Stewardship and Ownership differences. Too often an EA attempts to take ownership of a business process and ends up getting blamed. An EA is a Steward to practice strategic EA Leadership & Operational Stewardship --> alignment of execution with Strategy is extremely critical for EA success.
- EA Maturity: EA engagement model and governance. This gears toward corporate processes, politics and people issues. Enterprise Architecture is simply a heavy burden to a lot of people and projects if EA engagement and governance model is not efficient and effective. Somehow, fragmented EA engagement model and governance process is very common at work place. It seems taking forever to streamline. In other words, Governance and Compliance inward is extremely important.
- Organizational Maturity. A mature organization is base to start a successful EA program; on the other side, an effective EA program improves organizational maturity. Too many organizations try to institute an EA program when the organization is not prepared to do so. Often, leadership hears or gets the pitch that EA will save the day and they start a program, without supporting the program, thinking that "doing" EA will fix everything. EA requires wide preparation and active participation.
- Business/Architecture Alignment --> This has to be earned by EA Team and should not be considered a blank check or an entitlement, as this would require relationship management and transparency in delivery to match the business priorities. PMO and Architecture team are critical for earning and establishing the trust.
- Move from Vendor/Group/Institute-centric EA to Customer-centric EA. Advance from just being DNA or “enterprise genotype” (a full nomenclature of enterprise artifacts) to provide a formal link with “enterprise phenotype” (a set of observable characteristics such as performance) and business ecosystem.
- Constant jockeying with "tactical project savings" vs. "sustainable strategic advantage" argument...(classic misalignment of project team goals with architecture team goals!). Starting too big, that the EA initiative doesn't get success as originally intended. It is extremely important to start small and produce results to gain trust. Planning and prioritizing some quick wins to demonstrate what change a complete EA can bring to a enterprise. Though it is very difficult since it can backfire at times. Still, EA needs to demonstrate directly quantifiable ($$$) value - contribution to company's bottom line or direct savings as a result
- Mature EA Team: The EA team which don't just believe in Framework and Technology but also has the capability to carry the business with them and got a thick skin to sail through the politics and policies Staff. Also, it is not about the "chief architect," it is about the team of architects/support staff, a mature EA team.
- EA Skills/Talent: Architecture is more of an art than a science and requires more skills than certifications. Enterprise Architect requires broad knowledge from many aspects of, business domains knowledge, technologies project management experience, and organizational skills. There are many channels to mature as an Enterprise Architect. Enterprise Architects with different maturing paths may see the same organization with very different challenges.
Enterprise Architecture Framework
Enterprise Architecture Management (EAM)
Enterprise Architecture Value Framework (EAVF)
Business Systems Planning (BSP)
Federal Enterprise Architecture Framework (FEA)
Department of Defense Architecture Framework (DoDAF)
The Open Group Architecture Framework (TOGAF)
IT Strategy (Information Technology Strategy)
IT Strategy Framework
IT Governance (Governance of Information Technology)
Architected, Model-Driven Development (AMD)
Architected Rapid Application Development (ARAD)
Risks in Architecture
Architecture Description Language (ADL)
Architecture Development Method (ADM)
Architecture Driven Modernization
Architecture Tradeoff Analysis Method (ATAM)
Governance of Enterprise Architecture
- Definition of Enterprise Architecture by Sourabh Hajela of CIO Index
- Essential Elements of Enterprise Architecture based on Sourabh Hajela's Definition of Enterprise Architecture
- 10 Definitions of Enterprise Architecture Aris
- Evolution of Enterprise Architecture EITBOK Wiki
- The Scope of Enterprise Architecture EABOK
- What are the Components of Enterprise Architecture? Michael M. Gorman
- Enterprise Architecture Domains Modeliosoft
- Enterprise Architecture Principles Plymouth University
- Enterprise Architecture Frameworks Lise Urbaczewski, Stevan Mrdalj, Eastern Michigan University
- Benefits of Enterprise Architecture Wikipedia
- Top Ten Enterprise Architecture Challenges Future of CIO
- A timeline of key enterprise architecture events Bespoke
- Two IT gurus face off on value of enterprise architecture frameworks Techtarget
- On Layers of Enterprise Architecture Tetradian
- The Place of Business Architecture within Enterprise Architecture Daniel Lambert
- Why enterprise architecture maximizes organizational value Peter B. Nichol
- Enterprise architecture tools: Fake and real Svyatoslav Kotusev