1. Introduction
In this digital age, Enterprise Architecture (EA) planning is more important than ever before. New computing models such as cloud, mobility, Internet of Things (IoT) and API economy have arisen, and the overall complexity of the organization’s landscape increases continuously. However, quite often conventional Enterprise Architecture Frameworks have been found too complex, too academic and cumbersome to understand. More practical and easier approach with simpler framework is needed.
1.1 The Lean Enterprise Architecture Development (LEAD) Method
The Lean Enterprise Architecture Development (LEAD) method 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 value delivery chain. The Framework, with revised architecture practice, support the organization to fulfill the design, development and operational tasks. The LEAD combines Lean and Agile thinking with 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 whole enterprise, to business unit or other domain, to digital strategy planning and execution etc.
In LEAD, all the relevant organizational capabilities related from management to operations are organized around the value delivery chain based operating model. Those capabilites cover management, design, development and operations. The architecture practice is involved into 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 of multi-disciplinary roles & teams and architecture landscape visibility are the key principles and enablers. The LEAD operating model is supported by the Lean Enterprise Architecture Framework (LEAF), which is made available with appropriate EA modelling tool.
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.
Questions to which the LEAD concept tries to answer:
- How to set up an integrated, Lean and agile operating model that:
- integrates organizational capabilities around value chain based production line,
- utilizes lean and agile practices, methods and tools,
- leverages on collaboration and co-operation of multidisciplinary roles,
- organizes and adjusts the management and control mechanisms more practical.
- How to renew a conventional Enterprise Architecture practice to:
- support the Lean operating model,
- establish a new agile and collaborative architecture practice,
- modernize EA framework and development method to create architecture artifacts just-on-time basis,
- use a visualization tool to make all the development targets visible.
Operating Model
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.
Value Delivery Chain
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 “from ideas to production”. This puts the service concept into dominant position, as “everything is a service”. Service is the primary unit of value creation, development and operation.
LEAD value delivery is focusing on services instead of projects. This approach is supported with the Service-Driven Approach (SDA), which is in the core of the LEAD . As such, LEAD combines customer centric service design thinking with enterprise architecture. This interconnects the “outside-in” and “inside-out” -viewpoints into comprehensive approach, which take advantages from both design thinking and system thinking viewpoints. The value delivery chain can be expressed in the form of Service Delivery Chain, as illustrated in the figure 1 below.
Lean Enterprise Architecture Framework (LEAF)
The Lean Enterprise Architecture Framework (LEAF) can be used as a main navigation view of the overall operational development of an enterprise. The framework is organized into layers, each of which contains specific views. The layers are as follows:
- Management: Contains views that are related to governance, strategic planning and business planning of the organization.
- Value Delivery Chain: Contains the Idea to Production value stream, which consists of portfolio views (Conceptual, Logical and Realized Services). This layer visualizes the overall view of development targets (services) from ideation to production. This layer represents the “production line”, to which organization’s development capabilities can be assigned to. The Service Delivery Chain is based on Value Chain approach that can be supported with the Service-Driven Approach (SDA). That is a development method, in which the service -concept is crucial. The Service-Driven Approach combines outside-in (Service Design) and inside-out (Enterprise Architecture) viewpoints into one. The phases design, development and operations can be mapped to as plan, build and run phases.
- Architecture Landscape: Contains views of elements related to overall development. These elements are foundational enterprise architecture content building blocks, that are re-used in composed views on the middle layer. This layer consists of business domains, each of which is divided into three layers according to ArchiMate core framework as follows: Business, Application and Technology.
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.
1.2 Background
Management Challenges
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 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 organization culture may lack of collaborative atmosphere that stimulates “intrapreneurship” and motivates to continuously explore and experiment 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 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.
EA Crisis
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’t 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 “ivory towers”, external to other functions. Some business people and managers may say that architecture is the “necessary evil”, a function without a cause. As such, EA is underrated and misunderstood as a practice, “an sich”. EA is too difficult, it is not understood, it is not interesting. The EA practice has to be changed.
Finnish public sector organizations have been practicing enterprise architecture according to Public Administration Recommendation 179 (latest version v 2.0, 2017). Experiences haven’t 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.
Regardless of the disreputation of the EA, it has intrinsic value. Intuitively, overall insight to the organization’s 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.
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.
The Good, the Bad and the Ugly:
- The Good: Enterprise Architecture is valuable and EAM capability is necessary.
- The Bad: Enterprise Architects are the ones to blame of bad reputation (of EA function), they have to disrupt the EA function or die.
- The Ugly: EA Frameworks and methods are too difficult, complex, cumbersome and clumsy.
Agile Methods vs. Big Design Upfront (BDUF)
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.
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: “big design upfront” 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.
Pragmatic Approach Needed
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:
- Enables customer centric development and more efficient value creation
- Encourages to establish cohesive operating model with clearly defined capabilities
- Increases collaboration between multidisciplinary roles in teams,
- Motivates to cultural changes in the organization, to modern, open, innovative, co-operative approaches based on trust, openness, transparency etc.
- Enforces Lean and Agile thinking and practices throughout the organization
- Simplifies EA practice and framework used
- Balances big design upfront and agile architecture planning extremes
- Promotes tool supported and model-based development
- Consolidates certain distinct methods, such as service design ad enterprise architecture, into one, overall service-driven approach
- Visualizes all the development and operational aspects
- Improves visibility of all the development and operational aspects of the enterprise
- Focuses on smaller development targets such as services, to enable faster lead time from ideas to production
2. LEAD Concept More Detailed
Operating Model
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. 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 and IT-CMF.
An essential capability is “demand management”, 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 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). This “ScrumBan” -style approach makes the overall development collaborative and visible from ideas to production.
Customer Perspective And Holistic Development Approach
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 “complex” system, e.g. large consortium of enterprises, ecosystem, collaborative organization of organizations etc.)
It is worth noticing that there is slight difference between customer-centric and customer-driven 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.
Architecture Practice
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“). 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 nowhere as a distinct function, it is everywhere as an integrated function. It is much more practical to talk about “architecture” 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 -capability is illustrated in the figure below.
Architecture Work
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 – “stop doing enterprise architecture, start doing added value (architecture) tasks of the enterprise”. 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 “production line”, 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. 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.
Architect Role(s)
In LEAD, 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. Specific roles can be e.g. : 1) Enterprise Architect, responsible for business relationships, architecture 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).
Architecture Landscape
That architecture landscape is a combination of current “as-is” and target “to-be” architectures. According to Lean and agile thinking, architecture deliverables are created just-in-time, not just-in-case. The architecture landscape provides the current situation of the organization’s business services, -processes and applications. It is a “situational” view of the enterprise, that is created to fit for purpose. The architecture 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.
According to SAFe there may be “emergent design” and “intentional architecture”, both of which seeds the “Architectural Runway”. 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 technology aspects.
Architecture Content
The LEAF layer “Architecture Landscape” 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 ArchiMate. 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, 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.
This layered structure of the EA content can be managed within “domains”.
A Domain in the LEAD context is particular, precisely defined business area or other cohesive and logical unit that is considered as a whole, which may covers 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 “pace-layered strategy” according to Gartner.
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).
Conventional approach is not very practical, as it splits the architecture into content based domains (biz, data, app, tech) instead of “natural” domains of reality (e.g. business domains). The conventional approach is illustrated in the figure below.
Architecture Visualization
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 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, BPMN or UML.
A standard notation such as Open Group ArchiMate provides a common symbolic language (Lingua franca) 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 exists 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.
EA Tool
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.
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 “EA data” 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.
Service-Driven Approach (SDA)
Lean development encourages to Service-Driven Approach (SDA), in which the enterprise operational development is focusing on services – instead of projects. So it is all about services: “everything is a service”. 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.
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.
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.
There can be identified certain types of services (according to ArchiMate and TOGAF) as follows :
1. Business Service
– A business service represents an explicitly defined exposed business behavior
– A business service is associated with a value (e.g. customer value-add, value for the organization)
– A business service can be realized by a business process or -function, to which an organization structure (such as unit or group or role) can be assigned
– A business service can be realized by manual and automated phases, some of which can be supported or performed by application services
2. Application Service
– An application service represents an explicitly defined exposed application behavior
– An application service exposes the functionality of an application to its environment
– This functionality is accessed through one or more application interfaces
– An application service can be associated with a Use Case
3. Technology Service
– A technology service represents an explicitly defined exposed technology behavior
– A technology service exposes the functionality of a node to its environment
– This functionality is accessed through one or more technology interfaces
– technology services may include e.g. messaging, storage, naming, and directory services
4. IT-service
– An IT-service can be a combination of service types 1-3, but especially analogy with the application service (2) is most the clear
– according to ITIL definition: “A service provided by an IT service provider. An IT service is made up of a combination of information
technology, people and processes. A customer-facing IT service directly supports the business processes of one or more customers and its service level targets should be defined in a service level agreement.”
Note! Service-Driven Approach (SDA) aims to provide a holistic view to what is crucial in terms of overall enterprise development in an organization: SDA is focused on customer and business needs. This can be aligned with “architectural approaches” such as to microservices or Service-Oriented Architecture (SOA), or with other new pradigms such as API-economy or digitalization.
Conclusions
The LEAD acronym can be also be interpreted as LEAn Development, as the main focus is on “Lean and agile development”. The overall enterprise development is the “beef” – not the Enterprise Architecture (EA) as such (“an sich“), the EA is just a part of the story – though a crucial part of the whole story. Lean development is the next stage of evolution, whereas Lean Enterprise Architecture Development can be the first stage… The method is the same. The ultimate target is a lean organization, in which customer experience is valued the most.
Reference Implementation
An example Lean Enterprise Architecture Framework (LEAF) reference model can be found here, which is created with Sparx EA -modeling tool (link).
Any other modeling tool can be used tool that supports standard modeling notation such as Open Group ArchiMate (link) (as well as UML and BPMN). ArchiMate models can be transferred between the tools that support the Open Group ArchiMate Model Exchange File Format (link).
转：https://www.hosiaisluoma.fi/blog/lean-enterprise-architecture-development/
