Frameworks, Methods, Tools & Modeling (by Eero Hosiaisluoma)
Frameworks, Methods, Tools & Modeling (by Eero Hosiaisluoma)

Lean Enterprise Architecture Framework (LEAF)


The Lean Enterprise Architecture Framework (LEAF) is a tool- and modelling supported part of the Lean Enterprise Architecture Development (LEAD) approach (link). A case study introduced here.

The LEAD (aka Lean EA) approach consists of operating model, framework, and methods such as Goal-Driven Approach (GDA)Service-Driven Approach (SDA) and Layered Approach. The LEAD Operating Model organizes the enterprise’s capabilities around a value delivery chain, analogous to BizDevOps -approach. The LEAF is the core enabler of the LEAD method.

The Lean Enterprise Architecture Framework (LEAF)

The Lean Enterprise Architecture Framework (LEAF) can be used for visualization of overall aspects from ideas to production. The idea behind this LEAF is to manage end-to-end value delivery chains of any kind of development targets, such as services. The LEAF level-1 (the business architecture framework) consists of three layers as follows: 1) Management, 2) Value Delivery Chain and 3) Architecture Landscape (figure below).

Figure 1: Lean EA Framework (LEAF) level-1 – the “navigation landing page”, providing the visualization of the Lean EA -concept and related content in practice.

Management Part

The topmost Management layer of the Framework consists of management elements, from which all the other views and elements are to be derived from. These Management views and elements govern and guide the overall operational development of the enterprise. It is important to visualize all the top-level aspects that widely influence to overall development and operations of the organization. Typical management level elements are goals, the strategic intentions, from which all the other development elements and activities can be derived from. Other management level elements that guide the overall development are e.g. governance models and principles. Management can also identify required capabilities that are required to support strategies.

Value Delivery Chain Part

The middle layer, the Value Delivery Chain, is the end2end value delivery chain, which represents the operating model in practice (analogous to BizDevOps -approach). The value delivery chain-based approach is the fundamentally crucial idea behind this part of the LEAF. This delivery chain represents the “production line”, to which all the capabilities can be assigned to – in order to deliver value based on customer demands. The outcome of the process can be e.g. a new or modified service, process, operating model etc.

Capabilities are composed of organization resources: units, groups, roles and competencies. This Service Delivery Chain provides overall visibility to the life-cycle of each and every development target (such as service, digital transformation plan or any domain-specific development case). The service delivery chain can be used to manage the overall development, whether a service is in its early ideation or design phase, in the development phase, or whether the service is released into production. Accordingly, the service delivery chain is divided into phases that are related to the service life-cycle. These value streams are as follows: service design, service development, and finally the service operation. In addition, portfolios can be related to those phases accordingly: idea-, development- and service portfolios. There can be variations of this part of the LEAF depending on the other frameworks that can be used in the organization (such as SAFe, IT4IT, ITIL etc.). The value delivery chain can be defined according to the process that is the most appropriate and fits for purpose.

Architecture Landscape (the EA content) Part

The LEAF’s Architecture Landscape constitutes the actual enterprise architecture content: it contains the behavioral and structural architectural elements of the business domains of the organization. Each development target, -domain or -service (on the middle layer) is associated with relevant architectural views or diagrams, which are composed of architectural building blocks. These building blocks are maintained in the Architecture Landscape, which consists of business domains (as shown in figure 1 above). Each business domain (introduced on the 1st level) is linked to the 2nd level of the LEAF. An example of the 2nd level of the LEAF is illustrated in figure 2 below.

Figure 2: Lean EA Framework (LEAF) level-2 – the Architecture Landscape – based on the layered approach.

This part of the framework, the 2nd level, is organized into layers and aspects of the ArchiMate Framework (link), each of which consists of architectural elements such as business services and -processes, applications etc. These enterprise architecture content (architecture building blocks, ABBs) are maintained within the Architecture Landscape part of the framework. An additional Customer Views -layer can be added on top of the other layers. This customer-centric and Service Design aspect is positioned above all the organization’s internal behavioral and structural layers. This integrates the outside-in customer perspective to the inside-out organizational perspective together.

Note! These frameworks are examples, all the content placeholders (white boxes) can be identified and named to what is appropriate; content placeholders can be added, modified, removed or replaced according to what is essential in the organization. It is important to notice that these maps are collections (catalogs) of relevant elements in the enterprise architecture of an organization.
When customizing these content frameworks introduced here, the rule of thumb is to keep it simple. A good practice is to apply the Lean EA principles: use only the relevant content placeholders (“just enough”); create content placeholders only if needed (“just in time”) – not to create them “just in case”. However, content placeholders can act as reminders of what should be investigated and modeled. (A specific step-by-step method is to be introduced here.)

The Architecture Landscape provides a view to both the current state (as-is) and future state (to-be) of the organization and its parts. The elements of the Architecture Landscape are modeled together with those stakeholders that are involved in the design, development or operation of the services. Elements and diagrams are created according to Lean principles and “on-demand” basis: just enough and just in time.

A noteworthy fundamental difference compared to conventional, “content-based” approaches *), is that this LEAF is organized into layers according to the ArchiMate framework (link): biz, app, tech. This layered structure is analogous to methods such as the TOGAF ADM, or any variations of that. Another important consideration is that this layered approach is more practical for Lean development, in which multi-professional / multidisciplinary teams are co-designing development targets (such as services, digitalization strategy plans or some domain areas). It is easier for most of the stakeholders from diverse backgrounds to understand the big picture and overall context when it is visualized with layers.

*) Conventional “content-based” approach refers to EA domains introduced in TOGAF (Content Framework): business, data, application and technology.

This LEAF can be used together with other tools such as portfolio management tool, CMDB and/or ITSM. This framework can be implemented with any of the available modeling tools, that can be used for Enterprise Architecture Management (EAM) purposes. Some of the modeling tools can be integrated with other tools (such as mentioned above). The LEAF can also be aligned with other frameworks such as IT4IT or SAFe (that can be included into LEAF), or methods like Service Design or DevOps.

Visualization & Modelling

The framework can be created by using any visualization tool, as the framework and its content areas are agnostic to visualization styles or notations used. However, modeling with standard notations is the most systematic and professional way of managing enterprise architecture content. It is highly recommended to utilize a standard modeling notation for creating architecture artifacts. The most comprehensive and very popular modeling notation is ArchiMate, which can be used together with other optional standard notations such as BPMN and UML.

Use Cases Of The LEAF

This LEAF can be used e.g. for end2end Service development and operational purposes. In this usage scenario, the life-cycle of service can be managed with the help of the framework. For example, in the service design phase, the framework can be used for designing service blueprints or customer journeys. All the new and existing application services etc. can be linked to the process diagrams whenever necessary. In the service development phase, all the related elements can be linked to the service in development: e.g. business drivers and goals, requirements, business actors, other business services and -processes, other application services and applications, and finally, all the relevant technology elements such as technology services, platforms, software, servers, communication networks etc. When the Service is realized and deployed to production, all the operational aspects can be added into those same diagrams or completely new diagrams, all of which can help operational tasks of the services on production.

Development Methods With LEAF

There are several enterprise development methods that can be utilized with the LEAF. Those methods can be used as step-by-step development approaches – for any development targets of any size (e.g. services, digitalization plans, business domains etc.). Examples of practical methods are as follows:

  • Service-Driven Approach (SDA) – a simple method that focuses on services (instead of projects) as basic units of value creation and development
  • TOGAF ADM and ArchiMate combination.

The Service-Driven Approach (SDA) (link) is a method that focuses on services – instead of projects for example. SDA is all about services: “everything is a service“. A “service” is the primary unit of value creation and unit of development target. A “service” is designed based on customer viewpoint – by taking into account the “customer experience by design”. The LEAF visualizes how services flow through the service delivery chain, the “production line”, from conceptual services to realized services on production. This is how the LEAF concretizes the service life cycle management. As such, LEAF as a framework – implemented on modeling tool – provides a pragmatic, concrete tool for service development in practice. The SDA combines terminologies, principles, tools and methods from two complementary disciplines: 1) Service Design and 2) Enterprise Architecture.

TOGAF ADM can be used together with ArchiMate (figure below), as the ADM phases B to D map perfectly to ArchiMate layers: Business, Application and Technology. Also, ADM phases A, E and F can be modeled with ArchiMate Motivation and Implementation & Migration elements. In addition, ArchiMate Strategy elements can be used for modelling strategy aspects.

Figure 3: TOGAF ADM & ArchiMate.

Reference Implementation Published As HTML

  • Check the LEAF reference implementation via this link.

The model is created with Sparx EA tool (link). As typical to Sparx EA models, visual elements can be clicked to drill-down into the child diagram. If there is a child diagram included, it is marked with “glasses” sign on the bottom right corner of the element. More example content is to be added continuously into this model.

Note! The LEAF framework can be implemented on any EA-tool in addition to Sparx EA, such as QPR EA, BIZZdesign EA, Orbus iServer, Mavim etc.

LEAF in practice

The LEAF can be implemented on any appropriate modeling tool. Some tools, such as Sparx EA, provide powerful scripting- and data import capabilities. With scripting, it is possible e.g. create new model elements with relations automatically. For more advanced purposes, even the whole model can be created based on the existing data.

For advanced visualization purposes, the LEAF model data can be transferred to a Graph Database such as Neo4j. There is a couple of alternative ways to do that. The main advantages of using a graph database for end-user visualization, are as follows: a) the user experience of visualization can be made much more attractive. As a result of this, enterprise architecture data can be made more effective; b) enterprise architecture data can be combined and enriched with any data from other data sources.

For documentation purposes, an architecture model maintained in a repository, can be used for dynamic document creation. Most of the modelling tools provide document generation capabilities, with which a set or subset of the model repository data can be used for generating a document (e.g. Word or pdf format). For example, a document can be generated based on diagrams and description texts that are maintained in the modelling tool. No extra effort is needed for documentation. This is aligned e.g. with SAFe Model-Based Systems Engineering (MBSE) recommendation to “generate documents from the information in system models” (link).

For more details see:


The Lean Enterprise Architecture Framework (LEAF) can be used with an appropriate development method in an organization to support design, development and operation of services. The LEAF simplifies conventional Enterprise Architecture approaches and artifacts into a 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. The main advantage of this kind of framework is to provide a easier approach to support Lean and agile overall, holistic enterprise development ion an organization, which is not architecture-driven but development-driven: a simple and easy approach for all the stakeholders.