Lean Enterprise Architecture Development

Value Chain Based Lean Enterprise Aware Design, Development & Operations.

Drivers For Change

Continuous change in operational environment with new digital enabler technologies are driving enterprises to cultural and organizational changes. The overall development has to be organized around creating and delivering added value to customer. Organizations have to be more efficient and capable of providing new digital services. Customer experience – during the customer journey through diverse services – is the most important driving force for enterprises and ecosystems in this digital era. New services have to be designed according to customer needs, organizational value streams have to be adapted to the most optimal customer value add creation and delivery.

In addition, new computing models such as cloud, mobility, Internet of Things (IoT), blockchain and API economy enable new business models. For surviving in this continuously accelerating pace, organizations are forced to adjust their operating models accordingly. All this requires new operating models with adjusted and calibrated capabilities. As the velocity and volume of new services increases, the organization’s internal structure becomes more volatile without systematic governance. These challenges can be competed with Lean & Agile Development approach, which is an integrated operating model with adjusted capabilities and modern tools.  

Lean & Agile Development Approach

Overall operational development of an organization can be enabled with Lean & agile practices together with pragmatic architecture. Lean Enterprise Architecture Development (LEAD) is a holistic and pragmatic overall method that is based on value chain based approach. The LEAD (aka Lean EA) consists of operating model and integrated Enterprise Architecture (EA) practice.

The LEAD value chain is a development value stream, that is focused on creating and delivering customer and business value. Triggers for change can be initiated based on strategic goals and customer- and business on-demand based ideas. All the relevant capabilities are integrated into the value stream. The LEAD operating model is organized around the value delivery chain, which provides single funnel for all the customer- and business-driven demands. The overall development is based on Lean and agile principles such as co-operation and visibility.

The LEAD operating model is based on Lean principles and common agile practices, together with modernized and revised Enterprise Architecture Management (EAM) function. Appropriate agile methods and tools are applied to fit for purpose, such as sprints, meeting practices, Kanban and backlogs. Other frameworks and methods can be applied with the LEAD operating model, such as SAFe, IT4IT, ITIL, DevOps, Scrum, Kanban, “Scrumban” or whatever is used in the organization. The overall flow rate (throughput) from idea to production can also be measured. LEAD-method is described more detailed in this article (link). The LEAD value delivery chain is illustrated in the figure below.

Figure 1: Value Delivery Chain – Idea to Production – process, the “production line”. Analogous to BizDevOps -approach.

Idea to Production process flow :

  1. Demands are based on a) customer needs, b) strategic goals, c) regulations & legislation, d) changes in business conditions or technologies
  2. Demand Management team handles all the incoming demands and creates concepts (the Biz)
  3. Portfolio Management evaluates the concepts and directs them to development queues
  4. Development teams develop the concepts to realised services or products according to agile methods (the Dev)
  5. Services or products are deployed on production to be operated by the IT Operations Management (the Ops)

LEAD is Concrete, Coherent and Cohesive combination of following aspects:

  1. Operating model is based on value stream approach, with integrated capabilities
  2. Framework is supporting the Operating Model concretely
  3. Tool is supporting the Framework in practice.

Notes of Frameworks, Lean & agile methods:

  • Frameworks, Lean and agile methods and principles provide useful foundation for terminology and meeting practices
  • Frameworks and methods are to be applied, not taken strict disciplines by default

“Enterprise Design”

Culture And Structure

Not only the business models and operating models are subjects to change, but also the enterprise itself: its culture and organizational structures. The culture has to be changed, to make the organization capable to respond rapid changes in the environment. “Culture eats strategy for breakfast”, means that culture can be impediment for strategy execution. According to Gartner, “people and culture are the top barriers to change”. But also, “culture follows structure”, means that organizational structures are real root causes for many obstacles in an organization. So it would be valuable to start the change from the structures first, then the change in mindset can be easier. As the customer is the king, customer experience is dictating how new services are to be designed. A customer journey may covers several services in several business units, or it may crosses organizational boundaries in the case of ecosystem services. The overall mindset has to be adjusted to customer orientation and collaboration. For the most effective changes, both the customer satisfaction and the employee satisfaction shall be taken care. The latter produces the former. If people feel that they are trusted and appreciated, they perform well. In turn, stressed employees result reduced productivity, which reflects harmfully to revenue.

Organization should have agile competencies and modernized culture and structures, to be ready for new and continuously changing business environment conditions and demands.  If we change the structure and culture first, we are ready to play the game – with well prepared, exercised and motivated people in an open, collaborative and supporting atmosphere.

Shift From Projects To Products And Services

New customer -and business-driven demands may vary a lot, and they are triggered faster than ever before. To respond to these demands efficiently enough, it requires specific skills and competencies from organization. Designers and developers have to be more customer-oriented and more agile. New methods, tools and practices have to be adopted. To enable fast responding and continuous development model, organization have to shift from project-based model to product- and service-driven development approaches. This requires new skills and roles to be learned. This paradigm shift from projects to products and services is must: projects are timely restricted structures that are limited in their applicability to continuous change, whereas product- and service-driven development enables continuous design, development and operations during the life-cycle of a product or service. By adopting a product- or service-driven approach, organization can predict, react and produce new products or services faster, better and cheaper to its customers.

Teams And Roles

Certain self-organizing and agile teams and specialized roles can be identified to be assigned to the capabilities, that are serving the value stream (figure below). When defining the value stream and related Idea to Production -process, all the relevant capabilities should be identified and linked to certain value streams. An example of capability mapping to the value stream is shown below (figure 6).

Teams and roles.

A value stream -based approach is based on self-organizing teams, that are responsible for certain value-added tasks. A team is a fundamental unit of organizing the work within a value stream. Every team has a specific role and meaning of its own in the overall value stream. Each team performs specific items from a backlog, and the overall work, and every piece of work, can be followed and managed within a Kanban. A team produces specific value-added outcomes or collaborative results, those of which can be measured or associated with clear customer- or business related value-add. A team may consists of generalist or specialist roles, as long as the team share a common goal and an effective way to distribute the work load among the team members. It is much more easier and effective to share the work between the teams than roles in a value stream. Therefore it is important to find the most optimal granularity of the teams and roles, so that the overall lead time, performance and amount of control can be kept as lucrative as possible. Note! Naming convention of “team” can vary according to what is appropriate in an organization (team can be called e.g. as “squad” or “crew”).

Demand Management Team

The core capability of the LEAD operating model is the Demand Management multidisciplinary, cross-functional virtual team. It handles all the incoming requests and creates concepts to be approved to be into the development portfolio. Portfolio Management then evaluates and prioritises the concepts based on business case analysis, taking the financial aspect into account. Approved concepts are directed to development queues. Kanban can be used for managing the work flow. The Demand Management team consists of roles such as customer relationship representative (customer account manager), service designer, architect, product owner, technical specialist. A brand name for the demand management capability can be e.g. “Design Office”, as the main purpose is to find a solution to a problem (according to design thinking approach). A potential solution can be found most efficiently by combining Service Design and architecture approaches.

Figure 3: Demand Management – the funnel for incoming demands. (The Biz -phase of BizDevOps.)

A “concept” in this context is a document and/or visualization, in which the demand is defined as much is needed for further evaluation: What is the problem to be solved, to whom and why? The concept covers information clarifying the context, e.g. customer(s), service(s), process(es), data and application(s) involved. Meaning is to find a resolution for the problem within two-week sprint for further evaluation. Concepts are then rejected or accepted to the development portfolio. Portfolio management decides the priorities of development targets and then directs them to the correct development queue. Development queues are e.g. as follows: agile development, experimental development, procurement etc.

Innovation Management

Innovation management produces new ideas to be further conceptualized, when the innovation management co-operates with the Demand management. In addition, innovation management can activate a Business Model Innovation (BMI) procedure, which actively discovers new business models.

Lean Manager Role

A Lean Manager, “the facilitator”, is the tactical and operational leader of the value stream. This is the most important role in the overall development. And what is worth noticing: the Lean Manager is the only new role required for LEAD implementation in an organization – all the other roles already exists (to some extent). The Lean Manager role is responsible for the Idea to Production -process management and development (as a “Value Stream Manager”), and all the relationships with other functions and stakeholder groups in the organization. The Lean Manager role is “scaled Scrum Master” role. Lean Manager is also responsible for facilitating meetings and managing backlog(s) and Kanban board(s). The Lean Manager role shall have organizational soft skills, leadership- and managerial competencies and customer- and business-oriented attitude.

Development Team

There may exist several development teams, each of which operates according to typical agile approach by utilizing best practice methods and tools such as Scrum and Kanban (also “Scrumban”).

Figure 4: Development team. (The Dev-phase of the BizDevOps.)

Architecture Practice

The new LEAD architecture practice is integrated into the overall development. Architects are collaborating with other teams and roles on daily-basis. There is no architecture board meetings with review sessions taken afterwards, but instead, active co-operation with other teams continuously. Architects are involved in all the design and development cases right from the beginning, so the quality is built in the process. Architecture is created “just enough” for each development case. Architecture practice is supporting function that is organized as an agile team working in few-weeks sprints. All the architecture work is managed within backlog and Kanban, to make the architecture work visible (as any other agile team). Architectural deliverables (artifacts) are created “just-in-time” (on-demand) based on customer needs, this eliminates unnecessary efforts causing Big Design Up Front (BDUF). Too much planning produces deliverables beforehand, so creating artifacts “just-in-case” is to be avoided. This kind of pragmatic architecture work is collaborative and creates and delivers clear value as it is focused on business-driven outcomes. 

Figure 5: Architecture work.

Architects are responsible for managing the overall insight of the organization in the form of Architecture Landscape (the “Enterprise Digital Twin”, a.k.a. “Digital Twin of an Organization, DTO”), and providing it for other stakeholder groups within a tool based platform. Such an overall landscape consists of all the necessary behavioral and structural elements such as business services, processes, applications and technologies, as well as relationships between them. The Landscape can be used for providing “situational awareness” daily basis, e.g. when designing new services or products based on customer needs. The Landscape is managed with an appropriate tool that provides a repository for managing and publishing all the artifacts. It is much more practical to talk about customer-driven development, generic “architecture” competence and architecture “guild”, instead of a distinct enterprise architecture or solution architecture etc., as architecture work covers all the aspects from enterprise-level to solution level. So, “stop talking architecture, and start talking customer and business value”.

Development Portfolio Management

In the value stream there is a stage between design and development, which buffers the incoming development items before they can be directed to the actual development queues. The portfolio management can be used as a management tool for balancing the incoming work with budget, resources and other development and investment items. The development portfolio is the point of the value stream where strategy-driven goals and business- or customer-driven demands meet. Balancing those with available resources is the meaning of portfolio management. That is why the portfolio management is part of the overall design and planning, and the development portfolio requires continuous adjustment. Otherwise the development portfolio is just a list of work to be done. The development portfolio shall be managed so that it can be modified according to continuously changing conditions. For to be managed, all the development portfolio items shall be conceptualized and designed into comparable form for further evaluation. The better the development items are designed, the better they can be prioritized and be taken to development. Therefore it is important to identify and define interdependencies between development items, and the impacts to behavioral and structural elements of the organization. This can be enabled with architecture design and analysis against the as-is architecture landscape. Note! There is an implicit “development portfolio” anyhow, even though it is not explicitly managed. “Portfolio management is a dynamic decision making process whereby a business’s list of active new products and R&D projects is constantly up‐dated and revised.” In practice, the development portfolio can be managed within a tool, from which the development items can be linked to an Enterprise Architecture Management (EAM) tool and concerned diagrams.

Value Delivery Chain – The Development Value Stream

The LEAD operating model is based on value chain approach, which can be defined with all the relevant capabilities as shown in the diagram below (figure 6). Value stream modelling can be used for defining such an organization specific development value stream, and for identifying the concerned capabilities that are participating in value creation. As such, value stream modelling can be used as a starting point for complete reorganization of the enterprise. Values are linked to phase transitions, and capabilities to value streams. All in all, this diagram type can be used to define exactly how the value is created and by which capabilities. Capabilities represent the “what” organzation does. Note! This development value stream is supporting the actual operational value streams of the organization, those of which touching the customer and are close to the business model of the organization.

Figure 6: Idea to Production Value Chain Example View. .

Notes related to the value stream figure above:

  • Values are modelled with purple ellipses
  • Value streams are modelled with “chevron” symbol
  • Capabilities are modelled with rectangular (with rounded edges) – capabilities are “serving” (line with arrowhead) the value streams

“Value” needs to be defined: what is valuable, what can be associated with added value. Should we get rid of everything that is not providing direct, intrinsic value? For example, is innovating and experimenting (and mostly failing) worthless or valuable? We intuitively understand, that it is valuable to get more information what is working and what is not, so that we know how to proceed. To make better decisions needs investigations and experimental data. Value can be measured by e.g. how many ideas to production are processed, and how many of them are contributed with certain activities such as innovation management, experiments, architecture, Service Design etc. (The Value Stream -element is introduced in the ArchiMate 3.1.)

The Development Operating Model

The value delivery chain can be defined more detailed by identifying exactly which steps are to be taken, in which order and by which business actors. Process modelling can be utilized for defining the Operating Model, which is the actual implementation of the value delivery chain at Business Model abstraction level. The basic LEAD value chain process is illustrated in the figure below.

Figure 7: Idea to Production process – operational level representation of the business level development value stream.

Note! This basic LEAD operating model -process can vary depending on the case, and can be adjusted according to what is appropriate in the organization. E.g. if SAFe is used, related actors and information elements can be defined in the process, as it reflects the operating model in practice.


The Lean Enterprise Architecture Framework (LEAF) can be used to support the Idea to Production -process in practice. The LEAF-framework can be implemented on any enterprise architecture management (EAM) tool. The 1st level of the framework is meant for business-level management and planning purposes, such as strategy planning, business models (value streams, capabilities etc.), as such it is a business architecture framework. The 2nd level of the framework is the actual enterprise architecture content area.

Figure 8: Lean EA Framework (LEAF) level-1.

The 1.st level of the framework (figure above) can be used as a navigation landing page in a portal. The middle part of the framework is designed around the value chain concept (Idea to Production), but it can be applied to the development operation model, whatever is appropriate in the organization. The 2.nd level (figure below) is linked for each domain of the 1.st level.

Figure 9: Lean EA Framework (LEAF) level-2.

The 2.nd level consists of layers (business, application and technology) that are focusing on internal behavior and structure of the organization. On the left is a content placeholder for “Goals View” -diagrams. On the right is a content placeholder for “Layered View” -diagrams.

An alternative approach for organizing the enterprise architecture content on the 2nd-level, is to utilize the aspect-oriented approach (figure below). These aspects are based on the ArchiMate Framework (link). This aspect-oriented approach can be useful if the organization is not familiar with the layers, or layers is not the most appropriate way to organize the architectural content.

Figure 10: Lean EA Framework (LEAF) level-2 – the aspect-oriented version (with no layers).

Whether to take a) the layered approach or b) the aspect-oriented approach, depends on the case – again. The maturity of the architecture function in an organization defines should a layered approach be more appropriate, or should layers be used at all – as the “organization has no layers” but behavior and structure for sure…

The LEAF-framework’s 2.nd level can be adjusted for supporting both Service Design and architecture approaches, known as “outside-in” and “inside-out”. The “Customer Views” layer can be added on top of “Business Views”. The Customer Views -layer is focusing on customer experience and service design.

Figure 11: Lean EA Framework (LEAF) level-2 with Customer Views -extension.

The LEAF in a nutshell

In short, the LEAF-framework can be used for managing all the organization’s behavioral and structural elements. These elements are positioned on horizontal layers (instead of conventional vertical EA-domains: biz, data, app, tech). The idea behind this layering is to enable a “holistic” design and development approach. The holistic approach applies better to the overall development as it takes all the layers and aspects into account in design and development. All the behavioral and structural elements from business services and processes to applications, as well as information, are all related to each other and it is reasonable to consider them as a whole. The LEAF enables the holistic development approach. The LEAF-framework can be used for combining Service Design and Enterprise Architecture approaches, as there exist content placeholders for each and every aspect that cover bother customer and organization perspectives.

  • For more details of LEAF-framework see this link.
  • The reference implementation of the LEAF-framework (implemented with Sparx EA modelling tool) can be found via this link.

Diagram Types

The most useful diagram types are e.g. as follows:

  • Goals View (Motivation View)
  • Context diagram: a combination of actor- and application interaction -diagrams
  • Overview diagram: the Layered View -diagram
  • Interaction diagram: Actor-, Process- and Application Interaction -diagrams

Introduction to diagram types (see e.g. “The most useful diagram types“, ArchiMate Examples, ArchiMate Cookbook).

Positioning the Diagrams into the LEAF level-2

The diagram types are to be positioned into the LEAF level-2 as shown in the figure below.

Figure 12: Diagram types and LEAF level-2.


Lean & Agile Enterprise Development is mainly focused on customer value add-on creation and delivery, from which all the other principles and guidelines shall be derived from.

There are certain common principles by which an open and collaborative working is encouraged, such as:

  • Customer Value add creation and delivery above all, from which everything shall be derived from,
  • Collaboration, co-operation and open communication throughout the organization, over teams and functions,
  • Visibility, transparency and openness throughout the organization, e.g. all the development targets are to be visualized and made available (with appropriate tool).
Figure 13: LEAD Principles (core).

See the full list of LEAD principles via this link.

Note! There should be only few, but concrete architecture principles that are meant for guiding the development. If any architecture principles are formulated at all, those shall be useful and valuable. They shall provide guidance for development practices and allowed technologies. However, too detailed architecture principles are somewhat problematic, as those restrict the freedom of choices of the self-organizing development teams. With lots of too detailed principles, the development teams are forced to used methods, tools, techniques, and softwares that may not be the most suitable for the case. It is just that not the small architecture team, but the developers themselves know best what are the most appropriate methods, tools, techniques and softwares. It is not only question of the privilege to use the most optimal methods and tools, but more importantly, it is question of trust, respect and appreciation of the team members and their expertise. Decisions of operational level choices should be left to development teams. Good discussion concerning architecture principles can be found from here (link) by Gerben Wierda, who has also written an excellent book about EA titled as Chess and the Art of Enterprise Architecture (link).


In the LEAD, Service Design methods, tools and terminology is to be combined within the architecture framework, method, tool and terminology. The Goal-Driven Approach (GDA) can be used for defining the goals for each development target first, before any actions are to be taken. The Service-Driven Approach (SDA) can be applied for combining Service Design and architecture development approaches (for more details see this link). All the existing methods can be applied to what is appropriate and fit for purpose (e.g. Scrum).

Basic LEAD development is based on typical Lean and agile practices as follows:

  1. First the incoming idea is designed, and a concept with Minimum Viable Architecture (MVA) is created by the Demand Management team
    • Service Design and architecture approaches are used in combination, necessary artifacts are created
    • An idea can be conceptualized e.g. by utilizing an applied Business Model Canvas (BMC), for easier evaluations (an example here)
    • All the work is managed within Kanban, which can be organized into hierarchical levels such as an idea, portfolio, product, team etc.
  2. The concept is then further designed more detailed, and a Minimum Viable Product (MVP) is created
    • Feedback loop is active, as developers and business owners collaborate
    • The MVP can be further developed iteratively and incrementally
Figure 14: LEAD development method.


In the LEAD, tools play an important role. Tools are used for visualization of each and every development case that is flowing through the value stream. Tools support concretely the LEAF-Framework, that in turn supports the operating model. By utilizing the appropriate tool(s), the self-organizing teams and other stakeholders in the organization can see what is really happening, what are we doing and why. This increases the overall situational awareness, which is crucial for the organization to be capable of designing services and products. Tools also make the work more practical, and information and knowledge sharing more efficient.

There is a specific set of tools that can provide a holistic overview of an organization. Such tools enable a single platform, that can provide end2end management capabilities for handling the whole value stream: how the incoming demands flow through the value stream from ideas to production. All the portfolios, backlogs, Kanbans and organization’s behavioral and structural elements can be managed within a single tool. All the relevant data can be retrieved from diverse data sources and then combined and enriched, and provided via user-friendly interfaces as dashboards etc. These tools can be used for overall enterprise management: design, development and operations. Modern tools provide role based views for different stakeholder groups for a number of use cases. Most of the available tools provide many options and alternative visualization capabilities. For example, the modelling the details can be left to specialists, and provide more simplified views to other users. The capabilities of a modern visualization tool are illustrated at a high level in the figure below.

Figure 15: Visualization Tool.


  • Portfolio Management in a single platform enables smooth handling of portfolio items. Ideally an item on the idea portfolio can be transferred to the development portfolio just by switching the status from “idea” to “development”. As all the design and architectural artifacts are managed within the same platform, it is easy to jump from e.g. development portfolio item to its metadata or concerning architectural diagrams.

Leading-edge tools *) can be used for building an Enterprise Digital Twin, the “situational awareness” according to the Digital Twin of an Organization (DTO) concept (link), which combines several concepts together such as BI, BAM, BPM, EAM etc. These tools can be used for designing new services, managing portfolios and providing dashboards and reports for decision making and enabling diverse analysis such as impact analysis – all in one platform.

*) Leading-edge products are as follows:

  • Orbus iServer (link),
  • Mavim platform (link),
  • BiZZdesign Enterprise Studio and HoriZZon Portal (link).

There exist other potential modelling-driven products too, such as QPR EA (link), Sparx EA (link) or Archi (link), and several data-driven products such as Ardoq (link), Essential Project (link) and LeanIX (link).

Most of these above-mentioned tools are recognized in Gartner’s magic quadrants (link) or in Forrester’s reports (link).

For quick start the open-source Archi-tool can be a good choice, as it provides features such as HTML- and document generation. Also, the Sparx EA (14) can be used with the ready-made LEAF reference implementation, that is free for use (here).

It is also possible to utilize the best of breed tools for enabling a toolset for holistic enterprise development. Several specialized tools can be used together by allowing smooth linking and integration between them. For example, an open-source Archi -modelling tool can be used for design purposes, from which the data can be transferred to a graph database (such as Neo4j). In the graph database the data can be enriched with other organizational data from diverse data sources, and provided as dashboards with other specialized tools (e.g. BI-tools). Sketch for a visualization tool is described here (link).

A tool for holistic enterprise development and management shall provide at least the following features:

  • Repository for all the artifacts (deliverables) and related metamodel (of behavioral and structural elements)
  • Publishing capability for web-enabled (role-based) views
  • Design and modelling capabilities (support for standard notations such as ArchiMate, BPMN and UML, and Service Design tools e.g. Service Blueprint)
  • Dashboards for analysis and portfolios (such as idea-, development-, service-, application- and technology portfolios)
  • User management
  • Integration capabilities (with diverse data sources such as CMDB and ITSM)

Note! The LEAF-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. As the LEAF-framework provides a linking mechanism from the enterprise architecture (EA) level to the solution architecture (SA) level, accordingly, the LEAF-framework nicely enables a way to link high-level ArchiMate -diagrams to more detailed BPMN- and/or UML-diagrams.

LEAD Implementation

To start practicing LEAD is a learning process, which requires cultural readiness and well defined operating model. Here is the flow of actions to be taken when implementing the LEAD:

Figure 16: LEAD implementation.

Adopting the LEAD is a relatively straight-forward learning process as follows:

  • Preliminary: Train and familiarize people with Lean & agile practices (these are already common competencies in most of the organizations)
  1. Define the development value chain and related operating model (process), identify and integrate relevant capabilities (teams & functions)
  2. Establish and start practicing teams: a) Demand Management- and b) re-organized Enterprise Architecture teams
    • Establish a Demand Management multidisciplinary virtual team, managed and facilitated by the Lean Manager (the only new role!)
    • Establish/re-organize the EA function, utilize an appropriate tool with the LEAF-Framework, visualize every development case, publish into the portal
  3. Select the tools for managing the demands, backlogs and portfolios, architecture, tasks, development queues etc. (use the most appropriate MVP tools)
  4. Integrate all the teams (capabilities/actors/functions) within the operating model
  • Improve the process continuously, adjust the capabilities (teams, functions), fine-tune the tools, encourage to co-operation…
  • LEAD & LEAF is ready from day one. Start by executing the demand management team, and modelling all the demands to concepts into the architecture landscape.

Most of these above-mentioned competencies and structures already exist in the organization, which makes the LEAD implementation easier. Those already existing capabilities are just to be re-organized according to the operating model, as defined in the Idea to Production -process. LEAD complements all the existing frameworks and methods (e.g. SAFe, IT4IT, Scrum, DevOps, ITIL) by providing overall visibility with practical meta-framework. As a result of this adoption procedure, a transparent, collaborative and efficient operational value stream is implemented. And finally, the organization’s “production line” is prepared for execution, the performance can be measured and continuously improved.

Note! The LEAD-method and related LEAF-Framework are providing guidance for a pragmatic overall development approach, which can be made more practical by utilizing an appropriate tool. However, a tool is just for making things more practical and concrete. Most important is the co-operation between teams and roles! Nevertheless, a tool can make things easier: the value stream and related capabilities and the Idea to Production -process can be made visible to all concerned stakeholders. This makes the communication easier for co-operation, and assists the commitment to commonly shared goals.

The change program in an organization can be executed within a change program as illustrated in the figure below.

Figure 17: Implementation Roadmap View.

Executive Summary

Lead the development with LEAD. It is simple to be adopted, as it complements already existing frameworks and organizational structures. LEAD focuses on customer value delivery by integrating all the existing capabilities (functions, teams) into an integrated operating model. Organizations already have them all in place, the operational value stream (Idea to Production) just needs to be defined and adjusted properly. Anything more or new is not required, but instead, many things can be relieved or completely removed, such as unnecessary or inefficient practices, pointless meetings, useless documentation and heavy bureaucratic organizational structures etc.


  • Overall visibility and better insight for all the overall development activities
  • Defined and visualized value stream, to crystallize how customer value is created and delivered
  • Identified, adjusted and calibrated capabilities (functions, teams, roles)
  • Organized and integrated Idea to Production -process
  • Enforced collaboration and visibility, visualization
  • Practical guiding framework
  • Concrete, appropriate tool for providing dashboards and managing the virtual “Digital Twin of the Organization (DTO)” – in practice

Design, Development & Operations With Architecture

The LEAD is a concrete, pragmatic value stream-based operating model that integrates capabilities within the Idea to Production -process. LEAD leverages on the Lean and agile practices and principles such as collaboration and visualization, which can be supported by concrete LEAF-Framework and appropriate EA-tool in practice. All these aspects together support the overall design, development and operation.

Figure 18: Three dimensions.
  • Operating Model that supports the organization’s value delivery chain and integrated capabilities
  • Framework that supports the value stream based design, development and operations
  • Tool that supports the framework

Note! The LEAD-method and related LEAF-framework is continuously developed based on experimental and collected data from large organizations. New Service Design methods, tools and concepts are to be integrated with conventional architecture approach…

Figure 19: LEAD layers.

LEAD: Lead, Design, Develop & Operate your development value stream – to support your operational business value streams!

Figure 20: Design, Develop & Operate your value stream.


  • Yes, for sure it is possible to use this LeanEA method as described here as LEAD with the LEAF for free (without any costs or licenses).
  • There exist two reference implementations (Finnish public sector organizations) already, a lot of interest has been recognized and many queries have been received from many countries, from diverse sectors.
  • More research articles, blog posts are coming soon, and a free Lean EA Cookbook (pdf) is to be available soon…

See the research article introducing the LEAD and implementation in a case organization (link).

See the ArchiMate Cookbook for inspiration to Enterprise Architecture (EA) modeling (link).