Change is a constant for any organization. The drivers pushing change can be internal or external and include market pressures, regulatory and legal compliance, and adaptation to Mergers and Acquisitions.
The traditional operating model for delivering change was through the linear, plan-build-run, change process. However, although this approach can deliver value it is not optimal. It has operational limitations, is time-consuming, and, potentially, is wasteful of resources.
As the industry recognized these issues, a trend emerged to move away from the traditional plan-build-run approach to a more progressive and dynamic “continuous business change” or “continuous improvement” process to deliver value to the business on a continuous basis.
Continuous improvement has become a cornerstone of agile enterprise architectures including SAFe and the “From Project to Product” movement.
The Enterprise Architect, who builds models of both the As-Is and To-Be enterprises to support impact analysis, organization-planning, and time-planning of proposed changes has also, therefore, had to adapt, evolve, and develop their mindset to a new way of doing things.
This document describes the two approaches, explains the differences between them, and outlines what they mean for the Enterprise Architect and EA tool usage.
Plan-Build-Run Change
The traditional plan-build-run change process packages change as linear and time-bounded activities directed and orchestrated by centralized planning functions.
With this process, a change project starts with the definition and scope of the required change followed by the establishment of a project team which usually comprises members drawn from across the organization.
Company politics, project prioritizations, and the time required to inform team members about the subject can all introduce delays, often considerable, in this phase of the process.
The project team will be responsible for defining the planning and execution of the change plan.
After project delivery, the team is usually disbanded, with its deep domain knowledge either diluted or lost completely.
The plan-build-run change model is well-known in the industry and has a number of recognized characteristics. Primarily it perpetuates the mindset that business is separate from IT, where the business creates ideas and IT is the factory delivering them. This drives the idea that IT becomes the delivery cost center and a bottleneck in deploying change.
It also assumes a stable operating environment where differences are triggered, prioritized, funded, and driven by a plan-build-run process.
A plan-build-run change process starts with a business case that has a specific project scope and duration. The business case then competes with other project proposals for the necessary up-front investment. As a result, investments concentrate on features and requirements rather than business benefits.
When investment happens it does so in discrete, project-specific, decisions. Stakeholders do not always know if their project will be prioritized, which results in them over-specifying features. While feature cramming may improve their capability, it increases the project’s risk and the likelihood of failure.
Teams for plan-build-process projects usually comprise members from multiple departments with multiple skill sets. They usually collaborate, in parallel, with various other project teams and activities.
As discussed, the establishment of the project team often introduces delays, due to battles over personnel prioritization and time needed to onboard team members.
If a project fails to deliver within the agreed timeline and budget there can be renegotiations over investment, introducing additional delays, uncertainty, and cost.
The dissolving of the team at project completion results in a loss of deep domain knowledge, especially when a project has been delivered using external resources.
To support using the plan-build-run change process the EA model typically requires:
bulk updates of the EA model, which occur at discrete time points, and not on a continuous basis. The EA must collect and update the model in the tool for every major “plan” period. This entails a lot of effort, especially when starting the process, to collect and validate relevant data e.g. what applications do we have?
manual mapping whereby the creation and update of the model are performed by the architecture team. This can often be a bottleneck whenever change needs to be reflected in the EA model.
diarized events which are triggered by the decision cycle rather than the decisions being triggered by changes in relevant data. The EA model is updated during the “plan” process of major changes and so is triggered by the plan-build-run cycle. However, updates should occur when the architecture actually changes.
command structure controls updates through a centralized decision-making structure. As with diarized events, the EA model is controlled by the EA team. All changes go through the architects whenever they decide to update the EA model.
pre-prepared Big Picture Views that cover the entire, large, decision context. Traditional EA tools rely on the architect to manually create specific views which are manually kept up-to-date. Those views are created with a particular role in mind but it is not possible to create all possible views for all possible roles from all possible contexts. As such there will be a limited number of large views that try to cater to the broadest set of stakeholders.
These activities of updating the EA model during the plan-build-run process tend to be linear in execution and tightly connected to the change process. They can be visualized as:
The plan-build-run change process is a conservative way of driving enterprise change and has been the assumption underpinning traditional Enterprise Architecture tool product development, deployment, and use case execution.
The main benefit of the process is its command-and-control, where a single decision point enables major changes to be approved. Such a central node offers the ability to see the consequences of change and to maintain an overall perspective of the project.
Any change project is measured on its ability to deliver on time and within budget. With the plan-build-run process, the project usually delivers on large milestones and is often finished and dissolved before long-term feedback from customers/users is received. This makes it difficult to measure success, be flexible in adjusting projects over time, and increases the risk of not meeting user expectations.
From a modeling perspective, the plan-build-run process is not automated. Updates to the EA model are typically made using drawings, such as Powerpoint or Visio. These drawings tend not to be maintained or kept up to date.
The plan-build-run change process, although widely used, has a number of other drawbacks which are explained in detail in our EA Trends white paper.
As a result of these deficiencies, many change or transformation projects undertaken using this approach realize only limited benefits, must be repeated regularly, or fail completely.
These and other drawbacks are part of the reason for the global trend toward agile business practices.
Continuous Business Change
Continuous business change defines change as a constant flow of activity directed by distributed teams and democratized processes. It is orchestrated by the transparency of information and includes automated monitoring and workflows.
Continuous business change is an agile enterprise mindset that realizes change is constant and that the business needs to be organized to support this continual change. It is the progressive model of enterprise architecture and the target for new-generation EA tool development, deployment, and use case execution.
Consequently, continuous business change requires EA, as a discipline, to evolve to match the new mindset. Change processes need to be adapted and updated to deliver faster time to value and quicker iteration of business ideas. These adaptations require the democratization of design, away from a traditional centralized approach, to allow for a quicker and more efficient change process.
As a consequence, the organization focuses on autonomous areas that deliver their own change. One example of this is moving away from being project-focused to being product-focused. Product-based companies organize their teams around autonomous products which are also known as value streams or bounded domains.
The teams who work with these products are long-lasting and combine cross-functional skills from both business and IT. They continuously analyze and deliver business value and gain deep business or domain knowledge that builds over time. This allows them to drive forward new ideas autonomously.
The result is that the team has continuous value delivery rather than delivery segmented by scope, time allocation, or function.
The continuous business change process has a number of notable characteristics when compared to the plan-build-run process. It is best suited for companies operating in an environment of Volatility, Uncertainty, Complexity, and Ambiguity (VUCA). The product-focused mindset allows them to react to uncertain operating conditions, shifting customer needs, constantly changing competitive landscapes, and deliver continuously.
It provides a structure that allows continuous business and IT expertise for teams to collaborate and improve the company, especially by allowing teams to work autonomously.
Team members, who combine cross/functional business and IT skills, remain members over a long period of time. Such an environment ensures a buildup of domain knowledge, which in turn allows for independent, continuous, analysis and business value delivery.
The team has long-term goals, with smaller deliverables, rather than a fixed scope. Success becomes based on the benefit to the company rather than the milestones of a project. As a result, investment can be targeted at business outcomes for long-term and continuous business capability improvement.
These investments provide a direct, transparent, link between business strategy and capability investment. As a result of continuous investment teams experience long-lived stability.
To support a continuous business change process the EA tool and EA model need to:
be continuously updated through integrations, workflows, and surveys, including automatic updates from external sources
include automated analysis and inference, which removes the need for manual investigation and processing
have rule-based alerts for automatic notifications, removing the need for manual checking and processing
encompass context-driven collaborations
have a full, automated, contextual view of the enterprise
act as the process engine that captures events of the operational processes and automatically triggers follow-up process actions
As the team receives feedback on their successes or failures they can quickly and easily adjust the EA model as necessary. The team continuously prioritizes their work firstly on business outcomes and secondly on strategy. This flexibility significantly reduces the risk of investments not delivering as planned.
Activities within the EA model are performed continuously and automatically and can be represented in a circular manner:
By adopting a continuous business change process an organization will generate continuous benefits and be able to react faster to changing conditions. With a highly automated and distributed EA tool, the EA can provide this value to a large user base on a continuous basis.
With democratization, everyone needs EA to see the whole company and the connections for decision-making, teams, structure, and so on. Democratization allows teams to have more control over decisions within their area of autonomy. But change doesn't always follow organizational boundaries and teams will always need to know where their domain fits within the business and when decisions require collaboration across team boundaries. Architecture becomes more self-service, and enterprise architects take on the role of facilitating these semi-independent teams.
The establishment of the EA tool to support a continuous business change model may require more resources and cultural investment than with a traditional approach.
The need to provide both fast time-to-value and long-term growth and sustainability means that the plan-build-run process and the continuous business change process should not necessarily be seen as contradictory but simply as different points in evolution. Typically, continuous business change can be reached by first completing a plan-build-run change process, which can be illustrated as follows:
The focus for the enterprise architect has been on designing enterprise-wide solutions that require changes in operational processes and supporting IT applications. But today, progressive EAs are increasingly working on continuously adjusting the organization that produces the change. For instance, they try to ensure that teams are organized into development value streams to provide continuous value creation.
The EA, therefore, becomes much more of a coach, consultant, and facilitator to the organization.
The EA tools used within the organization need to support a continuous change environment. Representation of the organization and data must be maintained and automatically updated within the tool. Continuous updates from external data sources must be established and maintained.
The EA tool will also provide continuous and automatic notifications to stakeholders through, for example, alerts, based on integrations, workflows, and surveys.
Summary
Business-based change or transformation projects are constantly happening, driven by the market, legal compliance, Mergers and Acquisitions, and other activities. Traditionally change processes were based on a plan-build-run model but this has proved to be limited in the delivery of excellent and continuous value.
The market has recognized these limitations, resulting in a trend toward developing and adopting a continuous business change model. This model moves from a project-based approach to a product-based approach, whereby an organization creates its teams around autonomous products. These teams are long-lasting, combine cross-functional skills from both business and IT, have deep domain understanding, and effectively drive forward new ideas autonomously.
The approach democratizes processes and uses automation tools to maintain business activities on an ongoing basis.
Customer feedback or data changes, based on date triggers or other information, are used as the basis for collecting this information. Automatic updates can be requested through dashboards, notifications, surveys, or business actions.
By maintaining up-to-date data, accurate processes, and information for each of its business activities an organization can make quick, effective, and autonomous changes for continuous transformation work, resulting in a continuous business value stream for the organization.
For more information about continuous business change and other EA Trends read our EA Trends whitepaper.