What? Value Chain Based Lean Enterprise Aware Design, Development & Operations.
Drivers For Change
Continuous change in the 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 customers. 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 at 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 increase, the organization’s internal structure becomes more volatile without systematic governance. These challenges can compete with the 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 a value chain-based approach. The LEAD (aka Lean EA) consists of an 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 a single funnel for all the customer- and business-driven demands. The overall development is based on Lean and agile principles such as cooperation and visibility.
What is Lean? The core idea is to maximize customer value while minimizing waste. The ultimate goal is to provide perfect value to the customer through a perfect value creation process. A popular misconception is that lean is suited only for manufacturing. Not true. Lean applies in every business and every process. It is not a tactic or a cost reduction program, but a way of thinking and acting for an entire organization. [Lean Enterprise Institute]
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 purposes, 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 demand to production can also be measured. LEAD-method is described in more detail in this research paper “Lean Enterprise Architecture Method For Value Chain Based Development In Public Sector” (link). The LEAD value delivery chain is illustrated in the figure below.
Demand to Production process flow :
- Demands are based on a) customer needs, b) strategic goals, c) regulations & legislation, d) changes in business conditions or technologies
- Demand Management team handles all the incoming demands and creates concepts (the Biz)
- Portfolio Management evaluates the concepts and directs them to development queues
- Development teams develop the concepts to realized services or products according to agile methods (the Dev)
- Services or products are deployed on production to be operated by the IT Operations Management (the Ops)
LEAD is a Concrete, Coherent and Cohesive combination of the following aspects:
- Operating model is based on value stream approach, with integrated capabilities
- Framework is supporting the Operating Model concretely
- 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 Aware Design”
Culture, Structure and Behavior
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”, which means that culture can be an impediment to 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, one can say that it would be valuable to start the change from the structures first, then the change in mindset can be easier. However, culture is what happens when people interact. Culture is communication and cooperation. As such, culture is the behavior between people, the actors. Culture is the behavior of structures.
As the customer is the king, customer experience is dictating how new services and/or products are to be designed. A customer journey may cover several services in several business units, or it may cross 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 customer satisfaction and employee satisfaction shall be taken care of. The latter produces the former. If people feel that they are trusted and appreciated, they perform well. In turn, stressed employees result in reduced productivity, which reflects harmfully to revenue.
An 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 the organization. Designers and developers have to be more customer-oriented and more agile. New methods, tools and practices have to be adopted. To enable a fast responding and continuous development model, organizations have to shift from project-based models 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 a 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, the 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 Demand 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).
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 a clear customer- or business-related value-add. A team may consist of generalist or specialist roles, as long as the team shares a common goal and an effective way to distribute the workload 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! The 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 in the development portfolio. Portfolio Management then evaluates and prioritizes 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 workflow. 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 the design thinking approach). A potential solution can be found most efficiently by combining Service Design and architecture approaches.
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 a two-week sprint for further evaluation. Concepts are then rejected or accepted into 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 exist (to some extent). The Lean Manager role is responsible for the Demand 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 the “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 the typical agile approach by utilizing best-practice methods and tools such as Scrum and Kanban (also “Scrumban”).
Architecture Practice
The new LEAD architecture practice is integrated into the overall development. Architects are collaborating with other teams and roles on a daily basis. There are no architecture board meetings with review sessions taken afterward, but instead, active co-operation with other teams continuously. Architects are involved in all the design and development cases right from the beginning, so quality is built in the process. Architecture is created “just enough” for each development case. Architecture practice is a supporting function that is organized as an agile team working in few-week 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.
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. 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 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 updated 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 a 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 a 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 “what” organization does. Note! This development value stream is supporting the actual operational value streams of the organization, those of which touch the customer and are close to the business model of the organization.
Notes related to the value stream figure above:
- Values are modelled with ellipses
- Value streams and value stream stages 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 on 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 in more detail 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 the Business Model abstraction level. The basic LEAD value chain process is illustrated in the figure below.
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.
Lean EA Framework (LEAF)
The Lean Enterprise Architecture Framework (LEAF) can be used to support the Demand 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.
The level-1 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 (Demand to Production), but it can be applied to any development operation model, whatever is appropriate in the organization.
The level-2 of the framework (figure below) is linked for each domain of the 1.st level. This variant is based on the Maps and Views layout.
On level-2 there are placeholders for both Enterprise Architecture (EA) and Solution Architecture (SA) -level diagrams. EA-level content (Business-, Application- and Technology Views) consists of maps such as business services- and business process maps, and application maps. Maps illustrate the organization at rest (static diagrams showing certain lists of elements), whereas Views illustrate the organization in motion (dynamic diagrams showing how elements interact). SA-level content (Solution Views) consists of diagram types such as application structure and implementation views. In addition, there are content placeholders for motivation diagrams such as goals views (on the left part).
This variant of level-2 consists of layers: business, application and technology, according to the ArchiMate core framework) that are focusing on the internal behavior and structure of the organization. On the left is a content placeholder for “Motivation View” -diagrams. On the right is a content placeholder for “Layered View” -diagrams.
Which version of level-2 is to be chosen depends on the case – again. The maturity of the architecture function in an organization defines what kind of architectural content can be managed.
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, traditional 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 covers 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.
- The reference implementation of the LEAF-framework (implemented with Archi 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).
Diagram types and LEAF level-2
The diagram types are to be positioned into the LEAF level-2 as shown in the figure below.
Principles
LEAD is mainly focused on customer value add-on creation and delivery, flow efficiency, and continuous improvement (as they are common Lean principles), from which all the other principles and guidelines are derived.
The main principles are as follows:
- Customer Value add creation and delivery above all, from which everything shall be derived,
- Flow efficiency before resource efficiency,
- Continuous improvement as a guiding principle for all the work.
Some other fundamental principles e.g.:
- Collaboration, co-operation and open communication throughout the organization, over teams and functions,
- Visualization, visibility, transparency and openness throughout the organization, e.g. all the development targets are to be visualized and made available (with an appropriate tool).
Other important principles are e.g. as follows:
- Less is more (and more is less)
- KISS (keep it simple, stupid)
- MALT (More action, less talk)
See some more LEAD principles via this link.
Note! There should be only a 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 software 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 software. It is not only a question of the privilege to use the most optimal methods and tools, but more importantly, it is a 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 here (link) by Gerben Wierda, who has also written an excellent book about EA titled Chess and the Art of Enterprise Architecture (link).
Methods
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 the purpose (e.g. Scrum).
Basic LEAD development is based on typical Lean and agile practices as follows:
- First the incoming demand 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.
- 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
Tools
In the LEAD, tools play an important role. Tools are used for the visualization of each and every development case that is flowing through the value stream. Tools support concretely the LEAF-Framework, which 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 demand to production. All the portfolios, backlogs, Kanbans and the 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 of 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.
Note:
- Portfolio Management in a single platform enables the 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:
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 a 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, which 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:
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 organizations)
- Define the development value chain and related operating model (process), identify and integrate relevant capabilities (teams & functions)
- 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
- Select the tools for managing the demands, backlogs and portfolios, architecture, tasks, development queues etc. (use the most appropriate MVP tools)
- 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 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 Demand 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 Demand to Production -process can be made visible to all concerned stakeholders. This makes 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.
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 (Demand 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.
Benefits:
- 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 Demand 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 Demand to Production -process. LEAD leverages on 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.
- 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 the conventional architecture approach…
LEAD: Lead, Design, Develop & Operate your development value stream – to support your operational business value streams!
See the research article introducing the LEAD and implementation in a case organization (link).
See more details of the LEAF framework: link.
See the ArchiMate Cookbook for inspiration to Enterprise Architecture (EA) modeling (link).