This book covers the Enterprise Design approach and related EDGY (Enterprise Design Graph Interplay) notation. The EDGY is an Open Source tool designed by the Intersection Group.

This book introduces example diagrams to inspire people to use EDGY language for enterprise design purposes. The content in this document is based on material by the Intersection Group. This book is updated continuously.

You can get the pdf document from the link below:

Load Enterprise Design with EDGY Cookbook pdf from this link.

Enterprise Design with EDGY is designed by the Intersection Group.

Introduction

Enterprise

“An enterprise is an endeavour of people with a shared ambition” [3]. An enterprise is a human-centric entity of behavior and structure, a coherent whole with something in common. It consists of people and assets for performing behavior for a reason. Typically, we tend to consider an enterprise as single organisation. However, it is often bigger than that: cooperation of several organisations in a network, or collaboration in an ecosystem. In this context, the focus is on people, and on outcomes an enterprise is producing. ‘From people to people.’

An enterprise serves a clear purpose, is useful to people, and delivers on its promises.

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. [3]

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.

Problem space and the solution. 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. Fortunately, the Enterprise Design approach provides shared understanding with a common language – to innovate and transform.

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

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.

Better Enterprises pursue a clear purpose, are useful for people and their lives, perform and deliver on their promises.

EDGY – Enterprise Design Graph InterplaY

EDGY provides an easy yet expressive language that everyone can use. EDGY offers a simple but powerful language that is accessible to all stakeholder groups within an enterprise. Visualisations with EDGY are simple and attractive, and everyone can interpret them intuitively and quickly. EDGY can be used as a common language for different professionals of diverse disciplines (such as service designers, UX- and CX-designers, product owners, business analysts, architects etc.). EDGY is a simple, colorful and appealing language. It has a limited set of concepts, which are easy to learn and easy to use. Everyone can understand EDGY right away, without a long learning curve.

EDGY tool support. The EDGY language is supported by many tools such as Draw.io, Miro, QualiWare, Blue Doplhin, PlantUML and more to come. The EDGY diagrams can also be modelled with the Plain Old PowerPoint. Free EDGY stencils are available via Enterprise Design pages (EDGY Tools).

EDGY is Intersection Group’s Open Source tool designed to help people create better enterprises.

References

Intersection Group pages, (intro, tools, learning, events etc.) https://intersection.group
Enterprise design pages, https://enterprise.design/
EDGY language foundations, book, 2023, (available as pdf), link
EDGY 23 Language Foundations, Online course (4 weeks), Milan Guenther & Wolfgang Goebl, 2023 https://intersection.group/learning/intersection-academy/
Enterprise Design Patterns, Intersection Group book, 2020, (available as pdf) link
EDGY 23 product release, launch on 29th March 2023, webinar recording, Milan Guenther & Wolfgang Goebl, link.

Enterprise Design Approach

Enterprise Design Facet Model

Enterprise Design approach is based on the Facet Model, which consists of three facets and their intersections.

These facets exist in all enterprises and all types of business. They are characteristics and qualities, that enterprises have by their nature, regardless of the size, whether they are intentionally designed or not. The facets represent the perspectives or viewpoints from which an enterprise can be observed holistically.

The facets are:

Identity – why do we and our enterprise exist, what motivates and drives us?
Experience – what people need, feel and want to get done with our help?
Architecture – how and with what we are running our enterprise?

The intersections are:

Organisation – how are we organised?
Brand – what is our reputation and image?
Product – what do we make and offer for people’s benefit?

The Facet Model scales to different levels within an enterprise (enterprise-level, domain/unit, capability area, product- or service area etc.).

Intersections connect the facets. Intersections are shared between adjacent facets. So the suggestion is: when observing a facet, two intersections on the edges are to be observed too. The facets are interconnected via the intersections.

Facets

Facets are the perspectives which altogether cover the whole enterprise. Faces are the lenses, through which we can zoom into details. When we change the perspective from one facet to another, and then we can observe other aspects and meaningful interconnections between the elements.

Identity Facet

Identity[1] defines what is going on in and around the enterprise [3][4]. It defines what is the mission and purpose of the enterprise, what is story and goals, and beliefs and values. Identity motivates people and drives the enterprise and all its change activities. Identity defines the fundamental, crucial, reason for being.

Identity is covering existential matters and questions: why something exists, where it comes from, where it is now, and where it is going. Identity covers the past, the present and the future of the enterprise.

The values and beliefs enterprises exhibit through their messages and actions. [3]

Experience Facet

Experience defines people’s tasks and journeys, and with which channels they interact with the products and/or services of the enterprise. The tasks define what people are doing: what are their needs, what are the jobs to be done, and what they want to achieve. Through journeys it is possible to define what are the activities, and the steps they are taking when they are achieving their tasks.

Experience is a personal view of the enterprise, which is observed from a person’s perspective, focusing on the value created for people. Experience is supported by architecture, which is needed to create products and services, which are supporting people’s tasks in their journeys.

The impact through interactions the enterprise has on people and their lives. [3]

Architecture Facet

Architecture [2] defines how the enterprise operates. How are all the parts working together in the enterprise and around it. With architecture, the enterprise is capable of producing outcomes. This is performed by business processes and assets they are using, those of which together form the capabilities of the enterprise.

Architecture realises the products and/or services of the enterprise. With architecture, the enterprise delivers its products and/or services on its promises.

The structures needed to make an enterprise operate and connect to the ecosystem. [3]

Intersections

With the intersections, the facets overlap and are interconnected. The intersections make the Facet Model complete, a coherent whole, by connecting the dots – the elements of the enterprise. With the help of the Facet Model, the enterprise can be viewed as a holistic system in which the elements are interconnected with each other, either directly or indirectly. This makes it possible to explore and analyse cause and effects, how a change in an element in one facet affects other elements in other facets via intersections.

Organisation Intersection

Organisation structure is needed so that an enterprise can perform its activities that are needed for business operations, and for realizing the products and services for serving the customers. Organisation structure defines how people are organized in units, groups or teams etc. So organisation defines how people communicate and interact with each other, and how the work and responsibilities are shared between the people.

Organisation structure defines how people are organised to perform the activities of the enterprise.

Product Intersection

Products and services are what the enterprise makes and provides to people. Products and/or services are the results of the work of the employees, those of which comprise the organisation of the enterprise. Products and/or services appear in people’s lives, as they go on their journeys when doing their tasks. Products and/or services are realized (delivered) by the architecture. It can be said the products and/or services are the reason why the architecture is needed in the first place.

Why do we need products and services? Customers have tasks to do, they have needs. Products and services are what they can use when doing their tasks. Products and services are what an enterprise provides for people’s benefit. Products and services are important because they concretize what an enterprise offers: what is the added value for customers (customer value) and value for business owners and investors (business value).

Products and services are what the enterprise makes, offers and delivers for people’s benefit

Brand Intersection

The brand represents the identity of the enterprise internally and externally in the business environment. Brand reflects the organisation’s identity in the experiences of people, in and around the enterprise. Brand is an ‘actor’ in people’s lives. It manifests the story of the enterprise and makes its identity visible. The brand is the first impression we get when we see or hear the name of the enterprise or some of its products or services. The brand is the ‘face of the enterprise’ or ‘fingerprint’ with which we can identify the enterprise.

Brand reflects the identity of an enterprise as it is perceived in people’s experience.

Identity covers existential matters and questions related to an enterprise: why something exist in the first place, where it comes from, where it is now, and where it is going? Why we do what we do? Identity defines the purpose of an entity, whether it is an enterprise or any part of it. Identity drivers the enterprise. Identity covers the past, the present and the future of an entity. Every entity has an identity, or identification, characteristics of the purpose, and reason for being. Person, organisation, system, product etc. Identity comes to life in culture. The icon, the thought bubble, referes ro what people are having their heads.

Architecture in this context, refers to business architecture, to enterprise’s operations: how it works, how the business runs in processes etc. The ‘real’ construction architecture of designing buildings is not the focus area. However, the architecture ‘house’ icon symbolises how the enterprise is structured and constructed. The Facet Model can be applied to all kinds of architectures.

Using the Facet Model

Designing the Enterprise

An enterprise is constantly changing. Everything moves, everything changes, all the time. Conditions in the business environment are continuously changing, which requires infinite intervention: change activities by managers and mandated change agents (e.g. enterprise designers).

Enterprise Design approach with the Facet Model tackles any design challenges[1] from strategic challenges to operational change challenges. This helps enterprises of all sizes to innovate and transform. The Facet Model can be used as a tool in any kind of design challenges, problems to be solved, business transformations of any kind, size and scope etc. The Facet Model can be used for asking fundamental questions: why does the enterprise exist, what is its role in people’s lives and how it is working?

The Facet Model facilitates co-design.

A design challenge is a need for change (change demand) that can be initiated or triggered by any event or change in the enterprise’s environment. A design challenge can be a problem to be solved, or a desire to make things better. A design challenge can cover any aspect of the enterprise. It can concern new business ideas or innovations, or problematic matters (e.g. complexity or inefficiency of business operations). The Facet Model can be used for reframing the challenge and asking questions in different perspectives to help enterprise designers to find better solutions. A design challenge can trigger change initiative, concept design, problem solving, innovation planning, a business transformation of any size and scope etc.

Asking Questions, Considering and Thinking Differently

The Facet Model can be used to ask questions from different perspectives and take a holistic approach when co-designing solutions.

**Figure**: The Facet Model helps people ask questions from different perspectives.

Reframing Design Challenges

Perspective switching. Reframing means changing the perspectives, thinking differently and holistically to clarify what needs to be done and why. The Facet Model can be used for reframing, thinking differently from different perspectives. The perspectives refer to facets Identity, Experience and Architecture.

Any of these perspectives be taken as a starting point, depending on the case of the initial design challenge. A challenge is what has been given to be designed.

Design Challenge is a certain matter or issue to be resolved. It can be anything from the strategic level to the operational level. For example, to “design a new digital-first strategy based on a vision”, or “define strategic goals and course of actions for business transformation”, or “plan product portfolio roadmap for digitalization”, or “consolidate complex application landscape for digital transformation” etc.

Reframing encourages co-designers to think of other aspects instead of only considering the most obvious perspective. Typically, we tend to think of the most obvious solution first [1]. However, reframing enables us to think of other ways to solve the problem. We can challenge ourselves e.g. by using the how might we (HMW) -technique to find alternative opportunities to think and do things differently.

The Facet Model can be used for asking questions from different perspectives to analysing and finding alternative designs & solutions for creating better outcomes. The facets answer to questions of why, what and how things are happening in and around the enterprise.

Holistic thinking. Reframing with the help of the Facet Model makes it possible to see the whole enterprise at once, and change the perspective for exploring the adjacent facets and/or intersections. The Facet Model broadens and inspires us to think holistically and creatively, eliminating the need for distinct ‘boxes’. The perspectives can be used in any order, according to what is appropriate in the specific case of the design challenge. With the Facet Model, we can change the thinking from the enterprise level (Identity, Architecture) to the personal level (Experience). The Facet Model helps co-designers ask the right questions to get the best insight. Such deeper questions help co-designers find the fundamental reasons and root causes behind the design challenges, which in turn leads to better designs. The Facet Model is the best available tool for reframing.

Reframing is looking at a challenge from different perspectives and thinking holistically.

Shared understanding. Different perspectives are relevant but restricted, meaningful but have limited scope (an sich). Some may focus on customer experience, some may focus on business insight, operations or organisational structures etc. However, these specialised approaches of different disciplines are somewhat overlapping: they share the same elements but use specialised terminology. Reframing the design challenges with the EDGY Facet Model helps co-designers to change perspectives, discuss, and find common, shared understanding

Our way of thinking or understanding of things can change when we shift our perspective.

Co-design

By definition, co-design is a collaborative approach to designing products, services, applications, or experiences. In co-design, stakeholders such as users, customers, designers, and other relevant parties actively participate in the design process. The goal of co-design is to ensure that the final outcome meets the actual needs and preferences of the end-users.

Enterprise Design and the Facet Model enable, encourage and facilitate co-design, which is a collaborative, conversational, coherent approach for design challenges of any kind. Co-design integrates and involves people from different disciplines (co-designers) and stakeholder groups (co-creators) to work together and speak the same language, the EDGY.

Co-design integrates co-designers to collaborate and speak the same EDGY language.

The Enterprise Design Facet Model can be used to evaluate if the enterprise is well-designed, and if is it producing well-designed outcomes, according to these principles (figure beside).

The facets can be used as ‘lenses’, in any order, through which people can get into any design challenge when co-designing. This can be done e.g. by zooming into a specific perspective first and then switching to another. This helps people to consider all the aspects at once, without covering them separately. All the elements of an enterprise are interconnected to each other, directly or indirectly, they interact simultaneously and continuously. That is why the Facet Model can help people to analyse design challenges, change their perspective and communicate when co-designing and re-designing the enterprise together.

The facets can be used as ‘lenses’, through which people can get into any design challenge.

Boost Agile*) Development. Enterprise Design is a human-centric, holistic, coherent, conversational and collaborative approach. This encourages and improves agile development, as people start discussing all the aspects right from the start together. The Enterprise Design facilitates co-design sessions at the beginning of design challenges. This shifting focus from “Big Design Up-Front” to collaborative co-design improves the overall end-to-end development and building cycle from ideas to production, as there is more time for high-value collaboration, and less need for producing documentation needed for organisational handovers and knowledge transfers. In addition, co-design increases cooperation over organsational units and silos.

*) Agility is the ability to easily and quickly respond to change. Agile methods cover a wide range of tools and methods such as Scrum, Kanban and SAFe (Scaled Agile Framework).

Co-designers. Enterprise Design involves and influences several stakeholder- and interest groups, practices, professions, and disciplines, that are communicating and/or working together as co-creators.

An example stakeholder map of co-designers, partners and other interest groups is illustrated beside. Some groups are at the heart of co-design (inner circle), and some groups are somewhat involved or influenced (middle circle), some groups are just interest groups (on the outer circle).

What. Co-design with EDGY enables a common language for different disciplines. With the same terminology, people can understand each other better.

Why. People from diverse practices and backgrounds have their focus on different areas. They have somewhat restricted views of the enterprise. Each discipline has interpretations of its own about what is important. Every group has specialised language and jargon of their own. This is causing suboptimal decisions and designs, unclear communication, inefficient knowledge sharing, general unawareness of the problems, and misunderstandings because of the different names for the same things…

How. Enterprise Design with the EDGY is a collaborative co-design approach to be applied to design challenges of any size and scope. The EDGY provides a comprehensive Facet Model, which is a useful and practical tool for changing perspectives to get the most out of the cooperation of various disciplines. The EDGY provides shared vocabulary and easy, colorful notation that everybody can understand.

EDGY provides a language that encourages specialists and experts to explore and communicate together to enable a coherent enterprise co-design.

Enterprise Design Elements

EDGY is based on four elements called Base Elements:

People
Outcome
Activity
Object

With these four base elements[1] only, it is possible to describe all (!) enterprises. Using these base elements [2], it is possible to describe any enterprise and everything that is going on in and around them in an ecosystem, with sentences like this:

People perform activities, using and creating objects to achieve outcomes

The classification of the generic base elements is inspired by the FBS (Function, Behavior, Structure) ontology.

Shapes of the elements: rounded elements are outcomes (functions), arrowed elements are activities (behavior), and square elements are objects (structures). These shapes are used in base elements, facet and intersection elements.

EDGY Base Elements

EDGY Identity Elements

EDGY Experience Elements

EDGY Architecture Elements

EDGY intersection elements: Organisation, Brand and Product Elements

EDGY Relationships

Tags and Metrics

There are two kinds of labels to add to any EDGY element: Tags and Metrics.

Tags can be used for differentiating elements of the same type. Tags can be used for depicting additional information about the elements, e.g. priorities. Several tags can be added to an element when appropriate.

Asset types can be defined according to what is appropriate and fits the specific case in context. The minimum set of types (the shortlist below, the MVP) consists of types as follows: application, system software or data. These are the most common types that are enough for 80% of the cases. It is good practice to add some of these Legend -boxes into the diagrams that contain different types of assets. The suggestion is to create context-specific common tags that are used in all the diagrams for the sake of conformity.

Metrics are quantitative and qualitative attributes of the elements, which can be depicted with colored labels. Typically the traffic light coloring is an easy way to indicate certain metrics of elements.

With metrics it is possible to add extra information to elements. Here are some examples of the legend boxes that can be added into diagrams to explain what criteria is used. A N/A (not applicable) metric can be used e.g. when we want to show to from which elements we have no information yet.

Facet and Intersection Elements pre-defined Relations

Generic and Specific Depiction

All the base elements have specialised, faceted and colored counterparts in the Facet Model. A similar basic syntax and structure (activity-object-outcome) occurs in every facet. This makes it easy to translate and shift the focus from one facet to another, as the elements are related to each other. Such correspondence elements in all the perspectives make the Facet Model consistent, which eases co-design efforts.

EDGY introduces specialized variants of the base elements. This makes the EDGY language simple to learn and use, as the same triple of elements can be found in all the facets. It is possible to use the same analogy in all the perspectives:

People perform activities, using and creating objects to achieve outcomes. [3]

From which sentence we can formulate versions such as follows:

Customers experience journeys, using channels, to achieve tasks
Organisations perform processes, using and creating assets to enable capabilities
Enterprises and its initiatives communicate stories, producing content to achieve purposes.

The same generic observations can be turned into specialized elements, whenever it is appropriate to change the perspective in a design challenge. This simplicity of the EDGY language’s syntax, and its vocabulary of limited concepts and relationships, and its small number of relation types, make the EDGY easy to learn and use, but expressive enough.

Specialisations

The core of each facet is the outcome, as the whole idea of the enterprise design is to produce well-designed outcomes. The outcome elements, Purpose, Task and Capability, are the most crucial elements, as they represent what is essential in the enterprise. The shape of the outcome element is rounded rectangle.

The behavior in the enterprise is depicted with the elements that represent activities, Story, Process and Journey. The activity is arrow shaped element.

The structural objects of the enterprise are the facet elements, Content, Channel and Asset, and also the Intersection elements Organisation, Brand and Product. The shape of the structural object element is sharp-angled rectangle.

EDGY in nutshell

EDGY is:

Simple and easy, so that everyone can quickly become familiar with its structure and meaning.
Beautiful, colorful, and aesthetically appealing and comfortable for people to work with.
Flexible enough, to leave space for people to interpret and extend it with their own elements, so they can focus on what makes the most sense in their design challenge.
Expressive, rich, broad and comprehensive enough, so that all disciplines to hook into so they can tie their specialised insights into the holistic top-level views that hold them together.
General-purpose to keep the conversations broad and to encourage more specialised languages to hook into it to provide the required specificity when needed.
Common, multi-purpose language for all the various disciplines and stakeholder groups to support collaboration, cooperation and co-design.

EDGY is a simple, beautiful, flexible but expressive general-purpose common language.

Enterprise Design Methods, Techniques, Tools and Patterns

Enterprise Design In Practice

Enterprise Design is a holistic and people-centered approach. It integrates customer-, business- and operational perspectives.

Enterprise Design covers all that is meaningful in the context of an enterprise. Here are some examples of different design disciplines done by certain professional and competence groups of people, that are incorporated in the enterprise design.

Enterprise Design practice is the cooperation and collaboration of different disciplines that work together. Enterprise Design practice is a way of organising people to provide overall design and planning support for business owners at the enterprise level. Enterprise Design practice provides service(s) such as facilitating co-design, providing tools and methods for enabling, inspiring and encouraging to ideation, innovation, analysis and concept design, as well as visualising the design with the appropriate tool(s) by using the EDGY as a common language.

**Figure**: Enterprise Design covers all the design activities within an enterprise.

Enterprise Design Perspectives

All the examples introduced here are mixing and matching together the elements of different facets and intersections of the Facet Model.

The relations between the elements help designers to catch the connections with adjacent facets or intersections. The figures on this page introduce the elements and their relations per each facet. These facet-driven models can be used as starting points for all the modelling cases, and especially for reframing design challenges.

Identity Perspective

When exploring the Identity elements Purpose, Story and Content, it is useful to include Brand– and Organisation -elements in the picture too, for getting the most extensive overview.

Experience Perspective

When exploring the Experience elements Task, Journey and Channel, it is useful to include Brand– and Product -elements in the picture too, for getting the most complementary overview of people insight.

Architecture Perspective

When exploring the Architecture elements Capability, Process and Asset, it is useful to include Organisation– and Product -elements in the picture too, for getting the most comprehensive overview.

Changing the Perspectives

Perspective switching enables us to consider other aspects than the most obvious one. Usually we tend to have a preconception, an initial idea, of how things are. We all have our mental models into which we typically set all the things what we see and experience. By changing the perspective by utilizing the Enterprise Design Facet Model as an analytical tool, we can easily shift perspective from one to another. This encourages us to consider other aspects and recognize all the impacts in the enterprise, even those we didn’t pay attention in the first place at all.

Why changing the perspective? The first impression usually tight us with our existing conceptions (because of several cognitive biases we have, such as anchoring- and confirmation bias). We typically see only one part or some parts of the whole enterprise. Sometimes we can’t see the “forest from the trees”.

It is just advantageous and practical to think differently, change the perspective and consider other aspects than the most obvious ones. This brings up new aspects, both positive and negative, and makes further decisions better. The fact is, that all the facets are involved, implicitly, anyhow, as “everything affects everything”. By reframing we can consider all the parts of the enterprise, and all the things that affect or are affected. The is holistic view of the Enterprise Design Facet Model helps with this.

The facets are interconnected via intersections:

The business purpose affects to customer experience, operations and delivery.
The customer experience is affected by identity and architecture.
The architecture exists because of the purpose and goals of the enterprise and customer needs to fulfill.

The reason for reframing can be e.g. an event that has occurred in the business environment, which has changed some conditions or circumstances. Such an occurrence can be either internal or external, either positive or negative in its effects. An occurrence can be e.g. a new disruptive technology innovation, increased/decreased market share, or decreased customer satisfaction etc. Such a reason causes the need for change in the enterprise. By reframing we can consider all the parts of the enterprise holistically – as “everything affects everything”.

The Enterprise Design Facet Model can be used as an analysis tool for perspective switching.

Reframing

By reframing with the Facet Model, we can take a holistic approach and figure out the most beneficial end results (outcomes) for the entire enterprise. Reframing involves asking questions from all perspectives to identify the behavioral or structural elements that can impact solving the initial design challenge or enable achieving the best possible outcome. Finally, everything is interconnected and related in one way or another, either directly or indirectly. The holistic approach considers all perspectives.

By utilising the Facet Model we can change perspectives and ask “how might we do this and that” from other perspectives.
By changing the perspective, we can ask other questions that take another viewpoint to the design challenge.
By asking questions from different perspectives, we can discover new solutions and potential impacts – positive or negative.

Reframing is about asking questions from all perspectives to find solutions.

The change demand in the initial brief of a design challenge typically concerns certain aspects and elements only. Matters and issues are clustered around certain preconceptions or the most obvious choices. We tend to jump straight to conclusions quickly. However, maybe the given problem is not the real problem at all, and/or the solution is not the most successful for the enterprise. When further analysing and reframing the challenge, we can observe different causes and find completely new solutions. At least, we can find other elements that affect or are affected by the initial one.

Reframing, and shifting perspectives, help us consider alternative solutions to find the best one for this specific situation, for this problem, based on the information at hand.

With the help of the Facet Model, we can view the challenge through different lenses. We can change our way of thinking and perspective, leading to a solution that might be entirely new and completely different from the first, the most obvious one. Reframing can be started from any facet or intersection, depending on the case of the initial design challenge.

Reframing forces us to change our perspective, consider other aspects, and think differently.

The Facet model can be used as an analysis model or common theoretical framework to start discussions with diverse stakeholder groups. Most people can relate to the perspectives and intersections of the Facet Model, making it a good starting point for collaboratively examining design challenges.

It is important to analyse what is really needed – behind what has been asked. To find the real needs behind the desires. By reframing with the Facet Model, we can take a holistic approach and figure out the most beneficial end results (outcomes) for the entire enterprise.

The Facet model serves as a holistic, common and general analysis model in co-design.

Reframing Pattern Examples

Example patterns using the EDGY elements to illustrate the reframing procedure.

Pattern Example 1: Reframing Identity to Experience and Architecture.

Given that a challenge is initially concerning the Identity perspective, formulated e.g. “create a vision for digital transformation”. Then reframing starts from the vision statement, which is modelled with the content element. That expresses the purpose, after which the perspective can be changed via intersections of Brand and Organisation to other perspectives a) to Experience with Tasks, and b) to Architecture with Capabilities. Finally, the offered products and/or services can be evaluated.

Pattern Example 2: Reframing Experience to Architecture and Identity.

Given that the challenge is related to the Experience perspective, the initial brief could be e.g. “design enterprise’s channel strategy for better customer experience”. Then reframing starts by identifying the channel(s), after which the tasks that customers are trying to achieve are evaluated. Then the perspective can be changed via intersections: a) Product(s) can be evaluated and then changed to the Architecture perspective to evaluate concerning capabilities; b) analyse the Brand and change to the Identity perspective and analyse the purpose(s) of the enterprise. Finally, the organisational structures can be analysed.

Pattern Example 3: Reframing Architecture to Identity and Experience.

Given that the challenge is covering the Architecture perspective, the initial design brief could be for example “consolidate complex legacy application landscape for digitalization”. Then reframing starts by identifying the application assets, from which we get into the capabilities that lead us to concerning products and organisation structures. Then we can change the perspective via these intersections. We can a) analyse purpose(s) and change to the Identity perspective. And, we can b) evaluate the tasks and change to the Experience perspective. Finally, we can end up analysing the brand of the enterprise.

Reframing with the Facet Model. Reframing can be started from any facet or intersection, from any element. The Facet Model can be used as a “checklist” for identifying all the affected adjacent elements when considering possible and potential cause-and-effect relationships.

Goal-orientation. It is always good practice to accurately formulate the need for change by setting clear goals and defining desired outcomes. To facilitate goal setting, it is practical to identify the drivers of change – what motivates us to make changes. Drivers, goals, and outcomes help clarify the challenge and provide a solid starting point for taking action. A table format can serve as a useful tool, from which a visualization can easily be created when needed.

**Figure**: Clarifying the need by 1) identifying the drivers, 2) setting the goals and 3) defining the concrete outcomes.

Business Design

Business is what an enterprise does. Typically, business is all about providing products and/or services for the benefit of customers. A business, or enterprise, is run through business operations. Business operations are the day-to-day activities that a business undertakes to produce, deliver, and manage its products or services, as well as to achieve its goals (objectives).

Understanding what customers value is a good starting point for business design. This is the customer insight, which relates to people’s experiences and the role the enterprise plays in their lives. It also relates to the identity of the enterprise, explaining why it is meaningful to people and how the enterprise runs its business operations through its architecture.

The Enterprise Design Facet Model can be used to design and describe the core business in which an enterprise operates. The Enterprise Design and the EDGY language can be applied to design what the enterprise does, how it does it, and why. All the facets and their intersections together form the enterprise’s business. Business is at the heart of the Facet Model, as shown in the figure beside.

When we design and develop the business, we address all these facets and their intersections. Conversely, when focusing on any of these facets or intersections, we are designing the enterprise’s business.

Business

What is a business all about?

A business refers to an enterprising entity or organisation comprised of people working together to achieve common goals, aligned with its identity and promises. These entities engage in commercial, industrial, public, or professional activities. Some businesses are for-profit, while others are non-profit, fulfilling a charitable mission or furthering a social cause. These promises explain why an enterprise exists and why it operates as it does, motivating and inspiring the people within the organization.
A business runs operations that produce products (items, goods) or offer services, making them available to customers (consumers, business actors, etc.). This aspect covers the structure and behavior that explains how an enterprise runs its business operations.
A business is focused on meeting the particular needs of people. This aspect defines the needs that an enterprise aims to serve, fulfill, and support.

These fundamental elements of business can be translated into the core components of the Facet Model: Purpose, Task, and Capability. Purpose defines what people believe in and strive for, Task defines what people aim to achieve, and Capability defines what the enterprise can do. These are the outcome *) elements of the facets. Business design can be simplified using these outcome elements, representing the outcome-driven view of the enterprise.

Focusing on these outcome elements when designing a business, we are:

describing the identity of the enterprise in terms of the purpose, which reflects the promises that we have stated in the form of stories and content – via the brand,
defining the architecture that is comprised of capabilities as composable business components, with which the business operations are enabled, and executed by the processes and supported by the assets and employees of the organisation, and
influencing the experience, specifically regarding tasks that represent customer needs. The experience is shaped by how well the customers’ tasks are fulfilled during their journey, as they interact with the enterprise’s products and/or services through various channels.

Business value can be created by delivering customer value on the promises of the enterprise. This simplification of the business fundamentals clarifies how the Facet Model and its core elements, the outcomes, can be used for analysing and modeling the basic essence of business.

The purpose of the business is to provide goods (products and/or services) to customers, to fulfill their needs. The figure above illustrates how business capabilities deliver value on enterprise’s promises according to customer’s needs.

The purpose of the business is to provide goods to customers, to fulfill their needs.

Business basics. Customers have task(s) to do, which are served by the products and/or services that are produced by the capabilities of the organisation, which have a clear purpose that is made visible to customers via brand.

*) Outcome elements are goals or end results that we want to achieve. An outcome is a purpose to be served, or a task to be supported, or a capability to be performed. While an output is a product or service that we create or deliver, an outcome is the actual end result, the benefit or advantage that can be achieved. An outcome is the concrete experience that we have at the end of the day. In addition, an outcome could be a demand to be served or a problem to be solved with the products or services and a set of activities. Outcome elements of the enterprise comprise the heart of business design.

Business Core. Business operations, the actual operational business, is defined by the business architecture, which defines how we run our business, and how are we produce our products and services to help customers accomplish their tasks throughout their journeys. Capabilities represent composable business components, with which the products and/or services are produced. Capabilities combine behavior and structure that belong together.

Business design is an approach to creating and improving businesses that emphasizes innovation, customer-centricity, and holistic thinking. It focuses on the strategic design of a business model, organisational structure, processes, and customer experiences to achieve better results and adapt to changing business environment (e.g. market) conditions. The goal of business design is to align a enterprise’s strategy, operations, and customer value proposition in a way that creates sustainable competitive advantages. Here are key elements and principles of business design:

Customer-Centric Approach: Business design places a strong emphasis on understanding the needs, preferences, and pain points of customers. It aims to design products, services, and experiences that meet or exceed customer expectations. Customer-centricity conretised in customer-driven design.
Design Thinking: Business design often incorporates design thinking methodologies, which involve empathy, problem-solving, and iterative prototyping to create innovative solutions. It encourages a creative and user-centered approach to business challenges.
Business Model Innovation: Business design focuses on rethinking and innovating the fundamental aspects of a business model, including revenue streams, value proposition, customer segments, distribution channels, and cost structure. Tools & methods: Business Model Canvas (BMC).
Process Optimisation: It involves analysing and optimizing business processes for efficiency and effectiveness. This can lead to cost savings, improved customer experiences, and faster time to market. Tools & methods: e.g. Lean.
Organisational Design: Business design may include redesigning the organisational structure, culture, and talent management strategies to support the desired business outcomes.
Cross-Functional Collaboration: It encourages collaboration between different departments and functions within an organisation to break down silos and ensure a holistic approach to solving business challenges. Tools & methods: co-design, Enterprise Design with EDGY.
Prototyping and Experimentation: Business design often involves creating prototypes or conducting experiments to test new ideas, strategies, and solutions before implementing them on a larger scale.
Adaptation and Resilience: Business design acknowledges the need for businesses to be adaptable and resilient in the face of changing market conditions, disruptive technologies, and other external factors.
Sustainability and Social Responsibility: Many business design approaches consider sustainability and social responsibility as integral components of a business’s strategy and operations.
Data-Driven Decision-Making: The use of data and analytics plays a significant role in business design by providing insights for informed decision-making and continuous improvement.

Business design is employed by organisations seeking to remain competitive and innovative in a rapidly changing business environment. It is often used in industries where disruption and adaptation are essential, such as technology, retail, and finance. Design thinking and human-centered design principles are often integrated into business design processes to ensure a focus on the end user and their evolving needs.

Business design from the organisation perspective, is covered by the elements shown in the high-level simplification below. Customers use products and or services, that are produced by the capabilities of the organisation.

Products and/or services are what is provided to customers.
Capabilities represent the core operations of the business: what is required for creating and delivering products and/or services, what is needed for executing the business in which the enterprise operates.
Organisation *) makes products and/or services. There is an organisation behind every product or service.
Employees belong to organisation structures, and they are acting in capabilities (to be more precise: employees are actors in the processes of capabilities, or employees play roles of certain profession, skils and competencies).

Capabilities represent the core of the business operations and delivery.

Capabilities are the basic building blocks of the business, the business DNA, Capabilities are composable business components from which the business is made of. Capabilities ‘compose together what belongs together’, e.g. processes and assets. Capabilities cover both business and IT aspects. To be more precise, capabilities are realized by processes that require assets (such as applications, data, technologies, devices or facilities etc.). Capabilities combine certain people, processes and assets, that are required so that the enterprise can do what it needs to do according to its purpose. The capability “wireframe pattern” shown below.

*) Organisation can refer to e.g. the whole enterprise, or some of its parts such as business unit, group or team.

Capabilities are composable business components.

Architecture *) in this context, refers to business architecture, which encompasses an enterprise’s operations: how everything works, how the business runs through processes, how assets are utilized, where and when, and how the organisation functions as a whole.

Business Architecture refers to an enterprise’s operations and how it runs its business. In this context, architecture primarily covers the fundamental aspects of the business: people, processes, and assets, working together as a coherent whole of interconnected behavior and structure. Business architecture encompasses everything relevant to running a business. People, processes, and assets are organised into capabilities, which are carried out by organisational structures to produce products and/or services for customers. In contrast, IT architecture focuses primarily on applications and technologies, while business architecture addresses everything meaningful from a business perspective.

*) Architecture and ‘architecture’. 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 architecture covers all that is relevant to run a business, including the alignment of people, processes, and assets to effectively produce and deliver products or services.

System Thinking

“Systems Thinking is an approach of making inferences about behavior by developing an increasingly deep understanding of underlying structure.” So it is more like a learning method of getting insight of the enterprise’s behavior and structure, both are sides of the same coin.

Behavior and Structure. A system consists of both behavior and structure. At a large scale, an enterprise (or organisation) or an ecosystem is a system.

**Figure**: A system consists of behavior and structure.

A system, such as an enterprise, exists for a reason. The reason, purpose, the outcome, the system itself, can be associated with the output(s) it produces.

A system shares the same characteristics as each of its parts, making it fractal by nature. An enterprise is a system of (sub)systems that belong together.

In the enterprise context the behavior can be associated with the stories we tell about us, it can be associated with the journeys our customers experience, or it can be associated with operational activities such as processes. Structure can be associated with organisation or assets (of type such as application, data, facility or device).

Behavior and structure in the form of the EDGY base elements (figure below).

Design Thinking

Enterprise design is heavily based on the Design Thinking approach. The relationship between enterprise design and design thinking is rooted in their shared focus on solving complex problems through a human-centered, co-creative, and iterative process.

Design Thinking is a human-centered, iterative problem-solving methodology used to innovate, develop, and refine products, services, or solutions. It emphasizes empathy with users, creativity in generating ideas, and a hands-on approach to prototyping and testing. This process helps teams focus on user needs, generate diverse solutions, and refine ideas based on real-world feedback. The core of Design Thinking is a deep understanding of the needs, behaviors, and motivations of customers (users). Solutions are designed with empathy to ensure they address real user challenges. Design Thinking encourages multidisciplinary andinterdisciplinary collaboration, bringing together diverse perspectives from different fields or areas of expertise to generate more creative and comprehensive solutions.

Enterprise Perspectives

The Enterprise Design Facet Model introduces three facets (a.k.a. perspectives) into which an enterprise can be divided. All the enterprises have these properties, so it is practical to use these facets as lenses, through which we communicate when design new things are change existing ones.

The following chapters introduce viewpoints and diagrams as examples of these facts.

Experience Examples

Experience:

The impact through interactions the enterprise has on people and their lives. [3]
How various stakeholders (customers, owners, employees) perceive and interact with the organisation and its offerings, and how these interactions influence them.
Experience covers followin concepts: Customer Experience (CX), User Experience (UX), Employee Experience (EX), Brand Experience and Operational Experience (customers & employees).
Experience van be modelled with EDGY elements Task, Journey, Channel, Brand and Product.
Intersections:
- Brand refers to collective image and reputation that an enterprise builds through consistent communication, behavior and customer experience.
- Product refers to offerings that the enterprise produces and offers: Prodcuts or Services. The EDGY Product element can be used for modelling both products and services.

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

Task: What people want to achieve and get done [3].
Journey: The events and activities people experience in their lives [3].
Channel: The means of communication between people and the enterprise [3].

Customer Perspective

Business design from the customer perspective covers elements as shown in the simplification below. EDGY provides concepts with which it is possible to visualize all that is meaningful in the context of enterprise. The customer perspective can be analysed with EDGY elements Task, Journey and Channel, which open up the important aspects from customer’s point of view. These elements cover the outside-in view of enterprise’s business. The inside-out view is then covered with the customer-facing elements Brand and Product, which are then connected to other elements of the enterprise, Capability, Organisation and Purpose.

A customer has task(s) to do that are served by the products and/or services, which are produced by the capabilities of an organisation. A customer traverses a journey (of several steps), that represents what a customer experiences while doing task(s). The customer becomes aware of products and/or services with the help of the brand of the organisation. The customer contacts the products and/or services via channels, the touchpoints.

Customers access journey steps (stages, phases) via channels when they perform their tasks. Tasks are served by the products and/or services (offerings) that require certain capabilities from the organisation.

Business value is created based on customer value, which occurs when the customer benefits from the products or services of the enterprise. So focusing on customer experience an enterprise can gain success in business.

A capability comprises all that belongs together: everything required to produce certain outputs in the form of offerings, such as products and/or services.

Customer-Centricity as a Business Strategy

Customer-centricity (or customer-centrism) is an approach where the customer is put at the center of all designs and decisions when delivering products, services and experiences to create customer satisfaction and build long-term relationships.

Customer-first is a business strategy, where the customer is at the core of the business.

Designers and design teams in the organization must stay in touch with what’s happening in the customer’s life. It is important for designers to develop awareness and understanding of the journeys customers are going through and the tasks they are trying to accomplish. All change activities within the enterprise must be subordinate to creating the best possible customer experience.

A customer-centric approach can be supported by the Facet Model by asking the right questions to prioritize designing the enterprise around customer-centrism. The ultimate goal is to provide well-designed products and services to deliver the best possible experience. This can be achieved by gaining customer insights, supported by the Facet Model and related tools, methods, and techniques.

Customer-centric Business Strategy: The customer is at the center of all designs and decisions when delivering products, services, and experiences to create customer satisfaction.

Customer Transformation

The customer transformation concept refers to the approach introducing new and imporving existing customer focused processes in an enterprise. It take advantages of data analytics to better understnd customer behavior. It also leverages on implementing digital transformation intitiatives to create more personalised and seamless customer experiences across different channels.

Customer-Focused Business Design

Customer-focused business design is putting the customer first. Taking the customer-focused perspective, we can switch the Facet Model into the position, where the experience is on the top. This underlines the customer-oriented and customer-driven approach in the overall design. The Facet Model can be used in any position according to what is appropriate depending on the specific case.

Focusing on the customer, we can look at the enterprise from the customer’s point of view. Then it is important to get an understanding of what is happening in the customer’s life. What are the tasks a customer wants to achieve, and what are the jobs to be done that he/she needs to do? Answers to these questions we get by gathering information of customers’ lives. This customer insight is crucial information that can be used when designing products and services for the customer’s benefit. Customer insight clarifies what customer experiences and behaves, and what are the actual needs behind desires.

Customer Insight, can be obtained by seeing and harvested by observing and watching and by asking and then analysing. A good practice for asking what a customer needs and how he/she behaves is to make a survey. For example, by survey, we can ask customers what the tasks are they value the most. With surveys, the enterprise gets lots of data for further analysis. With the analysed data it is easier to make a difference between real needs and desires. What customer really needs and what he/she wants, should be be distinguished from each other. Data analytics *) is an important part of service design, with which it is possible to analyse the customer-related data that is harvested. In EDGY the customer needs are represented with Task elements.

Needs and desires: Value Demand. There are always both functional needs and emotional desires. Both impact the experiences of a customer. Functional needs can be fulfilled by the right products and services. Emotional desires can be satisfied by quality when interacting with customers. Good quality in services means good customer experience as a response to the value demand **).

Customer experience is a result of many things: interactions with service providers and employees. The most important factor for the experience is the outcome that the customer gets at the end of the customer journey. The outcome can be either beneficial and valuable, or it can be disappointing. Good customer experience is what an enterprise pursues, as good customer experience creates customer value that creates business value. Poor customer experience ***) is what should be avoided, as it can cause unwanted consequences for the business and the brand. Getting feedback from customers is important for analysing what can be done even better.

Customer Journey is the path of activities during which the customer is completing tasks. Customer Journey Mapping is an important tool for matching customer’s tasks to the enterprise’s products and services. This includes the channels (touchpoints), with which the customers are interacting with the enterprise.

*) Data Analytics is a capability, that consists of specialized skills and competences, and specific tools and techniques such as Data science, machine-learning and AI. Data Analytics capability includes specific processes and assets (applications and data), provides certain products & services, that are performed and provided by particular organisation structure(s).

**) Value Demand refers to needs that trigger a Value Stream. There can be two kinds of value streams: 1) Operational Value Streams and 2) Development Value Streams. The former is customer-facing and relates to business operations of the enterprise. The latter is related for change activities of the enterprise, those of which are typically performed according to agile methods and tools such as Scrum, Kanban and SAFe, and can be organized according e.g. to ITIL4 and/or reference architectures such as IT4IT. Value streams of all kinds typically utilize Lean practices.

***) Failure Demand (see link) is a remarkable reason for poor customer experience. That occurs when customer experiences poor quality, poor service, unnecessary interactions, unfriendliness, little or no attention, gets incomplete or wrong products, wrong information etc.

Customer-focused business design is putting the customer first.

Customer Experience. Taking the customer perspective, we can utilize the Facet Model as shown in the figure below. Starting from the customer point of view, by following the relations between the enterprise elements, we can find the most relevant aspects of the business that affect the customer experience:

Customer has Task(s) to do, that he/she experiences via Channel(s) during the Journey.
Customer Journey is influenced by the Brand of the enterprise.
Customer uses the Products / Services provided by the enterprise Capabilities.
Processes and Assets of the enterprise realise capabilities.
Processes are performed by the Organisation,
Organisation has goals, mission, value propositions etc. with a story and content, which altogether constitute the Purpose of the enterprise.
The purpose of the enterprise is made visible by the Brand.
Brand influences the customer to use the Products and/or Services of the enterprise…

The customer experience is made up of all this. Everything that a customer experiences while traversing through the journey is affecting to the emotions and feelings of the customer.

As the emotions of people are subjective *), they are difficult to be altered or interfered with by anything or anybody else. However, when a customer is interacting with the enterprise, there is much that can be done to provide the best possible quality in products and services.

Getting customer insight into the customer’s life is the predominant prerequisite for all the design efforts. With customer insight, it is possible to get information about the ultimate needs of the customers. By getting the right knowledge of customers’ needs, the enterprise can focus on the right products and services at the right time, and provide the best possible customer experience.

*) Emotions are hard to get. Emotions of people are as slippery as the organisation culture. Both are somewhat emergent by their nature. They are like shadows what we see, but we can’t touch them. Such an intangible things are difficult to design, compared to many other concrete tangible objects or activities that can be defined in detail. Emotions or culture cannot be directly altered or changed, but they can be indirectly affected by the design efforts. A dilemma is: a single product or service can cause thousands of emotions. So, there is this ‘circular reasoning’: experience is experience. Subjective experience refers to the emotional and cognitive impact of a human experience. However, with well-designed products and services an enterprise can produce good customer experience. Products and services can be well-designed by co-design, and supported by combination of customer insight and business insight.

Good customer experience is the result of well-designed products and services.

**Figure**: The Facet model as a tool for business analyses.

Customer-Centric Model

A customer-centric model is a business approach that prioritizes the needs, expectations, and satisfaction of the customer in every aspect of an organisation’s operations, from product development to marketing, sales, and service. Instead of focusing solely on products or services or internal processes, a customer-centric organisation places the customer at the center of all decisions and actions, aiming to create value and long-term relationships.

Customer-centrism leads to customer-driven business is that focuses its strategies, products, services, and processes primarily around the needs, wants, and feedback of its customers. In this model, the business adapts and evolves based on customer input and behavior, with the goal of delivering value, fostering customer loyalty, and staying competitive in the market.

Customer-Centric Business:

Proactive, holistic, and long-term relationship-focused.

Customer-Driven Business:

Reactive, adaptive, and focused on immediate customer feedback and demands.

Both approaches aim to put the customer first and improve customer experience (satisfaction). They both emphasize the importance of listening to customers and delivering value based on their needs and preferences.

Many customer-centric businesses are succesful, as they consistently focus on customer satisfaction and innovation driven by user feedback. By embracing a customer-centric model, businesses not only improve their customer relations but also drive sustainable growth and long-term success.

Customer Engagement Model

Customer-centric business model, Customer Engagement Model, enhances the traditional business model concept by focusing on customer *). Whereas the business model refers to the way in which an enterprise creates value for its stakeholders, the customer engagement model encompasses all the aspects and various elements with which an enterprise creates value to its customers via offerings (products and/or services). And when creating customer value with the offerings, the enterprise generates also business value. So the fundamental pardigm shift is related to the focus switching from organisation to customer. From inside-out thinking to outside-in thinking.

*) Hänti, Sirpa, Asiakkaista ansaintaan – Asiakaskeskeinen liiketoimintamalli, Alma Talent 2021.

The customer-centrism is a stratigic choice taken by the enterprise, which puts the customer as a focal entity in all the business decisions, as well as in the operational business. Consequently, this customer engagement model forces to customer-driven design & development, where the customer needs are the basis for all the change intiatives and activities in the enterprise. The basic principle is “customer first”, from which all the other principles are derived and subordinated from. Principels are as shown in the figure below.

Customer Insight and Business Insight: 1 + 1 > 2.

Think Big. Customer insight serves better the enterprise when used in conjunction with business insight – and business foresight. The most comprehensive insight can be accomplished when using these in-depth areas of knowledge together as a combined approach. This can be achieved by using the Facet Model, as its facets cover all the relevant aspects and all that is meaningful in the context of enterprises: people and their needs, existential purpose and story of promises, and operational abilities to deliver on promises.

Start Small. Take the most familiar perspective as a catalyst and then extend that with elements of other perspectives. Use the Facet Model as a map. Navigate to other territories with a curious and open mind. Take the changes *). Think differently. Change perspective. Discuss and learn with others. Calibrate your tools and methods with other disciplines. Discoveries and opportunities will soon appear.

*) Take the changes. ”Chance Favors The Prepared Mind”. When you are curious and open to new ideas, when you appreciate different professions and their opinions, when you are ready to change your perspective and perception, then you can learn and find new things and get better in what you do.

Take the holistic view. The fact is that there is this only enterprise that we have, so why not design it all together in a holistic way? It is just reasonable to create a shared understanding of the entire enterprise, and not just an aspect of it. It is unwise to observe and develop the enterprise within separate practices. It is not the most optimal way to do things within many distinct groups of people with the ways of their own. Those various disciplines produce inconsistent, somewhat overlapping, and slightly contractionary outputs and outcomes. This causes unnecessary misconceptions and ineffectiveness on a large scale. Instead, utilise the enterprise design approach with the Facet Model and take the holistic view. Take into account all the aspects and factors at once, so that nothing has to be added to the picture afterward.

Co-design. Take the holistic view by co-designing. Experience matters and Services are not exclusive areas of Service Designers only. Respectively, architecture is not the property of architects only, not mention IT. Instead, both experience and architecture are subjects that have synergy, so they’d better be done together, in combination.

Produce a coherent, holistic single source of truth in co-design with the help of the Facet Model.

Customer View and Organisation View

When customer meets the organisation, it is the moment of truth for the enterprise: customer needs should be fulfilled with the offerings, the products and/or services. This is the “normal, healthy” value demand that arises from the customer needs (tasks, jobs-to-be-done).

Customer gets information about the offerings the organisation by the brand communication.

Business-related design challenges can be analysed e.g. a) from the customer view or b) from the organisation view.

Customer has task(s) to do,
which are supported and served by the products and/or services,
that are produced by the capabilities
of the organisation,
that have a purpose
which is manifested by the brand
to the customers.

EDGY helps to take the holistic view of an enterprise by combining experience, identity and architecture perspectives, which is a practical approach to take into account both the customer and organisation viewpoints at the same time.

Customer Journey

Customer journeys are focal points of customer-centric enterprises. A customer journey is a specialisation of a journey, which expresses what people go through in their lives: what a person feels, does or experiences over time. A journey represents a ‘slice of life’. It is a chronological and simplified representation of complex experiences. [4]

A customer journey is an end-to-end process that a customer is going through while accomplishing some task(s). A customer journey represents a coherent whole from the customer perspective in a certain context. It is a completeness that is meaningful to examine as a coherent whole.

A journey consists of events and activities people experience in their lives. [3]

Journey Steps. A customer journey consists of a series of activities, journey steps, that a customer is taking when accomplishing certain task(s). Those journey steps represent events and activities a customer experiences and does during the journey. With journey steps, it is possible to make visible what a customer feels, does or experiences when trying to accomplish a task.

Customer Experience. The definite customer experience is an aggregation, combined influence, of all the journey steps of the customer journey. In addition, the customer experience is influenced, not only by moments in the customer journey, but also by the brand of the enterprise, and all the contacts and interactions with the enterprise, as well as all the marketing and media content that reach the customer. Customer experience can be divided into the following hierarchical levels: 1) functional, 2) emotional and 3) purposes.

Customer Value refers to the perceived benefit or worth that a customer derives from the enterprise’s products or services. By focusing on the customer, adopting a customer-centric approach, and encouraging customer-driven design and development, an enterprise prioritises customer value according to the customer-first principle.

Touchpoints. The journey steps can consist of touchpoints, service moments, with the enterprise. These touchpoints can be associated with channels, which represent the interactions with the products and/or services provided by the enterprise.

Tasks. The purpose of a customer journey is to accomplish some task(s). There can be an ultimate task that a customer wants to achieve, and several sub-tasks on the intermediate steps of the journey. Serving those tasks makes the customer journey interesting from the enterprise’s point of view. The tasks represent the needs of a customer. The enterprise tries to fulfill the customer’s needs by providing services and/or products.

**Figure**: Customer Journey mapping to tasks via channels.

On the journey and for the tasks customers use products and/or services provided by the enterprise. Products and/or services are “what an enterprise makes, offers and delivers for people’s benefit.” A customer journey visualisation can be enriched with the services and/or products that are serving the tasks as shown in the figure below.

**Figure**: Products and/or services serves the tasks on the journey.

**Figure**: Customer Journey mapping to products/services.

Customer Journey Analysis

The customer journey can be analysed in more detail by identifying all the tasks associated with each step of the journey. In this approach, tasks are identified and visualised from the bottom up, while the journey is read from left to right.

Customer Journey Map

Mapping is matching. Matching parts together. Like matching actors to roles, people to profiles (skills & competencies), or tasks to products. This view can be used for positioning customer tasks (a.k.a. customer needs) in line with products and/or services the enterprise offers. With this analysis, it is possible to find opportunities for possible new products/services.

An example customer journey mapping shown below.

Customer Journey Management (CJM)

Customer journey management refers to the strategic process of understanding, optimizing, and managing the end-to-end experience of customers as they interact with the enterprise and its brand across various touchpoints and channels. Customer journey management is the process of optimizing the experience of customers have with enterprise’s brand.

Customer Tasks

Customer-oriented design can be started by analysing the customer needs a.k.a. tasks. Tasks are whatever a customer wants to do. Tasks are the customer’s ‘jobs to be done’. Tasks can be e.g. functional or emotional, they can be high-level and long-term tasks, or low-level and short-term tasks.

Tasks can be harvested e.g. with surveys, or just observing and interviewing the customers. When the tasks are harvested, they can be grouped for further analysis. When visualized, top tasks can be color-coded so that they can be easily recognized. Top tasks are the most important tasks for the customers, from which they gain the most benefit. From the enterprise’s point of view, top tasks are the tasks to which to focus and put effort – for to enable the best possible customer experience.

Tasks are what people want to achieve and get done. [3]

Top Tasks

According to the book Top Tasks by Gerry McGovern, a basic pattern can be identified when analysing tasks that customers want to accomplish. Tasks can be distinguished between top and tiny tasks based on their customer importance.

Top task survey – Asking customers what they want with a survey. If we ask customers by survey what tasks they value the most important to get done, there is a pattern that can be observed. According to that, there can be found four (4) categories of tasks, 25% of the votes each:

Top Tasks (25%), few tasks of them all (e.g. 2-3) really matter to customers,
Important Tasks (25%), a small amount of all tasks (e.g. 5-10), that are meaningful to customers, they appreciate getting them done
Medium Tasks (25%), quite meaningful and important, but not highly prioritized by customers
Tiny Tasks (25%), there are plenty of small tasks, not as meaningful to customers as to enterprise.

These are typical answers from customers when they value a given list of tasks.

Top tasks are the most important, primary, top priority long-term tasks, the ’must’ tasks, from which customers get the most benefit, jobs that they want to get done. Top tasks affect the most customer experience and customer satisfaction. Finding these top tasks, focusing, designing and investing in them, the enterprise advantages the most.
Medium tasks are important, and highly valued by the customers, but not the absolute necessary jobs to get done. Customers appreciate them and they are meaningful, but not the highest priority tasks.
Small tasks are special tasks, quite meaningful but may not be necessary, perhaps nice to get done alongside the top or important tasks.
Tiny tasks are small low-level tasks, that are not so important to customers as they are for certain people inside the enterprise.

Service Blueprint

The service blueprint defines a customer journey of customer’s activities together with the services and/or products and activities of the enterprise. The service blueprint is one of the most comprehensive customer-driven visualisations. There are many variations of them. The main idea is to show what is the customer doing while trying to accomplish task(s), and how is he/she served by the enterprise. As such, a service blueprint combines a) customer experience in the form of the journey with b) the task(s) to be accomplished, c) the products and/or services, provided by the enterprise, and d) the back-office processes and e) supporting applications.

A service blueprint is based on a customer journey that is a ‘timeline’ of customer experiences. The customer journey of a service blueprint can be divided into periods as follows: 1) Pre-Service Period, 2) Service Period and 3) Post-Service Period.

This simple division into phases makes the overall service blueprint easier to understand and designed. This helps understanding a) what are the customer actions and needs before the decision to get into the service, b) what are the main needs within the service, and c) what is important for the customer aftter the service.

A service blueprint is visualised as a layered structure, where the customer actions and needs are introduced on top layers, and organisation’s actions are introduced on the bottom layers. The service layer is visualised in between the customer and organisation activities. Note! There is no typical or ‘standard’ service blueprint with commonly agreed terminology and visualization. Instead, there are many variations of it, some of which are shown here.

Simple basic structure shown below.

Basic structure shown below.

Note! There is no typical or ‘standard’ service blueprint with commonly agreed terminology and visualization. Instead, there are many variations of it, some of which are shown here. An example of the Service Blueprint elements is introduced here (below).

Service Blueprint examples below.

Organisation structures can be added to the service blueprint diagram (as swimlines) as shown below.

Service Blueprints can be used to define customer activities in contrast to the company’s activities, and to map customer needs (tasks) against the products and/or services provided by the company. Additionally, they make visible what happens behind the scenes of these products and/or services: the back-end processes, the parts of the organization involved, and the supporting applications.

Capabilities can be used as higher-level back-stage elements. Whether to use process or capability elements in the back stage depends on the level of abstraction, which in turn depends on the specific case and what is appropriate for the purpose.

Service Blueprint can contain an extra top layer (green) for defining high-level business story such as value propositions.

Service Bluperint elements are introduced in the table below.

The elements to be used depend on the case and what is appropriate to fit the purpose.

Service Blueprint can be specified with 1) pre-service- , 2) service- and 3) post-service periods as shown below.

Channels

Channels play an important role in serving the customers. Channels are the touchpoints via which the customers interact with the services of the enterprise. Channels can be visualized on a map and then introduced in more detail e.g. in a table.

Channels (as any other elements) can be listed in the table format, based on which the visualisation can be done easily.

Channels are the means people use to engage and interact with us. [3]

Product and Service Offerings

Enterprise offerings can be made visible within the Product/Service Map. It consists of products and/or services organized into hierarchies.

Products and services can be described in a table (example below) together with the map diagram.

When identified, products and/or services can be used to map customers’ needs (Tasks) to the enterprise’s offerings, e.g. in service blueprints. Then it is possible to analyse do we already have the right products and/or services to help customers accomplish their tasks, or whether should we design new or better products and/or services.

Products and/or services can be visualized in a map with metrics of certain criteria, such as customer satisfaction results as shown the figure below.

Product and/or Service

A product and/or service is what we make, offer and deliver for people’s benefit [3]. As such, a product and/or service is what an enterprise (or some of its part) provides to its customers. When modelling an enterprise’s behavior and structure either from the customer perspective or from the organisation perspective, we can use the Product element.

EDGY is a simple language, and the same element can be used for these purposes: to represent both tangible products and intangible services. However, there are differences between a product and a service. When a product is provided, the ownership is changed for e.g. money. When a service is provided, it is done within the interaction of the customer and the service provider. Some characteristics and differences between products and services are introduced in the table below.

Product and/or Service is what an enterprise makes, offers and delivers for people’s benefit.

Service Design

Service Design is a human-centric approach that focuses on services. The main focus is on the customer that uses the services (or products) of the enterprise. It can be said that a service comes alive when there is a customer that uses it. In addition, the customer, there are typically people from the enterprise, the employees, that provide the service. As such a service is an interaction between the customer and the employees.

Interaction between the customer and the service provider is crucial in services.

Service (and product) is what the enterprise makes and provides to customers. Services appear in people’s lives, as they go on their journeys when doing their tasks. Services are realized (delivered) by the operations (business architecture) of the enterprise. Services are what the customers can use when doing their tasks. Services are what an enterprise provides for people’s benefit.

Organisation. Behind every service, there is an organisation that produces the service. Depending on the business area, there are pure service organisations, and some product-oriented organisations. Quite typically there exists both products and services in the offerings of an anterprise. A typical service organisation (such as a consultancy firm) provides specialist services.

Offerings (products / services) are produced by an organisation.

Services are what the enterprise makes and provides to customers’ benefit.

Behind every service, there is an organisation that produces the service.

Service scene. According to theater analogy, customers see what is on the stage, the front stage. Customers can’t see what happens on the backstage, where are the supporting processes, people and assets with which the enterprise performs its services.

All the design should be driven by the goals. From the strategic goals at high-level, and from the operational business goals at detailed level.

Service Design starts from the customer perspective. The “wireframe model” figure below illustrates how a customer is informed by the brand what products or services can be used for performing the tasks.

Enterprise Design approach is human-centric as shown in the figure below.

EDGY people-centric — **Figure**: Enterprise Design is people-centric.

Service design covers the majority of enterprise elements as shown below. There is an infinite loop of dependencies between elements, “as everything affects everything else”.

Service Design aspects: focus on front stage, but covers also the back stage.

Use Case and User Story – revisited

Use cases and user stories are both techniques used in software development and systems design to capture and describe functional requirements from the perspective of end users. Use Case is an earlier technique, and User Story came popular in the age of agile methods.

**Figure**: Use Case and/or User Story with the EDGY elements *People* and *Task*.

Use cases are indeed an earlier technique, originating in the 1980s and 1990s as part of more structured, traditional software development approaches like UML (Unified Modeling Language). They provide detailed scenarios that describe how a user interacts with a system (an application) to achieve a goal.

User stories, on the other hand, gained popularity with the rise of agile methodologies, particularly after the early 2000s. They are simpler and more flexible than use cases, designed to encourage collaboration and iterative development. Agile teams use user stories to capture short, high-level descriptions of features or functions from the user’s perspective.

Both focuses on the user as a doer, typically against a system (an application) which is under construction. So they are both focused on system development. End users can be considered as customers of the system. Therefore we can take the customer perspective and think that the use cases or user stories are tasks of a customer. Accordingly, as shown below, we can model the use cases or user stories with the EDGY.

**Figure**: User task diagram / Use Case Diagram.

With EDGY it is possible to illustrate user tasks when using an application as shown below. Tasks are customer or end user needs, jobs they want to get done. Those can represent the use cases as user’s functional requirements towards an application are close to the tasks that a user wants to get done with the application.

EDGY Task elements represent both use cases and user stories, modeled with a simple, easy, and visually elegant graphical notation. The description of a Task should be kept short and compact, simply defining what the user wants to accomplish.

The EDGY Task element is by definition: “What people want to achieve and get done.” [3]

EDGY elements People, Task, and Asset can be used for modeling a whole sentence in simple terms that explains both use cases and user stories in a visual format, as shown in the figure above. This reflects how EDGY elements can visually represent key components of both use cases and user stories, breaking them down into roles (People), actions (Task), and tools or systems involved (Application), to create an easy-to-understand visual representation of functional requirements.

In addition, we can formulate more detailed sentences with the EDGY base elements whenever appropriate as shown below.

**Figure**: EDGY elements can be used for modelling sentences.

An Use Case is typically defined in structured document e.g. as follows:

Name of the Use Case, ID, Description
Actor, who is the user, what is the role of the user
Precondition(s)
Steps (main course, happy day scenario)
Postcondition(s)
Alternative steps
Exceptions

An User Strory is typically defined as a sentence as follows:

“As a <role>, I want to <action>, so that <outcome>”

An example:

As an author of an article I want to publish my data set, so that it can be found and cited by other researchers”

Customer Segment Map

Customer segments (or personas) can be identified and introduced in a customer segment map. This is a segmented representation that can be added with certain semantics: sizes of pies, and extra markings of certain criteria (such as importance, volume, costs etc.).

Stakeholder Map

A stakeholder map (a.k.a. People Map) can be defined e.g. for the enterprise, or some of its parts, such as for business area or product-/service area. A typical stakeholder map consists of circles (like an onion), starting from the ‘core’ (inner circle), and then introducing other levels of stakeholders in other circles.

Identified stakeholders can be placed into a stakeholder map that can be visualized a) from the customer perspective or b) from the organisation perspective. The former is focused on the customer and the latter is focused on the target organisation.

The customer perspective puts the customer in the middle, and other stakeholders into circles depending on their visibility from the customer’s point of view.

**Figure**: Stakeholder Map pattern – Customer perspective.

The organisation perspective is taken from the target organisation point of view. The target organisation is performing certain behavior and producing products and/or services with partners to customers.

Flat format. To save space we can squeeze the circles into a tighter form as shown in the figures below. An A4 landscape format fits better into laptop screens, with which we typically work in co-design sessions.

Example version 2 is partitioned in groups 1) organisation, 2) partners and 3) customers.

**Figure**: Stakeholder Map – Organisation perspective.

**Figure**: Intersection Group organisation (Stakeholder Map).

Identity Examples

Identity:

“The values and beliefs enterprises exhibit through their messages and actions.” [3]
Identity is concretised in the purpose.
Identity refers to mission, vision, strategy and goals of an enterprise.
Identity answers to fundamental WHY questions of an enterprise:
- Why does our enterprise exist? Why is our behavior / business meaningful?
- Why we do what we do?
- What matters to us?
- What is our purpose? What is our mission? What is our vision?
- What is our strategy? What are our goals?
- What we make and offer? What is our story? Who are we?
Identity can be modelled with the EDGY elements Purpose, Content, Story, Brand and Organisation.

In the enterprise context, identity refers to the unique characteristics, values, mission, vision, culture, and overall brand that define an organisation. It is the essence of what the enterprise stands for, what it aims to achieve, and how it is perceived both internally by employees and externally by customers, partners, and the broader market.

Key elements of an enterprise’s identity include:

Mission: The purpose of the organisation – why it exists and what it aims to accomplish.
Vision: The long-term goals or aspirations that guide the enterprise’s strategic direction.
Values: The core beliefs and ideals that drive decision-making and behavior within the organisation. They reflect what the organisation stands for and what it prioritizes in its operations and interactions. Values represent heaviliy the WHY.
Principles: The specific guidelines or rules that direct how the organisation operates in practice. They are derived from the organisation’s values and provide more concrete instructions on how to act in various situations. Principles represent the HOW, as they operationalises values in daily practices. They translate values into actionable standards, expectations, and finally into change requirements.
Culture: The shared attitudes, practices, and norms that shape how people within the organisation interact and work together.
Brand: The perception of the organisation, shaped by how it presents itself to external customers, the market, and the public.

An enterprise’s identity is crucial because it influences how stakeholders (employees, customers, partners, etc.) perceive and engage with the organisation. It also plays a key role in guiding strategic decisions, maintaining consistency in messaging and actions, and building trust and loyalty among stakeholders.

Identity reflect what the organisation stands for and what it prioritizes in its operations and interactions.

Identity View

The identity of an enterprise can be simplified with the elements shown below.

**Figure**: Identity elements of an Enterprise.

Identity expresses why an endeavour or entity (such as an enterprise, organisation or an unit) exists. Identity refers to the existential question of why. Identity defines why something is important, why we should care about it, and why it exists in the first place.

Identity elements can be used for analysing the reasons why, all the existential and deeper questions to clarify what actually matters.

With identity elements (purpose, story and content) and related intersection elements (brand and organisation), it is possible to focus on both of these aspects:

people, and describe the message around people’s purpose and reason for being, or
behavior, the business reason of activities that people do.

Identity clarifies all that is important to understand ‘why we do what we do’. The identity can be co-designed by people who are involved, by using these elements shown below. The example below starts with the topic, and the brand of the subject matter (e.g. entity, change initiative etc.). Then its purpose [1] is introduced with the story and content. And finally, the organisation involved is introduced. These elements reflect the identity perspective and its intersections. Note that the people dimension is strongly emphasised in sentences: “we are, we exist, we do” etc., as the Enterprise Design approach is especially people-centric.

*) Purpose essentials – the fundamental questions. Naïve question goes ‘what is the meaning of life’. This philosophical question cannot be answered with rational, scientific method-based arguments, as the question is absurd. We cannot define what is the deepest meaning or purpose of existence itself (an sich), or what is the intrinsic value of life. Or in a cosmological perspective, ‘why the cosmos bothers to exist at all in the first place’, is something that we don’t know. What we can do, instead, is to clarify the purpose of an entity such as an enterprise. We can state a purposeful meaning by using the Facet Model Identity elements as tools. It is possible to define and visualize what is important in the context of an enterprise.

Identity view use cases are e.g. as follows:

Identity and purpose of an entity or its part (e.g. enterprise, ecosystem, organisation, business unit, group, team).
Identity and purpose of a group of people working together.
Purpose and idea behind a change activity or -initiative (e.g. business transformation, concept, innovation etc.)

Identity clarifies “‘why we do what we do’.

Enterprise Analysis Levels

Enterprise and its behavior can be analysed in different levels from purpose to operations.

The identity, the purpose, forms the basic idea of the business in which an enterprise operates: the mission and vision.
The strategy level defines the goals and actions to be taken towards the vision.
The business model defines how the enterprise creates value, what are the value propositions and to whom enterprise provides its products and/or services – who and what are the customers (people and/ or organisations).
The operating model defines how the enterprise operates: what are the capabilities required for creating and delivering the offerings (products and/or services), with which processes and assets business is running.

Operational business (business operations) is defined by the operating model. Operating model defines how an enterprise is operates daily-basis. The operating model is derived from the business model, that is higher level representation of how an enterprise creates value.

Mission, Vision, Values, Strategy

The organisation’s mission, vision and values can be expressed, in written format or in visualisation. However, it should be considered if the identity visualization, as illustrated in the previous figure above, can be adequate enough. It can be the most appropriate way to communicate the organisation’s purpose, mission, and future vision and related values within a single visualization, what we can call simply the ‘identity’. The identity covers all that is important and meaningful in the context of an organisation: mission, vision, values etc.

Mission and vision both relate to an organisation’s purpose. They are typically communicated in some written form.

Mission statement communicates the organisation’s reason for being. Mission answers questions about ‘why we exist’.
Vision statement, in contrast, is a future-oriented declaration of the organisation’s aspirations. Vision is based on the mission. Vision answers questions about ‘where are we going’, ‘where do we want to be’, and ‘what we want to become’.
The strategy follows the vision statement, and the strategy aims to satisfy the mission. Strategy answers questions about ‘how we will achieve our vision’.

Which EDGY elements to use for modelling the Mission: Purpose or Content?

Depends on the case and what is appropriate to fit the purpose.
Purpose -element, an outcome, to represent why an enterprise is there for, what is its “outcome” for the business environment or society etc.
Content -element can be used when the mission can be understood as a sentence only, just a content of the deeper purpose of an enterprise.

Which EDGY elements to use for modelling the Vision: Purpose or Content?

Depends on the case and what is appropriate to fit the purpose.
Purpose -element, an outcome, to represent what an enterprise wants to be, what is the desired “outcome” for the business environment or society etc.
Content -element can be used when the vision can be understood as a sentence only, a content of the strategy of an enterprise.

I’d suggest using the Purpose -element for modelling the mission and vision.

The figure below illustrates the relations between the mission, strategy and vision. A roadmap is the actual course of actions to be taken to achieve the outcomes.

**Figure**: Figure 107: Mission, Strategy, Vision, and Roadmap.

The mission is the purpose why an enterprise exists in the first place – the reason for being. The vision is the future state that an enterprise wants to achieve. The strategy is the course of actions to be taken toward the vision.

The strategy is like a playbook, explaining how we play, what moves we make, and according to which values and principles. The roadmap is a detailed plan of when we do actions and what are the resulting outcomes.

Strategy execution can be started by identifying high-level goals, from which the more detailed operational-level goals can be derived. After goal setting, it is possible to define concrete actions to be taken to achieve actual end results [1]. It is suggested that the results can be measured so that it is possible to control the progress of the strategy. According to Peter Drucker: “You can’t manage what can’t measure”.

[1] End results are rather outcomes than outputs. Outcome-driven approach produces traceable deliverables according to the purpose of the enterprise.

Values are typically identified and made visible to guide decision-making and people’s working in an enterprise. Values can be communicated and visualized in conjunction with the mission and vision statements. In addition to the high-level guidance, the enterprise-level principles can be defined. Principles direct all the change activities in the enterprise to follow certain guidelines, in line with the values, to control and support people in design, development, decision-making and operations.

Values guide cultural behavior and design in an enterprise context. Values affect overall development principles in an enterprise and requirements for development initiatives (such as programs, projects, business transformations etc.).

**Figure**: Values, Principles and Requirements.

An example one-pager with concise mission, vision, strategy statements, values, and goals for an enterprise that provides IT services to local customers.

Purpose one-pager — **Figure**: Example one-pager of mission, vision, strategy and values.

Note! A visual-textual representation combines visual elements (such as EDGY elements and icons) with textual information to communicate information more effectively. This type of representation merges visuals and text to provide context, clarify complex content, or enhance understanding by appealing to both visual and verbal processing. Visualisation makes the content easier to absorb and understand.

Goals

It is suggested that the goals define the qualitative changes, which can be measured by outcomes. The outcomes represent the actual achievements and are the end results of the goals.

An enterprise should have clear goals to guide its direction. If changes are needed, the goals define the specific changes we want to achieve.

For the sake of simplicity, it is suggested that there are 1) high-level strategic goals and 2) detailed operational goals. The strategic goals define why we want to change, and the operational goals define how we are going to change. The questions why and how are sufficient to specify the emotional and functional aspects that can be communicated to the people involved. This provides direction and concreteness. Once these are made clear, more detailed courses of action can be defined in the form of concrete outcomes and activities. These can be further specified within strategic plans, execution or action plans, or roadmaps.

All changes in the enterprise should be derived from the business goals, as these define the changes we aim to achieve. It is important that the goals are traceable both to (a) customer needs and (b) operational capabilities.

A goals hierarchy refers to the structure of goals in a way that illustrates their relationships and priorities. This often involves breaking down high-level, broad goals into smaller, more specific objectives that contribute to achieving the larger goals. A goals hierarchy can typically be divided into the following levels, although it may be too complex for most cases: 1) Ultimate Goals (Top level), 2) Strategic Goals (Mid-level), 3) Operational Goals (Lower-Mid level), and 4) Tactical Goals (Bottom level).

Goal Map

Goals hierarchy can be visualized as shown below. Goals can be defined at high-level and operational level.

High-level goals are usually emotional, whereas operational-level goals are functional by their nature. We can also break the goals into conventional categories of strategic-, tactical- and operational goals when appropriate.

Strategic Goals

Strategic goals are high-level goals that an enterprise want to achieve.

The strategic goals represent what needs to be changed in the enterprise in the big picture.

Note! Goals are not strategy, but course of actions. Strategy can be directed by breaking it into clearly defined goals.

Goal Analysis

It is always good practice to define the goals first, at least at a high-level, before starting to do anything. Goals express what we try to achieve. However, to be more precise, it is reasonable to evaluate why something needs to be done, before getting into details about what exactly needs to be done. So it is practical to identify the drivers before the goals. That procedure makes it easier to find and define the goals, as drivers are the causes of the goals. By collaboratively discussing the reasons and business conditions, it is possible to find the root cause(s) for the change.

The why can be analysed by identifying the drivers for change: what drives us (to do changes)? The drivers can then be further analysed, and then defined in terms of goals. The goals are qualitative changes to be made because of the drivers. And finally, the concrete, measurable achievements, the outcomes, can be specified. Those are the actual changes that are to be happening in the enterprise. (The steps to be taken to implement the outcomes, and the activities, are to be further defined.)

The drivers, goals and outcomes can be identified in a table as shown below, and/or modelled with EDGY outcome and purpose elements as shown below.

**Figure**: Drivers, goals and outcomes can be modelled and/or defined in a table.

Causality and Determinism. It can be said that in enterprise, organisational and business context, there is typically, if not always, a cause (reason, driver) for a goal. That is why it is advantageous to first clarify the drivers: what drives us to achieve change. In addition, most events (and phenomena) in a business environment happen for some reason – according to causality and deterministic thinking.

Causality refers to the relationship between cause and effect. It is the principle that an event (the cause) leads to another event (the effect), where the effect is a consequence of the cause
Determinism:all events, including human actions, are determined by previously existing causes.

Cause and effect. Causal relation between causes and effects. A cause can be a driver that forces us to do some change(s). An effect can be e.g. a goal that we set.

Determinism is a causal chain of events.

Goal-driven design / Design by Goals. All the designs shall be derived from the goals of the enterprise. The high-level strategic goals and detailed operational-level goals can be further specified into measurable goals or outcomes. There have to be connection and traceability between the goals and designs in both directions. Otherwise either the goals can be disconnected from the operational reality and change activities, or the designs can be disconnected from the enterprise’s goals.

Goal analysis can be defined in more detail as shown below.

**Figure**: From drivers to requirements.

Finally, all the changes are directed towards business operations, operational business, that consists of capabilities. As such, all the changes can be traced to certain capabilities. Effectively, this means that a practical principle for business changes is the capability first -principle. In practice, this means that the capability map is a good starting point when analysing the effects of goals.

**Figure**: From drivers to operations: “all roads lead to capabilities”.

Strategic Planning

Strategic planning (or strategy planning) is a process through which an enterprise defines its long-term goals, establishes the actions necessary to achieve those goals, and allocates resources to execute the plan. It involves setting a direction for the enterprise and determining how to best pursue future opportunities and tackle potential challenges. Strategic planning focuses on making decisions that guide the enterprise toward achieving its vision.

Strategy planning typically led by top-level (C-level) management but involves input from various parts of the enterprise. The primary goal of strategic planning is to provide a roadmap for adaptation to changing business environment (such as market) conditions, and efficient use of resources.

Elements of Strategic Planning:

Mission: The purpose of the enterprise – what it aims to achieve.
Vision: The long-term goal or desired future state of the organization.
Goals: Specific, measurable targets that align with the mission and vision.
Values and Principles: guide the enterprise’s behaviors and decision-making.
Strategies: Broad approaches or methods for achieving the set goals.
Action Plans: Detailed steps, timelines, and responsibilities for implementing the strategies.
Resource Allocation: Deciding how to allocate financial, human, and physical resources to support the strategies.
Measurements: Key Performance Indicators (KPIs) to measure progress.
Risk Management: Identify and mitigate potential enterprise risks.
Monitoring: Evaluating progress and making necessary adjustments.

Strategic planning is making choices and decisions to achieve the enterprise’s vision.

The timeframe of a strategy can vary depending on the enterprise’s goals, industry, and the nature of the strategy itself. However, strategy is generally focused on long-term planning, typically spanning several years. Long-term strategies typically cover 3 to 5+ years, focusing on achieving the enterprise’s overall vision and high-level goals. Medium-term strategies generally cover 1 to 3 years, focusing on implementing significant initiatives that support long-term goals. Short-term strategies cover a timeframe of 6 months to 1 year, focusing on immediate priorities, operational goals, and tactical actions.

Even though strategies typically have a long-term focus, enterprises often review and adjust their strategies on a yearly or quarterly basis. This allows them to stay responsive to changes in the business environment, technology, or internal factors.

How to define a strategy?

A well-defined strategy answers key questions about the enterprise’s future direction:

Where are we now? (Current state analysis about the mission)
Where do we want to be? (Vision, long-term goals)
How will we get there? (Strategic choices and actions)
What capabilities and resources do we need? (Capability assessment and resource allocation)
How do we measure performance and success? (Key performance indicators)

Steps for strategy planning:

Current state analysis: Assess the Current Situation with the tools such as the plain old SWOT analysis (Strengths, Weaknesses, Opportunities, Threats), which helps in understanding the internal and external factors affecting the enterprise.
Clarify Mission, Vision, and Values: Ensure that the strategy is aligned with the enterprise’s mission (purpose), vision (long-term aspirations), and core values (guiding beliefs).
Goal setting: Set clear goals to provide clarity on what the enterprise aims to achieve over a specific period (e.g. 3-5 years or more). Prioritise goals.
Define actions: Based on the prioritised strategic goals, define actionable steps in an action plan (a roadmap of activities to be taken over time) that outlines how the enterprise will achieve its goals and within what timeframe.
Identify affected Capabilities: Identify which capabilities need to be changed or created, what resources they include (are to be allocated), and what are the associated costs.
Define measurements: Define measurements: Identify the outcomes with which to measure progress and success.
Risk assessment: analyse enterprise level risks.

Strategic planning is followed by strategy implementation and monitoring.

Strategy planning steps are illustrated in the figure below.

Strategic Management. Enterprise Design provides an overall holistic method for managing strategies at the enterprise level. The Facet Model can be used as a “theoretical framework” analysing e.g. following matters with appropriate tools (see templates, chapter 8. ):

Environmental Analysis: Understanding the internal and external environment, which involves tools like SWOT (Strengths, Weaknesses, Opportunities, Threats) and PESTEL (Political, Economic, Social, Technological, Environmental, Legal) analysis.
Strategy Formulation: This involves setting clear strategic goals, choosing the best strategic path (e.g., growth, stability, or retrenchment), and determining the competitive strategy (e.g., cost leadership, differentiation, or focus).

See template Strategy Canvas (one-pager Strategy Canvas) link.

Strategy Plan. Goals are not the strategy, but the course of actions. Actionable activities form the strategy.

**Figure**: From strategic goals to activities.

Simplified strategy plan:

**Figure**: From strategic goals to strategic actions.

Dwight D. Eisenhower: “Plans are useless, but planning is indispensable.”

Mike Tyson: “Everyone has a plan until they get punched in the mouth.”

Strategic Scenario Planning. “A scenario is a detailed and plausible view of how the business environment of an enterprise might develop in the future based on groupings of key environmental influences and drivers of change about which there is a high level of uncertainty.” [Exploring Corporate Strategy, Johnson. G. and Scholes K.]

A Wardley Map can be used for strategic scenario planning. See template Wardley Map (link).

‘Strategy without Scenario Planning is wishful thinking’.

Wardley Mapping

Strategic planning can take advantage of scenario mapping with Wardley Mapping [1]. A Wardley Map represents the situational awareness and assumptions about a context, and illustrates which strategic scenarios are available, or have been recognised. A Wardley map is a tool and an approach with which strategic scenarios can be made. The tool is simple, it consists of Y- and X-axes. The Y-axis represents the visibility towards the customer (activities needed to fulfill customer needs), and the X-axis represents the evolution (how activities change over time). The map is anchored to customer segment(s), related to which the strategic movements can be taken.

A Wardley Map is a representation of business operations in a certain context. The example below introduces an operational business landscape, in which certain strategic scenarios can be made by the management and specialists (C-level + professional advisors)

The diagram above represents the following strategic scenarios:

Scenario 1:

Customer Service -capability is outsourced, for better customer service and cost-efficiency. The new service provider manages both personnel and concerned applications (e.g. CRM).

Scenario 2:

Order Handling -capability is changed to utilize Order Handling application as a SaaS [2] cloud service from an external provider, for better and modernized features. This scenario is keeping the personnel and other applications within the organisation. Another option, scenario 2 B would e.g. outsource the whole Order Handling capability, not only parts of it.

Scenario 3:

Delivery and Logistics -capability is outsourced, as it is not the core but supporting operations of the business of the organisation.

These scenarios can be executed sequentially, or alternative scenarios can be created for each main scenario. There is always a scenario ‘no changes at all; nothing is to be changed’, and then several alternative scenarios in what extent the target area is to be changed (from partly to completely changed).

[1] Wardley map method is created by Simon Wardley. See more information from here: https://learnwardleymapping.com/book/

[2] SaaS = Software as a Service. One of the cloud computing related “as a service” business models (XaaS models such as Infrastructure as a Service/IaaS, Platform as a Service/PaaS). SaaS is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. Also known as on-demand software, web-based software, or web-hosted software. [Wikipedia]

Strategy Execution

Strategic planning forces the change in an enterprise. Strategy is implemented by the components such as initiatives, change programs, projects / products, work packages, change requirements and change actions.

An initiative can be e.g. a strategic level digital transformation. (Transformation is just another name for change).

**Figure**: An initiative executes strategy.

An initiative can consist of programs, projects, products, work packages or concepts, which direct concrete change actions that are derived from change requirements.

**Figure**: Strategy directs the change in an enterprise.

Components for strategy execution introduced in the table below.

Strategy Process

Common strategy process consists of phases with which we try to answer to following questions:

Insight: Where we are now? (as-is analysis)
- What we make and offer now?
- How we operate now?
Vision: Where do we want to go? (to-be analysis)
- What are the changes we want to achieve?
- Clarify the mission, vision, values and strategic goals.
Choices: How to get there? (Gap analysis & goals)
- What are our choices? Our strategic goals?
- What are the changes we choose to implement?
Execution: What actions are to be taken? (Course of actions)
- How we implement the changes according to our goals?
- What is our action plan? How we monitor/measure the progress?

Enterprise’s strategy process can be defined in detail as shown below.

**Figure**: Strategy process implementation.

Trends

Trends and phenomena are high-level change drivers for an enterprise. Trends are the external opportunities and threats that can be identified within SWOT analysis. There are many trends that affect nationwide, society and economy, people, businesses and organisations, and individuals. Here are some examples of megatrends or trends that can be considered when creating visions and strategies. These are modelled as EDGY outcomes, as they represent state changes, events, occurrences or phenomena that may appear or emerge.

SWOT-analysis (Strenghts, Weaknesses, Opportunities, Threats)

Plain old SWOT analysis tool can be used for any kind of business analysis. For example, SWOT can be used for current state analysis to support strategy planning and other change activities within the entire enterprise, business unit or certain product- or service area etc.

SWOT analysis cover internal strengths and weaknesses together with external opportunities and threats. It is a technique for assessing these four aspects of the business. SWOT analysis can be done by using EDGY Outcome base elements, as they represent states of affairs or business events that have occurred or may occur. These findings can be used e.g. as drivers for change within goal setting and creating a Goal Map and/or Strategy Map.

See the SWOT template. Load free PowerPoint templates for EDGY from here: link.

Drivers of Change

Drivers represent certain context-specific events or occurrences, that act as triggers for changes. Drivers are causes (some of them are root causes) for change activities. It is practical to first identify change drivers before starting to define goals. Change drivers make it visible why some changes are needed. With the help of change drivers it is easier to find what needs to be changed.

**Figure**: A driver triggers a change that results from an outcome.

According to Donald Rumsfeld “there are unknown unknowns”. Concepts of “known knowns”, “known unknowns”, and “unknown unknowns” are concerning drivers, some of which we know, some are unpredictable.

**Figure**: Some drivers are known, some are not.

Examples of sources, forces, and factors that influence an enterprise, its existence, and its changes.

**Figure**: Sources, forces, and factors that influence an enterprise.

Change is only constant in life – [Heraclitus]

Change Activities

Drivers affect the business operations (operational business) of an enterprise that sets goals to implement changes.

sources of forces that influence an enterrpise — **Figure**: Drivers of Change affect to business operations.

Since business operations are based on capabilities, all change activities are directed towards capabilities and their content (components): people, processes, and assets of the enterprise.

The change is performed by activities (actions) that are a) based on drivers and goals and b) directed to certain capabilities of the enterprise. At high-level, the business strategic goals are derived to more operational goals that define the desired outcomes. These outcomes are the drivers and demands for the changes required.

**Figure**: Drivers trigger change activities that affect to capabilities.

The diagram below illustrates how strategic and operational goals are directed towards operational business through capabilities. Ultimately, changes made to capabilities, and the related products and/or services, impact the customer experience.

Business Change

The identity elements Purpose, Content and Story of EDGY and base elements Activity, Object and Outcome can be used for analysing the business case of a business change. This means making visible what is the ‘beef’ in a certain activity, or innovation, or new concept or in change initiative, or in business transformation (of any size from a small change to a large transformation program). The best way to do that is visualise the introduction into a compact ‘one-pager’ diagram. All this can be modelled into a compact intro one-pager with various elements. Lots of example templates and canvases introduced in this document (see chapter Templates 9. ).

Compared to well-known business model analysing tools, such as the Business Model Canvas (BMC), this view is simplistic introduction to what the business is all about. The customer perspective can then be opened in more detail with e.g. stakeholder map and service blueprint. The latter describes the customer experience part of the story: what are the tasks/needs that this particular product or service fulfills.

Change Demand. The base element Outcome can be used for visualization of change demands that are to be further analysed e.g. in concept design.

**Figure**: Outcome specialisation examples.

Change Initiative, program, project, concept, change requirement or other structural aspect of design or development can modelled with the EDGY Object element.

**Figure**: Object specialisation examples.

Change Activity. The base element Activity can be used for modelling any change activities or actions. Every activity in an enterprise can be defined in a few, short and clear sentences. Every activity has a reason to be, some story, something to offer, and some people who are organized themselves.

**Figure**: Activity specialisation examples.

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.

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.

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.

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.

Roadmap

A high-level strategic roadmap can be modelled with the EDGY Story element.

**Figure**: Strategic phases / steps to be taken.

A basic roadmap (Activity Map) can be created for any kind and size of change efforts and initiatives. EDGY Activity element can be used for depicting the stages or phases of a roadmap, the series of activities to be taken for achieving a certain ultimate target.

**Figure**: Roadmap example (with EDGY *Activity* elements).

A roadmap illustrates what has happened and what’s next. An example below.

Another example below.

**Figure**: Roadmap example (with EDGY *Activity* and *Object* elements).

The EDGY base elements can be used for analysing the roadmap with outputs and outcomes.

**Figure**: Roadmapping with the EDGY base elements.

Business Capability Roadmap

As capabilities represent the core components of the operational business, all change initiatives, such as business transformation programs, can target these capabilities. A business capability roadmap can be used to illustrate why and what changes are to be implemented, and in what order.

Business Transformation Roadmap

EDGY can be used for analysing, defining and visualizing business change programs. For example, a business transformation program can be illustrated in the roadmap as shown below.

Each phase of the roadmap represents a certain transition that is to be taken. In this case, the transitions impact certain capabilities that are to be changed. The exact changes can be defined and visualized in detailed diagrams per each capability, explaining which parts of the capability are to be changed and how. The prerequisite is that the capabilities of the business are identified, and as suggested, visualized in the capability map.

Organisation Map

Organisation structure can be represented in a map e.g. in a) a hierarchical format or b) nested format as shown below.

**Figure**: Organisation chart – tree representation.

Element hierarchy can be represented by nesting elements: parent elements contain child elements, that are positioned inside the parent. This style saves space in the diagram, and is intuitively easy to interpret.

**Figure**: Organisation diagram – nested representation.

Organisation Culture

Organisation culture is what occurs when people interact with each other. Culture is an emergent occurrence of people’s behavior, which starts growing whenever two or more people work together. Culture exists for sure, we can feel it, but we can’t touch it. Organisational culture is the ‘basic assumptions and beliefs’ that are shared by members of an organisation.

Culture cannot be directly changed, but it can be influenced e.g. by mission, vision and values as well as and stories we tell about ourselves, and the content that we produce and share. Culture is much about communication and is reflected in the brand image.

Culture exists somewhere in between the identity, organisation and people of an enterprise.

**Figure**: Culture is a result that can be influenced by the communication of identity through branding.

Good culture can be seeded by management by enforcing good spirit and encouraging and inspiring working atmosphere, where employees appreciate each other. Bad culture consists of discouraging and dismissive attitudes toward colleagues, which causes bad results in employee satisfaction and recruitment. The phrase ‘culture eats strategy for breakfast’ means that culture is what happens when nobody is seeing. Culture is how people behave, how they interact, communicate and do their tasks in practice. In contrast, the strategy is (hopefully) concretised and implemented in operations, processes how people should do their work.

**Figure**: Cultural values, communication, and leadership impact the employee experience.

Employee experience. Organisational culture affects the employee experience and well-being. When employees are well and employee satisfaction is high, they deliver a better customer experience. Since people (humans) are psycho-physical-social beings, many factors influence the employee experience. Management and leadership in an organisation have a significant impact on employee satisfaction. An organisation’s leadership can influence either positively or negatively through its actions, as organisational culture is shaped both top-down and bottom-up.

Management and leadership, through poor example or communication, can weaken an enthusiastic and encouraging atmosphere. However, if the organisation’s management can create a functional physical work environment and a safe, inspiring, and supportive social work environment, then employees’ mental well-being and employee satisfaction will be at a good level. It is important that employees’ psychological workload (cognitive load) is at an appropriate level; otherwise, employee experience and well-being may suffer, leading to issues with endurance and absenteeism due to mental health reasons.

Poor management is the reason for a negative organizational culture and work atmosphere, leading to absenteeism and staff turnover. And conversely, good management encourages high performance, leads to a positive employee experience, effective business operations, and ultimately results in a good customer experience.

People-Focused Identity of an Enterprise

Identity – the Business reason. Identity explains the fundamental reasons why the business exists and why it involves people around it. That’s why it is crucial to clarify why the business we do is important so that people can be motivated and to provide the best versions themselves.

Cold story. American economist Milton Friedman developed the doctrine as a theory of business ethics that states that “an entity’s greatest responsibility lies in the satisfaction of the shareholders.” Therefore, the business should always endeavor to maximize its revenues to increase returns for the shareholders.

**Figure**: “Cold story”: The enterprise’s purpose is to provide profit for shareholders.

The Friedman Doctrine, also known as the Shareholder Theory, provides insights on how to increase shareholder value. According to the doctrine, shareholder satisfaction is an entity’s greatest responsibility. However, the doctrine also faces expansive criticism since it turns a blind eye to social responsibility activities.

Warm story. Now, what can or should be done is to adjust the focus on employees, as they are the ones who make things happen. Satisfied employees enable good customer satisfaction. Moreover, an enterprise should shift its focus to people and social responsibility on a broader scale: all the people interested or involved in the operations of the enterprise should be prioritized – instead of focusing only on shareholders. Shareholders benefit if all the people who experience the enterprise in some way can get the most out of it. That means:

“An entity’s greatest responsibility lies in the satisfaction of all the people.”

So, it is important to adjust the focus to people and ask ourselves, ‘What can we do for people?’ – for customers, employees, partners, owners, etc. People do what they need to do when the conditions are good and the atmosphere is encouraging and inspiring – rather than discouraging and divisive. Organisation culture matters. Organisation culture must be nurtured.

Turn the clock to people’s time.

Business Object Map

When co-designing design challenge, it is good practice to identify the business concepts / -objects of the target area. The object map introduces business objects used in the target area (such as ecosystem, enterprise, business unit, product- / service area). This is a simple view that consists of object elements that are related with each other. This object map can also be called to Concept Map or Mind Map, depending on the case: how abstract or detailed things are concerned. This view can be modelled with the EDGY Object -elements with association relationship (with labels).

This object map can be further enriched with more details such as cardinalities between the objects (e.g. one-to-one, one-to-many etc.) as shown below.

**Figure**: Object Map with cardinalities (e.g. one-to-one, one-to-many).

Master data objects can be marked e.g. with the labels as shown above. In the case of large models, a coloring scheme can be used to make a diagram more readable.

Business Map

Business Map can be used for analysing the business fundamentals: the customer perspective meets the organisation perspective. Customers and their needs are positioned on the outer circles, and the products and capabilities of the enterprise are positioned on the inner circles.

Context Diagram

Overview of the business environment explaining the context of the development target.

Outside-in & inside-out intersection as a layered overview, representing the context of specific subject matter area.

Architecture Examples

Architecture [1]:

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].

[1] 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[1] (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 [2].

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.

[1] Business Operations; Operational Business; Operations and Delivery; shortly: Operations.

[2] 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[1] 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.

[1] 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.

Activities represent the behavior that is going on in a capability, and objects represent structural elements that are used or produced.

**Figure**: 1) People perform activities using and creating objects. 2) Activities are behavioral and objects are structural elements. 3) People perform processes and use or create assets.

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

[1] 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 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.

anatomy of a capability — **Figure**: Anatomy of a capability.

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[1] 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).

[1] 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.

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 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 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.

**Figure**: Extended Capability with related elements.

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 Map

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.

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.

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.

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. [1]

[1] 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. The context typically explains the types. For example, an application architecture diagram titled “application architecture” implicitly implies that the asset elements are applications.

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.

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.

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.

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.

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.

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.

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 [1] 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.

[1] 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

Business Objects and Information Modelling

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 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.

Component Model (CM 1-2-3)

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.

**Figure**: An application consists of components (modules), each of which consists of components.

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):

**Figure**: Component Model abstraction levels.

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.

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.[1]

[1] 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)
Context level 1 (application of a capability in business context)
Composition level 2 (the content, internal structure of an application)
Component level 3 (the internal structure of a component of an application)

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.

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.

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

[M. Porter Value Chain link]

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.

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.

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.

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.

**Figure**: Operational Value Stream and 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).

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).

Value Demand and Failure Demand

Value demand is “normal, healthy basic demand” that arises from customer needs (tasks, jobs to be done), to which the organisation responds by offering appropriate services and/or products.

Failure demand is unnecessary additional demand that arises when customer needs have not been met, and the customer has to return to the service. Failure demand is a significant cause of inefficiency and cost escalation in organisations.

**Figure**: Customer meets the organisation at the service interface.

Value Demand describes a situation where customers have needs for which they seek products or services to help them achieve their desired outcome. Customer needs are tasks that customers want to accomplish (jobs to be done). Value demand is thus a situation where customer needs meet the services and/or products offered by the organisation.

If the organisation successfully responds to value demand in a way that meets the customer’s needs, that is, the outcome produced by the services and/or products benefits the customer, the customer feels they have had a good customer experience. Customer value is therefore the benefit, the added value that the customer feels they receive if the service and/or product meets their expectations. In other words, there is a benefit from the service and/or product, which can manifest in different forms. For example, the customer solves their problem or completes their task, or saves time if the use of the service and/or product speeds up the completion of their needs or tasks. The benefit can also be in the form of saved money, as the customer can complete their task more affordably.

Customer experience and customer value are based on the quality of the service and/or product. Quality determines the customer experience and the associated benefit perceived by the customer.

An organisation responds to value demand with its offerings (products and/or services).

What, where, when – and why? It is important to understand what the customer needs, why they need it, where (the situation, context) they need it, and when they need it. This information is called customer insight, which is obtained by collecting information about the customer’s actions, asking about the customer’s needs and motives. Customer insight can be obtained utilizing service design and data analytics methods. In this sense, it is paramount to start from customer needs.

Customer need creates value demand. The organisation aims to respond to this demand with its services and smooth processes. From a holistic perspective, the organisation should strive to respond to demand, i.e., customer needs, and then tailor its services and operations to meet this demand. As a result of focusing on creating customer value, the organisation also generates business value.

**Figure**: Customer need creates value demand.

From the organisation’s perspective, it is essential to focus not only on customer needs or expectations but also on service delivery, i.e., how the service process and employees’ function. It is worthwhile for the organisation to tune this operation to be as smooth as possible, following the Lean philosophy by maximizing flow velocity and minimizing unnecessary ‘waste,’ valueless activity. In this regard, the organisation can leverage technologies such as artificial intelligence (AI) and robotic process automation (RPA).

**Figure**: Employee satisfaction affects customer satisfaction.

It is worth noting that satisfied employees serve customers well. The better the work environment, the more likely customers are to receive good service. In this sense, employee satisfaction contributes to customer satisfaction, meaning that employee experience affects customer experience.

To ensure smooth operation and the quality of value demand, it is recommended to proceed in the following order when changing or renewing operations:

Identify customers/customer groups, as well as other stakeholders (using Stakeholder Map)
Identify customer needs and customer journeys (using Service Blueprint).
Identify services and/or products offered to customers for their needs, from which customers benefit.
Identify organisational processes related to service delivery (and necessary information systems if needed).

Value demand creates customer value and business value.

Failure Demand. Avoidable unnecessary additional demand, failure demand, describes a situation where the outcome of the service does not meet the customer’s expectations. The customer has to return to the service with additional needs, either during or after the service process. Failure demand is the result of poor or unsuccessful service by the organisation. Therefore, both customer experience and employee experience are poor: the customer experiences unnecessary trouble, and the organisation faces unnecessary additional work and costs. Failure demand ‘disturbs’ smooth customer service and smooth business operations.

**Figure**: Failure demand creates unnecessary additional demand in the service process when the service does not meet the customer’s expectations.

Failure demand is the result of failed or inadequate service by the organisation, leading to a poor customer experience and causing unnecessary additional work for the organisation.

Mismatch problem – Customer needs and organisational offerings do not meet.

The misalignment, or gap, between customer needs and an organisation’s offerings – referred to as the “matching problem” – occurs when there is either no suitable service available to meet customer needs or when the appropriate service exists but is not available at the right time. When customer needs and organisational offering (supply) are not aligned, it results in a matching problem, which often leads to failure demand.

The mismatch problem, or matching problem, occurs when an organisation’s offerings do not meet the customers’ needs.

“Failure to serve the customer properly leads to additional demands from the customer. This dissatisfaction burdens the organisation, tires employees, and increases costs. This phenomenon is known as failure demand. It occurs when the customer receives the wrong service, no service at all, or only a partial service. The issue lies not with the customer but with the organisation. Failure demand is always a clear signal that the interaction between the organisation and the customer is not functioning effectively.” [Hyytiälä, H.]

Failure demand is demand that we do not want.

What is the actual problem? Why is failure demand problematic, and why should it be addressed? Why not just acknowledge that such a phenomenon exists, occurring occasionally? Failure demand has consequences that are problematic for all parties involved (according to H. Hyytiälä):

Availability and Quality of Services Deteriorate: This reflects a quality issue, where unnecessary bouncing from one counter to another or repeatedly addressing the same issue causes customer frustration.
Increased Burden on Organisational Resources: This indicates a capacity problem, where the volume of unnecessary work detracts from value-producing activities, putting additional strain on organisational resources.
Rising Costs: This is an economic or cost issue, where unnecessary work leads to increased costs, both direct and indirect, such as additional time, raw materials, and other resources

These issues are significant for customers, organisations, and, more broadly, for society and the economy as a whole. Therefore, it is crucial to address failure demand. Ideally, this should be done proactively to prevent or reduce its occurrence. Reducing failure demand is economically beneficial, as it enhances both customer and employee satisfaction. Fewer instances of failure demand led to greater satisfaction and a better overall experience with the organisation and its services.

Failure demand occurs when a customer must return to a service because the initial outcome did not meet their expectations.

Causes of Failure Demand. When a customer’s needs and an organisation’s offerings do not align, failure demand arises. This creates a negative cycle that is harmful to the organisation and, more importantly, undesirable for the customer. The customer fails to receive optimal service, and their needs are not met as expected.

The root causes of failure demand are:

Poor understanding of customer needs and situation: When the organisation does not fully grasp what the customer needs or their specific context.
Ineffective service processes: When the processes in place are not efficient or effective in addressing customer needs, when service processes are dysfunctional, characterized by ambiguity, inaccuracy/imprecision, uncertainty, and lack of systemization:
- Ambiguity about the customer’s situation.
- Imprecision regarding the customer’s needs.Uncertainty and Data Gaps in the process of meeting the customer’s needs, resulting in the customer being “bounced around.”
- Inefficient and Disorganized Operations, including duplication, inconsistency, or inadequacy: incorrect information is requested from the customer at the wrong stage, or too much or too little information is sought, leading to a failure to meet the customer’s needs on the first attempt.

Both issues are the responsibility of the organisation. They are self-inflicted problems that result in dissatisfaction for both the customer and the organisation. Failure demand is not unexpected; it arises from a lack of proper understanding of both customer needs and organisational actions.

These causes highlight various factors that contribute to failure demand, emphasizing the need for improvements in service delivery and organisational processes.

The root causes of failure demand are: 1) a poor understanding of the customer’s needs and situation, and 2) dysfunctionality in the service process.

List of causes of the failure demand in the table below.

A common list of consequences shown in the table below.

Summary of Failure Demand consequences:

The customer does not receive the service they need and must return with additional requirements.
The organisation incurs unnecessary extra work due to these additional demands.
As a result, both the customer experience and the employee experience suffer.

**Figure**: Failure demand causes extra work.

Failure demand burdens the organisation.

The additional work resulting from customers’ unmet needs creates an illusion that the organisation is efficient because employees appear busy and have a lot to do. This illusion of efficiency – often referred to as the efficiency paradox – arises from the belief that a well-functioning organisation should ideally have no spare capacity [according to Modig, N., Åhlström, P.]. However, the reality is that a significant portion of this work may be unnecessary additional tasks.

From the customer’s perspective, an organisation that seems resource-efficient and fully occupied may actually be slow and inefficient. The overload on capacity is often due to the unnecessary work generated by failure demand. While value demand creates meaningful work, failure demand leads to unnecessary additional tasks that burden the organisation without adding value.

**Figure**: Value demand generates meaningful work, while failure demand results in unnecessary additional work.

“Is it possible that a significant portion of the work carried out in our organisations is simply waste? Perhaps we consider ourselves efficient because we manage thousands of tasks, but in reality, we are just squandering our resources. On a broader scale, what implications does this have for how we use resources at the societal level?” [Modig, N., Åhlström, P., This is Lean, 2013]

Failure demand may be the cause of the organisation’s capacity overload.

How can the emergence of failure demand be prevented?

Failure demand arises from both a poor understanding of the customer’s needs and situation, and issues within the service process. Both of these issues are caused by the organisation, and thus, both can be addressed by the organisation.

To address failure demand effectively, it is crucial to understand the customer’s situation (context) and needs. This involves analyzing the customer journey and the supporting service processes. Together, these elements create a comprehensive, holistic framework that includes both:

The customer perspective, which focuses on understanding the customer’s experience and requirements, and
The organisational perspective, which involves examining and improving the service processes that support customer interactions.

Understanding and addressing both perspectives are essential for reducing failure demand and improving overall service quality.

Addressing failure demand requires an understanding of both customer behavior and organisational behavior.

To prevent failure demand, it is essential to transition to a customer-centric approach by effectively managing customer journeys.

The customer journey (or service journey) encompasses the complete experience of a customer when interacting with the services provided by an organisation. It includes all the actions and experiences of the customer throughout their engagement with the organisation. Understanding the customer journey provides valuable insights into the customer’s situation (such as their life circumstances). With this understanding, with customer insight, the organisation can deliver services that are both timely and well-suited to the customer’s needs. The organisation’s goal should be to provide the right services and expertise at the right time.

Resolving failure demand begins with mapping out the customer journey, which is closely linked to the organisation’s internal service processes. These perspectives converge at the service interface. The customer perspective views the service from the outside in, focusing on the customer’s overall experience, while the organisational perspective examines it from the inside out, focusing on internal processes.

The most effective approach is to consider both perspectives holistically. This integrated view can be achieved through the Enterprise Design approach, which combines both perspectives and their respective methods.

A Service Blueprint is a descriptive tool that maps the customer journey in relation to the service delivery processes within an organisation. It highlights how the customer’s interactions intersect with the organisation’s operations through the service interface. As such, the Service Blueprint serves as a model that illustrates the interaction between the customer and the organisation, making it a valuable tool for analyzing both value demand and failure demand. Below is an example of a Service Blueprint.

**Figure**: In a comprehensive analysis, the customer journey and internal service processes converge.

Breaking down the customer journey into its components involves analysing customer feedback and process metrics to gain a comprehensive overview. This analysis allows for targeted interventions at individual customer touchpoints and process stages. By analysing both the customer service journey and the supporting organisational service process, we can identify pain points for the customer and organisational issues, addressing any dysfunctional steps in the service process. Process optimisation, following Lean principles, helps enhance flow efficiency and overall performance.

Understanding the customer’s situation and needs can be achieved through service design techniques, while gaining insights into the organisation’s operations is accomplished through business architecture. Together, these approaches form the Enterprise Design approach, which comprehensively examines both a) customer activities and b) organisational processes. Visualizing the entire process helps create a shared understanding.

It is valuable to describe processes in a way that is clear, quick, and easy for everyone to understand. EDGY is designed to be simple and straightforward while remaining expressive. It allows for the depiction of both customer and organisational activities in a way that facilitates discussions about necessary changes and fosters a shared understanding of the overall picture.

Enterprise Design begins with understanding the enterprise as a whole. This holistic approach allows us to view the organisation from all relevant perspectives, identify and explore key dependencies, and pinpoint the most significant leverage points for change. As a result, Enterprise Design integrates various disciplines to provide a comprehensive understanding and facilitate effective transformation. Enterprise Design is a valuable tool for preventing failure demand.

Development

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.

IT4IT Reference Architecture

The Open Group IT4IT reference architecture introduces four phases: 1) Plan, 2) Build, 3) Deliver and 4) Run.

IT4IT introduces Digital Product that is an unit of development.

To be continued…

Intersection Group

Intersection Group is a global community of people interested and invested in creating better enterprises [1].

Intersection Group is run by a community of people organized as a not-for-profit association, committed to the idea of creating better enterprises. Intersection Group brings together practitioners working with enterprises in internal roles or as external consultants, authors and academics from connected fields, as well as member organisations that partner with the community to develop the practice, tools and content.

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

TO BE CONTINUED…

Load the complete EDGY Cookbook pdf: link.

Applying Enterprise Design with EDGY

There are many disciplines, practices, and capabilities involved in the change and operational activities of an enterprise. Each discipline has its own purpose and specific focus area. Enterprise Design and EDGY can be applied across all disciplines to facilitate holistic collaboration.

Challenge. The problem is that these disciplines work independently and use different methods and tools. They have focus areas, concepts and terminologies and special competence roles of their own. Enterprise Design can be used to integrate distinct disciplines and enable cooperation by providing a holistic and coherent overview of the enterprise.

Competences, Skills and Roles. There are lots of different specialist groups in an enterprise. Many of these practices and specialist roles work in their own bubbles. Enterprise Design provides a common language, the EDGY, that all groups of experts can understand and easily learn to use, facilitating collaboration.

**Figure**: Examples of roles that participate in the disciplines of an enterprise.

All disciplines view the enterprise from their own perspective.

The Enterprise Design Facet Model can be applied to many different ways to analyse and design the enterprise.

**Figure**: The Enterprise Design Facet Model is adaptable to various uses.

The Enterprise Design Facet Model[1] can be applied as a method or an analytical tool, and the EDGY as a modelling notation.

[1] All methods, frameworks, and tools are limited, but some are useful. Enterprise Design with EDGY is simple yet powerful enough to fit most design challenges.

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

**Figure**: The Facet Model can be applied to cover the overall design and development of an enterprise.

Service Design and Business Architecture

Holistic triad:

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.

EDGY provides an easy yet expressive modeling language for visualisation that everyone can use. EDGY offers a simple but powerful language that is accessible to all stakeholder groups within an enterprise. Visualisations with EDGY are simple and attractive, and everyone can interpret them intuitively and quickly. An interesting aspect is the Enterprise Design Facet Model, which can be used as an analysis tool to shift perspectives and reframe challenges into new ideas – from different angles.

— Eero Hosiaisluoma, Helsinki, Finland, 25th Aug 2024

Take advantage of the free PowerPoint templates for enterprise design from here: link

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: 324