EDGY intro

EDGY is an open-source language for enterprise design provided by the Intersection Group. The EDGY is created for visualizing enterprises.

There are many isolated design and development disciplines such as service designers and enterprise architects without much communication and cooperation. The EDGY is designed to connect people from different disciplines and become collaborative co-designers of better enterprises.

The EDGY is aligned with the idea of enterprise design as stated by the Intersection group:

• to identify a purpose worth pursuing (identity), the WHY
• to make a valuable contribution to people’s lives (experience), the WHAT, and
• to perform and deliver on our promises (architecture) the HOW.

The EDGY complements other more specialised languages, by providing a higher level abstraction for enterprise design. The EDGY is simple and easy to learn, and it looks good visually.

The EDGY language provides a set of concepts (facets, enterprise elements) and their relationships. There are only four (4) base elements, and their specialisation into twelve (12) facet elements and intersection elements. These elements can be connected with only a few relation types: 1) link, 2) flow and 3) tree (hierarchy).

“EDGY provides a language that encourages specialists and experts to explore and communicate together to enable a coherent enterprise co-design.” [Intersection group]

References

[1] Intersection Group, link

[2] Enterprise design, link

[3] EDGY language foundations, 2023, link

Suggested material (Webinars, Youtube videos etc.):

• EDGY 23 product release, launch on 29th March 2023, webinar recording. An excellent introduction by Milan Guenther & Wolfgang Goebl (presidents of the Intersection Group), link.
• Capability Maps – Next Generation, Feb 2023, Webinar, Milan Guenther, link.

EDGY Facets and intersections

Facets

These are the three facets of EDGY: 1) Identity, 2) Architecture and 3) Experience. The factes integrate design and architecture disciplines into a single practice, into a single endeavor: enterprise design

1) Identity

• Why does our enterprise exist? Who are we? What matters to us?
• The values and beliefs enterprises exhibit through their messages and actions.
• The shared understanding of our purpose, personality, culture, values and aspirations, as it is perceived and lived every day by people’s behavior, communication and choices.
• Defining the core idea behind the enterprise and the way it is communicated and understood as a story to and by people in and around the enterprise.

2) Architecture

• How are we running our enterprise? What are we capable of? What makes everything work together?
• The structures needed to make an enterprise operate and connect to the ecosystem.
• Employees and other people, together with assets (resources), perform processes to enable capabilities. They are developed by its organisation and are required to make and deliver the products it offers.
• The parts such as assets, resources, information and tools we use and maintain, and how they fit and work together as a system that enables us to deliver and perform.
• Building capabilities enabled by people, information and management systems, with processes and rules governing the way we operate and achieve our goals.
• ‘Architecture makes everything work’ in practice

3) Experience

• What is the role our enterprise plays in people’s lives? What can we do for people?
• The impact through interactions the enterprise has on people and their lives.
• People interact with the enterprise via channels along their journeys to complete their tasks.
• The contribution we aspire to make to people’s lives, the understanding and insight we have of their reality, and the value we bring to them with everything we do and offer.

[Ref. 2: Enterprise Design. ]

Intersections

The facets are interconnected with the intersections, via which the facets interact and influence each other:

Organisation

• A group of people working together.
• How do we organise ourselves as teams? How do we work together?
• An organisation is a complex social structure. People form organisations to collaborate and co-design outcomes they cannot achieve alone without explicit agreements about membership, responsibilities and behavioural rules. Organisations are fractals: they are made up of nested structures (e.g. business unit-department-team) that have similar attributes on each level, such as purpose, goals, capabilities and hierarchy.
• Organisation in teams and roles with responsibilities for certain parts of the enterprise’s operations and management decisions.

Product

• What we make, offer and deliver for people’s benefit.
• What do we make and offer to people? What is the result of our work? What is the value these results create for people?
• Products are the results of our enterprise activities. Products encompass physical things manufactured and delivered, or services rendered to people. In EDGY, the Product element represents both products and services
• What we make and create, building upon our Architecture to contribute to people’s Experience, and how we make this available as product or service offerings with a successful business model for good outcomes.
• Products and services are packaged as offerings to our markets, with underlying business or operating models, made available for people to interact with.

Brand

• Our name and what it stands for.
• How are we being perceived? What is our reputation and image when people are in touch with us or our products?
• How we translate our Identity into representations to appear in people’s Experience, make our enterprise and its offerings visible and understood, and position us for a positive image.

[Ref. 2: Enterprise Design. ]

EDGY elements

Base elements

EDGY is based on only four Base Elements:

People, Activity, Object, Outcome.

These generic base elements are specialized in facet and intersection elements.

EDGY relations

The EDGY language contains three (3) relations: 1) Link, 2) Flow and 3) Tree. A link represents structural dependencies and a flow represents dynamic relations (e.g. control flows or object flows). Depending on the tools being used, additional nuances can be included via attributes or weighting to both elements and relations.

Link

Elements and relations overview

Facet and Intersection elements

EDGY elements & relations

Enterprise Design Facet Model with EDGY elements.

Example diagrams

These examples are based on EDGY materials. Examples are titled according to known diagram types. Some of the diagrams are patterns, showing the elements and their relations. Some diagrams are just examples of how the elements and relations can be used. All the facets and intersections are covered.

All the facets, Identity, Architecture and Experience, can be covered using five elements as shown in the diagram below: three Facet elements + two Intersection elements.

All in all, the EDGY provides a holistic, human-centric approach to enterprise design. All the EDGY elements can be used for modelling any design challenge. Use those elements that are appropriate.

EDGY is supported by many tools, e.g. Miro, QualiWare, Confluence & Draw.io. These examples are created with Draw.io EDGY stencils.

Note! This content is continuously updated (new example diagrams and more explanations are to be added).

Strategy Map

Also known as Goal Map.

Element(s): Purpose. Relation(s): Tree, illustrating indent(ation) hierarchy (which can also be shown by Link -relation).

The Purpose element can be used for expressed as outcomes/goals the enterprise aspires to achieve.

Concerning every endeavour, for each human activity, every business, cooperation etc., the very first thing to analyse is the question why. For example, why an enterprise exists at all? That’s the purpose, which can be further analysed e.g. defining the mission, vision and goals as a starting point for activities.

Organisation Map

Also known as Organisation chart.

Element(s): Organisation. Relation(s): Relation(s): Link (illustrating hierarchies).

Product Map

Also known as Product Portfolio. Products can be grouped by certain criteria such is organisation- / business unit.

Physical things or services rendered to people. [3]

Element(s): Product. Relation(s): Tree, Link.

Metrics can be added to the product elements as shown above.

Channel Map

Also known as Touchpoint Map.

Channel: The means people use to engage and interact with us. Channels are the means of communication between people and the enterprise. They are where moments of interaction between people and the enterprise take place. They includes media, devices, communication systems, or physical environments used to facilitate interactions.

The organisation’s products and services are used via channels.

Element(s): Channel.

Journey Map

Also known as: Customer Journey Map, Customer Service Map / -Path.

“The journey defines the events and activities people experience in their lives. A journey describes what a person does, feels, thinks, or otherwise experiences over time as they live a specific portion of their life, in particular when interacting with our enterprise. It is captured as a simplified sequential and chronological representation of activities and events people experience, and tasks they want to accomplish”. [EDGY language foundations].

Element(s): Journey, Task.

An example journey.

A journey map can extended with the tasks that a customer needs to accomplish.

A layered view or Service Blueprint can be used for further analysis & design when focusing on customer insight. More detailed diagrams can be depicted e.g. for identifying touchpoints etc.

Element(s): e.g. Journey, Task, Channel, Product. Relation(s): Flow, Link.

Customer View & Organisation View

Customer View. Enterprise is visible to customers via the products and services, which are made available via channels (outside-in view). It is important to provide customers what they need, not always what they want. That is why it is valuable to get a better understanding of what is meaningful for customers. By analysing the needs of different customer segments, it is possible to get customer insight for enabling better products and services.

Customer access products and/or services via channels (such as web applications, mobile apps, on-site face2face contacts, email, phone etc.).

A specific product or service can be accessed via multiple different channels.

Organisation view. Products and services are produced by the organisation with certain capabilities, processes and assets (inside-out view).

Capabilities are central components. They combine processes and assets that belong together to ‘composable business components’.

Business View

Business is all about providing products and/or services to customers. Those products and/or services are realised by the capabilities and resources of an organisation.

1. The business provides products and/or services to customers.
2. Products and/or services are realised by the capabilities of the organisation.
3. Capabilities require resources of the organisation (depicted as assets)

To be more precise, capabilities are performed by activities (in the form of processes), which use the resources of the organisation.

Service Blueprint

A Service Blueprint is an overview of a specific customer-driven part of a business. The visualisation is based on the layered approach, starting from the customer’s perspective, and representing how an organisation responds to the demand(s) of the customer.

Customer activities are illustrated by the customer journey and steps that are taken, in order to achieve specific outcome(s). The customer’s actions (activities) are linked to the products and/or services via certain channels. These express the customer view, the outside-in view.

The other layers and elements of the service blueprint depict how the products and/or services are realised: with which capabilities and processes, by which organisational structures etc.

A Service Blueprint focuses a customer’s view. In addition, the intra-organisational elements (such as processes, organisation structures and applications) can be covered too, those of which express the inside-out view. So a service blueprint covers both outside-in and inside-out views, and it can be used as an overall context diagram, which gives an overview of the target area. As such, a service blueprint is an extremely valuable and practical diagram type, that can be co-created together with business owners, service designers and architects.

A Service Blueprint covers EDGY Experience and Architecture facets via the Product intersection. There can be several versions of a service blueprint, some of which are shown below.

Element(s): e.g. Journey, Task, Channel, Product, Organisation, Capability, Process.

Service Blueprint – Basic simple version 1

This version focuses on the process flow: customer activities and organisation’s activities.

Element(s): e.g. Object, Journey, Channel, Process. Relation(s): Flow.

Service Blueprint – Basic extended version 2

This version combines customer actions to organisation’s products and/or services via channels (touchpoints). Organisational structures (units, groups or teams) can be included to point out the dynamics of ‘who is doing what, and with what‘.

The customer’s journey introduces what the customer is doing, and which products and/or services are used via the channels (touchpoints) when accomplishing task(s).

Service Blueprint – Organisation and Capabilities – version 3

This version represents a ‘capability view’ aligned with organisational responsibility.

Service Blueprint – Capability Focused version 4

This version represents a ‘capability view’, without any organisational alignment.

Service Blueprint – Map version 5

This version (more like a map of elements) represents a ‘capability viewpoint’, as it introduces the capabilities that are related to the customer journey and concerned products (or services).

(This is an applied version of the service blueprint, inspired by the Capability Maps Webinar, Feb 2023, Milan Guenther).

Service Blueprint – Matrix – version 6

This version uses “swimlines” with channels and organisation structures. This version illustrates which capabilities are supporting which products.

Service Blueprint – Matrix – version 7

This version (below) uses “swimlines” with channels and organisation structures. This version illustrates which processes are related (realise) to which products.

This version (below) uses “swimlines” of organisation structures.

Overview Context Diagram

The customer perspective, outside-in, meets the organisation perspective, inside-out, by an intersection in the form of products & services. Both views, a) the customer view and b) the organisation view, can be designed with an overall overview, layered view, as shown below. This view can be used for defining & designing the context, the overall overview of the target problem space.

Element(s): e.g. Journey, Channel, Product, Organisation, Process, Asset. Relation(s): Link.

Capability Map

Shows the intra-organizational behavior on a page. Capabilities represent WHAT an organization needs to fulfill its mission and execute its business. Capabilities are high-level abstractions of organizational properties or business features that are needed for an organization to do its business. As such, business capabilities are the basic building blocks, from which an organization is made of.

Element(s): Capability. Relation(s): Tree (stacked hierarchy).

Capabilities in a capability map can be grouped e.g. into the following categories:

1. Customer-facing capabilities – get in touch with the customer
   • e.g. Sales via various channels, Customer Services, Customer information
2. Core Operational Business capabilities – create the products and services, providing value to the customers directly
   • e.g. Manufacturing, Warehousing, Logistics, Order Management / -processing / -handling. Consists of business areas
3. Supporting (Shared) capabilities – reusable, shared business components, enabling the core business operations
   • e.g. Customer Management, Marketing, Legal, HR and
4. Change capabilities – enable an enterprise to innovate and develop the other three categories
   • e.g. Product Design, Strategy planning, Enterprise Design, Procurement

This example below is a Railway organisation, which is divided into specific business areas such as train operations and railway infrastructure management.

A capability map can be defined with metrics and/or tags as shown in the fugue below.

Metrics add a quantity or quality to an element that can be measured or otherwise determined. Typically this is used to express information about the performance, importance or status of the respective element. Combined with a colour coding scheme, metrics can be used to display a heat map to indicate areas that need attention or are otherwise in focus.

EDGY language foundations (Metrics, page 65).

Another heatmap example below.

Capability

What we are able to do by orchestrating people and assets [3].

Enterprises strive to achieve their purpose by creating products that feature in people’s experiences. To do so, they must design and realise their capabilities by orchestrating meaningful combinations of people and assets. Each capability produces well-defined outputs for internal or external business use and contributes directly or indirectly to product creation.

Capabilities guide the modularisation of our enterprise by defining boundaries around what “belongs together” and what is distinct from other capabilities. By deriving the realising processes and assets (resources such as the required organisation and applications), a well-designed capability model leads to enterprises and organisations that are adaptive to change. Capabilities can be decomposed into sub-capabilities (usually levels 1-3) to create a hierarchy. Each capability must have a clearly assigned business owner to ensure its strategic development and the effective creation of intended outputs. Business and IT structures are designed in on seamless approach.

Intersection Group

A capability is an outcome of being ready for execution. “A capability is the outcome that a process seeks to achieve.” A capability is a behavioral, coherent business component, that is a composition of elements (such as processes, organisation, people, information- and application assets, products and services, and channels) belonging together, based on certain cohesion criteria. Capabilities define what an organisation does, what an organisation shall have to deliver wanted outcomes. With capabilities, it is possible to analyze the structure of ‘who is doing what, and with what’ (with which assets).

Elements: Capability, Process, Asset, Product, Organisation, Object. Relation(s): Tree, Link.

Precisely, according to EDGY, a product is an intersectional element, that requires capability as shown in the figure beside. A product or service is an output of a capability. As such, a product or service is logically external to a capability. Though, a product and/or service is linked with a capability anyway. However, a product or service is realised by a process that is internal to a capability, so a product or a service can be included in the capability. . Product is related to capability with a process [EDGY]:

• process realises capability; process requires asset
• product requires capability; product is realised by process / process creates product.
• capability requires asset;
• organisation has capability

A capability is a ‘wrapper’ of elements belonging together. A capability can consist of specific assets depending on the business. Assets can be e.g. applications, data/information, technologies, facilities, equipment etc. For example, a hospital may have a capability for surgery, that consists of assets like facilities, equipment such as monitors, electrocardiogram (ECG) etc. Note! Data can be seen as an asset.

A capability can consist of people (with competencies as labels), organisational structures, processes, products and assets.

Capability Content

A capability can be modeled within a capability canvas, which can be defined in different forms. For example, a) a simplistic form, which introduces the behavior and structure (resources), and b) basic form, which contains architectural content together with organisation and product intersections.

Simplistic form

Simply showing the behavior and structure of a capability, plus people – to illustrate who is doing what, and with what.

Basic form

The basic form of capability content is a combination of architectural elements (Process, Asset) and organisation and product intersections.

Capabilities guide the modularisation of the enterprise by defining boundaries around what “belongs together”.

Capability Attributes and Additional Information

A capability consists of certain elements (attributes), that are required and necessary for the capability to be able to execute at the operational level. In addition, there can be certain extra information related to a capability, such as:

• Business Owner – who is responsible for a) operational performance and b) development of a capability
• Purpose – why such a capability is needed in the organisation
• Goal(s) – what changes to be made; which objectives are identified (e.g. according to OKR analyses), that can be pointed to the capability
• Risk(s) – what are the threats and weaknesses that can be identified as risks? Risks are outputs, that occur under the combined influence of external threats and internal weaknesses. Risks can be related to capabilities.
• Budget – what are the financial ‘boundaries’ (in some time frame).
• Customer(s) – what are the customer segments using the products and/or services realised by the capability
• Teams – which teams are working with the changes of the capability. To make a distinction between a) operational team(s) and b) development team(s). Some people / teams are working on concept design for the whole capability, and some teams are working on application development. Every team may utilize agile methods and tools (Scrum, Kanban etc.).

Capability can be associated with extra information. For example:

• it is interesting to associate capability with the costs of assets / resources, such as personnel (operational, development), applications (licenses) etc.
• a capability can be associated of a brand of its own,
• there is a business reason for being,
• strategic and operational goals,
• risks
• product(s) and/or service(s) realised by the capability,
• customer(s) related to product(s) and/or service(s) realised by the capability,
• organisational entities, developers, business owner etc.

All the elements of a capability core and related elements can be made visible.

Capability and Risk Modelling

Risks can modeled as outcomes that are associated with the elements of a capability. Another way is to model risks with the labels (as metrics).

Capabilities and Goal Setting

Setting goals is an important preliminary phase for every business transformation. Based on the goals it is possible e.g. to define roadmaps of changes to be made. Goals can be directed to capabilities to define why and what as shown below.

Element(s): Purpose, Capability. Relation(s): Link.

When setting goals it is important to make visible the relations between different levels of goals. This enables traceability from the higher level purpose(s) via the operational level goals and outcomes to capabilities – and back.

Roadmap of Capabilities

This view can be used for illustrating which capabilities are affected and when within a change program.

Capabilities and Customer View

Simon Sinek’s famous inspiration to ‘start with why’ (Youtube video) is a good starting point for all endeavors. This can be visualised with an applied version of the golden circle (Why, How, What) as shown in the figure below. The outermost circle is reserved for identifying the customers. Then we identify what are the products and/or services we might provide. Next, we analyse how those products and/or services can be realised: what are the capabilities we need to have in place. The inner circle defines the purpose and goals we have (in this context), explaining why we are doing what we are doing.

This example below illustrates how EDGY elements can be used for asking questions such as:

• what products and/or services do customers need, and which products and/or services we can provide to customers?
• how we can realise those products and/or services?
• why we are doing what we are doing?

This version below illustrates how we can focus (reframe) on what customers really want to do, what they want to get done – instead of concentrating on what we can provide. We can utilize EDGY elements for asking questions such as:

• what customers want to get done (Tasks)?
• how we can enable what is needed, what capabilities we need?
• why we are doing all this?

Galaxy Map – the Milky Way Map

Also known as Enterprise Map. A special type of capability map.

A Milky Way Map introduces the whole organisation at once: customer journey connecting to capabilities of the organisation. This diagram type can be used e.g. for analysing the whole enterprise, or some of its parts. The main advantage of this map is that it provides an overall overview, the big picture, the context of the enterprise for high-level analysis, which can be used as a starting point for more detailed analyses.

Element(s): e.g. Journey, Task, Capability, Purpose.

Process Map

Organisation’s processes can be grouped by certain criteria such as capability area or organisation-/business unit.

Element(s): Process.

Process

Element(s): Process.

Process Flow

A process can be expressed with a swimlane-syle diagram (figure below), which illustrates ‘who is doing what’ based on organisational actors.

Element(s): Process, Organisation. Relation(s): Flow.

According to Lean philosophy, it is beneficial to analyse a process and all the steps that are taken. It can be analysed e.g. which process steps can be automated (e.g. with RPA), or should some steps be avoided, joined or done differently etc. See the labels added to process -elements.

This version below illustrates how a process flow can be connected with applications. Tags can be used for adding extra information into elements. Outcome -element represents a business event that triggers the process.

Business Process(es) and Development Process(es)

The operational business of the enterprise can consist of several operational processes, depending on the business area and size of the business. These operational processes affect how organisation is arranged – how the units, groups and teams etc. are organised. The capabilities help with this: operational process defines what is the business, and capabilities define what is needed for executing that business and producing expected products and services to customers.

There can be several development processes, one per each operational process. Or, there can be only one development process for the whole business and all its operational processes, depending on the size of the business and the volume of the changes. All in all, it is important that all the related changes can be made holistically, without being siloed in organisational units. Enterprise design helps with this, as it takes a holistic approach and promotes co-design and leverages collaboration.

Operational Process

Organisation’s operational processes represent how organisation works, how it serves its customers and what products and services are provided to customers. This kind of high-level process, which binds capabilities together, can be identified as an operational value stream (also known in SAFe, see the link).

Development Process

The development process represents the change part of the capability map of the enterprise. The development process supports the operational business by managing the changes in organisation’s products, services and operational processes. Organisation’s development processes are typically performed with the help of agile practices (methods like Scrum and SAFe), appropriate tools (e.g. Jira, Confluence), and organised into agile teams.

Element(s): Process, Capability, Product, Activity. Relation(s): Flow, Link.

Note! The development process (above) is analogous to the conventional plan – build – run model. That is based on a product or service lifecycle management approach, which is somewhat analogous to what is represented in several frameworks such as Cobit or IT4IT, or ITIL4. SAFe uses the naming Development Value Stream.

Change Process – “Enterprise Design Activities”

Human decision-making is typically based on generic psychological activities (system 1 and system 2, according to Daniel Kahneman). The decision-making is impacted by the psychological implicit guidance and control (IGT) mechanisms. These activities apply also to any kind of maneuver, like decision-making in an organisation, when it interacts with the environment. [Lean Enterprise, Humble.J. et al.]

The overall decision-making activities are introduced quite exhaustively in OODA loop by US Air Force Colonel John Boyd. The OODA loop defines activities, Observe, Orient, Decide, Act, that are carried out by humans (like fighter pilots) when they interact with their environment. These same activities can be applied also to organisational decision-making too. An organisation is also observing its environment, orientating to ‘moves’ (status changes), and then deciding and acting. These activities are related to planning and executing changes: planning strategies and business, gathering customer insight for designing products and/or services – designing a better enterprise. The faster the loop is, the better the efficiency of an organisation is to react to changes in conditions of environment.

The OODA loop represents the flow of how an organisation analyses internal and external information, harvests customer insight, and then prepares and reacts to changes.

Element(s): Activity. Relation(s): Flow.

SIPOC (Suppliers – Inputs – Processes – Outputs – Customers)

The Six Sigma tool called SIPOC (Suppliers, Inputs, Processes, Outputs, Customers) can be used for defining all relevant elements of a process before improvement work (e.g. lean analysis) begins. This is an easy tool for analyzing the business case: what is the value the customer gets and how.

Element(s): Organisation, Object, Process. Relation(s): Flow.

Wardley Map

Wardley Maps is a framework created by Simon Wardley for designing and evolving strategies (link). Wardley maps can be used for analyses of strategic scenarios. A Wardley Map can be depicted by using the Task and the Capability elements of EDGY.

Asset Map

An example of usage is an Application Map (application architecture). An application map can be grouped by certain criteria such as organization unit, business unit, capability area (e.g. Finance, HR, Production) etc.

Element(s): Asset.

Application Map

Asset

An object we need and use to perform our capabilities.

Enterprises need to develop, buy and manage a broad range of tangible or intangible assets (such as buildings, machines, raw materials, software applications, financial assets and know-how) to perform the capabilities needed to run their business. [3]

Cloud service models of assets

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

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

More detailed cloud service models with different types of assets are illustrated in the figure below.

Information Flow Diagram

Also known as Application Interaction, Application Cooperation. Information flows can exist e.g. between a) organisations (business actors), b) processes, c) applications.

Element(s): Asset, Process, Organisation. Relation(s): Flow.

Organisation interactions (information flows) can be used for analyzing what information is exchanged between organisational entities (both internal and external).

Process interactions can be used for analyzing how the enterprise operates.

Application interactions can be used for analyzing which data elements are switched between applications.

Information flow in a B2B scenario shown below.

Activity Map

What is being done or going on in the enterprise or its ecosystem.

Also known as roadmap.

Element(s): Activity.

Object Map

Also known as Object Model, Entity Relationship Diagram, Domain Model or Data Model / Information Model.

Element(s): Object base element. Relation(s): Link.

People Map

Also known as Stakeholder Map. All the relevant groups of people within an enterprise can be illustrated – like circles of an onion: employees in the core, then partners etc., and customers on the outer circle.

Element(s): People.

Application Architecture

Detail-level application architecture can modeled with assets and their relations. Application architecture can be analysed at different abstraction levels, starting from high-level context diagrams, and then going into more detailed diagrams. For example, the C4 model consists of four (4) levels of diagrams: 1) System Context-, 2) Container-, 3) Component- and 4) Code diagrams.

Element(s): People, Asset. Relation(s): Flow, Link.

These examples below cover the Internet Banking System at different abstraction levels.

Application architecture can leverage from the Component Model approach:

Level-1: Context Diagram

Level-2: Composition Diagram

Level-3: Component Diagram

Labelling

It is possible to add short descriptions of the applications in the assets elements as shown in the figures above, to introduce the tasks of the applications. Some types of extra information can be expressed with labels (e.g. “Software System”, “External System”, “SaaS Application”, “COTS”, “In house Application”, “Web Application”, “Mobile App” etc.).

Interfaces

An application can provide two kinds of interfaces: 1) Graphical User Interface (GUI) and 2) Application Programming Interface (API). These interfaces can be analysed & designed with the Asset -elements. Labels can be used for indicating the type of interface as shown in the figure below.

Application A provides two interfaces: 1) GUI and 2) API. The GUI is used by the end user, and the API is used/required by Application B. Application A system boundary expresses as a dotted line.

Deployment Diagram

The deployment diagram illustrates the technology platform of a business application.

Asset type examples are shown below.

Application Integration Map

Data flows between applications (application interactions / application cooperations) are illustrated as a map like a ‘metro map’ / route map. With a map it is possible to find out a way – how data is transferred in the enterprise. Both internal and external integrations can be shown when appropriate (e.g. external parties are shown in the figure below, a Logistic company and a Bank).

Data flows can be added with extra information with colors or line widths explaining e.g. volumes, transfer protocols etc.

Capability Interactions

Data flows can be defined at a high level by analysing interdependencies between the capabilities.

Target Operating Model

For business planning purposes we can utilize an approach to identify fundamental elements of the operational business.

Goal Setting

Goals can be defined and visualized as a map of different level of goals.

Mission – Vision – Strategy

Mission and vision statements and strategy can be expressed with the Purpose -element.

The Purpose -element can be used for defining strategy and tactics, together with the Story -element.

Project

A project or a change 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.

The deliverable of a project can be e.g. a release of product (such as an application).

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

User Story

A user story can be modelled by using the Story -element. This is an applied way to utilize the Story -element, which is primarily meant for enterprise-level usage. However, many elements of EDGY can be used in different abstraction levels: e.g. a) enterprise-level, b) capability-level or c) asset-level (application etc.).

We can reuse the Strory -element by identifying user stories (like use cases). The Story -element can then be linked (associated) with other elements such as assets. This can be done e.g. for a single development target during the concept design phase. User stories can be defined e.g. for an application as shown below.

The typical syntax for a user story can be defined according to one of the following versions:

• As a < ROLE > I < CAN DO / WANT SMTHNG TO BE DONE >, so that < I CAN ACHIEVE THIS AND THAT >

An example user story as a text:

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

User stories explain what a user wants to do and achieve. It is also possible to define the actual goals with the Purpose -element.

Relation examples

Link examples

Link relations. ends can be labeled with labels (e.g. to show which role the element/party is playing).

Flow examples

Tree examples

Explicit hierarchy with Link relations.

Indented hierarchy.

Stacked hierarchy.

Labels

Labels can be used for indicating additional information about the element. E.g. to define more closely the type of the element. For example, an asset is a multipurpose element for different resources and aspects, so the label can be used to differentiate an asset from another: an application from a data element (information object).

Value Flow

The customer value and business value can be modelled with the EDGY labels (tags and metrics) as shown below.

Extras

Milky Way Map – the Big Picture of the Enterprise

‘Customer life meets the Enterprise’. The customer journey on the outer circle introduces what a customer does, and capabilities on the inner circle show what an organisation has (already now or in the future) in place for serving the customer.

EDGY overview

The EDGY is designed to connect people from different disciplines and become collaborative co-creators of better enterprises. The EDGY is a common language for enterprise design, which is a collaborative practice rather than a discipline of any kind.

EDGY elements and relations.

EDGY = Enterprise Design Graphical interplaY

Change in an enterprise can be started from any of the six aspects, in any order. A change demand can be triggered from outside or inside of an enterprise.

Enterprise Design Facet Model and questions.

Extras

EDGY mapping to ArchiMate®

Mapping from EDGY to ArchiMate (3.2) – an interpretation is shown here. The ‘official’ version can be found from here: link.

Base Elements

Facet and Intersection Elements

The Brand -element is quite debatable, it is questionable what is the counterpart in ArchiMate: Stakeholder or Meaning or..

Enterprise Design Facet Model & elements

EDGY elements and relations with people extensions (employee, customer).

— Eero Hosiaisluoma