The Lean Enterprise Architecture Framework (LEAF) is a tool- and modelling supported part of the Lean Enterprise Architecture Development (LEAD) approach (link). The LEAD 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 enterprise’s capabilities around a value delivery chain. 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 consists of three layers as follows: 1) Management, 2) Value Delivery Chain and 3) Architecture Landscape (figure below).
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
The foundation layer of the LEAF is the Architecture Landscape. 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 consists of business domains (as shown in the figure 1 above). Each business domain (on the 1st level) is linked to the 2nd level of the LEAF. The 2nd level of the LEAF is illustrated in the figure 2 below.
This part of the framework, the 2nd level, is organized into layers according to ArchiMate Framework (link), each of which consists of architectural elements such as business services and -processes, applications etc. The actual 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 the 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 inside-out organizational perspective together.
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 according to Lean principles: 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 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 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.
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 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, modelling with standard notations is the most systematic and professional way of managing enterprise architecture content. It is highly recommended to utilize a standard modelling notation for creating architecture artifacts. The most comprehensive and very popular modelling 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 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. A “service” is designed based on customer viewpoint – by taking 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.
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, 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).
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.