1.1 The Lean Enterprise Architecture Development (LEAD) Method<\/h3>\n
In LEAD, all the relevant organizational capabilities related from management to operations are organized around the value delivery chain-based operating model. Those capabilities cover management, design, development and operations. The architecture practice is involved into the overall end2end delivery chain from “ideas to production”. This means a paradigm shift from conventional EA practice to new, modernized, lean and agile EA practice. Collaboration<\/strong> of multi-disciplinary roles & teams and architecture landscape visibility<\/strong> are the key principles and enablers. The LEAD operating model is supported by the Lean Enterprise Architecture Framework (LEAF<\/a>)<\/strong>, which is made available with an appropriate EA modelling tool.<\/span><\/p>\n The LEAD can be utilized for holistic enterprise development, as the LEAD covers all the relevant aspects from strategy planning to operations. Also, the LEAD can be adapted to target area of any size: to whole enterprise, to business unit or other domain, to digital strategy planning and execution etc. <\/span><\/p>\n Questions to which the LEAD concept tries to answer:<\/span><\/p>\n LEAD integrates and mobilizes the organization and its capabilities into operating model, that is capable of dealing with customer demands and producing services efficiently. All the organizational functions and roles are adjusted seamlessly into the same production line, to the value delivery chain based integrated LEAD production machine.<\/span><\/p>\n The main idea of LEAD is to concentrate on customer needs and business value creation. This encourages enterprise to get organized around value delivery chain. All the organizational capabilities need to be aligned with the value chain process \u201cfrom ideas to production\u201d. This puts the service concept into dominant position, as \u201ceverything is a service\u201d. Service is the primary unit of value creation, development and operation. <\/span><\/p>\n LEAD value delivery is focusing on services instead of projects. This approach is supported with the <\/span>Service-Driven Approach (SDA)<\/span><\/i>, which is in the core of the LEAD . As such, LEAD combines customer centric service design thinking with enterprise architecture. This interconnects the \u201coutside-in\u201d and \u201cinside-out\u201d -viewpoints into comprehensive approach, which take advantages from both design thinking and system thinking viewpoints.\u00a0<\/span>The value delivery chain can be expressed in the form of <\/span>Service Delivery Chain<\/b>, as illustrated in the figure 1 below.<\/span><\/p>\n The Lean EA framework is organized into layers, each of which contains specific views. The layers are as follows:<\/span><\/p>\n The idea behind this framework is to provide simple and easy navigation view into diagrams for different stakeholder groups. The LEAF is based on open standards (TOGAF, ArchiMate, IT4IT) and can be adapted with frameworks such as SAFe and methods like DevOps.<\/span><\/p>\n Enterprise development is typically siloed into organizational structures, which are performing separated to each other. It is not necessarily crystal clear what are the required or existent capabilities and how they interact – nor how the information flows between them. It is not explicitly defined which capabilities, skills and resources are providing what value exactly, what is their reason for being. Should they be internal to the organization, should they be externalized, or should they exist at all? There are many unclear aspects and functions inside the organization, as there is no explicitly defined value chain to which all the capabilities can be assigned to. In addition, the organizational culture may lack collaborative atmosphere that stimulates \u201cintrapreneurship\u201d and motivates to continuously explore and experiment with new, better, innovative and more efficient ways of working. Working conditions may suffer the conditions caused by poor managership, by the command and control management system. As a result of this, the organization is not optimally adjusted for value creation nor customer-centricity. Often these matters mentioned above are symptoms of problems in management. <\/span><\/p>\n Enterprise decision making and -development should be supported by enterprise architecture, but only occasionally that is the case. After over 20 years of history EA hasn\u2019t been a success story, but there are number of failed or unfinished attempts instead. Lots of frameworks since Zachman framework have been seen the dawn, but none of them never succeeded with full extent. Conventional enterprise architecture frameworks and methods are considered as too difficult, too academic and cumbersome to understand – for others than architects. Some may argue that EA practice has been proven useless as a function, as it is not providing any direct business benefits. Too often architects have been working in their own \u201civory towers\u201d, external to other functions. Some business people and managers may say that architecture is the \u201cnecessary evil\u201d, a function without a cause. As such, EA is underrated and misunderstood as a practice, \u201can sich\u201d.\u00a0EA is too difficult, it is not understood, it is not interesting. The EA practice has to be changed.<\/span><\/p>\n Finnish public sector organizations have been practicing enterprise architecture according to Public Administration Recommendation 179<\/a> (latest version v 2.0, 2017). Experiences haven\u2019t necessarily been positive, instead, the recommendation has been found too complex and cumbersome. Although the recommendation is comprehensive, it is lacking of easy adoption guidance and the content framework is not very practical. EA domain based content framework is aligned with Togaf domains (business, data, application and technology), but this approach is not the most optimal in the age of agile and high-speed development.<\/span><\/p>\n Regardless of the disreputation of the EA, it has intrinsic value. Intuitively, overall insight to the organization\u2019s behavior and structure as a whole has been understood and convinced somewhat important and reasonable aspect anyway. EA supports management decision making, strategy execution and business development, as well as operational activities. Enterprise architecture management (EAM) is relatively important capability for every organization. Architecture competencies and architects (of some kind) are useful (not especially enterprise architects, but architects of some professionalism such as solution architects anyhow). There should be architects of some level capable of exercising enterprise architecture management in the organization. Architect roles should be carefully considered and aligned with the needs of organization: is there need for generalists or specialists (such as solution architects, security architects, cloud architects etc.). It goes without saying that old-school enterprise architects have to orientate themselves to more agile, practical and collaborative ways of working.<\/span><\/p>\n The most tedious part of the EA is the framework and method combination. That should be the most beneficial and valuable part of the puzzle, but that seems to be the hardest part. In spite of their meaningful purpose, EA frameworks and methods have been found somewhat awkward and boring from the business people point of view. Architects disagree, but accident has already happened. Thus, some more practical frameworks and methods could still renew, not only the EA, but also the whole enterprise development to be more efficient in its full extent. \u00a0<\/span><\/p>\n The Good, the Bad and the Ugly: <\/span><\/p>\n There has been lots of discussion lately related to how much planning is needed. According to practices of Agile methods, too much planning in early phases of development is unnecessary waste. Development should be left open to changing conditions. It cannot be seen precisely beforehand, what is the nature of the development target, what are the requirements exactly and how much planning can be done. As typical to agile methods, only high level epics or user stories are enough to get started experimenting and learning by doing. \u00a0\u00a0\u00a0\u00a0<\/span><\/p>\n What is the right size of architecture work? Are we doing development with or without architecture? The overall complexity increases in accelerating speed. New cloud services or APIs need to be managed in controlled way. Agile efforts are delivering new services fast. Without any overall planning the enterprise services landscape is shifting to chaos. It has been recognized that the truth lies somewhere in between both extremes: \u201cbig design upfront\u201d and ultra-agile planning. Some long-term architecture planning, continuous architecture repository refarctoring and updating keeps the overall architecture landscape coherent. But architecture team cannot anymore create architecture artifacts (lists, maps, diagrams etc.) without clear demand from business. However, this is not black or white, but the main idea gets clear: architecture team has to collaborate and create architecture artifacts on demand basis, according to lean principles and agile practises.<\/span><\/p>\n Efficient enterprise is balanced production machine, in which all the capabilities are integrated together enabling seamless information flow. Customer demands are flowing through the value chain-based production line in controlled manner. Architecture is co-operating with other functions by providing overall architecture landscape of existing and planned services of the enterprise. Challenges can be solved with better co-operation and interaction. This can be enabled with the LEAD concept, which is a practical approach for enterprise operational development. The key principles are collaboration and visibility. LEAD concept is concrete development approach, which:<\/span><\/p>\n The LEAD operating model is based on Lean and agile thinking as an overall philosophy. The operating model consists of capabilities and their interactions. The LEAD operating model defines how the information flows between the identified capabilities – and to be more precise – what information flows between which capabilities.\u00a0<\/span>Some of the capabilities are related to management layer, some capabilities are assigned into the Service Delivery Chain, and some of them are supporting capabilities. Operating model is to be defined: which capabilities exactly are concerned, what are the business services they provide, what are the information flows between them – and, what is the value add they can be assigned to. Capabilities can be identified based on organization structure, and based on frameworks such as IT4IT<\/a> and IT-CMF<\/a>. \u00a0<\/span><\/p>\n An essential capability is \u201cdemand management\u201d, the single funnel of development cases. This capability handles all the incoming demands from different channels. Some business-driven demands can raise when customer relationship management is in contact with the customers. Demand Management is illustrated in the Idea to Production<\/em> value stream diagram below. In practice, LEAD operates in collaborative way that requires strong personnel involvement and commitment, on both management and operational levels. All the ideas and other incoming demands are managed in the single backlog and single Kanban board (physical and electronic). <\/span>This \u201cScrumBan<\/a>\u201d -style approach makes the overall development collaborative and visible from ideas to production.<\/span><\/p>\n One of the most important observations is that when taking the customer perspective, the organization is forced to consider the enterprise as whole, to take a holistic, systemic development approach. This means that the behavior and structure of the enterprise have to be designed and optimized as a one system – based on the customer viewpoint. No partial optimization, but overall approach instead. The customer perspective, or customer experience, is the reason for systematic EA development. EA is the key enabler for taking an overall development approach. EA provides methods and tools for enterprise design so that the whole enterprise can be designed and developed as a one system. (An enterprise can refer to any \u201ccomplex\u201d system, e.g. large consortium of enterprises, ecosystem, collaborative organization of organizations etc.) <\/span><\/p>\n It is worth noticing that there is slight difference between <\/span>customer-centric<\/span><\/i> and <\/span>customer-driven<\/span><\/i> development approaches, both of which represent the customer perspective. It is not only question of nuances: the latter is more focusing on the customer experience, and thus it requires an overall insight of the enterprise. However, service design is crucial in both of them. For taking an overall, holistic development approach that can be combined with service design, EA is the most comprehensive tool for that. EA and related architecture practice supports developing services in the context of concerned organization(s) by providing an overall architecture landscape.<\/span><\/p>\n In LEAD, the Enterprise Architecture practice is no more a distinct function that is mostly planning future state architectures, joining seminars, reviewing project architectures afterwards in architecture board committees (the “ivory tower syndrome<\/em>“). Instead, new LEAD architecture practice is integrated into the overall development. Enterprise Architecture as a discipline has stopped being a guild of its own. Now, architecture is <\/span>nowhere<\/span><\/i> as a distinct function, it is <\/span>everywhere<\/span><\/i> as an integrated function. It is much more practical to talk about \u201carchitecture\u201d instead of enterprise architecture precisely, as architecture work covers all aspects from enterprise level to solution level. Architecture practice in the form of Enterprise Architecture Management -c<\/em>apability is illustrated in the figure below.\u00a0<\/span><\/p>\n Architects are collaborating with other teams and roles in each and every development target case – that is flowing through the value delivery chain. This collaborative approach focuses on overall development rather than separate aspects – \u201cstop doing enterprise architecture, start doing added value (architecture) tasks of the enterprise<\/em>\u201d (or “stop talking EA and start talking business value<\/em>“). This system thinking forces us to concentrate on holistic enterprise development: to integrate all the capabilities such as customer relationship management, enterprise architecture management, portfolio management, project management, service management and operations management into comprehensive production machine. Practically this means that all the teams and roles are working in the same \u201cproduction line\u201d, which produces value added services from ideas to production. This makes the architecture as ordinary citizen, but at the same time, promotes architecture as to all-round practice. EA is dead as we used to knew it, but long live architecture as a foundational discipline.\u00a0 In LEAD , architecture work is co-operating right from the start – together with e.g. customer relationship personnel by doing architecture artifacts in collaborative way. Architecture is not reviewed afterwards, architecture is living together with all the development targets.<\/span><\/p>\n In LEAD,\u00a0 architects collaborate with other roles and work in multidisciplinary teams. Architects co-operate right from the ideation phase of any development target. Architects provide their professionalism and assist in order to conceptualize all the customer- or strategy driven business demands against the existing overall architectural landscape. Architect roles need to be revised too. Architects should be capable of doing enterprise architecture management, modelling and working in or nearby projects. Most importantly, architects should be closely co-working with other roles such as customer relationship specialists, who are aware of customer- and business driven demands. So there cannot be specific long-term EA planning tasks only, but rather more practical, hands-on tasks together with other roles. The more all-round competencies an architect has, the more useful he\/she is for the organization. Architecture practice should be exercised by architects, who are generalists with some specialization areas. Modelling competence is at highest priority in LEAD. Architects should be familiar with agile methods such as Scrum<\/a>. Specific roles can be e.g. : 1) Enterprise Architect, responsible for business relationships,\u00a0architecture landscape, methods and tools, 2) Domain Architect in large organizations, responsible for architecture landscape of a domain, 3) Solution Architect, responsible for a solution and 4) Service Architect, responsible for a service or service area (successor of Solution Architect in Service-Driven Approach, SDA<\/a>).<\/span><\/p>\n That architecture landscape is a combination of current \u201cas-is\u201d and target \u201cto-be\u201d architectures. According to Lean and agile thinking, just enough architecture deliverables are created just-in-time, not just-in-case. The architecture landscape provides the current situation of the organization\u2019s business services, -processes and applications. It is an “enterprise digital twin”. It is a \u201csituational\u201d view of the enterprise, that is created to fit for purpose. The\u00a0architecture landscape is more than a snapshot, it is a living big picture which dynamically grows as more data is added into architecture repository. The LEAD architecture landscape is dynamically growing according to customer needs (like “Tetris”, as shown in the figure below). Architecture deliverables are created upon the value delivery chain process: a minimum viable product (MVP) architecture concept is created for each development target. However, LEAD architecture work contains long-term planning tasks, though. Those are related to so-called enabler epics, but again, those have to be triggered by a forthcoming customer- or business-related demands still.<\/span><\/p>\n According to SAFe<\/a> <\/span><\/span>there may be \u201cemergent design\u201d and \u201cintentional architecture\u201d, both of which seeds the \u201cArchitectural Runway<\/a><\/span>\u201d. The former presents the agile initiatives (e.g. project architectures), that create the architecture at technical basis as the solution is being built. The latter presents more long-term architecture planning that may crosses several solutions. Accordingly, the architecture landscape in LEAD represents both emerging and intentional design elements. All the architecture work and related deliverables (architectural artifacts) are created on-demand: all the tasks are managed with backlog and Kanban. As a result of this, architecture work is visible and clearly linked to value add delivery. Nevertheless, LEAD architecture landscape emphasis more on overall, holistic view of the business, rather than into technical aspects.<\/span><\/p>\n The LEAF layer \u201cArchitecture Landscape\u201d consists of elements typical to EA. This section of the LEAF is based on architectural layers: business, application and technology, according to core layers of\u00a0ArchiMate<\/a><\/span>. Information architecture elements such as “business concepts” and “data objects” are positioned vertically over the horizontal layers. This layered structure is better aligned with Service-Driven approach, in which development focus is on services. In addition, the layered structure is more practical as it can be intuitively aligned with reality: business behavior, customers and the services they use on the top, technologies in the bottom, and logical applications in between.<\/span><\/p>\n This layered structure of the EA content can be managed within “domains”.<\/p>\n A Domain<\/strong><\/em> in the LEAD <\/span> context is particular, precisely defined business area or another cohesive and logical unit that is considered as a whole, which may cover several services, processes etc. A domain can be an organization unit, a new capability (area), a digitalization plan (digital transformation plan) with specific coverage, a logical part of the enterprise, with specific business relevance as a connective purpose. Alternatively, a domain can be a construct that is based on a “pace-layered strategy” according to Gartner.<\/p>\n Actual EA content is managed within Architecture Landscape layer of the LEAF (figure below), which exists for each domain on the first layer. This layered approach is based on ArchiMate framework (link<\/a>).<\/p>\n Conventional approach is not very practical, as it splits the architecture into content-based domains (biz, data, app, tech) instead of \u201cnatural\u201d domains of reality (e.g. business domains). The conventional approach is illustrated in the figure below.<\/span><\/p>\n In LEAD it is important to make the overall development visible. This is enabled by utilizing a EA-tool for visualizing all the development targets from ideas to production. The visualization tool is used for design and publishing purposes. The tool can be whichever fits for purpose, as long it provides a browser-based publishing feature that makes all the architecture deliverables available for all the concerned stakeholders. LEAD highly encourages to model-based architecture design. This approach recommends to utilize professional modeling tool with a repository and support to standard modelling notations such as ArchiMate<\/a><\/span>, BPMN<\/a><\/span> or UML<\/a><\/span>.<\/span><\/p>\n A standard notation such as Open Group ArchiMate provides a common symbolic language (<\/span>Lingua franca<\/span><\/i>) that provides the most relevant concepts and their relations as a complete reference catalog for systematic modelling. Professional modelling is more advantageous in the long run, as all the diagrams follow the same style and there exist commonly agreed element types and connectors – instead of case-specific drawings with arbitrary elements and connecting lines between them. As visualization is one of the key elements of the LEAD , it is a significant matter how diagrams are to be created. In addition, according to research, most people perceive complex problems by visualization. So it is really worth of changing the culture to demand more quality from the architecture artifacts, just starting by doing. The more the maturity level of the organization climbs up, the more high-quality deliverables are appreciated and valued.<\/span><\/p>\n The LEAD approach is based on architecture visualization, which is enabled by utilizing an EA Tool. The EA Tool provides modeling and publishing capabilities. The EA Tool is used by modelers, who manage the enterprise architecture content in the repository. Other users in the enterprise can browse the architecture content typically via web-enabled portal interface. The EA Tool makes the architecture content visible in the organization. Modelers can publish the content continuously to different stakeholder groups. The published content can be restricted e.g. based on the content or the user group. Some content can be provided via Portal web-application (if applicable) to authenticated & authorized users only, and some content can be made publicly available also to unauthenticated users.<\/span><\/p>\n The EA Tool can be integrated with other applications such as portfolio management system, Configuration Management DataBase (CMDB), IT Service Management (ITSM) system and Service Portal. The \u201cEA data\u201d that is managed within the EA Tool, can be enriched with other data such portfolio items from the portfolio management system. In addition, the EA data from the repository of the EA Tool can be provided e.g. to ITSM system. <\/span><\/p>\n Lean development encourages to\u00a0Service-Driven Approach (SDA)<\/em>,\u00a0in which the enterprise\u00a0operational development is focusing on services – instead of projects. So it is all about services: “everything is a service”. The framework visualizes how services flow through the value delivery chain, the “production line”, from concepts to production. The services are associated with business value right from the start: from early design phase via development to operation. Co-creation and ideation phases, as well as experimental exercises can be included too – those are to be made visible more accurately in the framework.\u00a0<\/span><\/p>\n The Service-Driven Approach combines Service Design and Enterprise Architecture, by focusing on customer-facing services when developing a target area (such as business unit or another domain). This approach is based on modelling practice, and highly encourages to utilize a modelling tool.<\/span><\/p>\n The Service-Driven Approach is focused on services as primary units of value creation, planning, development and control. The services are planned based on customer needs by utilizing modern service design methods and architecture landscape. After development phase (build or buy), services are deployed to production (as Operation Building Blocks, OBB), that are operated as IT-services.<\/span> 1. Business Service <\/strong>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2017\/09\/LEAD-logo.png\"){kind=logo}
The Lean Enterprise Architecture Development (LEAD<\/a>)<\/strong> method\u00a0<\/span>is a new style of EA approach. The LEAD consists of a) value chain-based operating model and b) framework. The operating model organizes enterprise and its capabilities around the value delivery chain. The Framework, with revised architecture practice, supports the organization to fulfill the design, development and operational tasks. <\/span>The LEAD combines Lean and Agile thinking with an overall, holistic enterprise development & delivery approach, which covers all the aspects from strategy planning to operations. The LEAD can be adapted to target area of any size: to the whole enterprise, to the business unit or other domain, to digital strategy planning and execution etc.\u00a0<\/span><\/p>\n\n
\n
\n
Operating Model<\/h3>\n
Value Delivery Chain<\/h4>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2017\/09\/Idea-to-Production-development-value-stream.png\")
Lean Enterprise Architecture Framework (LEAF)<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/12\/LEAF-logo.png\"){kind=logo}
The Lean Enterprise Architecture Framework (LEAF) can be used as the main navigation view of the overall operational development of an enterprise. <\/span><\/p>\n\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/12\/LEAF-level-1-1.png\")
1.2 Background<\/h3>\n
Management Challenges<\/h4>\n
EA Crisis<\/h4>\n
\n
Agile Methods vs. Big Design Upfront (BDUF)<\/h4>\n
Pragmatic Approach Needed<\/h4>\n
\n
2. LEAD Concept More Detailed<\/h2>\n
Operating Model<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/12\/Idea-to-Production-Value-Stream-1024x597.jpg\")
<\/a>Customer Perspective And Holistic Development Approach<\/h3>\n
Architecture Practice<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2017\/09\/EA-Capability.jpg\")
<\/a>Architecture Work<\/h3>\n
Architect Role(s)<\/h3>\n
Architecture Landscape<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/LEAD-operating-model-and-EA-content-growing-like-Tetris-1024x395.png\")
<\/a>Architecture Content<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2017\/09\/EA-Content-Lean-EA-Approach.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/12\/LEAF-layer-2.png\")
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2017\/09\/EA-Content-Conventional-Approach.jpg\")
<\/a>Architecture Visualization<\/h3>\n
EA Tool<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2017\/09\/EA-Tool.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2017\/09\/EA-Tool-Integrations.jpg\")
<\/a>Service-Driven Approach (SDA)<\/h3>\n
\n<\/span>
\n<\/span>There can be identified certain types of services (according to ArchiMate and TOGAF) as follows :<\/span><\/p>\n
\n<\/span>– A business service represents an explicitly defined exposed business behavior<\/span>