The Lean Enterprise Architecture Framework (LEAF) is a tool- and modelling supported part of the Lean Enterprise Architecture Development (LEAD) approach (see “Lean Enterprise Architecture Development (LEAD) Method – A Practical Approach” link). The LEAD approach consists of operating model and framework. The LEAD Operating Model organizes enterprise’s capabilities around value delivery chain. The LEAF tool supported, concrete method that covers all the management, design, development and operational activities in the organization.
The LEAD combines Lean and Agile thinking with overall, holistic system thinking. This enables modern enterprise development & delivery approach, which covers all the aspects from strategy planning to operations. Then LEAD approach can be used for implementing cultural change to enterprise development, with practical architecture method. This highly promotes collaboration and visibility of all the development activities. In the LEAD approach, all the organization’s capabilities are integrated to deliver value to its customers.
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 services, domains or any kind of development targets. The LEAF consists of three layers as follows: 1) Management, 2) Service Delivery Chain and 3) Architecture Landscape (figure 1 below).
(See the reference implementation created with Sparx EA via this link).
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 that are the strategic intentions of the management, from which all the further development elements and activities are to be derived from.
The middle layer, the Service 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 add services on customer demand. 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.).
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).
Architecture Landscape – Enterprise Architecture Building Blocks
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).
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 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.
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:
- 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),
- 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),
- Conventional EA domains: Business-, Data-, Application and Technology Architectures (figure 4).
LEAF – variant 2: Architectural Layers (according to ArchiMate framework)
LEAF – variant 3: Conventional EA Domains (Business, Data, Application, Technology)
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 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.
The LEAD way of working differs from the conventional enterprise architecture work e.g. as follows:
- Architecture work is participating in all the (service) development activities (build or buy) – right from the start. There is no more distinct architecture reviews at specific checkpoints afterwards, but continuous participation and support already from the early phases (ideation).
- Architecture deliverables are co-created together with customers, customer relationship personnel, and architects, to share common understanding between all the parties.
- Architecture deliverables are created just-in-time – not just-in-case. Architects co-operate with customer representatives, projects etc. and they create together architectural content only when needed.
- Architecture deliverables / Architectural landscape shall be visualized and made available for the whole organization, by utilizing an EA-tool that supports publish functionality and standard notation(s)
- etc. (see more via LEAF from “Principles, policies” here)
There are several enterprise development methods that can be utilized with the LEAD. 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.). The Lean Framework contains some examples as follows:
- Service-Driven Approach – a simple method that focuses on services (instead of projects) as basic units of value creation and development
- TOGAF ADM and ArchiMate combination (figure 3)
- Simplified EA Method (figure 4)
TOGAF ADM can be used together with ArchiMate (figure 3), 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.
Here is the Simplified EA Method (figure 4), which is based on TOGAF ADM. This is an example of applied TOGAF ADM variation, a customized adaptation for organization specific needs.
Service-Driven Approach (SDA)
The LEAD encourages to Service-Driven Approach (SDA), in which the enterprise operational development is focusing on services – instead of projects. So it is all about services: “everything is a service“. A service is unit of value creation and unit of development target. The framework 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, this framework – implemented on modeling tool – provides a pragmatic, concrete tool and method for service development in practice. This reference model (link), that is created with Sparx EA -tool, can be taken in to use and adapted to fit for purpose immediately.
LEAD Key Enablers – An EA-tool and Standard Modelling Language
LEAD operating model can be supported by an EA-tool that supports publish functionality and standard modelling notation(s). Though enterprise modeling is more art than science, a combination of Framework, Method and Tool make the enterprise development more systematic and professional.
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 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 up to date enterprise architecture model can be used for dynamic document creation whenever needed. Most of the modeling tools provide document generation capabilities. This is aligned e.g. with SAFe Model-Based Systems Engineering (MBSE) recommendation to “generate documents from the information in system models” (link).