So Many Architecture Diagrams and Artifacts –– How to Choose?

An artwork or poem has a very personal effect on its viewers or readers. For some, a few simple brush strokes, or a special arrangement of a few words, evoke a very powerful emotional response. And for others the same artwork or poem doesn’t do much. Response clearly is a subjective experience, and it depends on the viewer’s state of mind and how they interpret the art. Art is a means of communication. And so is architecture.

Architecture is part science and part art. Although the scientific side requires architecture to contain well organized and precise descriptions, the artistic side requires the information to be rendered in such a way that it evokes the right emotional response. The intensity of the response depends on how closely that view or special rendition of information resonate with the viewer.

It is therefore very important for architects to ensure that they understand the stakeholders’ interests and needs so they can summon the right views to render the information to invoke positive reactions.

Many architecture services are provided by architecture practice to business and IT organizations. At the end of each service some value is delivered to consumers, typically an artifact of some sort is produced.

One of the main services provided by architecture practice is the development of architecture models and views. Typically, four domain models namely Business, Data, Application, and Infrastructure are developed for an enterprise that collectively represent the ‘digital twin’ of the enterprise. Architects must also consider impact of the crosscutting concerns, namely – security, scalability, availability, performance, and reliability, and develop appropriate architecture views. Many views are also created based on these models specific to various stakeholders’ interests and needs.

Architecture of enterprise is complex; it consists of several types of artifacts expressing different viewpoints showing numerous relationships in form of diagrams, maps, and tables, all packaged in what usually is referred to as the architecture specification document. The level of details may vary depending on the delivery process adopted by the organization (e.g., Agile). The artifacts containing “just enough” information, sometimes densely packed and sometime at a very conceptual level, are created to communicate specific intent and purpose with the viewers.

There are the following three main purposes for which an architecture view is created:

• Informing: here the objective of these types of views is to inform stakeholders. They may be interested in understanding the big picture and core concepts. The architect themselves may wish to obtain commitment and approvals from stakeholders and must provide rationale to convince the challengers. Typical examples of this type of views are illustrations, animations, cartoons, infographics, etc., any form that is visually appealing, conveys a powerful message, and evokes constructive emotional response.
• Deciding: here the objective of the views is to assist decisionmakers in the process of decision-making by offering as many different perspectives as possible and provide insight through cross-domain architecture relationships, typically using projections and intersections of underlying models, but also by providing supporting facts by means of analytical data. Typical examples of this type of views are cross-reference tables, landscape maps, lists, charts and reports, etc.
• Designing: here the objective is to create the views to support viewpoints of architects and designers who are involved during various stages of architecture development process, from initial sketch to final detailed design. The views of this type are intended to be consumed by the architects, designers, and technical implementers who require precise description. So invariably these views are very technical in nature and consists of diagrams like those created using some modeling languages (UML, BPMN, ArchiMate, etc.) which are understood by their consumers.

See the article: Architecture – Eating an Elephant: One Bite at a Time which describes how architecture for enterprise can be developed in phases and in small chunks with variety of perspectives serving the interests of different stakeholders.

The three types of architectures namely, Enterprise (Conceptual), Solution (Logical) and Technical (Physical) are very distinct and serve different stakeholder’s interests at different stages of the strategic planning cycle. It should be evident from that article that these three architecture types cover different breadths and depths and are developed at different stages of the strategic planning cycle. Each type of architecture requires architects with specific skillsets and deep expertise in their subject matter.

All types of purposes described above apply to all three types of architectures views; however, the Conceptual architecture is predominantly intended for informing, Logical architecture is predominantly intended for deciding, and physical architecture is predominantly intended for designing and implementing.

Like every other profession, architects need a set of right architecture tools to create models quickly and render them in appropriate visual forms that are appealing. How does one go about choosing the right architecture tool and whether one should use modeling languages for developing architectures, etc. will be the topics for future article.

Creating various architecture models and views for each type of architecture is a time consuming and complex cognitive undertaking. There is no single good answer for what artifacts and deliverables are right, which views should be produced under each type of architecture. It depends on many factors.

Every strategic initiative is unique, every business is unique, and people within these businesses have unique interests. Businesses can have very different IT and architecture operating models and follow all sorts of solution delivery processes (traditional vs agile) and so deliverables needed by them can vary significantly from one organization to other.?

A good thumb rule is to only create artifacts that will be useful for stakeholders, or those that are explicitly demanded by the stakeholders. Time is a precious commodity. Creating models and artifacts are time-consuming activities and therefore identifying in advance, what deliverables will be useful to the stakeholders, is one of the first very important responsibilities of architects.

Many architecture frameworks (e.g., Zachman’s ontology and TOGAF) provide guidance on models, artifacts, and deliverables to produce; however, architects must always use their own good judgement and expertise to decide for themselves which views will make the most sense given the situation.

The following few sections list typical architecture artifacts. The lists are not exhaustive, but these are some of the artifacts that most of the stakeholders find useful most of the times. So, you might want to consider them to be included in the architecture deliverables package. But again, be mindful of available time and use your good judgment. ?

Many of the artifacts and diagrams can be implemented using modeling languages such as ArchiMate, UML, BPMN, and others. Whether you should use these languages really depends on familiarity and general adoption within your organizations. Nobody will learn a new language just because you have created views using them, no matter how important you think they might be. So, it is really up to you to ensure that the conventions and symbols defined in these modeling languages are well understood by its viewers before using them.

Finally, the architecture artifacts listed below mostly represent future state or “to be” state views. It is assumed that the current state or “as is” state views are already available before the start of architecture development phase.

Foundational artifacts

The following are some foundational artifacts that provide guidance during architecture development and should be created by the architecture practice leads at the beginning of formation of the practice. These documents should be routinely maintained and socialized thereafter.

• Business and Architecture principles
• Architecture and technology standards and policies
• Enterprise (Industry) Reference Architecture
• Overview of architecture governance and assurance capability

A proper version-controlled repository or tool should be deployed for managing all the deliverables produced by the architecture practice.

Enterprise Architecture Deliverables

The enterprise architecture assessment and development take place during the early part of the Develop stage of the strategic planning cycle.

Also see the article - Enterprise Architecture for Operating Model – A Deeper Dive.

Note that, conceptual architecture is usually intended to inform and so a lot of attention must go into creating impactful visuals. The main consumers of the EA artifacts are the senior executives - COO/CIOs/CTOs/CDO/CISO, IT Management, Business Sponsors, and peer enterprise architects and optionally CEO and CFO.

The enterprise architecture represents target operating model designs for the impacted organizations within the enterprise and therefore enterprise architecture has a much wider scope. It provides conceptual level details of business and technology domains along with their interrelationships for the affected operating models. Enterprise architecture is developed at the enterprise scope (or within a product line or line of business scope) for the given strategic period.

Solution Architecture Deliverables

Once the initiatives are approved and launched as programs (or themes/epics under Agile) then the logical or solution architecture development must take place. The solution architecture assessment and development take place during the latter part of the Develop stage of the strategic planning cycle.

Note that, logical architecture is usually intended for decision making and so a lot of attention must go into presenting the views with as many perspectives as possible to help with decision making process. The views should show the solution building blocks i.e., actual technologies, commercial and open-sourced products, and their interactions with each other. The main consumers of the solution architecture are - CIOs/CTOs/CDO/CISO, IT Management, Business Sponsors, Senior developers, Business subject matter experts, IT Operations, and the other architects.

The solution architecture represents enterprise segment architecture and therefore has intermediate scope. Solution architecture is developed within a project (or epic) scope, and it provides logical level architecture details of business and technology parts of an impacted operating model.

Technical Architecture Deliverables

Once the solution architecture is developed for the given program then the individual solution building blocks within the solution must further be flushed out so that they can be implemented by the developers. This is the physical or technical architecture development stage, and it takes place during the Implement stage of the strategic planning cycle.

Note that, physical architecture is usually intended for IT engineering folks and so a lot of attention must go into presenting the details precisely using technical languages. With the right visuals ambiguity can be minimized so the technical architects can understand each others’ perspectives and the developers can implement the designs with greater accuracy and test them according to how they were intended to operate. The main consumers of technical architecture are IT Management, Business SMEs, Senior Developers/SMEs, IT Operations, and the other architects.

The technical architecture represents designs for individual solution building block that support a capability within an operating model and therefore it has the narrowest scope. It provides lowest level and most detailed views of business and technology parts belonging to the given capability and their interactions and have the scope of a project iteration or an Agile sprint.

It is worth emphasizing the fact that the architecture diagrams and views are important means of communication with their viewers. Therefore, architecture views must be developed with care to convey the right message intended by the architects.

Author: Sunil Rananavare, IT Strategy Planning and Architecture (CIO Advisory)

Follow me on LinkedIn to stay informed. Share the article if you found it useful.

The views in the article are author’s own and not necessarily of his employer.?