The most important property of enterprise architecture artifacts

Moreover, the EA discourse has been characterised by a persistent bias towards fashionable topics (e.g. fake tools), rather than topics that are really worth discussing (e.g. real tools). Many publications that appeared on the subject in the popular media either speculated on the advantages and disadvantages of existing EA frameworks, or addressed some fancy matters of passing interest, which resonate with the fuss of the day, but lose their relevance on the next morning and add no lasting value to our understanding of enterprise architecture. For example, recently EA gurus seriously discussed the relationship between enterprise architecture, Brexit, coronavirus and even the BLM movement. All these musings represent merely entertainment and convey no real information to EA practitioners. At the same time, some truly fundamental questions, whose importance to the EA discipline is difficult to overemphasise, received surprisingly limited attention, if any attention at all.

Practicing enterprise architecture implies producing and using specific EA artifacts - physical documents that capture some aspects of organisations’ businesses and their IT landscapes. Although an EA practice is a multifaceted phenomenon associated with numerous organisational benefits, few people would disagree that its core value proposition is business and IT alignment (call it business and IT integration, fusion, convergence, digital transformation or pick any other term you like). But, what makes EA artifacts useful for the purposes of improving business and IT alignment? How exactly do EA artifacts help align business and IT elements in organisations? What properties of EA artifacts turn them into effective alignment instruments? Despite their evident significance for comprehending the mechanisms of enterprise architecture, all these questions have never been in the limelight.

Enterprise architecture artifacts as alignment instruments

Most comprehensive sources on enterprise architecture, ranging from the earliest Enterprise Architecture Planning (EAP) methodology¹ to the current ‘industry standard’ TOGAF, present an EA practice as a sequential step-wise process, where the target state of an organisation is thoroughly described by enterprise architects with numerous EA artifacts (e.g. diagrams, models and matrices) and then implemented. Basically, all these methodologies embody classic engineering-style design approaches applied to organisations. The real-world experience has shown, however, that EA artifacts developed by architects in isolation for the purposes of depicting the desired situation from different viewpoints are barely understandable to anyone except their creators. Needless to say, such ‘grand’ designs of the envisioned future are usually abandoned and never materialise, resulting only in bloated document repositories instead of genuine business and IT alignment.

The fact here is that successful EA practices are, first of all, communication practices. They represent inherently social activities that rely primarily on a continuous and intense dialogue between various actors involved in strategic decision-making and implementation of information systems, as part of which the interests and concerns of these actors get aligned. Unsurprisingly, most EA practices today are headed by architecture managers responsible largely for deepening and institutionalising communication processes, rather than by chief architects acting as supreme designers. In this context, EA artifacts should be viewed specifically as instruments of communication between diverse audiences, most importantly between business and IT stakeholder communities, aiming to promote mutual understanding, support collective decision-making and, thereby, enhance business and IT alignment².

Duality of enterprise architecture artifacts

The property of EA artifacts that makes them suitable for bridging communication gaps between different audiences can be called, for the lack of a better word or established term, duality. Duality implies that an EA artifact makes perfect sense to two or more stakeholder groups simultaneously and informs each of these groups on the relevant matters. It is this property of duality that turns EA artifacts into effective translation tools helping diverse business and IT stakeholders stay on the same page, understand each other and develop balanced planning decisions taking into account the critical interests, objectives and concerns of all parties. The duality of EA artifacts is absolutely essential for their utility as a means of aligning business and IT.

The duality of an EA artifact is achieved when its informational contents are both comprehensible and relevant to the representatives of intended stakeholder communities. Comprehensibility and relevance, in turn, require at least three related but different constituents: syntactic, semantic and presentational. Firstly, a syntactic component implies using language easily understandable, or native, to all the audiences of an EA artifact. For example, employing highly IT-specific terms (e.g. ‘RESTful services’, ‘JVM platform’ or ‘pessimistic locking’) in EA artifacts renders them virtually inscrutable for normal business stakeholders. Similarly, some business terminology can be obvious for narrow subject-matter experts, but harder to grasp for broader stakeholder circles.

Secondly, a semantic component implies using concepts naturally meaningful to all the audiences of an EA artifact and to which they can refer. This component is linked to a syntactic one and even requires syntactic clarity as a necessary precondition, but has an important distinction from it. For example, the business notions of market share, profit margin and goods turnover are syntactically understandable, but convey little or no meaning to IT stakeholders due to the absence of their transparent connection to information systems. Likewise, some technology-related terms, such as data centre or network bandwidth, can be understood even by ordinary managers and yet be irrelevant to them because of their vague impact on the business.

Thirdly, a presentational component implies using visualisations intuitively appealing to all the audiences of an EA artifact. This component differs from the two previous components as it determines not what information is included in EA artifacts, but how it is presented. For example, working with some information presentation formats, like relationship matrices and drawings utilising specialised modelling notations, requires certain skills and these formats are unlikely to be comfortably digestible to unprepared executive-level stakeholders. Also, huge diagrams with numerous entities and overlapping interconnections can easily overwhelm a layperson, leading to confusion and embarrassment.

A combination of all the three components described above, syntactic, semantic and presentational, confers EA artifacts with the property of duality, which allows using them as practical tools during organisational decision-making processes involving both business and IT representatives to facilitate business and IT alignment. Within these processes, EA artifacts offer a common language, a shared meaning and a joint decision procedure to all their participants, thereby bringing business and IT communities together (or, to use sociological terminology, fulfil the role of boundary objects between these communities³). Although different organisations tend to leverage different, and sometimes even unique, types of EA artifacts for the purposes of aligning business and IT, all these artifacts must possess the property of duality to be able to serve as alignment instruments.

Implicit and explicit duality

The duality of EA artifacts can take two different forms: implicit and explicit. Implicit duality is achieved via high interpretive flexibility of EA artifacts, which allows different stakeholder communities to interpret their informational contents somewhat differently, according to their background, interests and concerns. A perfect specimen of EA artifacts with implicit duality are business capability models⁴, ⁵, ⁶. These artifacts provide structured graphical views of all organisational business capabilities, where each capability represents a high-level abstraction encompassing all the underlying capability components, e.g. people, processes, IT resources and other elements. This multifaceted nature of business capabilities allows different audiences to interpret them differently: C-level executives consider business capabilities primarily as general assets for strategy execution, lower-rank managers - as coherent groups of business processes and activities, HR officers - as human resources, competencies and skills, IT leaders - as information systems and hardware infrastructure. Such a broad interpretation of business capabilities enables the collaborative use of business capability models during strategic sessions to coordinate long-term priorities, ends and means between various business and IT representatives, achieving their mutual alignment.

By contrast, explicit duality is achieved via organising the informational contents of EA artifacts into different segments, sections or views intended for different stakeholder communities. Explicit duality can be best exemplified, for instance, by solution overviews⁴, ⁵, ⁶. These artifacts offer high-level descriptions of proposed IT solutions and are typically structured into multiple separate sections, e.g. strategic context, basic requirements, anticipated benefits, conceptual solution architecture, required resources and potential risks. Each of these sections contains rather concrete information that cannot be interpreted flexibly, but different audiences can concentrate their attention on different sections relevant specifically to them: business sponsors of IT solutions focus mostly on the strategic context and anticipated benefits, business analysts - on the basic requirements, project managers - on the required resources, IT experts - on the conceptual solution architecture. Such a multi-section structure of solution overviews enables their cooperative use by business and IT stakeholders as part of initiative approval procedures to make balanced investment decisions optimal from both the business and IT standpoints.

Implicit and explicit duality represent different approaches for pursuing one goal: ensuring comprehensibility and relevance of EA artifacts to all their audiences. Although these approaches leverage quite different cognitive mechanisms, many EA artifacts effectively combine the elements of implicit and explicit duality in their informational contents.

Documents not possessing duality

As explicated above, the property of duality is vital for EA artifacts to fulfil the function of business and IT alignment instruments. However, far from all documents that an EA practice deals with possess this property. One noteworthy example of documents that cannot be regarded as dual is top-level business strategy documents. These documents often include a mission statement, long-range vision and corporate values, as well as some goals, objectives and KPIs for the company. Semantically, this information is not particularly meaningful to IT managers because general business intentions (e.g. open a new line of business or enter a foreign market) and even specific business indicators (e.g. target numbers for revenue growth or customer loyalty) seldom offer any definite ideas about what IT should do to realise them⁷. This paucity of IT-related suggestions leaves IT leaders mostly with their own conjectures and guesswork as to what exactly is expected of their departments, undermining business and IT alignment. For this reason, business strategy documents - though, may play a crucial role in communication between C-level executives and their subordinate department directors - are largely unsuitable as alignment instruments between business and IT communities.

For you

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

Another important example of documents that do not possess the property of duality is various EA artifacts intended to capture the technology portfolio of an organisation, e.g. technology reference models⁴, ⁵, ⁶. These artifacts are full of technical jargon, focus on things arcane to mere mortals and usually contain no information on how the business is done, which makes them entirely impenetrable and irrelevant to average business managers. They are used exclusively within IT departments, or even only by architecture teams, and associated with such valuable benefits as faster initiative delivery, reduced costs and risks, but have almost nothing to do with business and IT alignment.

Yet another notable specimen of non-dual EA artifacts is all sorts of technical landscape diagrams depicting the current structure and composition of the corporate IT environment⁴, ⁵, ⁶. These diagrams are often rather sophisticated, use some or the other formal modelling notation and are rarely deemed intuitive by business representatives with no prior IT background. Even when they provide certain views potentially helpful from the perspective of business and IT alignment (e.g. descriptions of business processes and their connection to underlying applications and databases), by virtue of their pronounced IT-flavour, these views are still comprehensible mostly to specialists having the necessary qualification to interpret them properly. These EA artifacts are indispensable instruments for architects to manage complexity, plan the integration of new IT solutions and removal of legacy, but their presentation to business leaders for the purposes of discussing alignment-related questions, in most cases, requires substantial simplification and ‘beautification’ - essentially, conversion into plain powerpoints.

Duality and the CSVLOD model

In my previous works, I introduced the CSVLOD model of enterprise architecture that classifies all EA artifacts that proved useful in practice into six general types of EA architecture according to their functional roles: considerations, standards, visions, landscapes, outlines and designs (CSVLOD)⁴, ⁸, ⁹. These six general types can also be analysed from the perspective of their duality to better understand their features and properties.

Specifically, both considerations (e.g. principles and policies) and visions (e.g. business capability models and roadmaps) address different dimensions and aspects of strategic alignment between business and IT. They represent classic dual EA artifacts welding the communities of business and IT leaders together and bridging communication gaps between them. Considerations and visions use rather abstract IT-agnostic language, are normally expressed in simple textual or graphical forms and tend to rely more on implicit duality, which allows flexible interpretation and lets business stakeholders see the business consequences of the respective decisions and IT stakeholders - their implications for IT.

Outlines (e.g. solution overviews and options assessments) deal mostly with tactical business and IT alignment at the level of individual change initiatives. Like considerations and visions, they are also dual EA artifacts for business and IT representatives using technology-neutral terminology and intuitive presentation formats. However, outlines usually rely more on explicit duality by providing structured descriptions with multiple separate sections or viewpoints intended to satisfy the concerns of different parties.

Both standards (e.g. technology reference models and guidelines) and landscapes (e.g. landscape diagrams and inventories) purport primarily to facilitate IT landscape optimisation, not business and IT alignment, and are not dual EA artifacts. They are purely technical in nature and created to be used by specialists, rather than for communication with broad stakeholder circles. Standards and landscapes are important tools of the internal IT ‘kitchen’, but they rarely travel outside of the IT or even architecture community.

Lastly, designs (e.g. solution designs and preliminary solution designs) are produced to drive solution delivery activities. They can be viewed as a special type of dual EA artifacts intended to marry the communities of architects and project teams via combining organisation-wide concerns and implementation-level details in the same documents. Like outlines, designs typically use explicit duality and are structured into different sections covering different aspects of proposed solutions and aimed at different audiences.

Duality as a practical imperative

The treatise provided above explained the role of EA artifacts as tools of communication between business and IT representatives and introduced the notion of duality as the property of artifacts that enables this role. The discussion of EA artifacts as alignment instruments and their duality is summarised in Figure 1.

Click the diagram below to view a larger version

Figure 1. Duality of Enterprise Architecture artifacts and its role for alignment

As Figure 1 illustrates, dual EA artifacts can be used as a means of aligning business and IT, whereas documents that do not possess this property cannot be used as such (but they can be helpful for other purposes). If we assume that the core value proposition of enterprise architecture is business and IT alignment, then duality can definitely be regarded as the single most important property of EA artifacts as it is this property that makes their utility as alignment instruments possible.

So, what does it all mean in a practical sense for an enterprise architect in an organisation? First of all, architects should clearly realise that EA artifacts dealing with alignment issues are produced not for the sake of accurate or holistic description, as it is often instilled by the mainstream EA literature, but for the sake of communication. Hence, when creating such artifacts, architects should ensure their duality. First, obvious but still worth reminding, architects should always think of what audiences of an EA artifact are and find the right language for these particular audiences, preferably ‘borrowing’ their native terminology. Second, and somewhat less evident, in EA artifacts, architects should use the concepts truly meaningful to all the audiences, i.e. to which all of them can relate and around which they can build certain logical inferences or cause-and-effect relationships to be able to make intelligent judgments on alignment. Finally, in EA artifacts architects should avoid using any non-trivial modelling notations whose proper interpretation requires specialised knowledge, minimise the number of elements on diagrams and, to a large extent, adopt ‘the simpler, the better’ attitude.

Considering the duality of EA artifacts seriously and sticking with the simple recommendations outlined above can assist in overcoming the reputation of architects as inhabitants of ‘ivory towers’ and increase the success rate of EA initiatives. Practicing enterprise architecture, more than anything else, equals establishing effective communication across diverse stakeholder groups and communities involved in business and IT alignment processes. Blaming stakeholders for the absence of ‘architectural thinking’ is not going to help succeed with enterprise architecture, only creating appealing EA artifacts with the property of duality offers a genuine practical solution.