Applying Enterprise Architecture with Enterprise Design and EDGY

This is a chapter from the EDGY Cookbook (load complete PDF version of the EDGY Cookbook from this link).

Enterprise Design and Enterprise Architecture

Enterprise Design and Enterprise Architecture are closely related disciplines that both aim to improve the functionality, efficiency, and alignment of an enterprise. However, their focus areas and methods differ, creating a complementary relationship.

Both seek to align an enterprise’s capabilities, processes, and resources with its strategic goals. Both aim to create coherence within the enterprise, ensuring that design and architecture support the business strategy.

Enterprise design provides a holistic, human-centric and collaborative view of the enterprise, focusing on customer experiences, service delivery, and strategic alignment.
Enterprise architecture takes a systemic and technical view, focusing on structures, processes, and applications needed to implement and support the design.

Enterprise architecture can merge with enterprise design and leverage its holistic, human-centric and collaborative approach, not only without conflicts but with substantial relevance and advantage. Enterprise architecture can benefit from enterprise design’s holistic approach, which considers not only the architecture but also the business strategy and the customer’s perspective. Enterprise Design covers Enterprise Identity, Enterprise Experience and Enterprise Architecture.

enterprise design and enterprise architecture — **Figure**: Enterprise Design is a holistic approach that covers all what is meaningful in an enterprise.

Enterprise Design approach ensures alignment across all components of the enterprise, enhancing effectiveness and coherence:

Holistic Perspective: Enterprise Design integrates all aspects of an enterprise, including strategy, organisation, culture, processes, applications, data, and customer interactions.
Focus on Meaningfulness: Enterprise Design ensures that every part of the enterprise contributes value and aligns with its purpose, goals, and customer needs.
Systemic Approach: Enterprise Design doesn’t just address isolated issues; it views the enterprise as a connected system where changes in one part affect the whole.

Enterprise Architecture (EA) can benefit from Enterprise Design’s holistic, human-centric and collaborative approach.

Differences Between Enterprise Design and Enterprise Architecture:

While enterprise design focuses on what the enterprise should deliver to meet customer and business needs and how it should engage with its stakeholders, enterprise architecture focuses on how the enterprise organizes its resources and applications to deliver those outcomes. When combined, they provide a powerful framework for creating enterprises that are both innovative and operationally efficient.

Enterprise Design is about designing the enterprise’s value propositions and experiences with a human-centric lens.
Enterprise Architecture is about building the enterprise’s structure and systems to support and operationalize those designs.
Together, they bridge creativity and execution for a well-aligned and effective enterprise

Enterprise Design

The Enterprise Design is a holistic, coherent, and human-centric approach for designing better enterprises. Enterprise Design utilizes the EDGY language to enable collaboration between disciplines, leverages on collaboration and encourages to co-design.

The Enterprise Design approach is based three facets: 1) identity, 2) experience and 3) architecture, together with their intersections: a) organisation, b) brand and c) product. All these facets and their intersections exist in typical enterprises, no matter the size or scope. These facets and intersections form the Facet Model, which can be used for asking questions for designing and reframing all kinds of design challenges. The Facet Model can be used as an analysis tool to shift perspectives and reframe challenges into new ideas – from different angles.

As a holistic, coherent, human-centric and collaborative approach, the Enterprise Design tackles the following problems: isolated design disciplines, diverse methods and separated tools, different terminologies, different visualisation languages, lack of communication over practices and organisation units, different substance- and subject matter experts etc.

The Enterprise Design enables people in enterprises to collaborate, communicate and create shared designs, in all the change activities and business transformations, no matter of the scale or size of those efforts, for making better decisions – for creating better enterprises.

Enterprise Design facilitates the holistic co-design of enterprises through three coherent facets: identity, experience and architecture.

Architecture Examples

Architecture *):

The structures needed to make an enterprise operate and connect to the ecosystem. [3].
Behavior and structure of the operational business.
Architecture can be modelled with the following EDGY elements:
- Capability, Process, Asset, Product and Organisation.
Intersections:
- Organisation refers to organisational structures (e.g. units, groups, teams);
- Product refers to offerings that the enterprise produces and offers for people’s benefit: Products and/or Services.
- Note! The EDGY Product element can be used for modelling both products and services.

Key elements of architecture in enterprise design context are as follows:

Capability: What we are able to do by orchestrating people and assets [3]. Modular business components from which the business operations are made of. The “DNA” of the business. Capabilities consist of Processes and Assets.
Process: A set of related activities our enterprise carries out [3].
Asset: An object we need and use to perform our capabilities [3].

*) Architecture. In this context, not referring primarily to construction- or building ‘architecture’, but operational (business) architecture of an enterprise. The ‘real’ construction architecture of designing buildings is not the main focus area here, but it can be covered with the Enterprise Design approach and the EDGY Facet Model. The real estate, facility properties and assets are parts of the ‘architecture’ facet of the Facet Model. These elements of enterprise can be modelled with the Asset-element of EDGY. The EDGY Facet Model is flexible and expressive enough so that it can be used in all the use cases of when designing an enterprise. The Asset-element of the Architecture facet can be used for modelling any tangible or intangible object or resource or artifact in and around the enterprise, e.g. device, equipment, tool, instrument, switch, component, communication network, construction, building, location, electric system, lightning, heating-, plumbing- and air-conditioning (HPAC) systems, drains, software, hardware, applications, data etc.

Business Operations

Business operations *) (often referred simply as “operations”) refer to the day-to-day activities that an organisation undertakes to produce and deliver its products or services, manage resources, and meet its goals. These operations are the core functions that keep a business running.

Operational business, on the other hand, encompasses the entire range of activities within a business, both strategic and operational. The operational business is run by the business operations that are defined by operational business architecture, simply just architecture **).

Examples of business operations are as follows: production and manufacturing, sales and marketing, procurement, customer service, finance and accounting, human resources (HR), information technology (IT), legal and compliance, facilities and asset management. Each business operation includes the people, processes and assets (e.g. equipment, applications) required to produce them.

Business operations is also referred to simply as a “business in operation” or “business in motion”. It is a healthy business of a healthy organisation, that runs its business operations to deliver products and services to its customers on its promises.

Operational business consists of business operations, each of which require certain business capabilities to execute those operations effectively and achieve the business goals. Operational business is the holistic view of an enterprise. That can be covered and designed with the Enterprise Design approach. Conceptual model shown below.

**Figure**: Operational business hierarchy.

*) Business Operations; Operational Business; Operations and Delivery; shortly: Operations.

**) Architecture. Not referring to construction- or building architecture, but operational (business) architecture of an enterprise.

Operational Business Concepts

The following chapters introduce the main operational business concepts, with which an enterprise operates: Capabilities, Processes and Assets.

Business Components, the business capabilities, the modular units of operational business. Capabilities compose elements that belong together, such as people (roles, competences), processes, data, applications.

A capability refers to a specific ability of an enterprise to perform or achieve something, a combination of people skills and competences, processes, and assets. It represents a composition of elements that are needed altogether to perform certain behavior. A capability is a modular business component, that combines all the elements that have high cohesion with each other, but low-coupling with other elements (of other capabilities).

A business process *) is a series of related activities that are performed in a specific sequence to achieve a particular business outcome. Typically a process is triggered by certain business events or inputs (such as information). Then process handles the inputs in the flow of steps (activities) to produce outputs.

Business processes are fundamental to how an enterprise operates and are often documented, analysed, and optimised to improve performance and achieve strategic goals. Processes belong to certain capabilities.

*) There can be e.g. a) high-level processes with wider scope such as order-to-cash that span over several business units (or functions), or b) processes that perform specific task(s) to produce a certain output such as a service as part of an end-to-end customer journey.

An asset is a resource that the enterprise owns or controls and that have economic value. Assets typically belong to certain capabilities. Assets are used in the operation of the business to create value, provide goods or services, or support the overall goals of the organisation.

**Figure**: Operating model defines the operations.

Capability

A capability defines ‘what we are able to do by orchestrating people and assets’ [3]. As such, capabilities are organisational business components. They are containers for everything that belongs together and that is needed so that the enterprise is able to perform a certain behavioral part of its business.

A capability refers to the ability of an enterprise to perform a specific behavior or achieve a particular outcome through a combination of people, processes, technology, and assets / resources. It represents what a business can do, independent of how it does it, and serves as a building block for understanding, designing, and managing the enterprise.

Capabilities encapsulate the people, activities, and objects required to produce a certain outcome (or output). The figure below illustrates how activities and objects represent abstract behavior and structure, which are concretized in processes and assets.

People perform activities using and creating objects.
Activities are behavioral and objects are structural elements.
People perform processes and use or create assets.

**Figure**: Abstractions of capability content.

Capabilities are components with which an enterprise runs its business operations. Capabilities define what a business can do, not solely what people can do *). Capabilities consist of people, activities and objects that belong together: people, processes and assets (resources such as applications, data, devices, facilities etc.).

*) A quite typical false assumption is to think that capabilities are people’s skills and competencies only. But those are included in the capabilities.

Capabilities are typically business-focused and outcome-oriented: they represent what the enterprise does, not how it does it.

Capabilities are business- and outcome-oriented focusing on what the enterprise does.

Capabilities have well-defined outcomes or outputs, which are concrete and operational by their nature. These outcomes or outputs are associated with the business purposes and business values. In other words, an outcome or an output is the reason why a capability is needed. An outcome or output explains why a capability exists. The purpose of a capability is determined by the outcome(s) it produces. A capability can produce one or many outcomes or outputs. And, capabilities can be identified by the outcomes and/or outputs the enterprise produces with its business operations.

**Figure**: Capability consists of people and behavioral and structural elements.

Examples of outcomes and outputs: an outcome can be, for example, a payment that a customer receives from the Payment capability, while an output can be an application produced by the Development capability.

Capability contains all that belongs together.

Capabilities define the operational business. Not people, not processes, not applications or other resources solely, but them all together, composed into logically coherent groups: to capabilities. The operational business consists of capabilities. Capabilities are components of operational business.

Capabilities have well-defined outcomes or outputs.

Key elements of a capability:

Behavioral: Describes a specific behavior that an enterprise provides, such as “payment management” or “product development”. A capability defines what an enterprise can do, not how.
Outcome-oriented: Defined by the outcome (or output) they produce
Stable over time: Capabilities tend to remain stable while business processes, roles, or technologies may change. For example, an enterprise’s capability to handle “financial management” is a constant need, even if the processes or systems evolve.

**Figure**: Capability modelling pattern.

With the People -element, it is possible to define skills and competencies, and professional profiles, roles, that are needed for performing the activities (with processes). Example below.

**Figure**: Capability example: Sales -capability with roles of competence profiles.

See the templates Capability Canvas and Capability View (link). Load free PowerPoint canvases for EDGY from here: link.

Capability Canvas contains the internal elements of the Architecture Facet, and also intersection elements product(s) and organisation structures (+ relevant people elements representing roles, skills or competences).
Capability View -diagram can be used for illustrating also the external elements (such as goals, costs and risks).

It is practical to open the content of a capability to understand what its purpose is. The content explains the meaning, as activities represent what is going on, and objects represent what assets are used in the performance.

When analysing and defining the content of a capability, it is practical to consider, not only the internal people, processes and assets, but also the concerned organisation structures and products and/or services.

**Figure**: Capability extended content.

Capability can be decomposed into the different levels. It takes as many levels as it takes to find the atomic capabilities. Typically one to three (1-3) levels are enough – to keep the overall business structure simple.

**Figure**: Capability levels. The capability area, “HR”, represents the level 1 capability.

Capability as concept. A capability can refer to a group of elements that are belonging together. As such a capability element can be re-used for modelling any elements that compose a logical group. Examples are as follows: domain (e.g. business domain, business area), function (e.g. business function).

Capability and Function. When modeling the enterprise, the capability concept can be used to represent a business function, which typically means certain behavioral part of an organisation.

A function *) refers to specific tasks or areas of responsibility. It represents a specific area of responsibility or activity within the enterprise that contributes to its overall operations. Often represents a particular department or an area of the business (e.g. Finance, HR), which can contain certain service areas (each of which composed of atomic services).

*) Core functions are the specific, mission-critical activities of a business, while capabilities are the underlying resources, skills, and competencies that empower the business to execute those core functions effectively. The relationship between the two is crucial for a business’s success, as capabilities enable the execution of core functions in alignment with the overall business strategy, adaptability, and competitive advantage.

Capabilities and business functions are quite similar concepts. It is common mistake to confuse capability and business function. Quite often a certain business unit is responsible of a business function. As such there is an association between an organisational structure and a business function. In addition, a business function is closely related to a process, as they both represent the behavioral aspects of a business. In contrast, a capability is also behavioral concept, but it consists of all the other necessary aspects too, elements such as people, data, applications, devices, facilities that belong together. All in all, it is a matter of opinion whether to use the concepts of capability or business function when arranging the business into behavioral parts. Which one to use depends on the case and what is appropriate to fit the purpose in organisation’s terminology.

Note! People skills and competencies are part of capabilities.

An organisation realises and delivers its offerings through its capabilities.

**Figure**: The wireframe model of the business.

An organisation realises and delivers its offerings through its capabilities.

Why Capabilities Matter:

Strategic Alignment: Capabilities help align strategic goals with operations by clearly defining what the business needs to be able to do to achieve its objectives. This enables managers and leaders to focus on building or improving the capabilities that matter most to success.
Agility and Adaptability: By focusing on capabilities, enterprises can adapt more quickly to changes in the customer needs, market or competition. A capability-driven “capability-first” approach enables more flexibility in how things get done.
Prioritisation of Investments: Capabilities provide a framework for decision-making when it comes to resource allocation. Enterprises can prioritise investments in the most critical capabilities, ensuring that spending aligns with long-term strategic goals.
Clarity and Communication: Capabilities offer a common language for business managers, leaders, business people, and IT professionals to discuss what the enterprise needs to achieve. This makes it easier to communicate across different units, groups, teams and functions and avoid siloed working.
Gap Analysis and Transformation: Capabilities are often used in gap analysis to identify areas where the enterprise’s current capabilities fall short of what’s needed to meet future goals of enterprise’s vision. This can inform transformation efforts and initiatives helping to improve or create new capabilities.

How to identify business capabilities?

Define capability: First, define what we mean by business capability. What a capability means in context, in our business and organisational language. If not clear and not specified yet, take and use the Enterprise Design definition: a capability is ‘what we are able to do by orchestrating people and assets’. Capability is an organisational ability to do something and produce clear outcome(s) or well-defined output(s).
Identify business outcomes or outputs the enterprise produces. These are good candidates for capabilities. These can be found by analysing the operational value streams (or core processes) of the enterprise.
Scan business processes (such as process map) and find related processes that can be grouped logically. Processes that are closely related and tightly coupled may belong to the same capability.
Scan service or product offerings (such as service- or product map)) and find logical groups that are realised with specific processes.

Create a capability map, iterate it with business management and business owners at different levels of the enterprise. Identify capability owners and make the capability map a key tool for all change activities in the enterprise – from strategic to operational level.

Summary of Business Capabilities

As a business capability is an important concept and a key element in structuring a business, here are the most essential points.

A business capability is an abstraction, not a concrete entity. It represents what a business does or can do to achieve its objectives. Capabilities are high-level constructs that describe the business’s ability to deliver value without tying them directly to specific people, processes, or systems.

Understanding that a business capability is an abstraction allows enterprises to focus on aligning their resources and operations (concrete entities) to strengthen and optimize these capabilities, enabling better strategic outcomes.

Example Capability:

A capability like “Customer Relationship Management” (CRM) is an abstract concept. It encompasses:
– People (sales and customer service teams)
– Processes (customer onboarding, complaint resolution)
– Applications (CRM software)
– Data (customer information, interaction history)
– Devices and Facilities (customer service desks, communication devices)

Purpose of a business capability is to produce a business outcome.

The purpose of a business capability is to drive business outcomes and outputs. This recognition ensures that capabilities are not just theoretical constructs but actionable drivers of value and success. It ties the abstract concept of capabilities to tangible results, making them central to effective enterprise architecture and strategic execution.

Recognizing that the purpose of a business capability is to produce a business outcome and/or output is extremely important. This understanding serves as the foundation for aligning organizational efforts with strategic goals, ensuring that the enterprise focuses on delivering value. Here’s why this recognition is crucial:

Practical Implications:

Capabilities without outcomes are inefficient: If a capability exists without a clear purpose, it adds little to no value to the enterprise.
Business outcome-driven capability design: Design and evolve capabilities to achieve specific, measurable business goals.
Strategic discussions: Focus on how capabilities contribute to the bottom line, such as growth, efficiency, innovation, or risk management.

Capability Elements

A capability consists of people, process and asset elements. Assets can have many specialisations, as the EDGY Asset element can represent tangible or intagible elements.

“Enterprises need to develop, buy and manage a broad range of tangible or intangible assets (such as buildings, machines, raw materials, software applications, financial assets and know-how) to perform the capabilities needed to run their business. Assets as a concept are rooted in economics, strategic management and finance.” [2]

**Figure**: Simplified anatomy of a capability.

Examples of elements composed in a capability shown below.

**Figure**: Example of capability elements.

Capability View

Example Claims capability diagram that consists of competence roles, processes, application assets and data assets. Claims capability is performed by the Claims processing team. Claims capability provides Claims Handling Service.

capability view — **Figure**: Claims Handling Capability.

Capability Assessment

Operational ability, readiness to do something, according to what has been promised to be delivered.

Capabilities are:

The center of gravity of architecture
Connecting all the other elements of architecture that belong together
Capabilities are modules/components of the business, business components
Capabilities include people with the right skills with assets to perform processes
Capabilities are what an organisation is able to do by orchestrating people and assets

High Cohesion and Loose Coupling of Capabilities

When identifying the capabilities of an enterprise in the capability assessment, a good practice is to define the borders of capabilities based on high cohesion internally and loose coupling externally of the elements (such as processes and assets).

Capabilities have high cohesion internally and loose coupling externally.

A capability contains all that belong together, which means that all the elements that have tight interactions are closely related, so it is reasonable to keep them together. This high internal cohesion of elements justifies why certain elements belong together. Altogether they form a coherent whole, that represent certain operational entity. Such an entity includes all the activities and objects in the form of people, processes and assets, that are required so that certain behavior can be done. Capabilities are what is needed in an enterprise so that it can operate. Capabilities are fundamental building blocks of the business. They are composite business components, from which the business is made of.

Business Agility. Real business agility can be achieved by having adaptable business components. Business agility is the ability to adapt to changing conditions in the business environment. Capabilities are the core building blocks of business.

Composable Business. (Analogous to previous business agility.) Capabilities are basic units of concept composable business, which refers to businesses that can adapt to changing conditions by utilising clearly defined functional business components. These components provide certain services and/or outputs. They have clear boundaries, as they are autonomous and largely self-contained. Capabilities meet those demands.

Capabilities are fundamental building blocks of the business.

See the template Capability Assessment. A capability can be analysed not only based on its content, but also other attributes such as purpose, goals, costs and risks, as well as customer related aspects such as customer needs and benefits.

Capability Attributes and Properties

A capability is composition of elements that belong together: all what is needed so that an enterprise can perform certain capability. As such, a capability consists of people with skills and competences, processes and assets such as applications and data.

Capability-Based planning extends the core content of a capability to other aspects such as ownership- and financial aspects. This enables us to connect all the relevant elements around a capability to make visible all what affects or is affected by a capability. A capability can be connected with aspects such as ownership, costs, risks, goals etc. as shown in the figure below.

capability attributes — **Figure**: Extended Capability with related elements.

Capability Decomposition

Capability map introduces all the capabilities of an enterprise in different levels, typically in 1 to 3 levels. Decomposition of capabilities is breaking down a high-level capability into smaller, more specific sub-capabilities. This helps businesses better understand and manage the individual components (elements) that contribute to overall business success. By decomposing capabilities, an enterprise can more effectively allocate resources, improve processes, and drive targeted improvements according to strategic goals and more operational change activities. The figure below introduces high-level Claims capability that consists of several detail level capabilities.

**Figure**: Claims Handling capability split into lower-level capabilities.

Capability Map

A business capability map is a visual representation of the enterprise’s key capabilities. It usually categorises capabilities into groups (such as operational, strategic, or customer-facing). This map can be used for assessing the enterprise’s readiness for strategic changes, identifying improvement areas, and guiding resource allocation etc.

A capability map is the master structure of an organisation, as it contains all the major abilities from which the business is made. A capability map is a one-page illustration of what an enterprise does.

An example structure of a capability map can be e.g. as shown below. A capability map can be divided into groups that highlight the purpose of capabilities. A good practice is to divide capabilities into groups that make it easy to interpret the relevance of capabilities based on their behavior.

Another example structure.

Example capability map shown below.

Capability Map as Heat Map

Capability map can be enriched with extra information by tagging. Tags and metrics can be used for e.g. risk management purposes, which adds risk statuses on each capability.

**Figure**: HeatMap of a Capability Map.

Capability levels

A capability map can contain a few levels of capabilities, e.g. 1) high-level business areas and then 2) atomic capabilities underneath. A good practice is to group the capability map into a) customer-facing capabilities, b) core business capabilities, c) supporting capabilities, and d) change capabilities (which enable the management and transformation of other capabilities and the entire business).

It is suggested to identify capabilities of few levels, e.g. three (3) levels.

Capability levels can be e.g. as follows:

Level-0: high-level capability areas / groups (e.g. Customer Interaction, Operations, Support and Change)
Level-1: Business relevant capability groups and other enablers (e.g. Finance, HR)
Level-2: Base capabilities (mostly specific, atomic capabilities, e.g. Invoicing, Dept Collection)
Level-3: Sub-capabilities

Note that a capability can be decomposed into more specialised capabilities as shown below.

**Figure**: Capabilities may have sub-capabilities at a detailed level.

Composable Business Architecture

Capabilities are the building blocks of the composable business architecture of the enterprise. This makes the capability first approach a guiding design and development principle.

Enterprise’s business architecture consists of business capabilities, that represent the modular business components from which the business of an enterprise is made of. These capabilities, the business components, enable the composable business.

Each capability represents a logical unit that is meaningful for operational business of the enterprise. As such, a capability has a purpose that rationalizes its reason for being – right to exists – based on pure business criteria: operational business requires certain capabilities to function according to which is defined in the identity of the enterprise.

A composable business architecture consists of capabilities, each of which performs specific behavior that is crucial for operational business. Capabilities are organisational abilities to execute necessary activities of the operational business. Capabilities represent both a) the operational and b) the supporting business components (building blocks). They represent the organisational outcomes that are required by the operational business of the enterprise.

Capabilities are the building blocks of the composable business architecture.

Capabilities are the high-level business components that encapsulate their internals from strategic level. This enables enterprise to adjust its performance according to changing conditions. In other words, capabilities make the business composable and adaptive for new and changing requirements and possibilities. Capabilities represent what is needed for the business while hiding the details of how this behavior is performed, by who and by which resources.

**Figure**: Capability – composable business component.

A capability is a center of gravity that magnetises things that belong together. A capability exposes its behavior by products and/or services. A capability can be connected with certain organisation structures. Capabilities are required for producing the offerings (products or services) of the organisation.

**Figure**: A capability is required for the delivery of an organisation’s offerings.

Capabilities provide coarse grained granularity of components that can be used as composable building blocks of the operational business of the enterprise.

A capability is a center of gravity that magnetises things that belong together.

Process

A process is a set of related activities our enterprise carries out [3]. Processes are modeled with the EDGY Process element.

A process is a series of related activities that are performed in a specific sequence to achieve a particular business outcome.

Processes are designed to convert inputs into outputs in a way that adds value to the enterprise and its customers: a) business value and b) customer value. Processes can span across different units or departments and involve various stakeholders.

**Figure**: Process is flow of activities.

Process Flow

An example of a process flow, sequential steps of activities.

**Figure**: Claims process simplification.

Decision Points of processes (branching) can be modelled with the EDGY Activity element, to make distinction to actual process steps.

**Figure**: Decision point modelled with the EDGY *Activity* element.

The flow of a process can be modelled with ‘swimline-like’ diagram, in which the actors of the process steps are shown as horizontal swimlines. The actors are the organisation structures, each of which performs certain steps of the overall process. Customer actions can be illustrated when appropriate.

**Figure**: The process flow with organisation structures as ‘swimlines’ / actors.

SIPOC (Suppliers, Inputs, Process, Outputs, Customers)

Six Sigma tool called SIPOC (Suppliers, Inputs, Process, Outputs, Customers) can be used for defining elements common to all processes. This is an easy tool for analyzing the business case: what is the value the customer gets and how. EDGY object element is used for modelling inputs and outputs.

Which elements to use, depends on the specific case and what is appropriate to fit the purpose. The SIPOC pattern shown below.

SIPOC consists of basic elements as shown in the figure below.

SIPOC elements can be specialized as shown below.

**Figure**: Specialised elements of the SIPOC.

All the SIPOC elements can be modelled with the asset element only for the sake of simplicity as shown below.

Asset

An object we need and use to perform our capabilities [3]. Assets are modeled with the EDGY Asset element.

Assets are resources that the enterprise owns or controls and that have economic value. These assets are used in the operation of the business to create value, provide goods or services, or support the overall goals of the organization. Enterprise assets are anything of value that the enterprise can leverage to achieve its business goals.

Assets can be classified into several categories as shown below.

**Figure**: Asset categories and some examples.

Examples of assets below.

Architecture Modeling Extensions: Tags and Metrics

Tags and/or metrics are associated with any EDGY elements such as Asset elements. There can be cases where an asset element can be associated with several tags and/or metrics, which can be positioned one below the other (figure below).

**Figure**: Several tags and/or metrics can be attached to an asset element.

Tag. Different types of elements can be distinguished with the tag element. This can be necessary when it is important to precisely express the characteristics of elements. The use of tags makes the diagrams easier to interpret as the types of assets are made visible with declarative text, instead of special symbols that require extra knowledge.

There is a common set of asset types concerning application architecture. The minimum viable set, the short list, consists of the most typical asset types: 1) application, 2) system software and 3) data.

It suggested defining organisation context-specific asset types as tags, according to what is appropriate and fit the purpose, and then providing those tags within re-usable legend elements as shown below. This encourages to consistent modelling style.

A good practice is to avoid too many tags and metrics per element. It is preferred to use different views to focus on certain aspects such as business criticality or risk classification. Different versions of the diagram can be created for different purposes. The context typically explains the types. For example, an application architecture diagram titled “application architecture” implicitly implies that the asset elements are applications. Another good practice is to use ‘grouping’ of elements in the visualization tool (such as Draw.io or PowerPoint), so that the labels move together with the core element when it is moved in that diagram.

In addition, there can be number of other asset types as shown below.

**Figure**: More examples of asset types.

IT environments can be identified as follows:

Development environment for configuration, customisation, and usage of source control to build an image of the target application to be promoted to another environment.
Test environment for testing upgrade procedure against controlled data and performing controlled testing of the resulting target application.
QA (Quality Assurance) environment for testing upgrade procedure against data, hardware, and software that closely simulate the Production environment and where the intended users can test the target application.
Production environment for the actual business use.

Assets and tags simplify the architecture for both modelers and users. The diagrams are easy to create and easy to understand:

there is only a single element, the asset, for depicting any kind of asset,
tags can be used for adding explanatory information to assets when appropriate.

Color-coding can be used for additional information, extra semantic, e.g. element borders can be colored as shown above. In addition, also the backgrounds of the elements can be colored (if the context of the diagram explains the types of the elements).

Metrics can be used for adding extra qualitative or quantitative definitions, or any kind of classifications such as risk assessment, priorities, criticalities etc.

**Figure**: Examples of metrics associated with elements.

**Figure**: Process flow with tags & metrics.

Target Operating Model

The target operating model describes how the strategy and business model will be realised.

The modern business environment is more complex than ever before, with more challenging customer needs etc. This view is a tool that helps communicating which customer segments / -groups are served with which services, via which channels, etc. – according to strategic goals.

A simplification of the target (to-be) operating model at high-level is illustrated on the figure below.

Enterprise Map – the Milky Way Map (MWM)

A Milky Way Map is a visual representation of the whole business or some part of it. A Milky Way Map is a visualisation of the geography of the business of the enterprise. It shows what are the customer activities or tasks to be done, and how the enterprise serves those tasks, and why the enterprise is doing all this. The Milky Way Map is the map of the enterprise – the enterprise map.

**Figure**: Milky Way Map is a tool for analysing the why, how and what.

The Milky Way Map is analogous to the Golden Circle by Simon Sinek introduced in the book Start with Why. In his well-known TED talk *) Sinek explains the concept of the Golden Circle:

“Most organisations know WHAT they do,
some organisations know HOW they do it,
but only a few organisations know WHY they do what they do”.

According to Sinek, this latter group, which prioritizes understanding and communicating their purpose – why they do what they do – is often the most successful. He uses Apple as an example. By WHY, Sinek refers to an organization’s purpose, cause, and beliefs, its reason for existing. The clearest part is the what, while the why is often the most abstract. Sinek argues that inspired organizations think, act, and communicate from the inside out, starting from their why.

*) Simon Sinek’s TED talk Start With Why: https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=en

What = products provided and/or services offered, or the role in people’s lives
How = operational activities such as processes, and resources such as employees and applications
Why = purpose, cause, beliefs, values, principles etc. The ‘core’ that explains everything else.

There is an analogy between the Milky Way Map and the real Milky Way galaxy, in which the center of gravity keeps the objects in surrounding circles where they are going around.

The Milky Way Map is divided into sectors, that represent the value stages of the business value flow (a.k.a. value stream).

The customer journey steps (or tasks) are shown on the outer circle. The capabilities are positioned in the middle circle, and the purposes, the goals for each value stage are shown in the inner circle. The business value flow can consist of sectors such as Plan, Build, Market, Deliver, and Learn. The Milky Way base Map is shown below.

The Milky Way Map covers dimensions of the enterprise design as follows:

Y-axis: Strategic aspects on the bottom left corner, operational aspects on the top left corner
X-axis: Sourcing and marketing aspects on the bottom left corner, delivery and learning aspects on the bottom right corner.

The base map version above is just showing the basic idea of the Milky Way Map. There can be variations of the Milky Way Map depending on the case and what is appropriate to fit the purpose. For example, value flow stages (sectors) can be defined according to the business, which can be anything from the whole enterprise to some specific business area. Circles and their elements can be used according to what is necessary, e.g. tasks, journeys or channels, capabilities or processes etc. The Milky Way Map can be configured to fit for the purpose. With the Milky Way Map it is possible to contextualise the capabilities from the enterprise’s capability map by positioning them into the value flow. This visualizes which capabilities are performed and when, which capabilities are closer to the customer, and which are supporting those customer-facing ones. The purposes in the center of the Milky Way Map, represent the goals for each value flow stage, showing why the enterprise is doing and what it is pursuing. The journey steps or tasks on the outer circle represent the customer journey, and also the tasks of the other stakeholder groups (such as partners, owners, job candidates etc.) that have some interest in the business of the enterprise.

The Brand element can be added to the top of the map to explain what the focus area of the map is. For example, we can differentiate B2C and B2B customers and provide a map based on the customer segment. Then we may highlight or hide certain things (such as capabilities) from the map, or we can color-code certain tasks (e.g. showing the top tasks in yellow). Journey steps can be connected by arrows as shown below.

For more information about the Milky Way Map see the following sources:

Annika Klyver’s blog (the master source): https://annikaklyver.wordpress.com/
Eero Hosiaisluoma’s blog: https://hosiaisluoma.fi/design/milky-way-map-with-edgy/

Several excellent webinars by Annika Klyver and Milan Guenteher, e.g.:

Bridge the gaps with Milky Way enterprise maps, recording, Intersection Group, 2022: https://intersection.group/events/milky-way-enterprise–maps3

Information Modelling: Business Objects and Data Assets

The EDGY Object elements can be used for modelling information structures such as business objects (a.k.a. Information Objects), those of which represent the information concepts that are relevant and meaningful for the business. These business objects can be modelled as assets when appropriate. High-level information modelling can be done with the Object element, Link- and Flow-relationships.

**Figure**: High-level data modelling elements.

Object-element can be used for modelling relationships between concepts.

**Figure**: Relationships between concepts.

Object-element can be used for modelling hierarchies or specialisations of elements of the same type.

**Figure**: Specialisations of concepts.

High-level concept modelling example shown below.

High-level data modelling with the object elements can be used e.g. for diagrams such as conceptual data model or Entity Relationship Model (ERM). An example high-level conceptual data models shown below.

Another example of conceptual data model shown below.

Information Elements

Information can be modelled in two levels: 1) Conceptual level and 2) Operational level. The former objects are Business Objects that represent business relevant information concepts, such as customer, order or invoice. They are meaningful for business operations at conceptual and high level. The latter objects are Data Objects that represent operational data elements that are switched between the applications.

EDGY provides distinct elements for modelling high level business concepts and operational level data objects. Business Objects can be modelled with the EDGY Object-element, and Data Objects can be modelled with the EDGY Asset-element (figure). In the architectural diagrams that represent the concrete business operations, the Asset-element is used to represent data element as data object.

Data Elements

Data elements (a.k.a. data objects) can be modelled with the EDGY Asset element with the tag element that indicates what is type of the asset, in case the diagram contains assets of different types (such as applications and data).

**Figure**: Data Object modelled with the Asset -element.

Data elements are entities used in architecture can be depicted as data assets, modelled with the EDGY Asset-elements. These are the data elements that are transferred between processes and/or applications. Note! Tag element is not necessary to indicate the type of asset, as the diagram is titled “Data Model”.

**Figure**: Data model – assets as data elements -objects.

Tagged elements. The types of the Asset -elements can be differentiated from each other with that tag, that is positioned on the bottom of the element. An Asset -element can represent e.g. data, application, or any other asset such as facility, device or technology. (Tag element can be attached to the Asset -element by ‘grouping’ functionality that is available in many tools such as Draw.io or MS PowerPoint.) A tag can be e.g. as follows: ‘Data’, ‘Application’, ‘Software’ / ‘Technology’, ‘Device’, ‘Facility’. In addition, tags can be used to indicate any type -information that defines the characteristics of an element.

Information Flow Diagram

The data flows can exist e.g. between processes, organisations or applications. Data objects are transferred in these data flows, as these flows are operational: they represent the actual business-relevant information flows between the entities.

Data objects / -elements are introduced as texts (labels) on flow relations as shown in the figures below.

**Figure**: Information flows between processes.

**Figure**: Information flows between organisations.

**Figure**: Data flows between applications.

Process Cooperation View

Information flows between processes define how an enterprise operates. As such this view represents the operating model of an enterprise. This view illustrates what is happening in and around an enterprise.

Application Cooperation View

Application cooperation view a.k.a. application interaction view can be used for depicting how business data is transferred between the applications.

Application Integration

Integrations. This high-level application cooperation view can be used as the first (if not the only) diagram for exploring the integrations between the applications. This diagram introduces what business-relevant data is switched, and what is the direction of those transfers. However, this view doesn’t specify how the transfers are executed, and via which interfaces. These can be further analysed based on this high-level overview diagram. So this high-level overview represents the business architecture (and enterprise architecture) level of details. respectively, more detailed solution architecture level diagrams can be created for development purposes (e.g. for agile development teams).

**Figure**: Application cooperation view – as a map like a ‘metro map’ / route map.

Both internal and external integrations can be shown when appropriate (e.g. external parties are shown in the figure above, a Logistic company and a Bank).

Overall information flow of the operational business of an enterprise can be illustrated with combining processes and assets that are interacting with flow relationships.

**Figure**: Data flows between the processes and applications in a B2B scenario.

High-level information flows between the business actors / organisations shown below.

**Figure**: Information flows between the business actors.

Application Map

Applications of an enterprise are typically managed within a Configuration Management Database (CMDB) that can be used as a master data source of application portfolio. In addition, application catalog can be maintained in other tools (such as EA tool, Confluence based content management system etc.). The main idea is to have an overall view of the applications with attributes, such as business owner, supplier, functionalities, criticality, life-cycle status etc.

Application portfolio can be visualised as shown below.

Application Architecture

Application architecture describes the logical structure of an application. Application architecture introduces both the external and internal aspects as follows:

Externals: who are the users and what information is switched with other applications?
Internals: what is the internal structure, and what are the integral parts (components, modules, subsystems) that the application is composed of?

Note! An application (a.k.a. system) refers to a component of the overall business architecture of the enterprise, or enterprise level architecture = Enterprise Architecture (EA).

Application architecture can be modelled with only a few elements of EDGY:

Asset element and
relationships Link and Flow.

**Figure**: Elements of application architecture.

This simplicity of the EDGY makes it productive, as the modellers can concentrate on the problem instead of notation. However, the EDGY is expressive enough, and it is easy to do and easy to use. Everyone can easily understand EDGY diagrams.

The asset element is a multipurpose element, which can be used for modelling any kind of structural asset of an enterprise, e.g.:

intangible assets such as applications, software and data as well as things such as competence, know-how, financial assets and -instruments etc.
tangible, physical assets such as hardware, devices, facilities, equipment, (raw) materials, tools, machines, vehicles, instruments, network components, buildings etc.

The EDGY elements can be added with labels that express additional information. Labels enrich the usage of elements by providing extra information or any kind of characteristics that are meaningful in the context. There are two kinds of labels: 1) tags and 2) metrics.

**Figure**: Tags and Metrics used as labels of the elements.

Application architecture patterns introduced below illustrate the usage of these architectural elements.

Relationships between architectural elements are typically either 1) structural or 2) dynamic by their nature. The link defines a structural association between two elements, and the flow defines dynamic, directional influence or data flow between two elements.

**Figure**: Structural and dynamic relationships: link and flow.

The structural relationship between the elements can be modelled explicitly with the 1) link relationship or 2) by nesting the elements as shown below.

Structural relationship with explicit link relationship can introduce the characteristics of the association (e.g. “Is part of”).

Dynamic relationship typically introduces the data object that is switched between the elements.

Application Architecture Patterns

Application architecture patterns introduced below illustrate the usage of these architectural elements.

Three-tier architecture. A classic example of introducing the application’s internal structure is the traditional three-tier architecture, which consists of the following tiers:

presentation tier (a.k.a. user interface tier),
business logic tier, and
data tier.

These tiers altogether represent the separation of concerns, the functional decomposition of an application into structural parts. Each tier has its specific responsibility, and the whole application is composed of these individual tiers and their functionalities. As these tiers are the structural parts of the application, they are included in the application by nesting.

**Figure**: Full stack example with typed assets.

Layered Architecture is analogous to three-tiered architecture. The same basic structure is now defined with other names of the parts, e.g. tiers are called layers.

Technologies. Assets can be used for representing e.g. application or technology a.k.a. system software as shown in the figure. When an application includes system software elements, then tags can express their type (such as Front-end, Back-end, User interface, Business logic etc.).

Note! Technologies, in the form of system software, are assets that are kept in control in the enterprise level, e.g. utilising a Configuration Management DataBase (CMDB). It is important to manage the technology portfolio as part of the enterprise architecture.

Model-View-Controller (MVC) pattern is compatible with the three-tiered and layered architectures. The MVC divides the application into functional components, each of which has a specific role and is responsible for certain functionalities: presentation, business logic and data access.

**Figure**: Model-View-Controller (MVC) pattern.

Notes:

Additional information can be included in the asset elements – if that can be done without making the diagram too “busy”. Careful consideration must be given to how much information is sufficient, and how much is too much.
Tags are not necessary when the diagram introduces only structural elements (components) of the same type, or the types of the elements are implicitly clear.

Technologies, the system software, are assets of the enterprise.

Data Processing

Input-Process-Output. As architecture defines the structure of an application, then the application consists of structural elements – all of which are modelled with the Asset element. The basic pattern of an application consists of the following elements: a) input data, b) processing unit (hiding the internal behavior as a black box), c) data storage and d) output data. This view introduces the basic concepts. The application is an active structure element, that performs certain behavior for processing the input and producing the output. The data objects (input and output) are passive structure elements.

Extract – Transform – Load (ETL) pattern represents how data is retrieved, processed and then loaded. ETL process consists of the following phases:

extracting is data retrieving/fetching from the source (typically a data source, but can be e.g. cloud service, analytics tool etc.),
transforming is processing (e.g. cleaning, enriching) the input data (source-, raw data) and
loading phase is storing the transformed output data into the target storage (e.g. database, data warehouse, data lake).

**Figure**: Extract-Transform-Load pattern.

The behavior of the application is modelled with the Process element, which represent any activity taken (by some structural element of the enterprise, such as organisation, application, component etc.). An alternative way of modelling the ETL is based on the asset elements only as shown below. The choice between asset and process depends on the context and what is appropriate to fit the purpose.

**Figure**: An ETL application modelled with asset elements instead of process elements.

Architecture Modelling with Nesting

Nesting elements. Elements can be included in other elements. That can be done when there is a hierarchical structural dependency between the elements: an element belongs to another element. Or, there can be a behavioral dependency between the elements: an object performs an activity, e.g. an organisation performs a process.

This modelling style has advantages e.g. as follows:

simplicity; the structural dependency hierarchies are illustrated without (link) relationship elements, and
compact layout; The diagram can be modelled into a more compact form, as space is ‘economically’ saved by including elements with others.

For example, 1) an organisation makes products/services, 2) an organisation has capabilities, 3) an organisation performs processes, 4) an organisation has applications, 5) a capability consists of processes and assets (application- and/or data assets) 6) an application consists of components – all these can be modelled by nesting the elements.

**Figure**: Nesting elements – for the sake of simplicity and compact layout.

Nesting elements of a capability: processes, applications, data and people included in the capability, which is a ‘container’ for things that belong together.

**Figure**: Elements nested in a capability

Architecture Modeling Principles

Principles. The asset elements can be resized based on the content such as text, tags or metrics. However, the size can comprehend the meaning of the importance: a bigger element can be considered more important than the others. The suggestion is: to keep the elements with the same importance at the same size.

Principles:

Model only what is relevant (limit width and depth: scope and level of details).
There are not too many elements in the same diagram (split, use abstraction levels).
Only elements of the same abstraction level into the same diagram.
The elements are of the same size.
Elements aligned.
Connecting lines aligned orthogonally, no crossing lines.
Harmony, symmetry and balance of elements.
Use colors with care: not too much.
Less is more (minimalistic approach: as little as enough, not as much as possible).
Simplicity (KISS = Keep It Simple, Stupid).

**Figure**: Suggested modelling style on the left.

An element is either an internal part of another element or an external element. For example, an organizational structure belongs to another structure, an application component consists of other components (such as a UI, business logic components, or a database), or a capability is made up of certain elements (such as people, processes, and assets).

**Figure**: Nesting elements inside another element depicts hierarchy.

Place elements either inside other elements or outside of them. Use relationships if elements are not nested but positioned beside each other.

**Figure**: Place elements either inside or outside.

Avoid placing one element on the edge of another! Positioning them on the edge, like shown below, creates confusion and lacks logic. This kind of modelling style doesn’t make any sense and should be avoided.

**Figure**: Don’t model elements on the edge.

Component Model (CM 1-2-3)

An enterprise consists of structural parts, all of which are components of the whole. An enterprise can be viewed as a component model consisting of high-level components, the capabilities, each of which includes applications that are composed of modules, and so on. As such, an enterprise is hierarchical system of systems, system of components, that can be considered fractal *) by nature. Fractal due to its hierarchical and recursive structure (not in a strictly mathematical sense).

*) A fractal entity refers to a system, structure, or concept that exhibits self-similarity across different levels or scales. This means that its overall pattern or behavior is mirrored in its smaller subcomponents, regardless of the level of abstraction. A fractal entity is composed of smaller components or subsystems, each reflecting the properties of the whole. Examples: 1) Enterprises / organisations can be seen as fractal entities, with departments and teams reflecting the structure of the whole; 2) Application Architectures are modular and exhibit fractal properties.

The Component Model views the enterprise as a whole comprised of individual components. It is important to understand which components the enterprise consists of and the role each component plays as part of the whole. Capabilities are enterprise level components, each of which consist of components such as applications, data, processes and people.

**Figure**: Component Model of an enterprise.

An enterprise is hierarchical, component-based, and recursive by nature.

**Figure**: Component Model abstraction levels.

Component Model (CM 1-2-3) is an application architecture modelling approach, in which a target application is depicted on different abstraction levels: 1) context-, 2) composition- and 3) component levels.

**Figure**: Component Model abstraction levels hierarchy.

Component Model level 1 (CM-1):

Context of a solution of a Business Architecture of an enterprise. The solution Architecture of an application in context. Typically a single application.
Represents the external contextual aspects of an application: users and interactions with adjacent applications.
The target application is depicted as a black box, its external services, interfaces and interactions are relevant. Its internal structure is not interesting at this abstraction level.

Component Model level 2 (CM-2):

Composition of the target application, the main components of within the system boundary.
Represents the internal behavior and structure of the target application.
The target application is depicted as a white box by illustrating how it is decomposed into main components (a.k.a. sub-systems or modules), what are their responsibilities, and what interfaces are provided and required. Interfaces can be user interfaces (GUIs) or application interfaces (APIs). The internal components are depicted as black boxes at this abstraction level.
The technology choices per component can also be shown, as the composition represents an executable and deployable unit.

Component Model level 3 (CM-3):

Each (main) component can be depicted in detail whenever appropriate as white boxes.
This abstraction level zooms into individual components by showing their internal behavior and structure.
This level of diagram can be useful if the component is complex.

An application consists of components (modules), each of which consists of components (figure beside).

All parts of the enterprise are components of the whole.

The application view consists of levels 1 to 3 as shown in the figure below.

**Figure**: Component Model 1-2-3 abstraction levels of an application architecture.

See Component Model 1-2-3 (CM 1-2-3).

Component Model example diagrams of example target application named “Order Handling System” below.

Component Model level-1 (CM-1)

CM-1 Context diagram example below.

Component Model level-2 (CM-2)

CM-2 composition diagram example below illustrates the internal structure of the application.

Component Model level-3 (CM-3)

CM-3 component diagram example below, showing the internal structure of a component.

Component Model level-0 (CM-0)

Level 0. The Component Model 1-2-3 can be extended to Component Model 0-n when starting from the overall business architecture and focusing on capabilities. Capabilities are the fundamental building blocks (DNA) of the business operations. A capability map is the “base map” of the whole operational business of an enterprise.*)

*) Each component (such as application) of an enterprise belongs to certain capability. As such, when analysing any changes is reasonable to start from the capability map of the enterprise – according to “capability first” principle.

**Figure**: Component Model (0-n) starts from the capability level.

In the case of any change in an enterprise, such as concept design or a change initiative, the most practical approach is to analyse the customer and business needs in relation to the capabilities of the enterprise. Capabilities represent the business behaviors where changes need to be made, as they encompass all the behavioral elements of an enterprise. Once the appropriate capability is identified, the related applications are also determined. Capabilities form the foundation of the business, as they are the main building blocks of business architecture, as shown in the figure above.

Component Model (CM 0-n) can be extended with the capability level, level 0 as follows:

Capability level 0 (business level, Enterprise Architecture, EA)
Context level 1 (application of a capability in business context, Solution Architecture, SA)
Composition level 2 (the content, internal structure of an application)
Component level 3 (the internal structure of a component of an application)

**Figure**: Hierarchy of architecture levels.

Component Model Examples

Component Model example diagrams of target application named “Internet Banking System”.

Component Model Level 1 (CM-1) diagram illustrates interactions between the target application and adjacent applications. All the relevant application interactions are introduced.

**Figure**: CM-1: Application architecture at a high level, the context level.

Component Model level 2 (CM-2) level illustrates how the target application is decomposed into modules (or main components), and which module realizes which application interfaces.

**Figure**: CM-2 Application architecture at a detailed level, the internal structure.

Component Model level 3 (CM-3) level illustrates how the target application’s main modules are composed of sub-components, and how they interact. CM-3 diagram can be modelled for each application component separately, as shown in the diagram below.

**Figure**: Main component of the application.

Note! Component Model is similar to C4-model, which can be modelled with EDGY, see this EDGY and C4 mapping (pdf).

Deployment View

Deployment diagram. Technical infrastructure can be modelled also with EDGY architecture elements (Assets). This view illustrates the deployment environment, in which the business application is running. It is possible to define distinct test-, QA- (Quality Assurance) and production environments.

Deployment diagram example below. A deployment diagram can contain technologies.

Deployment environment with facility and location examples below.

Technology architecture diagram below.

**Figure**: Technology platform diagram.

Technology Architecture

Technology architecture can be visualized with EDGY by using only one element and one or two relation types: with the Asset element and association or flow relations. Additional tags can be used for informing the type of the asset (e.g. application).

**Figure**: EDGY element *Asset* and link (association) relation.

Technology architecture can’t be made any simpler than this! All that is meaningful in a technology architecture can be modelled with the Asset element with labels, and with Association relation. That’s all what is needed for visualisation of technology architecture.

An example of technology architecture is shown below. This deployment diagram visualizes the run-time environment of a business application.

**Figure**: Technology architecture (the deployment environment).

When necessary, also the Flow relation can be used as shown below.

**Figure**: Flow relation between applications.

Application Integration

Application interactions a.k.a. integrations between applications can be modelled with flow -relation. The basic integrations illustrate what business data is transferred in which direction. Certain typical application integration patterns illustrate how applications interact with each other. Examples shown below.

**Figure**: Application integration patterns.

Note! If a bi-directional connection between elements is intended, two relationships should be defined: one from element A to element B and one from B to A. [https://www.enterprise.design/wiki/Relationships]

Extra semantics can be added into flow relationships e.g. by line color or width.

**Figure**: Additional semantics of flow relationships.

Extra semantics can be added to the line, such as protocols, mechanisms, volumes or frequencies.

**Figure**: Additional information of mechanisms.

Value Flow

The value flow is a concept that represents how an enterprise creates value for its customers. The value flow can be divided into phases, activities, each of which create certain value add.

The value flow of an enterprise can be visualised with the EDGY process element. The business value can be visualised with the labels that can be used for adding extra information to elements.

**Figure**: A value flow as an intra-organisational process.

There are a few concepts that are analogous with each other and explain the similar view of an enterprise. The value flow is analogous to what Michael Porter has introduced in his well-known famous book “Competitive Advantage” (1998) about concept of value chain.

**Figure**: Value Chain by Michael Porter.

Value Stream Map. Value Stream concept is a high-level concept that is used typically in the business model level. On the other hand, the operating model is based on actual processes. Customer Journey represents the customer actions. The customer value and business value can be modelled with the EDGY labels (tags and metrics) as shown below.

**Figure**: Customer Value and Business Value can be represented with the labels.

The concepts around the value flow introduced in the table below.

[M. Porter Value Chain link]

Value Stream Types

The value stream is typically process-focused, and looks at the enterprise’s efficiency in delivering value. There can be identified two types of Value Streams: 1) Operational Value Stream and 2) Development Value Stream.

While operational value streams drive the immediate delivery of products and services, development value streams ensure the continuous improvement and evolution of the enterprise’s capabilities and offerings (products and/or services).

**Figure**: Operational Value Stream and Development Value Stream.

Operational value streams are the core business processes that directly deliver products and services to customers. They are focused on day-to-day operations and revenue generation.
Development value streams focus on creating and enhancing the systems, products, and services that enable operational value streams to function effectively. They are based on projects or products (e.g. digital products) and services, working behind the scenes to improve the enterprise’s ability to deliver value.

Operational and development value streams are deeply interconnected. Operational value streams depend on the outcomes of development value streams. Development value streams provide the tools, products, services, and processes that operational value streams need to efficiently deliver value to customers.

The continuous improvement of operational value streams is often driven by the success of development value streams. Development teams, by iterating on their products, services or processes, enable operational teams to perform better, faster, and more efficiently.

Operational Value Stream (Organisation Perspective)

Operational Value Streams (operational processes) represent the organisation view of how an enterprise creates value to customers and/or end users (internal view). An operational value stream is connected with the capabilities of the enterprise.

Development Value Stream (Development Perspective)

A development value stream (also) connects with the capabilities of the enterprise. These capabilities are basically the support- and change capabilities of the enterprise (see the capability map that introduces different types of capabilities: customer-facing-, operational-, supporting- and change capabilities).

**Figure**: Development process (Development Value Stream).

Customer Journey (Customer Perspective)

Customer Journeys represent the customer perspective, the customer view of how a customer experiences the enterprise, and how customer value is created.

**Figure**: Customer Journey represents the customer view.

Customer Journey and Value Stream

The Customer Journey and Value Stream are both tools used in understanding how value is delivered to customers, but they differ in focus and perspective:

the Customer Journey focuses on the external experience of the customer, while
the Value Stream looks at the internal processes that create and deliver that experience.

Both are critical for understanding how value is created and delivered but address different parts of the overall process. The key is to get the whole picture, the holistic overview what is happening in and around the enterprise. That big picture can be taken by analysing both the customer journey and the value stream. This can be done by analysing the customer experience and operational architecture perspectives (facets) of the enterprise.

Customer Journey characteristics:

The customer journey maps the customer’s experience and interaction with an enterprise and its product(s) or service(s).
It focuses on how customers perceive and experience every touchpoint with the business of an enterprise.
The journey is often emotional and subjective, highlighting customer needs, pain points, and how they engage with the business across multiple stages (awareness, consideration, purchase, support, etc.).

Value Stream characteristics:

A value stream maps the internal processes and activities required to deliver a product or service to the customer.
It focuses on the flow of value through the enterprise, from the initial concept or request to final delivery and support.
It is about how the enterprise creates and delivers value, identifying each step of production or service delivery, highlighting inefficiencies, and optimizing workflow.

State Machine

A state machine in software development is a conceptual model used to design systems that can be in a specific state at any given time and transition between states based on defined events or conditions. It is widely used in software engineering to represent and manage complex workflows, behaviors, or processes in a structured way.

Key components of a state machine:

States: The distinct modes or conditions in which the system can exist. E.g. Initial state, Final (End) state.
Transitions: The movement from one state to another triggered by an event or condition.
Events: Inputs or triggers that cause transitions between states.
Actions: Operations performed during a state transition or while in a specific state.

A state machine visualised by using the EDGY Outcome elements representing the states.

Examples:

UI/UX Design: Managing user interfaces that respond to inputs and change states, such as navigation flows or form validations.
Workflow Management: Orchestrating business processes like order fulfillment or ticketing systems.

Example of a state machine for an order management system, illustrating the states an order can go through and the events that trigger transitions between those states.

**Figure**: Order handling state machine.

Types of state machines are e.g. as follows:

Finite State Machine (FSM): A system with a finite number of states and transitions. E.g. a traffic light system with Red, Yellow, and Green states.
Deterministic State Machine: The next state is determined by the current state and the event.
Non-Deterministic State Machine: The next state may depend on additional factors, leading to multiple possible transitions for a given event.

A state machine is a tool in software development for modeling and managing systems with distinct states and transitions. By defining states, events, and transitions, state machines help create clear, predictable, and maintainable workflows for various applications.

State machines help create clear and maintainable workflows for various applications.

Enterprise Risk Management

Enterprise Risk Management (ERM) is an enterprise-level approach to managing risks by identifying them and preparing against them. Risks should be taken into account not only at the enterprise level but also in each and every change activity. Risk management aims to prevent risks proactively. Risk categories are as shown in the figure below.

More specific risk categories can be specified based on the problem domain such as: human capital risks, legal/regulatory risks, technological risks and natural disaster risks. Risk management covers coordinated activities to direct and control an organisation. These are covered by ISO31000 standards. Risks can be modelled with the EDGY by relating risks to elements (such as assets).

A risk occurs when a threat meets vulnerability.

Risk management concepts are introduced in the table below.

Risk Assessment illustrated below. (Process flow with the EDGY Activity elements.)

[Source: Open Group, White Paper W172, 2017.]

See the templates: Risk assessment and Risk Identification & Assessment (link).

Capability-based Risk Management. Enterprise Risk Management can utilize capabilities as main components, as they consist of all the other elements of the enterprise. Capabilities or capability areas can be used as risk ‘domains’.

Risks can be set to capabilities at a high level (as shown in the heat map above), or risks can be directed to the particular elements of the enterprise such as resources/assets. Potential targets of risks are elements of the enterprise, such as products and/or services, organisation units/groups/teams, employees (skills & competencies + career-related matters), processes, applications, data, technology, devices, facilities etc.

Risk modelling can be done by using EDGY elements and metrics as illustrated below.

**Figure**: Assets with risks as metrics.

Another capability risk modelling example below.

Alternatively, risks can be explicitly modelled as outcomes and connected to elements as shown below.

**Figure**: Risks connected to assets of a capability.

Risk management aims to prevent risks proactively.

Enterprise Design as a Holistic, Human-centric, and Collaborative approach

Enterprise Design facilitates a holistic, human-centric, and collaborative approach by aligning business strategy, customer needs, and operations, enabling enterprises to create meaningful, efficient, and sustainable products and services for people’s benefit. At a practical level, when people from different disciplines work together, Enterprise Design provides the Facet Model as an analytical tool to assist discussions, and EDGY language to facilitate communication.

**Figure**: “Holistic Triad” of enterprise design.

Holistic Thinking considers the enterprise as a connected ecosystem where all elements, processes, people, technology, and environment, work together seamlessly. Thinking holistically ensures that business design, business architecture, and service design work in tandem to create an enterprise that is aligned, efficient, and responsive to change. This approach allows for a well-coordinated execution of strategic goals, enhances customer satisfaction and optimizes capabilities.

Human-Centrism focuses on understanding and prioritizing the needs, behaviors, and experiences of people, customers, employees, and stakeholders, at the core of the design process.

Collaboration encourages cross-functional teamwork and stakeholder involvement to co-create solutions that align with both human needs and organizational goals.

Enterprise Design and EDGY can be applied across all disciplines to facilitate holistic and human-centric collaboration.

Business Design

Business Design is a multidisciplinary approach that integrates principles of design thinking with business strategy, innovation, and organizational development to create value-driven, human-centered solutions for enterprises. It focuses on designing not just products or services but the underlying business models, processes, and systems that make them viable, desirable, and feasible.

Business design consists of aspects such as human-centered approach, Business Model Innovation (BMI) *), systems thinking, cross-disciplinary collaboration, organisation design and brand design. As such, business design is integral part of Enterprise Design, which is the most comprehensive approach covering business design, service design and business- or enterprise architecture. By aligning business goals with human needs and operational realities, it enables enterprises to create sustainable, customer-centered, and competitive solutions. Business design ensures that enterprises can adapt to a rapidly changing business environment – the world around the enterprise. Business design integrates creativity, strategy, and practical execution to shape businesses that thrive in both current (as-is) and future (to-be) landscapes.

*) Business model innovation (BMI) is the process of fundamentally rethinking and redesigning the way an enterprise creates, delivers, and captures value. It goes beyond improving existing processes or products; instead, it involves creating entirely new ways for a business to operate, often challenging industry norms, capitalizing on emerging opportunities, and seeking disruptive innovations. Business model innovation is not just about making incremental improvements; it’s about reimagining how an enterprise operates to deliver value in groundbreaking ways. It is essential for staying relevant, efficient, competitive, and adaptable in today’s fast-changing business landscape.

Business Architecture

Enterprise Design introduces the Architecture Facet that represents all the architectural aspects and elements that are meaningful for operations and how an enterprise produces and delivers its offerings (products and/or service).

In this context, the Architecture is an umbrella term for all the diverse “architectures” that exists in an enterprise. We can identify several architectures e.g. as follows: Enterprise Architecture, Business Architecture, Solution Architecture, Information Architecture, Integration Architecture, Security Architecture.

Business Architecture (BA) covers most of the relevant elements that the business consists of. This makes Business Architecture suitable for design purposes, as it is both comprehensive and detailed enough. Business Architecture provides holistic view of how an enterprise operates, helping to ensure that its structure and behavior (capabilities, processes) are aligned with strategic goals. It bridges the gap between strategy and execution, ensuring that business operations support the overall mission and goals of the enterprise.

**Figure**: The role and importance of architecture are essential.

The Architecture Facet of the Enterprise Design Facet Model represents elements that can be related to the Business Architecture. Simplification of the Business Architecture content shown below. This view is a subset of enterprise design elements that altogether represent the enterprise.

The elements of Enterprise Design describe the entire enterprise, the business as a whole.

**Figure**: Enterprise Design elements covers the business architecture.

This business entity, the enterprise, is a system in which everything influences everything else, and it does not make sense to examine it only partially. The Enterprise Design Facets and their intersections together represent the entire business, where all the elements are interconnected. As such, the Enterprise Design Facet Model represents the whole enterprise, as it is important to view the entire business as a whole. Business Architecture metamodel according to BIZBOK® guide shown below.

Business Architecture content by the BIZBOK® is shown below.

**Figure**: Business Architecture according to BIZBOK®.

**Figure**: BIZBOK® metamodel with EDGY elements.

BIZBOK® is created by the Business Architecture Guild®.

The figure below illustrates the scopes and levels of the architectures.

Business architecture focuses on aligning enterprise’s strategy, business model and operating model with capabilities. Questioning about the capability as a concept:

Why capability is an important concept?
Why not use another concept instead, as there are few of them already, such as function, process and service?

In the big picture, the name of the concept isn’t what matters. What is important is that certain substantial and behavioral elements are commonly understood and accepted. These elements can be used for the logical grouping of an enterprise’s business. They include all the people, processes, and assets that work together to produce and deliver specific outputs or outcomes. The capability concept encompasses all of these. As such, capability model (capability map) can serve as a framework for organizing the business into behavioral structures.

Service Design

Service Design is a human-centered approach to designing and improving services. It focuses on understanding customer needs and creating seamless, enjoyable experiences across all touchpoints. Service design considers both the customer journey and the organization’s internal processes, aiming to align them for optimal service delivery.

Customer Insight refers to a deep understanding of customers’ behaviors, needs, motivations, and pain points. This understanding is derived from researching and analysing customer experiences, attitudes, situation in life, and preferences etc., which allows designers to make informed decisions that enhance the value and relevance of the service. It involves gathering data and insights about how customers interact with a service, what they value, and the challenges they face. Customer insight provides the foundation for creating user-centered services that meet real needs and enhance the overall customer experience. Customer insight is crucial in service design because it grounds the design process in real user experiences, ensuring that services are relevant, valuable, and capable of meeting or exceeding customer expectations. Customer insight is a critical input for the service design process. It serves as the foundation for understanding customer needs, behaviors, expectations, and pain points, guiding the design of user-centered services.

Customer insight is input for the service design process.

Service Design and Business Architecture – better together

Service Design and Business Architecture have strong synergy because they complement each other in aligning the design of services with the operational foundation of an enterprise. They combine customer-centric thinking with enterprise-level operational view (like Jin and Jang).

Together these practices help creating a balance between desirability, feasibility, and viability. This integrated approach ensures that services are impactful, sustainable, and fully supported by the enterprise’s capabilities. Their synergy lies in combining the human-centered approach of service design with the systemic and structural perspective of business architecture, resulting in solutions that are both desirable for customers and feasible for the enterprise.

Service design and business architecture complement each other.

By working together, service design and business architecture ensure that innovations are customer-driven (desirable), strategically aligned (viable, lucrative and cost-effective), and operationally sustainable (feasible), making organizations more agile, competitive, and capable of delivering exceptional value to both customers and stakeholders.

**Figure**: Service Design and Business Architecture.

Service Design and Business Architecture are better together.

Synergy benefits of Service Design and Business Architecture

There are several reasons why service design and business architecture work better together than as separate disciplines:

There are several synergy benefits in the collaboration between service design and business architecture, as illustrated by the following examples:

Synergy benefits arise when service designers and business architects work together in collaboration.

Service designers and business architects design together what customers’ need, what services are required and what information is handled and switched between processes or applications. Business people make the decision what solution is to be selected to support business.

Collaboration benefits of Service Design and Business Architecture

Collaboration between service designers and business architects can be highly advantageous as it combines complementary skill sets to create customer-centric, strategically aligned services. Here’s how they can collaborate in practice:

Collaboration between service designers and business architects is advantageous, as it combines complementary skill sets to create customer-centric services that are strategically and operationally aligned.

The collaboration between service designers and business architects results in better designs, concepts, and implementations of services and products.

Service designers and business architects can share a variety of tools and methods to facilitate collaboration, align their perspectives, and achieve cohesive solutions. These tools and methods are often centered around understanding customers (users), mapping processes, and aligning business goals.

All in all, when it comes to methods and tools, the mindset in the Enterprise Design approach is both-and, not either-or, meaning that all proven methods and tools are valid and usable.

Enterprise Design approach with EDGY supports co-design.

Here are some examples of benefits how service designers and business architects can utilise Enterprise Design and EDGY with appropriate tool (there are plenty of tools available ranging from free open-source solutions to commercial products with extensive features):

Service Blueprinting provides a holistic view that bridges user experiences and internal processes.
Co-create detailed service blueprints to connect customer experiences with backend operations.
Visualize and streamline business processes and service delivery processes.
Manage iterative co-design and implementation processes collaboratively.
Align on how customers experience the service across different stages and touchpoints, including back-end processes and supporting applications.
Helps both service designers focus on user experience and business architects understand process impacts.
Stakeholder Mapping to identify and analyze all key stakeholders and their roles in delivering or experiencing the service.
Outline the value proposition, target audience, channels, and resources needed to deliver a service.
Align business architecture goals with customer-focused strategies.
Customer Journey Mapping to map and analyze the flow of value through processes and applications.
Collaboratively generate ideas, prioritize features, and solve problems.
Build alignment and ensure all perspectives are considered in decision-making and design.
Prototyping and Testing to develop low-fidelity to high-fidelity prototypes to validate ideas with stakeholders and customers to ensure alignment with business goals and customer needs.
Evaluate how proposed changes impact customers, processes, and business outcomes.
Create visualisations and presentations of key user groups to understand their needs, goals, and behaviors.
Ensure solutions are grounded in real user insights and aligned with business objectives.
Identify risks associated with service delivery or business processes.
Balance the creative aspects of service design with the operational stability valued by business architects.
Ensure both service designers and business architects align their efforts toward a unified vision.
Streamline workflows by eliminating redundant tools or processes.
Create a common, simple, easy and visually appealing language for discussing customer needs, business goals, and operational capabilities.
Enable solutions to evolve with the enterprise’s changing needs.

By utilising Enterprise Design with EDGY and leveraging shared tools and methods, service designers and business architects can foster greater collaboration and co-create services that are human-centric and aligned with business operations and enterprise goals.

Enterprise Design and EDGY ensure that the outcomes are better when created in collaboration between service designers and business architects.

Enterprise Architecture (EA) is at a crossroads

Enterprise Architecture (EA) can survive as a discipline on its own and choose between maintaining the traditional track or shifting to a more business-oriented approach. Alternatively, EA can integrate with other disciplines and become part of Enterprise Design. This requires changes in thinking, practices, tools, and methods. The benefit is staying relevant and achieving a better position in the overall changes and transformations within the enterprise. Rebranding the entire EA discipline can open new possibilities to make its value more beneficial to new stakeholder groups than before.

Rebranding Enterprise Architecture (EA)

Examples of actions to make enterprise architecture more efficient and beneficial for the enterprise’s business.

From traditional EA to Business-Outcome-Driven Enterprise Architecture (BODEA)

A focus area for enterprise architecture is business-outcome-driven EA (BODEA) as Gartner has introduced it.

BODEA “starts with business architecture to align business and IT by putting the “Why” and “What” of EA before solutions and technical architecture, the “How” of EA. Business-outcome-driven approach shifts EA from the traditional EA to more business-oriented. Traditional EA “is technology-centric that focuses on solutions and technical architecture with an emphasis on projects as well as command and control governance” according to Gartner. [Ref: 8 Steps to Start a High-Impact EA Practice, Gartner, 2024].

EA as Internal Management Consultancy (IMC)

A preferred shift to more business focused defines EA as an internal management consultancy (IMC). “IMC is stakeholder-centric. IMC extends BODEA by delivering EA services to meet the needs of stakeholders. It professionalizes the EA practice by offering advice and guidance, working in a responsive and agile way, using adaptive governance”. [Gartner]

From BODEA TO IMC

The shift in enterprise architecture from traditional EA to internal management consultancy (IMC) represents the next organic maturity step, evolving from being business-outcome-driven to becoming a real, practical advisor and collaborative partner within the enterprise. If enterprise architects (EAs) want to shift from being technical specialists to more business- and human-oriented professionals, they can adopt a variety of tools and approaches that emphasize collaboration, accessibility, and business alignment.

EA Criticism

There are reasons why EA needs to rethink its role and relevance.

Enterprise Architecture (EA) has not been success. EA has often failed and faced criticism for its lack of success in delivering value in many enterprises – even though EA covers crucial aspects of the enterprises. EA has disconnected from business management and customer experience. The criticism has focused on the following issues:

Problems with Enterprise Architecture in the Finnish public sector, that are typical and common to many organisations in many countries, are handled in the dissertation by K. Penttinen: The long and winding road of enterprise architecture implementation in the Finnish public sector, dissertation, Penttinen, K., 2018, University of Jyväskylä, Finland. https://jyx.jyu.fi/handle/123456789/60447?locale-attribute=en

The world for which traditional Enterprise Architecture (EA) was created no longer exists. Today, business is faster and more agile, and the pace of change requires a more flexible and collaborative approach.

EA Opportunities

What enterprise architects could do to keep their professional relevant in enterprises?

Enterprise architects can remain relevant by evolving from technical specialists to strategic business enablers. By focusing on value delivery, human-centricity, agility and communication, they position themselves as indispensable contributors to enterprise growth and transformation. Enterprise architects need to reinvent themselves and embrace renewal. To remain valuable in today’s fast-changing business environment, enterprise architects must transform their roles and approaches.

What enterprise architects could (= should) do to stay relevant:

Enterprise architects must evolve from being technical specialists to strategic business enablers who drive value and adaptability. By becoming agile, business-focused, and human-centric, they can secure their roles as indispensable leaders in the modern enterprise.

Enterprise architects must shift from technical specialists to strategic business partners.

Tools, Frameworks, and Methods

No tool alone can make a discipline successful, and ‘a fool with a tool is still a fool.’ Success depends on how the tool and visualization are used. Is it easy for everyone to use, or difficult for most people?

What kind of tools and visualisations are the most useful and valuable to EAs shift their focus from technology-driven to business-outcome-driven planning. EAs can utilise e.g.:

Visual Collaboration Tools, that simplify communication and foster collaboration across technical and non-technical stakeholders. E.g. digital whiteboards for brainstorming, journey mapping, and collaborative workflows. These make architectural concepts more accessible and encourages input from all stakeholders, they visualize processes and systems in an intuitive way, bridging technical and business perspectives.
Diagramming Tools, for creating simple, human-readable diagrams that anyone in the enterprise can understand. E.g. Draw.io (https://www.drawio.com/ and https://app.diagrams.net/ ), a lightweight, free tool for creating flowcharts, process diagrams, and capability maps etc. Or Customer Journey Mapping Tools to incorporate customer experience into architectural planning by mapping customer journeys, stakeholder insights and touchpoints, e.g. with Smaply (https://www.smaply.com/ ).
Enterprise Design Approach and language, for holistic overview that integrate human, business, and technical perspectives. E.g. EDGY, a simple visual language for aligning stakeholders and disciplines that can be used diagramming tools (such as Draw.io) and with plain old PowerPoint.
Simplified EA Tools with Business Alignment Features, adopt tools designed for both business and IT users, e.g. Confluence (https://www.atlassian.com/software/confluence ), that allows people to create content in diverse formats such as plain text, tables or figures.
Data Visualization and Analytics Tools, make data-driven architectural decisions that resonate with business stakeholders. E.g. Tableau / Power BI.
Agile and Lean Tools, integrate agility into EA processes to better align with business priorities and reduce time-to-value. E.g. Jira (https://www.atlassian.com/software/jira ).

Using tools effectively requires discipline; otherwise, the structure of content degenerates, and the quality of outputs suffers. Managing the content requires continuous refactoring and care, agreed and shared practices, and a governance model, or otherwise, the content becomes fragmented. A tool doesn’t make the quality of content, a tool doesn’t make good visualisations but discipline and commonly agreed guidelines. As a result of this, the outputs, the artifacts, the visualisations are understandable, usable and valuable. Paraphrasing Wittgenstein: “the meaning of visualisations lies in their use”.

“The meaning of visualisations lies in their use.” [Applying Wittgenstein]

“A fool with a tool is still a fool.”

EAs can move toward a business- and human-oriented role by adopting tools that:

Simplify complexity for non-technical stakeholders.
Focus on business capabilities, customer journeys, and strategic alignment.
Foster collaboration and communication across all levels of the enterprise.

This shift will make enterprise architecture more relevant and valuable in driving business success.

Overemphasis on theoretical frameworks and models, combined with complex tools, makes enterprise architecture too cumbersome and inaccessible for other stakeholders, such as business people. Enterprise architecture tools are often too technical for non-technical stakeholders to use, and the models and diagrams, while detailed and accurate, are often difficult to understand.

Too theoretical and technical – too difficult for other stakeholders.

Tool with a repository – or not?

The necessity of an enterprise architecture (EA) repository managed within specialized and complex tools depends on the enterprise’s specific needs, but modern trends increasingly favor tools that facilitate collaboration and accessibility.

When can an EA tool with a repository be useful:

If the enterprise’s architecture involves highly complex systems, processes, and dependencies, a specialized EA tool may be necessary for detailed modeling and analysis.
In highly technical environments where deep system-level analysis is required, these tools can be useful.
When reusability of the elements is necessary.

When can a collaboration tool (without a repository) be reasonable choice:

If cross-disciplinary collaboration and shared ownership of enterprise artifacts (models, visualisations, descriptions) are important (to prevent siloing and stakeholder group isolation).
In business- and customer-driven enterprises, where tools should be accessible and understandable also to non-architects, such as business people, designers.
When simplicity and accessibility are necessary, so that diverse stakeholder groups can easily share a common understanding of designs.
When agility and flexibility are needed, like in n fast-moving environments, lightweight and shareable tools may be more adaptable, enabling quicker updates and easier access for all stakeholders.
For holistic Enterprise Design, where designers and architects are working together for customers’ benefit.

Concept Design

Concept design refers to the phase where the foundational ideas and high-level design of a product, service, or system are developed before moving into the implementation and operation phases. This is an essential early stage that focuses on defining what will be built and why, ensuring that the end product aligns with customer needs and business objectives.

Concept Design Principles. Viability, feasibility, and desirability are core principles used to evaluate and shape ideas to ensure they are practical, sustainable, and meet user needs

In every demand and in every concept, the following three priniples must be met:

Desirability: the customer perspective, we must ensure that the service or product meets the customer needs and expectations, and it is usable, valuable and benficial for the customer. The service must be beneficial, relevant, provide good user or customer experience and fulfill customer needs. We should always ask questions like: “Do people want or need this service / product?” “Do customers pay for this?”
Viability: there must be a business model behind the concept. It must be aligned with business goals and strategy, economically sustainable, and cost-effective. Essentially, it answers the question, “Can this service survive and thrive?”
Feasibility: examines the practicality, efficiency, and reliability of the service or product, ensuring it is both operationally and technically feasible to implement. It considers the operational and technical resources required to produce and deliver the service effectively, including people’s skills and competencies, processes, and assets (such as technology and infrastructure). Feasibility addresses. Feasibility answers the question, “Do we have the means and resources to make this service a reality?”

In successful enterprise design, these three principles intersect, creating solutions that are desirable for users, feasible to implement, and viable for the business. Balancing these three principles, desirability, viability and feasibility, ensures that services are both user-centered and sustainable within the organization. For a demand or concept to be successful, it should ideally balance these three aspects:

Desirable but not viable or feasible: The concept may be attractive to users but could fail due to high costs or operational (e.g. technical) limitations.
Feasible but not desirable or viable: The concept can be built but may not meet user needs or generate enough value to sustain itself.
Viable but not desirable or feasible: The concept might be cost effective and profitable in theory but could be difficult to implement or not resonate with users.

The goal in enterprise design is to find the sweet spot where a concept is desirable to users, feasible to implement, and viable for the business, ensuring long-term success and sustainability.

**Figure**: Concept Design principles and viewpoints.

In successful enterprise design, these three principles intersect, creating solutions that are desirable for users, feasible to implement, and viable for the business.

Concepts and solutions are interconnected yet distinct elements in the process of problem-solving, innovation, and design. The concept provides the “why” and “what”, the vision and rationale for addressing a challenge or opportunity, while the solution provides the “how”, the specific implementation plan that operationalizes the concept. Both are essential, with the concept ensuring alignment with strategic goals and the solution delivering practical outcomes.

Concept Design is a co-design process, which is triggered by certain demand (event or need) that is occurred in the business environment of the enterprise. Concept design can encompass the following phases and artifacts:

Problem definition: drivers, goals and outcome
Customer needs: customer- and organisation views (Service Blueprint, BMC etc.)

A concept content example shown below. A concept design canvas can be used for defining the customer need and possible solution.

Making changes is asking questions. The purpose of Concept Design is asking right questions to analyse why a change is needed, what is the change, who benefits from the change and how the change can be implemented.

Capability-Based Approach

The Capability-Based Approach focuses on identifying, planning, developing, enhancing and operating the enterprise’s business capabilities necessary for achieving strategic goals. As such, capability-based approach enables strategy execution. In addition, the capability-based approach leverages the capability-first principle, which makes capabilities the primary units of management, design, planning, and operations within the enterprise. Effectively this means that capabilities link the strategy, business model and operating model of the enterprise.

**Figure**: Capabilities link strategy, business model and operating model.

A capability refers to an enterprise’s ability to perform a specific activity that is essential for delivering value and maintaining competitive advantage. Capability-based approach ensures that an enterpirse allocates resources, invests in skills, and optimises processes that are critical to its success.

Instead of focusing on individual initiatives or projects, capability-based approach emphasises building and strengthening the capabilities that are most important for the enterprise’s strategic success. Capabilities are developed based on their alignment with the enterpise’s strategic goals. By understanding which capabilities are necessary to execute the strategy, the enterprise can focus and invest in the right areas.

Holistic. Capability-Based design, -planning and -development is a holistic approach. Capabilities are typically a combination of people, processes, and assets (such as data, applications, technology, and resources). Capability-based approach considers how these elements work together to enable the enterprise to achieve its goals.

Incremental and iterative. Capability-Based approach is incremental and iterative, as the business environment is in continuous change, and so is the enterprise. They continuously assess their capabilities, identify gaps or weaknesses, and focus and invest in improvements to enhance those capabilities over time.

Cross-Functional Collaboration. Since capabilities are enterprise-level, unique, and agnostic to organisational structures, they span across multiple units, departments, or functions. Capability-based approach encourages collaboration between different parts of the enterprise to ensure that all necessary components are integrated. This approach helps prevent the silo effect, where distinct units develop their own components in isolation, without an enterprise-wide analysis.

Strategic. Capability-based approach is a strategic approach that helps enterprises align their internal strengths (capabilities) with their long-term strategic goals. By focusing on developing the right capabilities, whether related to people, processes, or technology, enterprises can improve efficiency, drive innovation, and maintain a competitive advantage. This approach ensures that all initiatives are connected to the enterprise’s strategy, enabling more effective execution and resource allocation. A key tool in capability-based approach is the capability map, which visualises the enterprise’s core capabilities and how they support strategic goals. The map helps in identifying gaps and areas where development is needed.

Capability-Based Approach is strategic, holistic, iterative and incremental.

Comparing capability-based approach with continuous demand-based development, and concept design. They are interconnected approaches that together drive an enterprise’s ability to respond to changing business needs, innovate, and maintain competitive advantage.

Capability-based approach, continuous demand-based development, and concept design are highly interrelated approaches in an enterprise’s development strategy. Capability-based approach builds the foundational skills, processes, and technologies needed for long-term success. Concept design drives innovation and identifies new opportunities for capability building, while continuous, daily-basis demand-based development ensures that the enterprise can respond quickly to short-term needs. Together, they create a dynamic system that allows for both innovation and operational agility, ensuring that the enterprise is well-positioned for success in an ever-changing environment.

Capability-based approach provides the foundation for daily-basis development: the capabilities built through capability-based approach enable enterprises to respond effectively to daily demands. A capability map is the base map of the enterprise’s business operations.

Capability-based approach provides the foundation for daily-basis development.

Concept design is an early-phase development activity focused on creating innovative solutions, products, services, or processes. It involves ideation, prototyping, and exploring new ideas based on customer or market needs. Concept design often occurs at the front end of innovation. Concept design identifies new ideas and opportunities that may require the development of new capabilities, or update existing capabilities. Again, the capability map provides a ready-made overview of the current business. All the new ideas are somewhat related to existing capabilities. Capability-based approach serves as the backbone that enables both concept design and continuous, demand-based development. It focuses on building long-term capabilities that support both innovation (concept design) and operational agility (daily demand-based development).

**Figure**: Capability Map serves as the foundational map of an enterprise’s business operations.

Capability-based approach is the backbone that enables both concept design and continuous, demand-based development.

Capability-based approach emphasizes building and refining the skills, processes, and resources necessary for an enterprise to achieve its strategic goals and maintain a competitive advantage. By focusing on capabilities, enterprises can enhance their agility, foster innovation, and effectively respond to changing market conditions. Real agility comes with well-defined capabilities in place, as capabilities represent the fundamental behavioral units of an enterprise. Capabilities are focal-points of business operations as well as business management and -development. Capabilities operationalise change demands of any kind: strategic goals, customer initiated demands and other business-related changes.

**Figure**: Capabilities are focal points of business architecture.

Principle: Focus on Capabilities (Capability First approach) in development. All the operational changes in an enterprise are changes to its capabilities.

All the operational changes in an enterprise are changes to its capabilities.

Benefits of Capability-Based Approach:

Strategic Focus: Capability-based approach ensures that the enterprise focuses its efforts on areas that directly support its strategic goals, rather than investing in isolated or disconnected initiatives.
Better Resource Allocation: By understanding which capabilities are critical for success, enterprises can allocate resources more effectively, ensuring that investments are directed toward areas that deliver the most value.
Improved Agility: Focusing on developing core capabilities allows enterprises to be more agile and responsive to changes in the business environment, market, technology, or customer demands. Strong capabilities enable enterprises to pivot more effectively when needed.
Sustainable Competitive Advantage: By continuously improving and developing the capabilities that matter most, enterprises can build and sustain a competitive advantage over time.

Capabilities serve as the foundation that enables the implementation of strategic goals, customer needs, and other business-related changes at the operational level.

Steps in Capability-Based Approach:

Identify Strategic Goals: Understand the organization’s strategic goals and align capability development with those objectives.
Map Existing Capabilities: Use a capability map to assess the enterprise’s current strengths and weaknesses.
Identify Gaps and Opportunities: Determine where the enterprise’s current capabilities fall short of supporting strategic goals.
Develop a Capability Roadmap: Create a plan for developing, enhancing, or acquiring capabilities over time.
Execute and Monitor: Implement initiatives to build capabilities, monitor progress, and adjust the plan as needed.
Continuous Improvement: Regularly evaluate capabilities to ensure they remain aligned with changing business needs and external factors.

Capability-based approach is a strategic approach that focuses on building and enhancing core business capabilities, enabling enterprises to effectively execute their strategy, adapt to change, and achieve sustainable competitive advantage.

capability-based development — **Figure**: Capability-Based Aproach is crucial for business development.

Capability-based approach is the primary development tool, supporting all other development and design efforts within the enterprise.

Capability Based Planning (CBP)

Capability-based planning is a strategic approach focused on building specific capabilities rather than simply acquiring assets or resources. It’s commonly used in fields like defense, business, and government, where enterprises need to ensure they can effectively achieve their goals under various conditions. The main idea is to identify the essential capabilities needed to meet strategic goals and then plan, prioritize, and allocate resources to develop those capabilities. Capability-based planning primarily focuses on what an enterprise needs to be able to do rather than how it will do it. This approach centers on identifying and defining the essential capabilities (the high-level abilities) required to achieve strategic goals and fulfill the enterprise’s mission and business model – the why.

**Figure**: Relations between strategy, business model and operating model.

In capability-based planning, planners first define what the enterprise needs to be able to do, like responding to a security threat, launching a product, or delivering a public service, without being overly prescriptive about the means (the “how”). They then evaluate the current and future capabilities required to achieve these outcomes. This method (capability first -principle) allows flexibility, focusing on building adaptable skills, tools, and processes that can respond to changes, uncertainties, or evolving scenarios. The capability map is a good starting point – the base map – when analysing the impact of goals in any change initiatives or business transformations within an enterprise.

Capability-based planning primarily focuses on what an enterprise needs to be able to do.

Capability-based planning is important and valuable because it aligns resources and planning directly with an enterprise’s strategic goals. This makes enterprise more adaptable and efficient, especially in uncertain or rapidly changing environments. Examples of benefits:

Example Use Cases:

Developing digital transformation roadmaps.
Preparing for changing business environment conditions.
Building new operational abilities for the business operations of an enterprise.

Summary: Capability-based planning helps enterprises focus on the “what” of achieving goals in a way that is responsive, resource-efficient, and resilient, making it a critical component for long-term success in complex environments.

**Figure**: Capabilities link enterprise’s goals and customer needs.

Capability-Based Planning (CBP) ensures that the enterprise focuses not only on isolated outputs (such as products, services, applications, or processes) but on building the foundational capabilities needed to thrive in a dynamic, volatile, and ever-changing business environment.

Enterprise Design Model

Enterprise Design Facet Model Venn-diagram can be applied to concept design. The Facet Model can be used in many ways. The starting point can vary. Design can be started from any part of the Facet Model. To start from the Experience forces us to take the customer first approach and analyse first the desirability of the demand, new idea or innovation candidate.

**Figure**: Enterprise Design VENN-diagram.

**Figure**: Enterprise Design Facets and Intersections.

Enterprise Design Wheel

The Enterprise Design Wheel (or Enterprise Wheel for short) method can be used as a source of inspiration and guidance when starting with an enterprise design challenge. Enterprise perspectives and intersections are introduced as sectors of a wheel in two levels: 1) Facets represent the sectors at high-level and 2) enterprise elements represent the sectors at detail-level.

Analysis can be started on any sector, and then continued to adjacent sectors to any direction. The view can be taken from different viewpoints such as from enterprise, organisation, employee or customer viewpoint. The viewpoint can be placed in the middle of the wheel.

**Figure**: Enterprise Design Wheel and questions to be asked when visualising.

The Enterprise Wheel supports holistic thinking and considering all the elements. Enterprise elements around the Enterprise Wheel.

**Figure**: Enterprise Design Wheel and enterprise elements.

Enterprise Design House

The Enterprise Design House (or Enterprise House for short) is a high-level approach for enterprise design. It introduces the main points of the enterprise design, starting from the Identity perspective. As such, the Enterprise House is a management method. It covers strategic level on the top, then customer and architecture perspectives. Enterprise Design House covers all the viewpoints visualised as layers. Enterprise Design House main floors shown below.

This view can be used as a landing page in enterprise’s content management tool (such as Confluence). This page provides a front page, a gateway to drill down into descriptions such as diagrams and maps.

**Figure**: Enterprise Design house as a content framework.

Enterprise Development Examples

Development is an overall process that can be divided into high-level phases such as design, implementation and operations. In other words, to plan, build and run phases.

**Figure**: Enterprise Design can be applied to support holistic enterprise development by covering all the aspects motivations, operations and experiences.

This overall process (Plan, Build, Run) can be supported by the Enterprise Design approach, which can be applied not only to design and implementation but also to the experience aspect.

By aligning motivations with the Identity facet, operations with the Architecture facet, and experiences with the Experience facet, the Enterprise Design Facet Model provides a robust framework for addressing the holistic needs of the enterprise. It ensures that strategic goals, operational systems, and user interactions are seamlessly integrated, driving value and long-term success.

IT4IT Reference Architecture

The IT4IT Reference Architecture, developed by The Open Group, is a framework for managing the business of IT. It provides a vendor-neutral, technology-agnostic standard for managing the entire IT lifecycle, focusing on integrating and automating IT processes to deliver value more effectively. IT4IT is based on a Value Chain that aligns IT operations with business needs. It identifies key activities in the IT lifecycle that drive value to the organization.

The architecture is divided into four value streams that map to the end-to-end IT lifecycle:

Strategy to Portfolio (S2P): Focuses on aligning IT strategies with business objectives and managing the IT portfolio.
Requirement to Deploy (R2D): Manages the development and delivery of IT solutions, including Agile and DevOps practices.
Request to Fulfill (R2F): Streamlines how IT services and products are requested and delivered to consumers.
Detect to Correct (D2C): Covers monitoring, detecting, and resolving issues in IT services and infrastructure.

These four value streams can be mapped to phases plan, build, deliver and run.

IT4IT introduces Digital Product that is an unit of development.

Examples of Digital Products: eCommerce Websites, Mobile apps, Operational Technology (OT), smart devices, Digital Platforms (PaaS, SaaS, Low code/No code dev, content platforms (docs, videos etc.)). Operational Technology (OT): monitors, sensors, RPA and AI solutions etc.

**Figure**: Digital Products may use other digital products (on system level).

Change Project or Program

All the changes in the enterprise should be derived from the business goals, as they define what are the changes we want make happen. Accordingly, all the change activities or -initiatives of the enterprise are related to the operations of the enterprise. However, the changes are affecting to the identity of the enterprise. It is important to identify the drivers reasoning and explaining why a change is needed, and then set the goals for the change. A change project or program can be modelled with the Activity element. Goals of a project can be modelled with the Purpose, deliverable with the Object, and triggering demand with the Outcome element.

Project Development

The deliverable of a project can be e.g. a release of product (such as an application). The changes of an enterprise are related to the operational architecture of the enterprise. As such, the changes are affecting to concrete elements of the operations of the enterprise. Such operational elements are e.g. processes or assets (such as applications, facilities or devices).

**Figure**: Release of a software project.

In the case of a software project, each phase can product a release as the output.

**Figure**: A software project with releases.

Projects are changes in the capabilities of the enterprise.

Project Management

Project Management triangle introduces primary constraints on any project (or program):

Scope refers to the overall goals, deliverables and tasks need to be completed in the project. The scope defines what the project is supposed to achieve and includes expected outcomes.
Schedule (or Time)represents the project timeline including deadlines for deliverables and the overall duration of the project.
Budget (or Cost) represents what is allocated for the project. It includes all the required resources such as financial, labor/employee, tools and other costs.

The visualisation shown beside. The quality in the center of triangle represents the balancing factor. The quality is affected by balancing scope, schedule and budget.

Product Development

Product development in an organizational context refers to the structured process of designing, creating, and bringing a new product or improving an existing product to production environment that is used by the business operations.

The “From Projects to Products” paradigm change refers to a shift in how organisations approach software development, delivery, and operational models. It involves moving away from a project-based mindset, which focuses on temporary, isolated initiatives, to a product-based mindset, which emphasizes long-term ownership, continuous improvement, and delivering value to customers through sustained investment in products.

The “From Projects to Products” paradigm shift reflects a fundamental change in how organisations operate, focusing on long-term value creation rather than short-term deliverables. This approach aligns with modern customer expectations, technological advancements, and the need for agility in dynamic business environments. While it requires cultural and structural changes, it ultimately enables organisations to deliver better, faster, and more customer-focused results.

Why the shift is happening?

Customer-Centricity:
1. Customers increasingly expect continuous innovation, support, and updates.
1. A product-oriented approach ensures organisations focus on customer needs rather than simply completing a project.
Agility and Adaptability:
1. The project-based approach often struggles to adapt to rapid changes in market demands or technology.
1. A product-based approach allows organizations to pivot and evolve their offerings over time.
Value Creation:
1. Projects often focus on completing tasks, while
1. products focus on delivering measurable, ongoing business value and solving real-world problems.
Technological Advancements:
1. Modern technologies like cloud computing, DevOps, and Agile methodologies favor continuous delivery and iterative improvements, aligning better with product-based thinking.

Agile Development

Agile development is a modern approach to software development and project management that emphasizes flexibility, collaboration, incremental progress, and the ability to quickly adapt to changes.

Agile methods and frameworks such as Scrum and SAFe promote iterative and incremental development, which performed in time boxed manner. The Scrum method is based on the following aspects and phases:

Product Backlog, a list of desired work, requirements. Prioritized, prepared and estimated list of items for to be selected to sprint
Sprint, a development period of few weeks (e.g. 1 to 4 weeks) that produces a product increment
Product Increment, a version, a release of the product
Sprint Planning, selection of backlog items/tasks for the next Sprint
Daily Scrum: 15-minute event held each day for the Development Team.
Sprint Review, a demo session of features of the product increment
Sprint Retrospective, a development team session for reflection and improvement.

Scrum Roles:

Product Owner (PO): a business representative, the voice of the stakeholders, responsible of the business requirement management and prioritisation for the Product Backlog, works closely with the development team, defines and prioritises the Product Backlog
Scrum Master, facilitates Scrum ceremonies, assists the development team
Development Team consists of members of specialisation areas such as programming, testing, release management, continuous integration etc.

Agile Team

Agile team is an autonomous, independent and self-organising team that consists of members each of which is capable of doing tasks from the team’s product backlog. Team members are equal and can share the tasks. However, typically team members are specialised to certain competences such as user interface (UX), back-end programming or testing. Typical team structure is illustrated in the figure below.

Scrumban provides the structure of Scrum with the flexibility of Kanban, making it a versatile approach for teams that need to adapt to changing priorities and workloads.

Tribe Model

Tribe model is based on the Spotify tribe model (also known as Enterprise Agility). A tribe consists of squads (teams), chapters and guilds. A Tribe is established based on e.g. a value stream.

Tribe model actors:

Tribe: a collection of squads that share a purpose (= mission and vision)
Squad: a cross-functional team that is responsible for delivering a specific functionality or capability. A squad is autonomous, self-organising with members from different disciplines such as software development and design.
Chapter: a group of individuals who share similar skills such as software development, design, test etc. Chapters organise forum for collaboration, knowledge sharing and skill development.
Guild: a community of interest of individuals from different tribes who share a common interest or passion, such as UX, agile practices, service design etc.

Tribe roles:

Tribe Lead: responsible for guiding and supporting the tribe in performing its purpose and achieving its goals according to the organisational goals and priorities.
Product Owner: represents the voice of the stakeholders, defines the requirements and prioritises the backlog of features, work closely with the stakeholders to understand the customer needs.
Tech Lead: a specialised senior engineer or technical expert who leads, guides and mentors the squad
Agile Coach: provides coaching, training and support to tribes and squads for adopting agile practices, improve team dynamics, and increase performance and effectiveness.

Development Team as multidisciplinary Fusion Team, introduced by Gartner. This means that a team consists of diverse competences that complement each other.

**Figure**: Fusion Team – a multidisciplinary team.

Team Topologies

Team topologies introduces an approach to organize teams for development.

Following types teams are introduced:

Stream-aligned team
Enabling team
Complicated subsystem team
Platform team

Team Topologies is a modern approach to designing and structuring software development and operational teams to optimize collaboration, delivery, and adaptability in an organization. It was introduced by Matthew Skelton and Manuel Pais in their book “Team Topologies: Organizing Business and Technology Teams for Fast Flow.”

The concept focuses on creating team structures and interaction patterns that align with the organization’s goals, systems, and desired outcomes, particularly in complex and dynamic environments like technology organizations.

**Figure**: Team Topologies and topology of teams.

Team Topologies provides a practical framework for structuring teams, improving collaboration, and reducing bottlenecks in software development and operations. By focusing on flow, clear team roles, and adaptable structures, it helps organizations achieve better alignment between their teams and their goals, leading to faster and more efficient delivery of value.

The Team Topologies approach provides significant benefits by structuring teams around value delivery, collaboration, and adaptability. It is particularly effective in dynamic and complex environments, such as software development or large-scale systems engineering.

The Team Topologies approach improves employee satisfaction by:

Reducing cognitive overload.
Empowering teams with autonomy and clear roles.
Facilitating productive collaboration and support.
Providing opportunities for mastery and growth.
Promoting a culture of continuous improvement and work-life balance.

**Figure**: Teams positioned according to the Team Topology.

Flight Levels

The Flight Levels approach is a framework developed by Klaus Leopold to help organisations visualize and manage work at different levels of the business, ensuring alignment between strategy, coordination, and operations. It provides a holistic view of an organisation’s activities, helping teams and leaders see the big picture and understand how work at different levels impacts overall business goals.

The framework is based on the metaphor of flying at different altitudes, with each “flight level” representing a different perspective or scope within the organisation:

Flight Level 3: Strategic (Highest Level)
- Focus: Organisational strategy, long-term goals, and portfolio management.
- Purpose: Aligns the enterprise’s strategic vision with operational activities. It ensures that business goals are clear and provides direction on how to achieve them.
- Participants: Typically c-level management or leadership teams.
- Example: Setting goals like increasing customer satisfaction by a certain percentage.
Flight Level 2: Coordination (Middle Level)
- Focus: Coordination across multiple teams and units to ensure strategic alignment and smooth delivery of work.
- Purpose: Breaks down high-level strategy into coordinated activities. Ensures that various teams are working together and not in isolation.
- Participants: Middle management, product owners, and team leads.
- Example: Coordinating the development of products between different units.
Flight Level 1: Operational (Ground Level)
- Focus: Day-to-day work and operations of individual teams.
- Purpose: Ensures that the actual work being done aligns with higher-level strategies. Teams focus on executing tasks efficiently and delivering value.
- Participants: Teams and individuals responsible for daily operations.
- Example: Developers writing code, customer support responding to tickets, or marketing teams creating campaigns.

Benefits of the Flight Levels Approach:

Big Picture and Detail Balance: Helps avoid the siloed thinking common in organizations by encouraging both strategic thinking and operational execution.
Cross-Functional Collaboration: Encourages different teams and departments to collaborate more effectively by visualizing dependencies and coordination needs.
Agility at Scale: Supports the application of agile principles across large organizations, ensuring that strategy is connected to the work being done by teams.
Continuous Improvement: By visualizing work at various levels, organizations can better identify bottlenecks, inefficiencies, and opportunities for improvement.

When to Use the Flight Levels Approach:

If your organisation struggles with aligning strategic goals to operational activities.
If you want to scale agile practices across multiple teams or units.
If coordination between teams is a challenge, leading to misalignment or delays.

The Flight Levels approach offers a structured way to view and manage work across an organization, ensuring that strategic goals align with everyday team activities and that different teams are working cohesively.

DevOps

Software Development (Dev) and IT operations (Ops) together form the DevOps model. It is a set of practices that emphasize collaboration and communication between development and operation. Traditionally development and operations teams have worked separately in silos. In DevOps, they work together as an integrated team. DevOps is not only a way to organise people, Sometimes, quality assurance and security teams come along, and then the model is called DevSecOps.

Definitions:

“DevOps is the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organisations using traditional software development and infrastructure management processes. This speed enables organisations to better serve their customers and compete more effectively in the market.” [Source: AWS]

DevSecOps stands for Development, Security, and Operations, and it’s an evolution of the traditional DevOps approach that integrates security practices into every phase of the software development lifecycle. The goal of DevSecOps is to automate security throughout the entire process, from development and testing to deployment and operations, rather than treating security as a separate, final step.

Organising Development in an Enterprise

Conventional hierarchical command and control, and holacracy, represent two extreme models for organizing and managing work within an organization. Conventional command and control is characterized by a rigid hierarchy, centralized decision-making, and structured roles, while holacracy enables enterprises to become more agile, innovative, and adaptive by distributing power and giving employees more autonomy. Holacracy encourages to self-management and enforces self-organising teams, called circles, according to agile practices (as introduced in Scrum or SAFe).

Holacracy is a system of organisational governance and management that decentralizes authority and decision-making, distributing power across the organization rather than relying on a traditional hierarchical structure. In a Holacracy, authority is spread throughout self-managing teams, circles, which are structured to allow for autonomy, flexibility, and responsiveness. This approach contrasts with conventional command-and-control systems, where power and decision-making are concentrated at the top levels of the hierarchy.

Self-Managing Teams (Circles): The organization is broken into circles, which are self-managing teams that operate autonomously to achieve specific goals. Each circle has its own purpose and authority to make decisions within its scope. Circles are often nested, meaning that smaller circles are part of larger circles, creating a dynamic structure where decisions and responsibilities are decentralized.

Holacracy provides a more flexible, adaptive, and self-managed system where decision-making authority is distributed across the organisation, empowering employees to manage their roles and responsibilities independently. The conventional command and control model, on the other hand, is a top-down hierarchical structure where decision-making and power are centralized, with a more rigid and controlled approach to management. Holacracy fosters higher employee engagement, faster innovation, and agility, while traditional hierarchies may be better suited for organizations requiring clear, centralized control, particularly in highly regulated or risk-sensitive environments.

Comparing conventional, hierarchical command and control approach with holacracy.

To enable communication, the self-managing teams are networked with each other.

To enable coordination, the self-managing teams can be assigned to value stream.

**Figure**: Value Stream based organised teams.

For coordination, communication, and business alignment, the self-managing teams can be assigned to a value stream, which has a clear business purpose, vision, and ownership. This organizational approach is based on the Tribe model and leverages Team Topologies practices.

**Figure**: Development organised around the Value Stream.

The Customer Journey is what customers are doing and experimenting, while operational value stream is providing the products and/or services. Teams are assigned to capabilities that are connected with the value stream.

**Figure**: Operational Value Stream requires business capabilities.

Organisation according to value streams is related to tribe-model (introduced in the chapter above). This organisation model is based on the customer journeys and customer needs. The operations (the operational value streams or core processes) are organised to support the customer journey. Management and executives are playing a supporting role as shown in the inverted pyramid figure below.

IT-Services

An IT service is made up of a combination of information technology, people and processes. An IT service is an ITSM (IT Service Management) concept, to which a ticket is directed in case of failure in production environment of an application (or applications). An IT service can be managed as an asset of the enterprise, so it can be modelled with the Asset element of EDGY.

**Figure**: IT service and IT application (a.k.a. IT system).

An IT service can be associated with one or many IT applications. An application is a packaged software that provides functions, which are required by an IT service. In case of application failure, an incident (an ITSM ticket) is directed against the IT service.

An IT service is developed by a development team, that is developing new features (epics, stories) based on the product backlog. That is managed by the product owner (PO) role, which is a business representative who manages requirements of the target application, the product (in agile context). Typically the development team also operates the target application, the product, in the production environment, which refers to the DevOps practice (or DevSecOps). An IT service can be associated with a service level agreement (SLA), which is a contract between service provider and consumer parties.

An IT service:

is not a behavioral or structural component of enterprise architecture. It is an abstract asset / entity, it is not concrete as an application that performs e.g. data processing.
is not used by users (business people, or business at all). Compared to an application that is used by users when they are handling information (create, read, update or delete, CRUD) . An IT service is not developed like an application. An agile team is organised around a product, typically a software product such as application.
does not contain any intelligence, it does not perform any actions, and it is not directly used by users or the business. However, an IT service is needed by the business to ensure that certain applications can function in production.

An IT service is NOT used by users, but it is needed by business to operate.

Cloud Service Models

Assets can be managed by different models according to management levels: assets can be managed by the enterprise itself, or managed by service providers. This distinction is a strategic choice that is related to the nature of the business. In this digital age, cloud services are very popular as they enable new business- and operating models.

For example, if the core business is related to certain business processes, not the technology, the enterprise can outsource its IT management. That can be done partly or completely according to different models introduced in the figure below. There are several factors such as costs of maintenance, business criticality, security etc. that have to be considered when choosing the strategy.

On-premise:
- all the applications and required platforms and infrastructure is managed and hosted by the enterprise and/or on the enterprise’s facilities.

Cloud-hosting models are as follows at high-level:

IaaS (Infrastructure as a Service):
- on-demand access to cloud-hosted physical and virtual servers, storage and networking – the backend IT infrastructure for running applications and workloads in the cloud
PaaS (Platform as a Service):
- on-demand access to a complete, ready-to-use, cloud-hosted platform for developing, running, maintaining and managing applications
SaaS (Software as a Service):
- on-demand access to ready-to-use, cloud-hosted application (software).

[Source: IBM, https://www.ibm.com/topics/iaas-paas-saas ]

Output and Outcome

Outputs and Outcomes are interconnected, but are different by their nature.

Output: direct results or deliverables produced by an activity (such as process, product or project).
Outcome: effects or changes that result from the outputs.

Typically an activity produces an outcome, which enables an outcome to be achieved.

**Figure**: Relation between the Output and Outcome.

Finally, at the end of the day, outcomes are what matters. Outcomes are what the customers want to achieve, tasks they want to get done. Outcomes represent the value (customer value, the business value), the benefit that can be achieved – with the help of outputs. Outputs are enablers of outcomes.

To shift the mindset from Outputs to Outcomes means changing the focus from outputs to outcomes that are associated with value. Previously, we were taught to ‘shift from projects to products,’ but now we should focus on ‘shifting from products to outcomes’ – the real benefits that help customers achieve their desired end results. For example, the “customer doesn’t want a drill, they want a hole in the wall”. So they can hang a picture.

[Applied from Gartner material by Gaughan, D.]

Outputs are needed to deliver an outcome – the value.

Visualisation

Visualisation is valuable and useful for facilitating shared understanding. Visualisation is a useful tool to analyse and communicate what’s happening in and around the enterprise.

The most valuable aspect is the visualisation co-design process itself, during which the development target (the problem domain) is examined together, and all relevant aspects are identified and discussed, and a shared understanding of the whole is established and made visible for further evaluation.

We can identify two kinds of communities (schools) that use visualisation in their work: 1) non-technical business people and 2) technical development-oriented people. EDGY is positioned between these communities to bridge the gap between them, as EDGY provides both simple and comprehensive language that is familiar for most of us. See the figure below.

**Figure**: EDGY is positioned in the middle of “schools”.

Figure above from the book “Visualising Business Transformation”.]

EDGY comparison with ArchiMate®

All in all, these languages (notations) complement, not compete, with each other. The EDGY is suitable for high-level co-design when creating a common understanding of design challenges and development target areas. The ArchiMate® is suitable for detailed architecture planning when concentrating on technical details.

Other Modeling Notations

The EDGY is a simple, colorful and holistic visualisation language that fits to every discipline and practice such as service design, business architecture and strategy planning. EDGY is complementary, high-level language that provides an easy approach and common language for co-design and cooperation of different stakeholder groups. The EDGY is a “Rosetta Net” for every change activity in an enterprise. EDGY is simple but comprehensive enough and it is visually appealing. EDGY complements, not replaces other more specialised languages.

How does EDGY differ from other notations ArchiMate, BPMN and UML?

EDGY focuses on high-level, strategic alignment across different disciplines, offering a simple and colorful notation, while ArchiMate, BPMN, and UML are more technical, detailed, and specialized in their respective areas of enterprise architecture, software development, and business process modeling
EDGY is cross-disciplinary whereas the other notations are more discipline-specific.
EDGY provides a holistic view of the organisation and it is less concerned with the specifics or details while the other notations focus on specific aspects of the organisation.

Characteristics of the notations analysed different aspects below.

Purpose:

EDGY provides a holistic view of an enterprise. EDGY is designed as a high-level multipurpose approach for enterprise design, focusing on the relationship between identity (purpose and vision), architecture (systems and structure), and experience (customer and user interaction). It is particularly suited for conceptual and holistic views of organizations.
ArchiMate is a comprehensive enterprise architecture modeling language specifically designed to model an organization’s business processes, information flows, applications, and technology infrastructure.
BPMN (Business Process Model and Notation) is a notation specifically designed to model business processes. It is used to visualize the flow of tasks and activities in a process.
UML (Unified Modeling Language) is a general-purpose modeling language used primarily for software design. It helps model software systems and their relationships.

Audience / target group(s):

EDGY is designed for strategists, designers, business architects, business analysts, business owners and leaders who need to align high-level organisational facets (identity, architecture, and experience) without diving into deep technical details. It’s ideal for interdisciplinary teams that span business strategy, service design, and architecture.
ArchiMate is targeted to enterprise architects and IT professionals who need to model and align business processes with technical systems. It’s more technical and suited for detailed architecture work.
BPMN is targeted at business analysts, process engineers, and stakeholders who are focused on optimizing and visualizing business processes. It is used by those who need to document or improve process flows within an organization.
UML is a general-purpose modeling language used primarily for software design.

Visuals:

EDGY uses simple, colorful visuals such as Venn diagrams to illustrate the overlap and relationship between key organisational facets (identity, experience, architecture) and their intersections (brand, product, organisation). This makes it easy for non-technical stakeholders to understand key concepts.
ArchiMate utilises more detailed and structured diagrammatic representations of layers and views within the organisation, which are more suited for in-depth technical analysis and documentation.
BPMN uses flowchart-like diagrams to represent business processes, with specific symbols for tasks, events, gateways, and flows. The visual language is highly structured but still intuitive for those familiar with process modeling.
UML uses various diagram types (class, sequence, use-case, component etc.) to visualise software components, their interactions, and behaviors. Each diagram serves a specific purpose, often with highly technical notation.

Simplicity vs. Complexity:

EDGY is intentionally simple and accessible, using a minimalistic visual style (like Venn diagrams) and color-coding to represent abstract concepts. It’s designed for ease of understanding and for fostering conversations among non-technical stakeholders, such as business leaders, strategists, business people and designers. Complexity Level: Low, designed to be intuitive and visual with no deep technical modeling requirements.
ArchiMate is more complex, offering detailed views across various layers of the enterprise (business, application, and technology). It requires specialized knowledge to create and interpret the models. Complexity Level: High, as it models enterprise architecture in significant detail, which can involve many interconnected systems and processes.
BPMN is more intuitive than UML or ArchiMate for business users but still requires understanding of process flows and technical details to create accurate process models. Complexity Level: Moderate to high, depending on the level of process detail and automation needed.
UML can be complex, especially when used for large-scale software systems. It includes various diagram types (class, sequence, activity, etc.), which require technical expertise to understand and create. Complexity Level: High, especially in large software engineering projects, but provides specific diagrams for different views of a system.

Scope:

EDGY is less concerned with technical details and more with cross-functional alignment between various aspects of the enterprise, such as branding, service design, and organizational structure. It offers a broad view of how different elements intersect to shape the enterprise.
ArchiMate is focused on detailing the architecture of business, application, and technology layers within the organization, making it suitable for more technical, system-centric use cases.
BPMN provides a graphical notation for specifying business processes in a process flow model. It’s heavily focused on workflow and task automation, making it suitable for process optimization, business process management, and documentation.
UML is highly technical and detailed, focusing on the design of software systems, their classes, interactions, and behaviors. It’s used by developers and software engineers to document and visualize software architecture and functionality.

Use Cases:

EDGY is inherently cross-disciplinary and adaptable, applying to various practices such as service design, business architecture, and strategy planning. It’s used at a strategic level across multiple domains, making it more multipurpose than technical notations.
ArchiMate is focused on enterprise architecture in detail
BPMN is focused on business processes
UML is focused on software design

All in all, when it comes to notations, the mindset in the Enterprise Design approach is both-and, not either-or, meaning that all proven methods and tools are valid and usable.

EDGY tools

The Enterprise Design language, EDGY, from the Intersection Group, enables people to design well-designed outcomes for better enterprises!

EDGY diagrams can be created with several tools, such as:

Draw.io (available as Confluence plugin, which enables lots of features for combining diagrams, text and tables)
- Draw.io net (web browser based tool, Windows, Mac)
- Draw.io desktop client
Miro
QualiWare
BlueDolphin
Powerpoint (stencils from EDGY tools)

More to come.

EDGY stencils (+ lots of information) can be found on the Intersection Group’s Enterprise Design with EDGY pages:

Enterprise Design with EDGY
EDGY Tools (stencils for Draw.io, PowerPoint etc.)
- E.g. for Draw.io, just drop stencils XML-file to Draw.io user interface, and you will see this on the tool palette:

References

[1] Intersection Group pages, https://intersection.group

[2] Enterprise Design with EDGY pages, https://enterprise.design/

[3] EDGY language foundations, book, 2023, (available as pdf), link

[4] EDGY 23 Language Foundations, Online course (4 weeks), Milan Guenther & Wolfgang Goebl, link

[5] Enterprise Design Patterns, Intersection Group book, 2020, (available as pdf), link

[6] EDGY 23 product release, launch on 29th March 2023, webinar recording, Milan Guenther & Wolfgang Goebl, link

— Eero Hosiaisluoma

Post Views: 15,461

Tags: Application Architecture, Business Architecture, EDGY, Enterprise Architecture, Information Architecture, kokonaisarkkitehtuuri, Solution Architecture