Lean Enterprise Architecture Framework (LEAF)

Introduction

The Lean Enterprise Architecture Framework (LEAF) is a tool- and modelling supported part of the Lean Enterprise Architecture Development (LEAD) approach. The LEAD approach consists of operating model, framework, and Service-Driven Approach (SDA) as a method. The LEAD Operating Model organizes enterprise’s capabilities around a value delivery chain. The LEAD framework is this LEAF that is introduced here. Overall, the LEAD is a tool supported, pragmatic method that covers all the management, design, development and operational activities in the organization.

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 consists of three layers as follows: 1) Management, 2) Value Delivery Chain and 3) Architecture Landscape (figure 1 below).

Lean EA Framework
Figure 1: Lean EA Framework (LEAF).

(See the reference implementation created with Sparx EA via this link).

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. The value delivery chain based approach is the fundamentally crucial idea behind this part of the LEAF. This delivery chain represents the “production line”, in 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 from organization resources: units, groups, roles and competencies. This Service Delivery Chain provides overall visibility to 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 development phase, or whether the service is released into production. Accordingly, the service delivery chain is divided into phases that are related to 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 process that is the most appropriate and fits for purpose.

Architecture Landscape Part

Each development target, -domain or -service (on the middle layer) is associated with relevant architectural views or diagrams, which are composed from architectural building blocks. These building blocks are maintained in the Architecture Landscape, which can be organized e.g. according to business domains.  This part of the framework can be organized into layers, each of which consists of architectural elements such as business services and -processes, applications etc. Alternatively, this Architecture Landscape can be organized e.g. into business related domains or other domains, that can be composed based on some specific criteria (such as capability area, digital transformation plan, or some logical grouping such as Gartner’s “pace-layered strategy”). The Architecture Landscape provides a view to both current state and future state of the organization and its parts. The elements of the Architecture Landscape are modeled together with those stakeholders that are involved in design, development or operation of the services. Elements and diagrams are created when needed: just in time, not just in case – according to Lean principles.

The framework can be created by any modeling tool that supports standard modeling notation, ArchiMate, and some other optional standard notations such as BPMN and UML.  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 modelling 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 (that can be included into LEAF).

The reference implementation created with Sparx EA tool is available via this link (as HTML version).

The actual enterprise architecture content (architecture building blocks, ABBs) are maintained within “Architecture Landscape” part of the framework. Architecture part is based on ArchiMate Framework, which consists of the most relevant concepts of an enterprise. This Architecture part is on the 2nd level of the LEAF (figure below).

Architecture Landscape.

Note! Every placeholder on the landscape (figure above) can contain more specialized views (diagram types) – according to what is appropriate for the purpose. For example, “Business Services” can contain e.g. Business Services Maps, Service Blueprints, Customer Journeys etc. Business Processes can contain e.g. Process Maps and Process Co-operation Views. Business Actors can contain Maps of Actors and Actor Co-operation Views. Applications can contain Application Maps and Application Co-operation Views.

A noteworthy fundamental difference compared to conventional, “content based” approaches *), is that this LEAF is organized into layers: 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 startegy plans or some domain areas). It is easier to 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.

Variations Of The Framework

There can be different variations of the LEAF, depending on the case. The middle layer of the Framework can be modified according to the operating model and value stream approach that are used in the organization. The Architecture Landscape part can be organized according to EA content management approach or the organization structure.

The middle layer (Value Delivery Chain) contains the portfolios e.g. as follows: 1) the idea portfolio, 2) the development portfolio and 3) the service portfolio. Roadmaps can be located in this part.

The bottom layer (Architecture Landscape) contains the actual EA content. This layer of the LEAF can be modified according to organisation’s preferences. For example, the Architecture Landscape can be organized based on following aspects:

  1. Business Domains, each of which contains the actual EA content on the 2nd level (when opened on the 1st level). The overall view of the enterprise is on the top of the underlying domains (figure 1),
  2. Architectural layers (according to ArchiMate): Business Layer, Application Layer and Technology Layer. Motivation aspect on the left side and layered views on the right side (figure 3),
  3. Conventional EA domains: Business-, Data-, Application and Technology Architectures (figure 4).

LEAF – variant 2: Architectural Layers (according to ArchiMate framework)

Figure 3: LEAF variant 2.

LEAF – variant 3: Conventional EA Domains (Business, Data, Application, Technology)

Figure 4: LEAF variant 3.

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 a 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 primary unit of value creation and unit of development target. 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 7: TOGAF ADM & ArchiMate.

Reference Implementation Published As HTML

This LEAF reference implementation is created with Sparx EA tool (link), from which the model published into HTML and made accessible via this 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.

LEAF in practice

The LEAF can be implemented on any appropriate modeling tool. Some tools, such as Sparx EA, provides 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 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).

Conclusions

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.

Leave a comment

Your email address will not be published. Required fields are marked *