Transformation and Target-State Planning
From Current State to Future State
Target-State Architecture for Enterprise Transformation Planning
Target-state architecture gives organizations a structured way to define where the enterprise is going and understand what must change to get there.
GlobeArc keeps Current, Interim, and Target states within the same connected repository, so teams can compare architecture states without maintaining a separate set of future-state diagrams that gradually drift away from the information describing the organization today.
This makes transformation planning more concrete.
Architecture, process, and transformation teams can identify what is being added, removed, or changed, examine property-level differences, understand how plans vary across locations and organizational units, and use those differences to inform sequencing, roadmaps, and decision checkpoints.
What Is Target-State Architecture?
Target-state architecture describes the intended future structure of the organization across relevant business and technology domains. It provides a defined destination against which teams can assess the Current architecture and determine what needs to change.
A useful Target state goes beyond a static future-state diagram. It should remain connected to the applications, capabilities, processes, organizational structures, and other architecture information that transformation decisions depend on.
What Is the Difference Between Current-State and Target-State Architecture?
Current-state architecture represents how the organization operates today, while Target-state architecture represents the intended future structure after planned change. The difference between them reveals the architecture changes the transformation needs to address.
Interim states can represent meaningful stages between those two points. This allows teams to describe transition architectures where moving directly from Current to Target would be unrealistic.
Why Do Current and Target Architectures Become Disconnected?
Future-state models often begin as useful planning artifacts but become outdated when they're maintained separately from the Current architecture. As applications, processes, capabilities, and organizational structures change, teams have to update multiple diagrams and reconcile different versions of the same enterprise information.
That creates familiar transformation problems:
- Target architectures that no longer reflect the Current estate
- Different teams working from different future-state assumptions
- Changes that are difficult to trace between architecture states
- Location or organizational unit differences hidden by one enterprise-wide view
- Roadmap discussions based on diagrams that can't be compared consistently
GlobeArc addresses the structural problem by making architecture state part of the repository context rather than treating Current and Target as unrelated models.
How Does GlobeArc Keep Current and Target Architecture Connected?
State is a native planning context applied to architecture information, allowing Current, Interim, and Target perspectives to coexist within the same repository. Teams can therefore work with different architecture states while preserving the relationships and context needed to compare them.
State also works alongside Location and Org Unit. That combination gives architects a way to examine not only how architecture changes over time, but also how it differs across geographical and organizational contexts.
The underlying approach is:
State × Location × Org Unit
This makes transformation context part of the architecture data rather than something added only to presentation diagrams.
How Do You Compare Current and Target Architecture?
Compare States identifies structural and property differences between two architecture states, giving teams a clearer view of what the transformation changes. Instead of visually inspecting separate diagrams, architects can compare defined states using information from the connected repository.
The comparison can reveal:
- Elements present in Current but not Target
- Elements introduced in the Target state
- Relationships that differ between states
- Properties whose values have changed
- Directional changes between property values
This helps teams move from a general future-state vision to a more specific description of the architecture delta.
How Do Property-Level Comparisons Improve Transformation Planning?
Property-level comparisons show how an architecture element changes even when the element itself exists in both states.
This matters because transformation doesn't always involve adding or removing applications, capabilities, or processes. Sometimes the important change is in their characteristics.
For example, an application can exist in both Current and Target while its lifecycle status, Technical Fit, or annual cost changes between the two. A team can therefore distinguish structural change from changes to the information describing an object.
Those differences provide additional evidence for planning discussions, impact assessment, and decisions about what needs attention during the transition.
How Do Interim States Support Transition Architecture?
Interim states represent meaningful architecture stages between the Current and Target environments. They help teams describe how the enterprise may need to look during a transition instead of assuming that every change can happen simultaneously.
An Interim state can be useful when dependencies, organizational constraints, or implementation decisions require the transformation to progress through distinct architecture configurations. Teams can model those stages and compare them to understand how the enterprise changes along the path.
How Can Dependency Analysis Inform Transformation Sequencing?
Connected architecture relationships help teams understand which changes may depend on others before deciding how transformation should be sequenced. A proposed application, process, or capability change can be investigated in the context of the other enterprise elements connected to it.
This can reveal considerations such as:
- Applications that support an affected capability
- Integrations connected to a changing application
- Processes associated with the business area
- Organizational units involved
- Architecture elements that remain until a later state
- Target elements that depend on earlier changes
How Does GlobeArc Support Transformation Impact Analysis?
Impact analysis starts by tracing the relationships around an architecture element and then examining how those relationships differ across states and contexts. This helps teams understand whether a proposed change is isolated or connected to a wider set of business and technology dependencies.
Relationship Explorer, connected repository information, and state comparison provide complementary perspectives. Architects can investigate the surrounding architecture before deciding how a proposed Target-State change should be implemented.
That context can reduce the risk of planning a change in isolation from the capabilities, processes, applications, integrations, and organizational areas that depend on it.
How Do Geographic Variations Affect Target-State Architecture?
Location context allows the same transformation to be examined across different geographic areas rather than assuming that one architecture applies identically everywhere. Teams can see where architecture follows the broader enterprise pattern and where a regional variation needs to be represented explicitly.
This is useful when regulations, operating models, technology availability, local systems, or other constraints affect how the Target state should be implemented. Hierarchical location context also supports broader rollups while preserving more specific differences where required.
How Do Organizational Unit Variations Affect Transformation Planning?
Org Unit context lets teams represent architecture differences across organizational units while keeping those variations connected to the wider enterprise model. This provides a clearer way to distinguish a deliberate organizational exception from an inconsistent or outdated architecture.
Combined with State and Location, organizational context allows architects to examine transformation from several dimensions without creating an entirely separate repository for every variation.
That becomes particularly useful in federated organizations where the destination may be shared, but the starting point and transition path differ across organizational units.
How Can BPMN Process Models Be Compared Across States?
BPMN comparison shows how a process changes between architecture states by identifying matched, changed, renamed, added, and removed process elements. This provides a more detailed process-level view of transformation than simply knowing that the process exists in both Current and Target states.
Because process models can connect to repository objects such as stakeholders, organizational units, locations, and applications, the comparison can be considered within the wider transformation context.
For processes, simulation and the Process Analysis view also compare how Current and Target variants perform on cost, duration, wait time, and team capacity.
Transformation Roadmap
How Can Target-State Architecture Inform a Transformation Roadmap?
The architecture delta between Current, Interim, and Target states provides evidence for deciding what a transformation roadmap needs to address. Teams can use state comparisons and dependency context to identify meaningful packages of change and determine where sequencing, milestones, and decision checkpoints are required.
A practical planning flow can move through:
1
Establish the Current Architecture Baseline
Document the existing architecture to create a reliable baseline of applications, business capabilities, technologies, and dependencies for transformation planning.
2
Define the Intended Target Architecture
Model the desired future architecture to align business objectives, technology investments, and organizational priorities with the long-term enterprise strategy.
3
Identify Structural and Property-Level Differences
Compare the Current and Target architectures to identify changes in architecture components, relationships, and properties, highlighting the gaps that need to be addressed.
4
Investigate Dependencies Around the Affected Architecture
Analyze relationships and dependencies surrounding affected components to understand the potential impact of proposed changes and reduce transformation risks.
5
Define Interim States Where Transition Architectures Are Necessary
Model intermediate architecture states when changes need to happen in stages, so each step of the transition can be planned and compared.
6
Examine Location and Organizational Unit Variations
Assess differences across locations, organizational units, and operational environments to account for local requirements while maintaining alignment with the overall target architecture.
7
Determine an Appropriate Sequence for the Required Changes
Prioritize architecture changes based on dependencies, business value, complexity, and risk to establish a practical and achievable transformation sequence.
8
Translate Architecture Changes into Roadmap Milestones and Decision Checkpoints
Turn planned architecture changes into actionable roadmap milestones, defining key decision points to track progress, validate outcomes, and guide transformation delivery.
How Do Roadmap Milestones and Decision Checkpoints Fit Into Transformation Planning?
Roadmap milestones and decision checkpoints give teams defined points to assess whether planned architecture and process changes are progressing toward the Target state.
An Interim state can serve as one of those checkpoints, helping leaders review whether key dependencies, organizational changes, and required conditions are in place before the next stage proceeds.
GlobeArc provides the connected context behind those decisions by showing how Current, Interim, and Target states differ and what relationships surround the proposed changes.
That gives transformation teams clearer evidence for deciding when to move forward, when to adjust the plan, and where additional investigation is needed.
How Do You Keep Target-State Architecture From Becoming Outdated?
Target architecture stays more useful when it is maintained as part of the same architecture repository as the Current state rather than as a disconnected future-state artifact. Changes can then be understood in relation to shared objects, relationships, properties, and planning contexts.
This doesn't remove the need for architecture governance. Teams still need to maintain the intended Target state as decisions change. It does, however, reduce the structural problem of maintaining the future architecture in an entirely separate set of files and diagrams.
Who Uses GlobeArc for Target-State Architecture and Transformation Planning?
Enterprise architects typically lead the architecture work because they need to define the future state, understand the delta from Current, and assess the dependencies around proposed change. Business architects and process teams can contribute capability, process, and operating-model perspectives, while executives and transformation leaders use the resulting architecture context to understand what the intended change actually means for the organization.
What Does Target-State Planning Need?
Target-state planning needs enough Current-State evidence to define the gap to the future architecture, expose important dependencies, and understand where the transformation may vary across the organization.
Useful inputs can include:
- Applications and their relationships
- Business capabilities
- Business processes
- Value streams
- Organizational units
- Locations
- Relevant object properties
- Current, Interim, and Target states
- Application integrations
- Stakeholder relationships
- Other architecture dependencies relevant to the transformation
The required depth depends on the decision being made. A technology modernization may require detailed application and integration information, while an operating-model change may place greater emphasis on capabilities, processes, stakeholders, and organizational context.
How Do Transformation Outputs Support Architecture Decisions?
Transformation outputs help teams identify the difference between today's architecture and the intended future state, then investigate the context behind those changes. This gives architects and transformation leaders a shared basis for discussing what must change before translating architecture decisions into delivery plans.
Useful outputs can include:
- Current-State architecture views
- Target-State architecture views
- Interim-State views
- Compare States results
- Added, removed, and changed architecture elements
- Directional property changes
- BPMN process comparisons
- Location architecture variations
- Organizational unit architecture variations
- Dependency context around proposed changes
What Other EA and BPM Solutions Support Transformation Planning?
Related solutions include:
- Application Modernization and Landscape Management
- Application Rationalization
- Strategy to Execution
- Mergers and Acquisitions Integration
- Process Standardization Across Locations and Organizational Units
Move From Current Architecture to a Defined Target State
Transformation becomes easier to reason about when teams can see where the organization is today, where it intends to go, and what changes between those two points. GlobeArc keeps Current, Interim, and Target architecture connected to the same repository so those differences can be examined rather than reconstructed manually.
Use GlobeArc to compare architecture states, investigate dependencies, understand geographic and organizational variations, and provide the architecture evidence behind transformation sequencing and roadmap decisions.
We’re here to help you bring clarity to complexity.