Enterprise Architecture artifacts: facts and decisions

Enterprise architecture artifacts provide various views of an organisation from the perspective of its business and IT. But what is the meaning of EA artifacts? And why are EA artifacts even created?

Problem with Enterprise Architecture methodologies

The purpose of EA artifacts cannot be purely descriptive since organisations do not benefit from creating descriptions for the sake of descriptions. However, all widely known EA methodologies^1,2,3, advocate doing exactly that - developing many EA artifacts with unclear goals in mind.

The so-promoted ‘proven EA methodology’, TOGAF, provides a comprehensive list of EA artifacts and describes, in great detail, the sequence in which they should be developed, however, it barely explains why they are created.

It’s not surprising, since all these EA methodologies originate from consultants, who care primarily about their fee, but rarely about what eventually happens with the produced EA artifacts⁴. This had led to organisations, guided by consultants’ best practices, wasting billions of dollars on creating aimless architectural descriptions of little or no business value (see Enterprise architecture frameworks: The fad of the century).

Instead, the real value of EA artifacts is in their use. My analysis of EA artifacts within multiple organisations shows that these artifacts can be divided into two specific classes: facts EA artifacts and decisions EA artifacts. These two groups are handled very differently by architects and have fundamentally different purposes in an EA practice.

What are facts EA artifacts?

In the case of facts EA artifacts, these reflect the current situation in an organisation. For example, facts EA artifacts may describe the structure of the existing IT landscape, list available IT assets and explain the connections between them. Facts EA artifacts only ever focus on the current state of the organisation and have no implications for the future.

Facts EA artifacts are ‘simple’ artifacts. They can be created or updated by sole architects alone or with only a minimal involvement of other actors. In essence, an individual architect is able to study and document a particular area of the IT landscape if it is not yet documented. Or, after a new system is placed in the IT landscape, an architect can add this system to the corporate asset inventory and update corresponding landscape diagrams. Since these EA artifacts merely document some objective facts (independent of specific people and their opinions), their development or modification should be free of debate or politics.

However, facts EA artifacts only offer a supporting role within an EA practice. It’s true that these EA artifacts help capture, store and leverage knowledge on the current state of the IT landscape for planning purposes - but they still only provide ‘static’ information that can be used by architects, for example, during the planning of new IT initiatives and solutions. Therefore, the value of facts EA artifacts is realised after their development, while their most critical success factor is their accuracy.

What are decisions EA artifacts?

Decisions EA artifacts represent made planning decisions. In other words, they capture achieved agreements regarding the desirable future course of action. For example, decisions EA artifacts may describe architectures of proposed IT solutions, organisation-wide target states or recommended technology standards. These EA artifacts either explicitly describe the future state, e.g. solution designs, or at least have some articulate implications for the future, e.g. architecture principles.

Decisions EA artifacts are ‘complex’ artifacts. They cannot be created and updated by individual architects, but always require collective efforts with the involvement of all relevant stakeholders of these EA artifacts. Essentially, architects serve only as facilitators, rather than real developers of decisions EA artifacts.

For example, an architect cannot develop an investment roadmap for a business unit alone. Instead, an architect should meet with all business unit executives, discuss their business objectives and needs, recommend the best possible response from IT, reach an agreement with the business leaders on the desirable future IT investments and then document these agreements in the roadmap.

Similarly, an architect cannot ‘re-heatmap’ the business capability model alone, but only as part of the strategic dialog with C-level business executives. Unlike ‘routine’ facts EA artifacts, the development of decisions EA artifacts is a very tricky, highly creative and politicised process, which requires an intensive dialogue and negotiations between stakeholders. These EA artifacts are subjective in nature, i.e. their contents are wholly determined by the personal opinions and concerns of their creators.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

Decisions EA artifacts fulfil the primary role in an EA practice. They provide instruments for communication and decision-making which help make optimal planning decisions, taking into account the key interests of all involved parties. Essentially, the development process of decisions EA artifacts is the actual planning.

After being developed and endorsed by their stakeholders (and in most cases formally signed-off by an authorised governance committee), these EA artifacts define future activities and oblige all the stakeholders to act in accordance with the respective planning decisions. Unlike facts EA artifacts, the value of decisions EA artifacts is realised mostly during their development.

Decisions EA artifacts arguably constitute the core of an EA practice, since it is this very process of their development that enables effective communication between business and IT that will eventually lead to the mutual alignment of both business and IT plans. The single most critical success factor for decisions EA artifacts is the timely involvement and active participation of all relevant stakeholders in the process of their development.

Why is this classification so important?

The distinction between facts EA artifacts and decisions EA artifacts has numerous implications for an EA practice. Both have different development processes and purposes as well as several other more subtle differences affecting their informational contents, presentation formats and even physical storage.

The contents and formats of facts EA artifacts are intended primarily for the convenience of their future users, e.g. they must be comprehensive and searchable. Conversely, for decisions EA artifacts they are intended largely for their developers, e.g. support of collaboration and decision-making.

Facts EA artifacts can be physically stored in sophisticated EA-specific tool-based document repositories for easy access, navigation and analysis. Whereas, decisions EA artifacts are more often stored in ‘lighter’ formats enabling simpler distribution, wider sharing and collective editing - often as plain MS Word, Visio and PowerPoint files or in wiki-based collaboration platforms.

Avoiding failure with decisions EA artifacts

The single most important lesson to be learned about decisions EA artifacts is that all the attempts to define the desired future must involve all the stakeholders of this future. Unfortunately, numerous expensive failures of EA initiatives of both internal and external origin have occurred from not learning this lesson.

On the one hand, internal failures are often caused by inexperienced architects trying to define idealistic future states via interviewing some business representatives and then creating decisions EA artifacts on their behalf. Any future plans developed in this manner, i.e. in a way similar to facts EA artifacts, are naturally ignored, shelved and never acted upon - while organisations get disappointed in architects and architecture.

On the other hand, external failures are caused by EA consultancies trying to develop architectures for client organisations without their real involvement, i.e. by means of studying their business strategies, objectives and processes and then producing comprehensive architectures for them. ‘Gartner has observed... clients who have derailed the EA effort (and any subsequent attempts) through improper use of consultants. This usually happens when the client engages a consultant to do the architecture ‘to them’ rather than ‘with them’. Without the active participation of the client in the EA effort, the critical link to the business is lost’⁵ (p.3).

Generally, important planning decisions cannot be made on behalf of other people. Only decisions developed collaboratively by all parties together may be considered as actual planning, whereas all the decisions made by lone architects without an adequate stakeholder engagement can be considered only as wishful thinking.

Facts, decisions and the CSVLOD Model 

Previously, I reported that all EA artifacts used in established EA practices can be classified into one of the six general types: Considerations, Standards, Visions, Landscapes, Outlines and Designs (CSVLOD), accurately defining their practical roles (see Six types of enterprise architecture artifacts, Eight essential enterprise architecture artifacts and The relationship between enterprise architecture artifacts). These six general types of EA artifacts have obvious interpretations from the perspective of facts and decisions, facilitating a better understanding of their general meaning in an EA practice.

Specifically, Considerations represent decisions on how an organisation needs to work from the IT perspective. Standards represent decisions on how all IT systems should be implemented and some facts on the current approaches and technologies. Visions represent decisions on what IT should deliver to an organisation in the long term. Landscapes represent facts on the current IT landscape and some decisions on its future evolution. Outlines represent decisions on how approximately specific IT initiatives should be implemented. Finally, Designs represent decisions on how exactly specific IT projects should be implemented.

Importantly, of all types of EA artifacts only most Landscapes and some Standards are facts EA artifacts, while all other artifacts represent planning decisions and, therefore, must always be developed collaboratively. Due to the critical importance of distinguishing facts EA artifacts from decisions EA artifacts I have added their respective properties to the newly updated Enterprise Architecture on a page (see also Enterprise Architecture on a single page). The comparison of facts and decisions EA artifacts is briefly summarised below.

Interestingly, some EA artifacts can combine the features of both facts and decisions. For example, technology reference models can show all the technologies currently used in an organisation (facts) as well as the future plans regarding each of these technologies, e.g. invest, maintain or retire (decisions). Likewise, in some other EA artifacts their primary objects of description, e.g. systems or IT assets, represent merely documented facts, while the colour-coding of these objects reflects made planning decisions regarding their future.