By Jason Baragry, Chief Enterprise Architect at Ardoq

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, the industry is moving away from the traditional plan-build-run approach to a more progressive and dynamic “continuous business change” or “continuous improvement” process. This approach distributes autonomy, reacts in a more agile way, and delivers value on a continuous basis. Continuous improvement has become a cornerstone of agile enterprise architectures including Scaled Agile Framework (SAFe) and the “From Project to Product” movement.

The Enterprise Architect (EA), who works with the As-Is and To-Be enterprise models to support impact analysis, organization-planning, and portfolio-planning of proposed changes has also, therefore, had to adapt, evolve, and develop their mindset to a new way of doing things. With today’s modern EA role being more a facilitator of change, both mindset, approach and tools must be updated.

Plan-Build-Run – an outdated approach

The traditional plan-build-run 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.

To support the plan-build-run change process the enterprise architecture artifacts typically require:

Bulk updates of the enterprise architecture 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 application dependencies do we now have and how does IT support the relevant capabilities to be updated in the coming project?
Manual mapping whereby the creation and update of the model are performed by a centralized architecture team. This can often be a bottleneck whenever change needs to be reflected in the enterprise architecture model.
The organization command structure controls updates through a centralized decision-making structure. The enterprise architecture model is controlled by the EA team. All changes go through the architects whenever they decide to update the enterprise architecture model.
Pre-prepared Big Picture Views that cover the entire, large, decision context. Traditional enterprise architecture 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.

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.

However, these change projects are measured on their ability to deliver on time and within budget rather than benefit realization. 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.

Continuous Business Change is The New Normal

Continuous business change is an agile enterprise mindset that begins with the realization that change is constant and that business needs to be organized to support this continual change. This change is delivered 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.

This 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.

These change processes recognize autonomous business 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 may also be 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 responsibility for 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 is measured based on 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, continuous investment teams experience long-lived stability.

To support a continuous business change process the Enterprise Architecture needs 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

Each team continuously prioritizes their own work based on business outcomes and strategy. This requires the EA to enable each product team to also quickly and easily adjust the enterprise architecture model as necessary.

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 will generate continuous benefits and be able to react faster to changing conditions. With a highly automated and distributed Enterprise Architecture, the EA can provide this value to a large user base on a continuous basis.

Autonomous teams require the Enterprise Architecture to see the whole company and provide the connections needed for local decision-making. 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.

Architecting in these two modes of organization change

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 is reached by as a change to the existing plan-build-run 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. This is one of the emerging trends in enterprise architecture.

The EA, therefore, becomes more of a coach, consultant, and facilitator to the organization.

The enterprise architecture 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.

Next steps for EAs

Enterprise Architects must adapt to agile, continuous ways of working. The goal is to improve throughput by reducing the need for coordination between teams, but it will be unrealistic to expect total elimination. There will always be some change initiatives that require prioritization and delivery coordination across areas and EAs will play their traditional roles to support this.

Similarly, there will be design decisions that are common for all rather than for individual product-areas. For instance, security, stability, and robustness. Architects are still necessary to take responsibility for these cross-domain design issues. Optimizing for one set of outcomes de-optimises for another, and that’s why the EA still has a role in agile change.

However, evolving to these new ways of working is part of the new rules for EAs:

Stakeholder Management: The architect’s role moves from being the formal architect / governor / auditor to being more of a facilitator / broker / influencer. This isn’t a complete shift, more a change of primary emphasis. The architect must curate and mediate multiple intersecting virtual communities-of-interest.

Models and Artifacts: The architecture itself must go from being formally-defined and centrally-provisioned to being mass-consumable and self-service. Non architects must be able not only to self-serve but also self-create. UX and agility is more important than Frameworks and formal notation.

Processes: Processes to create, approve or update architecture must be done by the teams themselves. The EA’s task in these cases is to monitor, govern, and mediate.

In other words, with democratized architecture the EA has as much role in providing structure to collaborations as he/she does to providing structure to systems.