Enterprise architecture artifacts

Last updated February 02, 2022

Enterprise architecture artifacts, or EA artifacts, are separate documents constituting enterprise architecture.^[2] EA artifacts provide descriptions of an organization from different perspectives important for the various actors involved in strategic decision-making and implementation of IT systems. They can be considered as key elements and cornerstones of an EA practice. Essentially, an EA practice revolves around using specific sets of EA artifacts for improving communication between different actors.^[3]

Overview

EA artifacts are main instruments of an EA practice enabling effective decision-making and IT planning in organizations.^[2] The systematic use of EA artifacts for collective decision-making distinguishes a disciplined approach to information systems planning from an ad hoc and ill-organized one. Different EA artifacts are used by different actors at different moments for different purposes and fulfill different roles in organizations.^[4] EA artifacts can be very diverse in their basic properties and attributes. From the perspective of their properties all EA artifacts can differ in their informational contents, general meanings and lifecycles in the context of an EA practice.

Informational contents

From the perspective of their informational contents, various EA artifacts can use different representation formats, provide different levels of detail, cover different scopes, describe different EA domains and focus on different points in time:^[5]

EA artifacts can have different representation formats. Specifically, EA artifacts can be represented in textual, graphical and sometimes tabular formats, or as a mix of these formats. Purely textual EA artifacts contain only plain text. Purely graphical EA artifacts contain only diagrams and models sometimes created using special modeling languages or notations. Purely tabular EA artifacts contain only tables with rows and columns. Mixed EA artifacts can contain the elements of all these representation formats in different proportions
EA artifacts can provide different levels of detail. Descriptions contained in EA artifacts can range in their granularity from very high-level abstractions (e.g. business or IT capabilities, overarching rules, executive-level considerations, etc.) to pretty low-level details (e.g. specific business activities, IT systems, databases, etc.)
EA artifacts can cover different organizational scopes. From the perspective of their scopes, coverage of EA artifacts ranges from entire organizations, lines of business and business functions to narrow organizational areas, specific change initiatives and even single IT projects. Typically EA artifacts covering wider scopes are less detailed, while EA artifacts covering narrower scopes are more detailed
EA artifacts can describe different EA domains. EA domains often described by EA artifacts include business, applications, data, infrastructure and security domains, as well as all possible combinations of multiple different EA domains
EA artifacts can focus on different temporal states of an organization, i.e. describe an organization at different points in time. All states typically described in EA artifacts can be roughly separated into the current state (now), short-term future state (<1 year), mid-term future state (2-3 years) and long-term future state (3-5 years). Additionally, some EA artifacts can describe a combination of all these states in different proportions or can even be essentially stateless, i.e. do not focus on specific points in time. For example, some EA artifacts can describe the current state of an organization as well as the planned changes to this state in both the short-term and mid-term future, while other EA artifacts can describe some timeless imperatives for an organization which were relevant in the past, are relevant now and will be relevant in the future

Lifecycles

From the perspective of their lifecycles in an EA practice all EA artifacts can be separated into permanent EA artifacts and temporary EA artifacts:^[5]

Permanent EA artifacts are long-lived EA artifacts often existing for many years. They “live” and evolve together with an organization. Permanent EA artifacts are created once and then updated when necessary according to the ongoing changes in an organization and its business environment. They may be either developed at once in a proactive manner, or produced reactively on an as-necessary basis, i.e. accumulated in organizations gradually over time. After being developed these EA artifacts are constantly used, continuously maintained and occasionally discarded when become irrelevant. Most EA artifacts covering wider scopes beyond specific IT initiatives or projects tend to be permanent EA artifacts
Temporary EA artifacts are short-lived EA artifacts often existing for several months or even weeks. They are transitory, single-purposed and disposable. Temporary EA artifacts are created at specific moments for particular purposes, used as intended and then immediately discarded or archived. Due to their short lifespan, the very need to update or maintain temporary EA artifacts is usually absent. All EA artifacts covering narrow scopes, e.g. specific IT initiatives or projects, tend to be temporary EA artifacts

Meanings

From the perspective of their general meaning in an EA practice all EA artifacts can be separated into decisions EA artifacts and facts EA artifacts:^[5]^[6]

Decisions EA artifacts represent made planning decisions, i.e. achieved and formalized agreements between various stakeholders regarding the desired future course of action. Decisions EA artifacts always have certain implications for the future and usually imply specific changes in an organization. Since all planning decisions regarding the future require the discussion and consensus between their stakeholders, these EA artifacts are always developed or updated collaboratively by all relevant stakeholders and represented in formats convenient for these stakeholders. Decisions EA artifacts are inherently subjective, speculative and people-specific in nature. They are based only on informed opinions of their contributors regarding the desirable future course of action and shaped primarily by the key interests of their stakeholders. Essentially, decisions EA artifacts play the primary role in an EA practice by providing the instruments for effective communication, balanced decision-making and collaborative IT planning. Their general purpose is to help make optimal planning decisions approved by all relevant stakeholders. After decisions EA artifacts are created and approved, all their stakeholders should be ready to act according to the corresponding planning decisions reflected in these EA artifacts. Since any ideas regarding the desired future always imply collective decisions, all EA artifacts describing the future state, as well as all stateless EA artifacts also having specific implications for the future, can be automatically considered as decisions EA artifacts from the perspective of their general meaning in an EA practice
Facts EA artifacts represent documented objective facts, i.e. reflections of the actual current situation in an organization as it is. Unlike decisions EA artifacts, facts EA artifacts do not imply any planning decisions and have no implications for the future. Since objective facts are normally not discussable and do not require any real decision-making, these EA artifacts may be developed or updated solely by specific actors, but represented in formats convenient for their future users. Facts EA artifacts are based only on acknowledged “hard” data and largely independent of specific people involved in their development. Essentially, facts EA artifacts play the supporting role in an EA practice by providing the information base required for developing decisions EA artifacts. Their general purpose is to help capture and store the objective facts regarding an organization important from the perspective of IT planning. After facts EA artifacts are created, they can be used by any actors as reference materials for planning purposes. Since a mere documentation of the current situation does not imply any real decisions, all EA artifacts describing only the current state can be automatically considered as facts EA artifacts from the perspective of their general meaning in an EA practice

Duality

One of the most important properties of EA artifacts is the duality of their informational contents.^[5] Duality of EA artifacts implies that the information provided by these EA artifacts is relevant to two different audiences simultaneously, satisfies the information needs of both these audiences and presented in a convenient format appealing to both audiences. Their duality allows using EA artifacts as a means of communication and partnership between different groups of actors involved in strategic decision-making and implementation of IT systems. Duality of EA artifacts can be considered as one of the most fundamental mechanisms underpinning an EA practice and enabling effective collaboration between diverse stakeholders. Duality of EA artifacts can be explicit or implicit:

Explicit duality is when different parts of EA artifacts are relevant to different groups of actors, e.g. some sections of an EA artifact are intended primarily for business stakeholders, while other sections of the same EA artifact are intended primarily for IT stakeholders
Implicit duality is when same parts of EA artifacts are interpreted differently by different actors, e.g. the same diagram in an EA artifact is relevant to both business and IT stakeholders, but has significantly different implications for each of these parties

In other words, duality of EA artifacts implies either providing different information to different actors, or providing same information having different meanings for different actors. Explicit and implicit dualities in EA artifacts are often combined. However, not all useful EA artifacts are dual in nature.

Related Research Articles

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.

The Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: Identification, Definition, Representation, Specification, Configuration and Instantiation.

Enterprise architecture (EA) is an analytical discipline that provides methods to comprehensively define, organize, standardize, and document an organization’s structure and interrelationships in terms of certain critical business domains characterizing the entity under analysis. The goal of EA is to create an effective representation of the business enterprise that may be used at all levels of stewardship to guide, optimize, and transform the business as it responds to real-world conditions. EA serves to capture the relationships and interactions between domain elements as described by their processes, functions, applications, events, data, and employed technologies.

The Open Group Architecture Framework (TOGAF) is the most used framework for enterprise architecture as of 2020 that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. TOGAF is a high-level approach to design. It is typically modeled at four levels: Business, Application, Data, and Technology. It relies heavily on modularization, standardization, and already existing, proven technologies and products.

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

A federal enterprise architecture framework (FEAF) is the U.S. reference enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models - typically matrices and diagrams - for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

Enterprise information security architecture (ZBI) is a part of enterprise architecture focusing on information security throughout the enterprise. The name implies a difference that may not exist between small/medium-sized businesses and larger organizations.

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

Enterprise systems engineering (ESE) is the discipline that applies systems engineering to the design of an enterprise. As a discipline, it includes a body of knowledge, principles, and processes tailored to the design of enterprise systems. An enterprise is a complex, socio-technical system that comprises interdependent resources of people, information, and technology that must interact to fulfill a common mission.

In the business sector, business architecture is a discipline that "represents holistic, multidimensional business views of: capabilities, end‐to‐end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders."

Enterprise architecture management (EAM) is a "management practice that establishes, maintains and uses a coherent set of guidelines, architecture principles and governance regimes that provide direction and practical help in the design and development of an enterprise's architecture to achieve its vision and strategy."

ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.

Enterprise life cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance, disposition and disposal of existing elements of the enterprise.

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of a whole system from the perspective of a related set of concerns.

Treasury Enterprise Architecture Framework (TEAF) was an Enterprise architecture framework for treasury, based on the Zachman Framework. It was developed by the US Department of the Treasury and published in July 2000. May 2012 this framework has been subsumed by evolving Federal Enterprise Architecture Policy as documented in "The Common Approach to Federal Enterprise Architecture".

This article documents the effort of the Health Level Seven(HL7) community and specifically the HL7 Architecture Board (ArB) to develop an interoperability framework that would support services, messages, and Clinical Document Architecture(CDA) ISO 10871.

The Federation of Enterprise Architecture Professional Organizations (FEAPO) is a worldwide association of professional organizations, aiming to standardize, professionalize, and otherwise advance the discipline of enterprise architecture." Brian Cameron is the founding director."

Agile architecture means how enterprise / system / software architects apply architectural practice in agile software development. A number of commentators have identified a tension between traditional software architecture and agile methods along the axis of adaptation versus anticipation.

Business capability models provide structured graphical representations of all organizational business capabilities, their relationship and hierarchy.

References

↑ "Enterprise Architecture on a Page", Svyatoslav Kotusev, October 2017
1 2 Winter, R. and Fischer, R. (2006), Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, In: Vallecillo, A. (ed.) Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference Workshops, Hong Kong, China, pp. 30-37.
↑ Abraham, R. (2013) Enterprise Architecture Artifacts as Boundary Objects - A Framework of Properties, In: van Hillegersberg, J., van Heck, E. and Connolly, R. (eds.) Proceedings of the 21st European Conference on Information Systems, Utrecht, The Netherlands: Association for Information Systems, pp. 1-12.
↑ Niemi, E. and Pekkola, S. (2017) Using Enterprise Architecture Artefacts in an Organisation, Enterprise Information Systems, Vol. 11, No. 3, pp. 313-338.
1 2 3 4 Kotusev, Svyatoslav (2021) The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment (2nd Edition). Melbourne, Australia: SK Publishing.
↑ "Enterprise Architecture Artifacts: Facts and Decisions", Kotusev, S., June 2019

External links

Enterprise Architecture on a Page (June 2018)

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[EAonaPage-1] "Enterprise Architecture on a Page", Svyatoslav Kotusev, October 2017

[Winter-2] 1 2 Winter, R. and Fischer, R. (2006), Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, In: Vallecillo, A. (ed.) Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference Workshops, Hong Kong, China, pp. 30-37.

[3] Abraham, R. (2013) Enterprise Architecture Artifacts as Boundary Objects - A Framework of Properties, In: van Hillegersberg, J., van Heck, E. and Connolly, R. (eds.) Proceedings of the 21st European Conference on Information Systems, Utrecht, The Netherlands: Association for Information Systems, pp. 1-12.

[4] Niemi, E. and Pekkola, S. (2017) Using Enterprise Architecture Artefacts in an Organisation, Enterprise Information Systems, Vol. 11, No. 3, pp. 313-338.

[Kotusev2018-5] 1 2 3 4 Kotusev, Svyatoslav (2021) The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment (2nd Edition). Melbourne, Australia: SK Publishing.

[6] "Enterprise Architecture Artifacts: Facts and Decisions", Kotusev, S., June 2019

[2]

[3]

[4]

[5]

[6]