Change is a constant for any organization. The multiple drivers pushing change are both internal and external. Uncontrollable factors like market pressures, regulatory and legal compliance, plus mergers and acquisitions make instability a constant.
The operating model for delivering change in business has traditionally been through linear, plan-build-run change processes. This approach can deliver value, but it is far from 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 evolution” process to continuously deliver value to the business.
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 had to adapt, evolve, and develop their mindset to a new way of doing things.
Here we will explore two approaches: “plan-build-run” and “continuous business change.” We will outline the difference between them and what they mean for the Enterprise Architect and the tools they use.
The Plan-Build-Run Change Model
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, followed by the establishment of a project team. The project team members usually come from across the organization. Company politics, project prioritizations, and the time required to inform team members about the subject can all bring long delays 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.
Vulnerabilities of Separating Business from IT
The plan-build-run change model has a number of recognized characteristics. The process is a conservative way of driving enterprise change and it has been the assumption that it underpins traditional Enterprise Architecture tool product development, deployment, and use case execution.
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 and 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.
Challenges to the Enterprise Architecture Model with Plan-Build-Run
Not focusing on continuous change and rather focusing on plan-build-run can have negative consequences for organizations. For example, if a project fails to deliver within the agreed timeline and budget there can be renegotiations over investment, introducing additional delays, uncertainty, and cost.
There are also consequences for the people working on the project. 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 Enterprise Architecture model typically requires:
- Bulk updates of the model at discrete time points, and not on a continuous basis. The architect must collect and update the model in the tool for every major “plan” period. This entails manual effort, especially when starting the process.
- Manual mapping by the architecture team. This can often be a bottleneck whenever change needs to be reflected in the Enterprise Architecture model.
- Diarized events triggered by the decision cycle rather than the decisions being triggered by changes in relevant data. The architectural model is updated during the “plan” process of major changes. However, updates should occur when the architecture actually changes.
- Command structure controls updates through a centralized decision-making structure. As with diarized events, the Enterprise Architecture 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 decision context. Traditional EA tools rely on the architect to manually create specific views which are not automatically 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 potential roles from all contexts. As such, there will be a limited number of large views that try to cater to the broadest set of stakeholders.
In this evolving landscape, enterprise architecture principles play a crucial role in guiding the transition from traditional models to continuous change processes. These principles ensure that the architecture remains aligned with the organization’s strategic goals, promote consistency, and facilitate efficient decision-making across autonomous teams.
Updating the EA model during the plan-build-run process tends to be linear in execution and tightly connected to the change process. They can be visualized as:
Benefits of a Plan-Build-Run Process
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 increase 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.
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.
What Is Continuous Change in Business?
Continuous change for business is a constant flow of activity directed by distributed teams and democratized processes. It is orchestrated by information transparency and includes automated monitoring and workflows.
Continuous change is an agile enterprise mindset. It knows that 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.
Enterprise Architecture Supports Continuous Change
Consequently, Enterprise Architecture as a discipline needs 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.
The organization can then focus 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, 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.
Benefits of a Continuous Change Process
Continuous change for business 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). A product-focused mindset allows organizations to react to uncertain operating conditions, shifting customer needs, constantly changing competitive landscapes, and deliver continuously. VUCA provides a structure that enables teams to collaborate and improve company operations, 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. This then opens up doors for independent and continuous analysis while delivering real business value. When business change is “always on,” teams can thrive by having long-term goals with smaller deliverables rather than a fixed scope.
Connecting Business Strategy and Capability Investment
These investments provide a direct and transparent link between business strategy and capability investment. Project teams experience long-lived stability, so long as the Enterprise Architecture tool and model need to:
- be continuously updated through integrations, workflows, and surveys
- include automatic updates from external sources, plus automated analysis and inference
- have rule-based alerts for automatic notifications
- encompass context-driven collaborations
- have a complete, automated, and 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 and failures, they can quickly and easily adjust the Enterprise Architecture model as necessary. The team continuously prioritizes their work to focus on business outcomes. This flexibility significantly reduces the risk of investments not delivering as planned.
Activities within the Enterprise Architecture model are performed continuously and automatically and can be represented in a circular manner.
By adopting a continuous business change process, an organization generates continuous benefits and reacts faster to changing conditions. With a highly automated and distributed EA tool, the EA team can provide this value to a large user base.
With democratization, Enterprise Architecture can see the whole company and the connections for decision-making, teams, and structure. Democratization allows teams to have more control over decisions within their area of autonomy. However, change doesn't always follow organizational boundaries, and teams will 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.
Typically, continuous business change can be reached by first completing a plan-build-run change process, and then adjusting automatically and regularly:
Progressive architects make sure teams are organized into development value streams to provide continuous value creation. Then the Enterprise Architect becomes much more of a coach and consultant 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 through, for example, alerts based on integrations, workflows, and surveys.
A Value Stream for Always-On Enterprise Architecture
Business-based change or transformation projects are constantly happening. These projects are 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 approach democratizes processes and uses automation tools to maintain business activities on an ongoing basis.
Customer feedback or data changes based on date triggers are used as the basis for collecting this information. Automatic updates can be requested through dashboards, notifications, surveys, or business actions.
Maintain Data for Continuous Change
By maintaining up-to-date data and keeping processes accurate, each business activity an organization has can make quick, effective, and autonomous changes. This creates a continuous business value stream for the organization. Success then 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.
For more information about continuous business change and other Enterprise Architecture trends, read our Enterprise Architecture Trends whitepaper.
