Lean Enterprise Architecture Framework (LEAF)

Intro

Lean EA approach supports the holistic development of an organization. Lean EA consists of value chain-based development operating model (LEAD) and integrated Enterprise Architecture (EA) practice – with the supporting framework (LEAF). The Lean EA combines management and operational development with the EA.

First some basic facts: Lean EA is not focusing on EA. Lean EA is focusing on the overall business development work of an organization (incl. management, operational development and operational business). That’s the beef. A Lean way to produce services and products from idea to production. Lean EA is focusing on the outside-in view, the customer perspective, which is in the heart of business orientation – not IT orientation. The EA function is just a supporting practice, but a crucial one. That’s why it is called Lean EA. EA is integrated into the overall management, development and operational business as shown in the figure below. The EA provides maps and views to the behavior and structure of an organization (the foundation of the Digital Twin of an Organization, DTO).

In the Lean EA context, the production line is the development value chain of an organization, which produces digital services and products or process improvements. This operational development performs changes to the operational business (to operative level / operations / production / execution of the organization). As such, the Lean EA supports the management and operational development of an organization, in order to manage and develop changes to the actual operational business. The EA is integrated into the development work. The main focus is on the development value chain, but the EA is an important part of it. The Lean EA encourages to do architecture just enough and just-in-time – together with other roles for analyzing and planning the concepts for the development (build or buy).

Lean philosophy is taken as a fundamental backbone as it is based on the performance of the customer value creation process. The production means here in this context: the production line of developing digital services and products, from idea to production. Including all the supporting functions required.

What is Lean? The core idea is to maximize customer value while minimizing waste. The ultimate goal is to provide perfect value to the customer through a perfect value creation process. A popular misconception is that lean is suited only for manufacturing. Not true. Lean applies in every business and every process. It is not a tactic or a cost reduction program, but a way of thinking and acting for an entire organization. [Lean Enterprise Institute]

What is Lean EA?

Lean EA approach consists of value chain based development operating model (LEAD) and the supporting framework (LEAF). The Lean principles are behind the development operating model, into which the revised EA practice is integrated. That’s why it is called the Lean EA.

LEAD is a business-oriented practical approach, which is based on the development value chain. The basic idea is to model all the incoming demands right from the beginning. All the incoming demands are handled by Demand Management, which is a multidisciplinary actor. The Demand Management works in sprints and utilizes an agile board (Kanban-board) for managing development cases. All the demands are then analyzed and created as concepts for the development portfolio. Prioritized concepts are taken into development (build or buy), and finally delivered to production. EA provides the overall insight to the behavior and structure of the organization. This overall architecture content is maintained with the LEAF -framework on EA-tool by the architecture team (or guild members). Architects are involved in Demand Management, and they are having a Kanban-board for all the architecture tasks.

• See more details covering the LEAD as a method from here: link.
• A case study using Lean EA in practice is introduced here: link, and related research article (from Research Gate): link

The Lean Enterprise Architecture Framework (LEAF) version 1 (v1)

The “Lean EA house” represents the organization (figure above). This visual representation intuitively bridges the thinking to the concept of Digital Twin of an Organization (DTO), which can be (according to Gartner) the next evolution of EA. The DTO is a digital representation (model) of an organization: all its elements and their relations. From the DTO, we can see how the organization works, and what are the parts from which it is composed of. As such, the EA content is the key enabler of the digital twin of an organization, so there is a clear analogy between the EA content and the DTO. The level-2 of the Lean EA house shows the elements as maps and views, grouped into business units as domains. The overall EA content consists of behavioral and structural elements and their relations of the domains. This is the foundation of the Digital Twin of an Organization (DTO). The Lean EA Framework provides an approach to start building a comprehensive DTO.

The Lean Enterprise Architecture Framework (LEAF) version 2 (v2)

The LEAF supports the operational development according to the Lean EA -approach (the LEAD). LEAF is a meta-framework, that can be utilized together with other frameworks and methods (such as DevOps, IT4IT, ITIL4, Cobit, SAFe, Scrum, Lean, Togaf).

The Lean EA encourages to do architecture just enough and just-in-time. The LEAF can be used for visualization of each development case – from ideas to production. The LEAF is modelling language agnostic, but the preferred modeling notation is ArchiMate. ArchiMate is the most comprehensive modelling notation, and especially suitable for enterprise architecture modelling (see ArchiMate Cookbook).

LEAF v2 Level-1

The LEAF v2 level-1 (the business architecture framework) consists of three parts as follows:

1. Management,
2. Operational Development,
3. Architecture Landscape.

This is the organization-level view, which supports management and operational development. Actual architecture content is placed in the domain-specific views at the Architecture Landscape part.

1. Management

The topmost Management part of the Framework consists of management elements such as strategy views, value streams, capabilities and principles. The management content (the views) governs and guides the overall operational development of the organization. It is useful and practical to visualize all the management-level aspects as maps and/or views, as they affect all other views that are to be visualized.

A View represents any kind of diagram that depicts some area of interest, e.g. “strategic goals” (like an OKR view), “operational value stream”, or “process cooperation view”. A Map, in turn, is an inventory list of elements like a “capability map”. At modelling level, all the maps and views are diagrams.

2. Operational Development

The middle layer, the development Value Delivery Chain, is the end2end development value delivery chain, which represents the operating model in practice. The value delivery chain consists of phases (value streams) as follows: 1) Design, 2) Development and 3) Operation (Production). These phases are typical to Plan-Build-Run service life-cycle model (as versioned in other frameworks such as Cobit and IT4IT). In addition, this organization level development approach is following the A-B-C -model: Analyze, Build and Consume.

The value delivery chain is linked with the organizational capabilities (actors, functions), that are involved in certain phases of the overall end2end development value chain. The value delivery chain can be defined according to the process that is the most appropriate and fits for purpose in the organization.

In addition, the middle part of the LEAF level-1 contains also content placeholders for development- and service portfolios and development roadmaps.

3. Architecture Landscape

The LEAF’s Architecture Landscape constitutes the actual enterprise architecture content for each business unit (domain) of the organization. These domain content areas are shown as “Domain” content placeholders, each of which opens the level-2 (below).

LEAF v2 Level-2

Each domain content area (on level-2) consists of content placeholders. These content placeholders are divided into Maps and Views, which are based on the fact that there exist two kinds of views (diagrams types): 1) maps of elements and 2) views of elements and their relations. Every diagram is either a map or a view.

Note! Level-2 can be modified according to what is appropriate in the organization, or in the business unit. These domain content areas (one for each unit) can differ from each other. For example, some units can be technologically oriented and there can be some extra content placeholder such as “Technology Services” and “Technology Platforms” etc. As Maps and Views -content areas can differ from one unit to another, this makes the LEAF level-2 easy to fit for purpose.

Here is another version of the level-2, which is based on the layers as follows: business, application and technology – according to ArchiMate core framework layers.

LEAF Content Areas and Diagram types

LEAF v2 Level-1 diagram types

LEAF v2 level-2 diagram types

Maps & Views

There are two kinds of diagrams in the architecture content of an organization:

1. Maps (inventory lists of behavioral and structural elements of the organization, may grouped based on a certain criteria)
   • E.g. Capability Map, Process Map, Application Map
2. Views (consist of elements and their relations, taken from a ceratin viewpoint, covering a specific and restricted area of interest)
   • E.g. Layered View, Actor cooperation View

All the diagrams that are to be created can be divided into these two categories. It is reasonable to divide the architecture content into these categories, so that:

• the diagrams are easy to place into certain content area in the framework
• the diagrams are easy to find (for communication and publishing)

Maps

The maps are inventories of elements of certain types such as services or applications, which end up in maps like “service map” or “application map”. The maps are created on the organization and/or business unit level.

Elements on a map can be grouped based on certain business-relevant criteria, according to what is appropriate in the business context. E.g. application map can be grouped based on the unit, a capability area, or a service area. This grouping can be visually informative (at model level grouping makes relations between the group and the elements).

Note! Maps are useful, but at the end of the day, they are nothing but grouped lists of elements. E.g. a capability map just introduces WHAT are the capabilities of an organization, but this does not explain WHY these capabilities are there for. This is why a value stream view is valuable: it explains what capabilities are linked with which value stream stage, and what is the value add per each stage. This is why we need the views that relate the elements to each other. One kind of element types between other kinds of element types.

Views

The views are all the other diagrams that are not maps. The views are taken from a certain viewpoint. They provide some specific, restricted views against the overall view of an organization. A view consists of the behavioral and structural elements and their relations (structural, dependency, or dynamic). When creating views we utilize maps as they provide the elements that are used in the views. A view depicts some logically cohesive combination of elements.

A view is a “zoomed picture” from the “overall big picture”. Or the other way round: a view gives a “big picture” of a specific restricted area of interest. Typically this means some development target case, when some customer or business demand is to be first conceptualized and then analyzed in more detailed.

The views are created based on just-in-time principle for each development case (e.g. a solution, a restricted area of interest) whenever there is a need (demand) for a change. The views typically are “living objects” by their nature: they start from a simplification that gets updated with more details as the knowledge increases… not necessarily ending to perfection – as the Lean EA principle is pointing: just enough architecture is reasonable.

Note! Often diagram with a readiness state of 80% is good enough. What is enough, is up to the modeller her- or himself. The “knowing” comes along with the experience. It is intuition. It is in the diagram already, you just have to recognize what is relevant. Often this matter is revealed when you notice that you’ve been thinking of and adding more and more details for some time – without changing the basic “message” or “feel” of the diagram. You should now and then ask yourself: “to whom this diagram is meant for?” To whom I’m creating this view”. It should be clear what is the purpose of the diagram, why, where it is to be used and to whom it is to be meant for. “The meaning is in the use” (as it has been said that Wittgenstein has put it). So do not add things trying to get a complete end result, but rather, reduce details as much as possible until there is nothing to be left out, without losing some essential points! Then you might realize what is enough. Keep it simple, stupid (KISS)!

Maps & Views in LEAF level-2

Maps and Views content areas are visually the same sized as they both play important role in managing the enterprise architecture content of an organization. These content types have different purposes though: Maps are used for keeping a list of the elements of the behavior and structure of the organization. Views are architectural figures that use those elements from the maps, but add relations between the elements. Maps are important when keeping all the elements in a coherent order.

Maps are necessary for enterprise architecture management purposes, whereas the views are used for day-to-day architecture work. There may be only a few maps in an organization and/or unit, but a continuously increasing number of views. Views are created on both Enterprise Architecture (EA) and solution architecture (SA) levels. Dividing diagrams based on their type makes architecture content management an easier task to do.

The model structure in the repository follows the Maps & Views idea as shown in the figure. By organizing the repository structure according to the LEAF framework, keeps the diagrams and related elements in the correct places. This requires a disciplined way of working. Also, it requires that all the diagram types and elements are agreed and communicated between the architects of the organization. The LEAF provides a set of the most useful diagram types and a ready-made meta-model for the modelling elements (to be used in diagrams).

The most useful diagram types are as follows: Layered View, Cooperation View [variants a) actors, b) processes and c) applications], and Conceptual Data model (of business concepts/-objects).

It is good practice to place the common, re-usable elements (such as business services, applications etc.) of maps under the Maps, from where they can be managed and found easily. This is especially useful in Sparx EA, which stores the elements under the same folder (package) as the diagram by default. If the elements are not dragged into the specific Map -folder (such as Applications), the model gets degenerated and fragmented slowly. (E.g. Archi -tool places elements in the element-specific folders automatically.)

All the views (such as layered views, actor cooperations etc.) are to be placed into the sub-folders under the Views. This makes both creation and finding easier of diagrams of the same type.

Using the Maps & Views idea for classifying the diagrams makes the overall architecture work and architecture content management easier in the long run. Organizing diagrams and related elements based on their type pays back very quickly. A coherent repository speeds the modelling work in practice. Diagrams are easy to do and easy to find.

A model repository needs continuous refactoring and a disciplined way of modelling – no matter which EA-tool is used in the organization. A good principle is to keep it simple. It is important that architecture diagrams are to be created in the first place – for each and every development case that flows through the development value delivery chain (from idea to production). To encourage business developers to create architecture content, architecture should be easy task to do. It is a good practice to start small – and start quickly. Right from the beginning. Then add more details if necessary. Sometimes just a good overview picture is enough (see LEAF level-2 placeholder for overviews – the diagrams of the free form).

Reference Implementation Published As HTML

The LEAF framework can be implemented on any EA-tool such as Sparx EA, Archi, QPR EA, BIZZdesign EA, Orbus iServer, Mavim etc.

This reference implementation is created with Sparx EA tool, and then imported as MEFF -format to the Archi-tool.

Some tools, such as Sparx EA or Archi, provide powerful scripting- and data import capabilities. With scripting, it is possible e.g. create new model elements with relations automatically, or the model can be populated based on the existing data.

LEAF v1 reference implementation with Sparx EA

LEAF v1 Sparx EA reference implementation link

LEAF v2 reference implementation with Sparx EA

LEAF v2 Sparx EA reference implementation link

LEAF v1 reference implmentation with Archi

LEAF v1 Archi reference implementation link

LEAF in practice

The LEAF can be used e.g. for end2end Service design, development and operational purposes, together with the LEAD -method of the Lean EA approach. In this usage scenario, the life-cycle of service can be managed with the help of the framework. For example, in the design phase, the framework provides all the existing elements (such as services, processes and applications) that can be used and linked with the new elements.

For more details see:

• Lean EA Development (LEAD)
• Lean Enterprise Architecture Method For Value Chain Based Development In Public Sector ( a research article, 2018)

These above-mentioned articles give more detailed information on how the Lean EA -approach can be adapted in practice, and how the development value delivery chain (aka Idea-to-Production) works.

LEAF – an easy way to do and manage EA

The Lean Enterprise Architecture Framework (LEAF) can be used with an appropriate development method in an organization to support the design, development and operation of digital services or products. The LEAF simplifies conventional, traditional Enterprise Architecture approaches and artifacts to more practical approach. The terminology is simplified and only the most relevant elements are introduced for the sake of simplicity. The LEAF can be applied and modified to fit for the purpose and what is appropriate in the organization. The main advantage of this kind of framework is to provide an easier approach to support holistic enterprise development in an organization.

The LEAF provides a foundational platfom for a Digital Twin of an Organization (DTO). The DTO is a digital representation (model) of an organization, from which we can see how the organization works, and from which parts the organization is made of: what are its customers, what are the products and/or services, processes, actors, data, applications and technologies. There is an analogy between the EA content and the DTO. The LEAF “house” is an approach towards the real DTO…

The Lean EA is an easy way to do EA and manage the EA content. Lean EA is based on the LEAD and is supported by the LEAF.

Terminology

Term	Description
Demand	E.g. Business-, customer-, strategy- or technology-related idea or requirement, triggered by some business actor.
Demand Management	A multidisciplinary function/actor (team) that handles all the incoming demands. Consists of business developers, architects, product owners, technology specialists etc.
Development case	Development target that is first handled as a demand or idea or requirement then processed and prepared to a concept. A concept can then be either accepted into the development portfolio, or rejected. From the development portfolio the cases are flowing into the development phase, and finally they are ready for production.
Diagram	A modelling artifact. Figure that is created by a modeling tool (with some modelling notation). Can be either a Map or a View.
Diagram type	E.g. Overview, Layered View, Cooperation View, Capability Map etc. (Introduced more detailed in LEAF).
Lean	The core idea is to maximize customer value while minimizing waste. The ultimate goal is to provide perfect value to the customer through a perfect value creation process. A popular misconception is that lean is suited only for manufacturing. Not true. Lean applies in every business and every process. It is not a tactic or a cost reduction program, but a way of thinking and acting for an entire organization. [Lean Enterprise Institute]
Lean EA	An approach that consists of the value chain based development operating model (LEAD) and the supporting framework (LEAF). The Lean principles are behind the development operating model, into which the revised EA practice is integrated.
Lean Manager	A central role that leads and facilitates the Demand Management, develops the development process and plays an important role in communication and relations (e.g. with management) of the overall Lean EA practicing in the organization.
Map	Diagram class. An inventory list of elements, possibly grouped based on some business-relevant criteria (such as business unit, or capability are, or service are). E.g. capability map, application map.
View	Diagram class. Represents any kind of diagram that depicts some area of interest, taken from a certain viewpoint. Consists of elements and their relations. The elements are typically harvested and maintained with Maps.