Often compared with town-planning or urban design, enterprise architecture (EA) is a well-defined practice for conducting enterprise analysis, design, planning, and implementation for the successful development and execution of strategy. Enterprise Architecture reduces redundancy, complexity and information silos and business risks associated with IT investments. Thus, EA provides a blueprint for an effective IT strategy and guides the controlled evolution of IT in a way that delivers business benefit in a cost-effective way.
Practitioners of enterprise architecture, enterprise architects, are responsible for performing the analysis of business structure and processes and are often called upon to draw conclusions from the information collected to address the goals of enterprise architecture: effectiveness, efficiency, agility, and continuity of complex business operations.
There is no shortage of EA frameworks in the IT industry, Zachman was the first to formalize the concept and publish a framework. Since then, many other EA frameworks have been published and are used by many organizations. They attempt to address the basic challenge of assessing, aligning, and organizing business objectives with technical requirements and strategies such as the Zachman Framework, The Open Group Architecture Framework (TOGAF), NAF, DoDAF, MoDAF and etc. Each framework possesses different strengths and weaknesses.
Enterprise architecture is unique to every organization, however, there are some common elements. Since Stephen Spewak’s Enterprise Architecture Planning (EAP) in 1993, and perhaps before then, it has been normal to divide enterprises architecture into four architecture domains.
The four commonly accepted domains of enterprise architecture are:
Business architecture domain – describes how the enterprise is organizationally structured and what functional capabilities are necessary to deliver the business vision. Business architecture addresses the questions WHAT and WHO: WHAT is the organization’s business vision, strategy, and objectives that guide creation of business services or capabilities? WHO is executing defined business services or capabilities?
Application architecture domain – describes the individual applications, their interactions, and their relationships to the core business processes of the organization. Application architecture addresses the question HOW: HOW are previously defined business services or capabilities implemented?
Data architecture domain – describes the structure of an organization’s logical and physical data assets and data management resources. Knowledge about your customers from data analytics lets you improve and continuously evolve business processes.
Technology architecture domain – describes the software and hardware needed to implement the business, data, and application services. Each of these domains have well-known artifacts, diagrams, and practices.
Business architecture domain – describes how the enterprise is organizationally structured and what functional capabilities are necessary to deliver the business vision. Business architecture addresses the questions WHAT and WHO:
Application architecture domain – describes the individual applications, their interactions, and their relationships to the core business processes of the organization. Application architecture addresses the question HOW: HOW are previously defined business services or capabilities implemented?
Data architecture domain – describes the structure of an organization’s logical and physical data assets and data management resources. Knowledge about your customers from data analytics lets you improve and continuously evolve business processes.
Technology architecture domain – describes the software and hardware needed to implement the business, data, and application services. Each of these domains have well-known artifacts, diagrams, and practices.
For many years, it has been common to regard the architecture domains as layers, with the idea that each layer contains components that execute processes and offer services to the layer above. Many EA frameworks combine data and application domains into a single information system layer, sitting below the business and above the technology (the platform IT infrastructure).
The scope of enterprise architecture includes: the people, business processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architecture applies architecture principles and practices to guide organizations through the alignment of these architecture domains: business, information, process, and technology. These involve utilize the various aspects of an enterprise to identify, motivate, and achieve these changes by performing:
An Architecture Framework establishes a common practice for creating, interpreting, analyzing and using architecture descriptions (Views and Viewpoints) within a particular domain of application or stakeholder community. It is a structure for the content of an Enterprise Architecture Description, according to the IEEE 1471 definition, we can describe an EA framework as the model shown below:
Utilizing an Enterprise Architecture framework streamlines the process for creating and maintaining architectures at all layers (e.g. enterprise architectures, functional business segment architectures, cross-cutting technology domain architectures, and solution architectures) and enables an organization to leverage the value of architecture best practices.
An Enterprise Architecture framework provides a collection of best practices, standards, tools, processes, and templates to assist in the creation of the Enterprise Architecture and architectures of various scopes. Enterprise Architecture frameworks typically include:
Addresses – View addresses Concern
Agile – An iterative approach to planning and guiding project processes.
Application Architecture – A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.
Application Portfolio Management – The discipline applied to managing software assets to justify and measure the financial benefits of each application in comparison to the costs of the application’s maintenance and operations.
Architecture – The organization of a System in terms of components, their relationships to each other and the environment.
Architecture Description – An Architecture Description is a work product used to express the Architecture of some System of Interest. The Standard specifies requirements on ADs. An AD describes one possible Architecture for a System. An AD may take the form of a document, a set of models, a model repository, or some other form (AD format is not defined by the Standard).
Architecture Principle – A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
Business Architecture – A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs.
Business Architecture Framework – A conceptual view of how business blueprints, business scenarios, and business architecture knowledgebase interrelate to provide a foundation for establishing the business architecture.
Business Capability – The expression or the articulation of the capacity, materials, and expertise an organization needs in order to perform core functions. Learn more in our definitive guide to business capabilities!
Business Capability Modeling – A technique for the representation of an organization’s business anchor model, independent of the organization’s structure, processes, people or domains. Learn how to get started with business capability modeling in 4 steps!
Business Capability Roadmap – A capability roadmap is a plan describing a feasible series of carefully scoped initiatives along with the sequence and estimated timelines in which those initiatives should take place, in order to achieve a business objective. Usually delivered as a document or architectural model describing the business capabilities as they are, and the changes planned over the course of a future period of time. Read more in our whitepaper about business capabilities.
Business Capability Taxonomy – A business capability taxonomy is an ordered hierarchy of business capabilities, structured in a manner that makes sense to the stakeholders, and used to create associations between capabilities and business units.
Business Goal – A Goal is a statement about a state or condition of the enterprise to be brought about or sustained through appropriate Means. A Goal amplifies a Vision – that is, it indicates what must be satisfied on a continuing basis to effectively attain the Vision.
Business Information Model – A model illustrating the groupings and relationships between the data elements that make up business documents.
Business Model – A business model describes the rationale of how an organization creates, delivers, and captures value. Read a case study here.
Business Policy – Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and appropriate development and implementation of Processes, Standards, Roles, Activities, IT Infrastructure etc.
Business Process – An event-driven, end-to-end processing path that starts with a customer request and ends with a result for the customer. Business processes often cross-departmental and even organizational boundaries.
Business Service – Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
Capability – An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve.
Change Management – The automated support for development, rollout, and maintenance of system components (i.e., intelligent regeneration, package versioning, state control, library control, configuration management, turnover management and distributed impact sensitivity reporting).
Cloud Transformation – The process of moving data, applications or other business elements from an organization’s onsite computers to the cloud, or moving them from one cloud environment to another. Read more in our white paper “How enterprise architecture paves the way into the cloud”.
Concern – A Concern is any interest in the system. The term derives from the phrase “separation of concerns” as originally coined by Edsgar Dijkstra. Examples of concerns: (system) purpose, functionality, structure, behavior, cost, supportability, safety, interoperability.
Data Object – Reflects information about important business items. This could be data of the kind of account, employee or organization. A Data Object Fact Sheet can be linked to Applications and Interfaces and stores additional information about data sensitivity. A good use of the Data Object is when you want to manage data sensitivity or manage consistency of business information.
Digital Transformation – The process of changing from analog to digital form, also known as digital enablement. Said another way, digitization takes an analog process and changes it to a digital form without any different-in-kind changes to the process itself. Read more in our white paper “Digital transformation: A case for lean enterprise architecture management”.
Enterprise Architecture – A discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions.
Enterprise Information Architecture – The part of the enterprise architecture process that describes — through a set of requirements, principles and models — the current state, future state and guidance necessary to flexibly share and exchange information assets to achieve effective enterprise change.
Enterprise principals – A basis for decision-making throughout an enterprise. Such principles are commonly found as a means of harmonizing decision making across an organization. In particular, they are a key element in a successful architecture governance strategy.
Environment – The environment, or context, in which the system exists including the social, business and technical aspects.
Framework – Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders.
Information Architecture – Set of rules that determine what, and how and where, the information will be collected, stored, processed, transmitted, presented, and used. On the internet, information architecture means how a website’s content is organized and presented to its users to facilitate navigation and search functions.
Kanban – Technique used in lean manufacturing (i.e., just-in-time) environments to reduce process cycle time by managing the flow. Learn the difference between Agile, Kanban and Scrum here.
Key Performance Indicator (KPI) – A high-level metric that reflects a process or characteristic that is typically measured on a business leader’s scorecard.
Lean – A focused approach to the provision of effective solutions involving the consumption of a minimum of resources.
Model – A view is comprised of Architecture Models. Each model is constructed in accordance with the conventions established by its Model Kind, typically defined as part of its governing viewpoint. Models provide a means for sharing details between views and for the use of multiple notations within a view.
Model Kind – A Model Kind defines the conventions for one type of Architecture Model. Purpose The purpose of a system is a concern of the relevant stakeholders.
Portfolio Management – The selection, prioritization and control of an organization’s projects and programs in line with its strategic objectives and capacity to deliver. Learn all you need to know about portfolio management in our definitive guide.
Product Lifecycle Management – A philosophy, process, and discipline supported by software for managing products through the stages of their life cycles, from concept through retirement. As a discipline, it has grown from a mechanical design and engineering focus to being applied to many different vertical-industry product development challenges.
Project – A temporary endeavor undertaken to achieve a specific business outcome, creating a unique product, service or result. A project may be sequenced or grouped with closely related projects within a Program. Each project has a life cycle that typically includes specific project phases: initiation, planning, execution, and closure.
Quality Assurance – The maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production.
Resource – An economic or productive factor required to accomplish an activity, or as a means to undertake an enterprise and achieve the desired outcome. The three most basic resources are land, labor, and capital; other resources include energy, entrepreneurship, information, expertise, management, and time.
Risk – One of the elements of a business model assessment, a risk is a type of potential impact to the organization that should be considered as part of business judgment. The business model assessment is composed of one or more business judgments and puts perspective around the model or models evaluated.
Scrum – A framework for project management that emphasizes teamwork, accountability and iterative progress toward a well-defined goal.
Service Level Agreement (SLA) – A service level agreement is a contract made between two business units, where one business unit provides a service to another. The contract describes specific measures by which the service provider’s performance will be measured, as well as acceptable ranges of those measures that the consumer would find acceptable.
Service-Oriented Architecture (SOA) – A design paradigm and discipline that helps IT to meet business demands. Some organizations realize significant benefits using SOA including faster time to market, lower costs, better application consistency and increased agility. SOA reduces redundancy and increases usability, maintainability, and value. This produces interoperable, modular systems that are easier to use and maintain. SOA creates simpler and faster systems that increase agility and reduce the total cost of ownership (TCO).
Software-As-A-Solution (SaaS) – Software that is owned, delivered and managed remotely by one or more providers. The provider delivers software based on one set of common code and data definitions that is consumed in a one-to-many model by all contracted customers at any time on a pay-for-use basis or as a subscription-based on use metrics.
Solution Architecture – An architectural description of a specific solution. Solution architectures combine guidance from different enterprise architecture viewpoints (business, information and technical), as well as from the enterprise solution architecture.
Stakeholder – Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest. Examples of stakeholders: client, owner, user, consumer, supplier, designer, maintainer, auditor, CEO, certification authority, architect.
Statement of Work (SOW): An objectives section allowing the customer to emphasize the desired end state or performance metric to be achieved. It also mandates the assessment of past performance, technical approach, and cost for each task order. The customer determines the relative importance of each criterion.
Supply chain management (SCM): The processes of creating and fulfilling demands for goods and services. It encompasses a trading partner community engaged in the common goal of satisfying end customers.
Technical Reference Model – A foundation to categorize the standards, specifications, and technologies to support the construction, delivery, and exchange of business and application components (Service Components) that may be used and leveraged in a Component-Based or Service-Oriented Architecture.
Technology Obsolescence – The time and state in which a piece of technology or product ceases to be useful, productive or compatible.
Technology Risk – Any potential for technology failures to disrupt your business such as information security incidents or service outages. Learn all you need to know about technology risk management in our definitive guide!
Total Cost Of Ownership (TCO) – A comprehensive assessment of information technology (IT) or other costs across enterprise boundaries over time. For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses and the opportunity cost of downtime, training and other productivity losses.
Value Proposition – The central notion of a business model, the value proposition describes how the business, through its activities, adds value to the consumer or marketplace. The Value proposition binds together the notions of customer demands, required competencies, revenue models and business partnerships. It is a statement from the viewpoint of the target customers that informs everyone “why” the business’ products and services are valuable.
Value Stream – A sequence of business processes the boundaries of which are typically defined by business transactions. They represent end-to-end sequences such as “order to cash” or “idea to available product”.
View – An Architecture View in an AD expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models.
Viewpoint – An Architecture Viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of Architecture View. A viewpoint includes Model Kinds, viewpoint languages and notations, modeling methods and analytic techniques to frame a specific set of Concerns. Examples of viewpoints: operational, systems, technical, logical, deployment, process, information.
Web-oriented architecture (WOA) – A substyle of service-oriented architecture (SOA) that leverages Web architecture. It emphasizes the generality of interfaces (user interfaces and APIs) via five fundamental generic interface constraints: resource identification (e.g., uniform resource identifier [URI]), manipulation of resources through representations (e.g., HTTP), self-descriptive messages (e.g., Multipurpose Internet Messaging Extensions [MIME] types), hypermedia as the engine of application state (e.g., links) and application neutrality.
