Business Architecture
A capability model of the organisation's functions, independent of its current structure, serving as the anchor for every other architectural view.
01Service · Digital Transformation
Architecture that governs what is delivered
Enterprise architecture justifies its place when it changes decisions. X-Shift produces architecture that is applied in practice: capability models recognised by the business, an application and data estate mapped as it exists, and a target state supported by the governance required to maintain procurement and delivery in alignment with it.
Enterprise capability mapCurrent estate traced to capability
GovernedBusinessServicesLicensingFinanceWorkforce
ApplicationCRM ×2No systemERPHR suite
DataCustomerLicenceLedgerEmployee
Integration
TechnologyCloudHostingNetworkSecurity
AlignedOverlapGap
Design authorityTarget state governed
Enterprise ArchitectureConsult X-Shift
What we do
Architecture at the level at which decisions are made
X-Shift develops enterprise architecture across the four domains (business, application, data and technology), together with the integration layer that determines whether the whole functions as a coherent system. The work commences from business capability, as this is the language used by executives and the only stable basis for assessing application overlap. From that point, the estate is mapped as it exists, a target architecture is defined that resolves the duplication and dependency identified by the mapping, and the governance that maintains the alignment of new work is established. The practice aligns with recognised architecture frameworks and national reference models, adapted to the organisation's decision-making model rather than applied as doctrine. The output is a set of artefacts that architecture boards, procurement and delivery teams can apply within the week of receipt.
- 01Business capability
- 02Application estate
- 03Data
- 04Technology
- 05Integration layer
- 06Governance
Capabilities
Four domains, one connected view
Architecture that concludes at diagrams does not alter outcomes.
Application Architecture
The application estate mapped to business capabilities, revealing overlap, gaps, unsupported systems and the full cost of maintaining duplication.
02Data Architecture
Core data entities, ownership, mastering and flow between systems, establishing which system is authoritative for each entity and why.
03Technology Architecture
Infrastructure, hosting, platform and security foundations described in terms of what they permit and constrain for the application estate above them.
04Integration Architecture
Integration patterns, interface inventory and the target approach to connectivity, replacing accumulated point-to-point links with a governed model.
06
Target-State Architecture
The intended future estate across all domains, with the rationalisation decisions made explicit and the transition dependencies identified.
07
Architecture Governance
Architecture review forums, design authority, standards and exception management, so that decisions can be made promptly without diverging from the target.
08
Architecture Roadmap
The sequence of rationalisation, replacement and integration work that transitions the estate from current to target without interrupting operations.
Architecture
How each view builds on the preceding one
Each view is anchored in the preceding one. Commencing from any point other than capability produces architecture that becomes obsolete with the next reorganisation.
- 01Business capability model
- 02Current-state estate map
- 03Rationalisation analysis
- 04Target-state architecture
- 05Design authority
- 06Transition roadmap
Capability is the only anchor sufficiently stable to withstand structural change.
Deliverables
What is provided to architecture boards and procurement
Artefacts that are usable within the week of handover, without a further interpretation exercise.
- 01
Business capability model
The organisation's functions, expressed independently of structure, serving as the anchor for every other architectural view.
- 02
Current-state estate map
Applications, data entities, interfaces and technology catalogued against capabilities, including systems absent from any official inventory.
- 03
Rationalisation analysis
Overlap, gaps, risk and dependency assessed, with a stated recommendation to retain, replace, consolidate or discontinue each item.
- 04
Reference architecture
The target estate across business, application, data, technology and integration, with principles and standards stated explicitly.
- 05
Architecture governance charter
Design authority, review forums, standards, exception routes and the decision points in which architecture participates.
- 06
Transition roadmap
Architectural change sequenced against dependencies and business constraints, transferred to portfolio governance as fundable work.
Approach
From capability model to design authority
The current-state view is developed rapidly enough to remain accurate, and the target view precisely enough to govern against.
ACCOUNTABILITY AT EVERY STAGEA named owner and a defined output at every stage, from commencement to completion.
01 / 06
01
Capability model
Business capabilities are defined and agreed with leadership, providing every subsequent architectural view with a stable, organisation-independent anchor.
OutputBusiness capability model
02 / 06
02
Current-state mapping
Applications, data entities, interfaces and technology are catalogued against capabilities, including systems absent from any official inventory.
OutputCurrent-state estate map
03 / 06
03
Analysis and rationalisation
Overlap, gaps, risk and dependency are analysed, producing clear recommendations on which items to retain, replace, consolidate or discontinue.
OutputRationalisation analysis
04 / 06
04
Target architecture
The future estate is defined across business, application, data, technology and integration, with principles and standards stated explicitly.
OutputReference architecture
05 / 06
05
Governance design
Design authority, review forums, standards and exception routes are established so that architecture participates in decisions at the appropriate point.
OutputArchitecture governance charter
06 / 06
06
Transition roadmap
Architectural change is sequenced against dependencies and business constraints, and transferred to portfolio governance as fundable work.
OutputTransition roadmap
When this is required
The estate has grown faster than it has been documented
Systems accumulate through procurement decisions, each reasonable in isolation.
Over a decade, an organisation acquires overlapping applications, point-to-point interfaces and data held in multiple locations under multiple definitions. This outcome is rarely intentional. The cost emerges later, as every change requires investigation and every new system arrives with an unforecast integration cost.
Client responsibilities
What the engagement requires from the client
Mapping an estate depends on stakeholders disclosing the systems that are absent from the inventory.
- 01
Access to application inventories, licence records, contracts and interface documentation, regardless of completeness
- 02
Named contacts in each business area who can identify the systems in use by their teams
- 03
An architecture sponsor able to confer formal standing on the design authority in procurement decisions
- 04
Agreement on the recognised framework or national reference model with which the architecture must align
Outcomes
Decisions are no longer made without full visibility
Resulting changesThe organisation obtains a shared and current view of its estate, and a target towards which it is measurably progressing. Procurement, delivery and architecture reach agreement more readily because the standard is documented.
- 01
Every application is linked to a business capability and a named owner
- 02
One authoritative source is agreed for each core data entity
- 03
New systems are assessed against a target architecture before procurement
- 04
Integration cost becomes predictable rather than identified during delivery
Common questions
Questions commonly raised before commissioning this work
What is the typical duration of this work?
Capability modelling is rapid. Current-state mapping takes as long as the estate is undocumented, which is rarely known at the outset. X-Shift will scope the mapping to the capabilities of greatest business value rather than attempting the entire estate in a single pass.
What is required from the client for this work to succeed?
Inventories and contracts regardless of completeness, named contacts in each business area, and a sponsor able to confer standing on the design authority. Architecture without authority in procurement becomes documentation, which is a predictable waste of investment.
How is this contracted and priced?
Typically in two phases: capability model and current state, followed by target architecture and governance. Pricing is fixed per phase, and the second phase is optional by design, as some organisations require only an understanding of their existing estate.
Architects are already in place. What does X-Shift add?
Frequently capacity and independence rather than knowledge. Internal architects typically know the estate better than any consultant; what they lack is the time to map it and the standing to enforce a target. Where both exist, this work is not required.
Next
Recommended next steps
01
Map the existing estate
Capability model and current-state estate map, including systems absent from any official inventory, delivered as a usable catalogue.
Applicable where no party can state which applications support which capabilities.
Consult X-Shift02
Address the integration layer
Where the architecture is broadly understood and the constraint lies in the connections, enterprise integration is the faster route to resolution.
Applicable where every change has unpredictable effects across systems.
Solution Architecture and Systems IntegrationArchitecture without standing in procurement decisions produces artefacts that become obsolete unnoticed.
Related offerings
Related
Service
Solution Architecture and Systems Integration
Translating target architecture into integrated systems that operate as a single whole.
Service
Data Governance and Management
Ownership, definitions and quality behind the data architecture.
Service
Digital Maturity and Transformation Strategy
The strategic direction that architecture is designed to serve.
Service
Application and Platform Development
Developing new systems within the standards defined by architecture.
Solution
Data and Business Intelligence
Analytics established on a governed and documented data architecture.
Industry
Government
Architecture aligned to national reference models and standards.
Is this the work required?
A short conversation is typically sufficient to establish whether this is the appropriate engagement, a narrower one, or an alternative.