# Current-State Assessment: [Organisation, domain or programme name]

> Evidence-based baseline of how an organisation's technology estate
> works today: business context, applications, integrations, data,
> infrastructure and hosting, security posture, operations and support,
> measured quality, cost, skills and contracts, ending in rated findings
> and recommendations that the target-state design can act on. It is the
> "as-is" or baseline view that precedes gap analysis in architecture
> methods such as the TOGAF Standard, 10th Edition (Baseline Architecture,
> Gap Analysis), and the portfolio discovery stage of a cloud migration
> programme as described in AWS Prescriptive Guidance (application
> portfolio assessment). Quality is baselined against ISO/IEC 25010:2023,
> security against the NIST Cybersecurity Framework (CSF) 2.0 Functions,
> delivery against the DORA software delivery metrics, and cost with
> FOCUS 1.4 column names where cloud billing data exists. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Agree scope, questions and the evidence standard (section 1) with the
  sponsor first. An assessment without explicit questions turns into an
  inventory nobody reads.
- Collect evidence before interviews where possible: CMDB exports,
  discovery tool output, monitoring data, invoices, contracts, incident
  reports. Use interviews to explain the data, not to replace it.
- Rate the confidence of every finding (section 1.4). Low-confidence
  findings are still useful if they are labelled.
- Keep the inventories in sections 3 to 6 as summaries; link the full
  data set in the evidence log (section 15).
- This document describes today. Options and designs belong in Solution
  Options Analysis (`architecture/solution-options-analysis`), Solution
  Architecture (`architecture/solution-architecture`) or the
  Architecture Definition Document
  (`architecture/architecture-definition-document`). Use Legacy
  Modernization Assessment (`architecture/modernization-assessment`) or
  Application Migration Assessment
  (`architecture/application-migration-assessment`) for disposition
  decisions per application.
-->

## Document control

<!-- Guidance: Identify the scope and the date the baseline describes. Baselines age quickly: state the evidence cut-off date so that readers know how current it is. -->

| Field | Value |
|---|---|
| Document ID | [CSA-001] |
| Organisation, domain or programme | [Name] |
| Baseline date (evidence cut-off) | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Sponsor | [@sponsor] |
| Approvers/reviewers | [@enterprise-architect], [@head-of-it-operations], [@ciso], [@finance-partner] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential: contains system and security details] |
| Related documents | [Engagement brief], [Stakeholder interview guide], [Discovery workshop plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Sponsor | [@name] | [Accept / Accept with comments / Reject] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| IT operations | [@name] | [Decision] | YYYY-MM-DD |
| Information security | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope, questions and method agreed |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Inventories and evidence complete; draft findings for review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved baseline; findings handed to target-state design |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope and method](#1-scope-and-method)
2. [Business context](#2-business-context)
3. [Application landscape](#3-application-landscape)
4. [Integration landscape](#4-integration-landscape)
5. [Data estate](#5-data-estate)
6. [Infrastructure and hosting](#6-infrastructure-and-hosting)
7. [Security posture](#7-security-posture)
8. [Operations and support](#8-operations-and-support)
9. [Quality baseline](#9-quality-baseline)
10. [Cost baseline](#10-cost-baseline)
11. [Organisation, skills and sourcing](#11-organisation-skills-and-sourcing)
12. [Pain points and risks](#12-pain-points-and-risks)
13. [Findings and recommendations](#13-findings-and-recommendations)
14. [Gap summary for the target state](#14-gap-summary-for-the-target-state)
15. [Evidence log](#15-evidence-log)
16. [Glossary and references](#16-glossary-and-references)

## 1. Scope and method

<!-- Guidance: Define what is assessed, which questions the assessment answers, and how strong the evidence must be. Questions: what decision will this baseline support? What is deliberately excluded? Pitfall: assessing everything at the same depth, which delays the parts the decision depends on. -->

### 1.1 Purpose and assessment questions

[One paragraph: why the assessment is being done and which decision it
feeds. *Example:* The organisation plans to consolidate three regional
order management platforms. This assessment establishes the baseline the
consolidation business case and solution design will start from.]

| Question ID | Assessment question | Answered in |
|---|---|---|
| AQ-01 *(Example)* | Which applications support order to cash, and in what condition are they? | Sections 3, 9, 13 |
| AQ-02 *(Example)* | How are those applications integrated, and where are the fragile points? | Section 4 |
| AQ-03 *(Example)* | What does the current estate cost to run per year? | Section 10 |
| AQ-04 *(Example)* | Which components reach end of support in the next 36 months? | Sections 3, 6 |
| AQ-05 *(Example)* | Which security and compliance gaps would block or shape the target state? | Section 7 |
| [AQ-NN] | [Question] | [Sections] |

### 1.2 Scope

| Dimension | In scope | Out of scope |
|---|---|---|
| Business | *Example:* Order to cash in regions North, Central, South | Procure to pay |
| Applications | *Example:* 23 applications tagged to order to cash in the CMDB | End-user productivity tools |
| Infrastructure | *Example:* Two data centres and the cloud tenancy hosting the in-scope applications | Branch networks |
| Organisation | *Example:* IT teams and suppliers supporting the in-scope applications | Business unit headcount |
| [Dimension] | [In scope] | [Out of scope] |

### 1.3 Method

| Step | Activity | Output |
|---|---|---|
| 1 | Agree questions, scope and evidence standard | Section 1 approved |
| 2 | Collect existing data: CMDB, discovery tool, monitoring, invoices, contracts, incident data, previous reviews | Evidence log entries |
| 3 | Interview application, infrastructure, security and business owners using the Stakeholder Interview Guide (`requirements/stakeholder-interview-guide`) | Interview notes, themes |
| 4 | Run discovery workshops where processes or interfaces are unclear (`requirements/discovery-workshop-plan`) | Workshop record |
| 5 | Build inventories and diagrams; reconcile conflicting sources | Sections 3 to 11 |
| 6 | Rate health, identify pain points and risks | Sections 3, 12 |
| 7 | Draft findings and recommendations; review with owners | Section 13 |
| 8 | Approve baseline and hand over to target-state design | Section 14, approvals |

### 1.4 Confidence rating

| Rating | Meaning |
|---|---|
| High | Confirmed by system data or documents and by an owner |
| Medium | Confirmed by one source (data or owner) and not contradicted |
| Low | Based on estimates or a single unverified statement |

## 2. Business context

<!-- Guidance: Record the business facts that make technical findings matter. Questions: which capabilities depend on the estate, what volumes does it carry, and which business changes are coming? Pitfall: a technical baseline that cannot say which business outcome each problem affects. -->

### 2.1 Drivers and constraints

| ID | Type | Description | Source |
|---|---|---|---|
| BC-001 *(Example)* | Driver | Group strategy targets one order platform within three years | Strategy paper YYYY |
| BC-002 *(Example)* | Driver | Order volume growing about 12 % per year | Finance plan |
| BC-003 *(Example)* | Constraint | Regulatory requirement to keep invoices for 10 years in the country of issue | Legal register |
| BC-004 *(Example)* | Constraint | Data centre lease ends YYYY-MM-DD | Facilities contract |
| [BC-NNN] | [Driver / Constraint / Change] | [Description] | [Source] |

### 2.2 Capabilities and volumes

| Capability | Applications supporting it | Volume *(Example)* | Business criticality | Owner |
|---|---|---|---|---|
| Order capture *(Example)* | APP-001, APP-007, APP-008 (regional platforms), APP-002 (portal) | 42,000 orders per month | Critical | Head of Sales Operations |
| Pricing *(Example)* | APP-003 | 1.1 million price records | High | Pricing manager |
| Invoicing *(Example)* | APP-004, APP-005 | 39,000 invoices per month | Critical | Head of Billing |
| [Capability] | [APP-] | [Volume] | [Critical / High / Medium / Low] | [Owner] |

Use the Business Capability Map (`architecture/business-capability-map`)
for the full capability model if one exists.

## 3. Application landscape

<!-- Guidance: List the applications in scope with the facts needed for decisions. Questions: who owns each, how critical is it, what is it built on, when does support end, and how healthy is it? Pitfall: an inventory without owners or lifecycle dates. -->

### 3.1 Inventory

| ID | Application | Capability | Business owner | Technical owner | Type | Technology | Hosting | Users | Criticality | Vendor support end |
|---|---|---|---|---|---|---|---|---|---|---|
| APP-001 *(Example)* | Order Desk North | Order capture | Sales ops North | IT North | Package, customised | Vendor product v8, Oracle Database | DC-A virtual machines | 120 | Critical | YYYY-MM-DD |
| APP-002 *(Example)* | Order Portal | Order capture | Digital sales | Digital team | Custom | Java, PostgreSQL | Cloud, containers | 3,500 customers | High | Not applicable |
| APP-003 *(Example)* | Pricing Engine | Pricing | Pricing manager | IT Central | Custom | .NET Framework, SQL Server | DC-B | 40 | High | Framework version out of support YYYY-MM-DD |
| APP-004 *(Example)* | Billing Central | Invoicing | Head of Billing | ERP team | ERP module | [Product and version] | DC-A | 80 | Critical | YYYY-MM-DD |
| APP-007 *(Example)* | Order Desk Central | Order capture | Sales ops Central | IT Central | Package | [Product and version] | DC-B | 85 | Critical | YYYY-MM-DD |
| APP-008 *(Example)* | Order Desk South | Order capture | Sales ops South | Supplier | Custom | [Stack] | Supplier hosting | 60 | Critical | Not applicable |
| [APP-NNN] | [Name] | [Capability] | [Owner] | [Owner] | [Custom / Package / SaaS / ERP module] | [Stack] | [Location] | [Number] | [Critical / High / Medium / Low] | YYYY-MM-DD |

### 3.2 Application health

Rate each application from 1 (poor) to 5 (good) on each dimension, using
evidence from sections 8 to 10. The example rates the four applications
assessed in detail (APP-001 to APP-004); rate the others at summary level
in the full inventory. Business fit reflects owner and user
views; technical health reflects code, platform currency, defects and
operability.

| ID | Business fit | Technical health | Supportability (skills, vendor) | Cost efficiency | Overall | Confidence | Key evidence |
|---|---|---|---|---|---|---|---|
| APP-001 *(Example)* | 3 | 2 | 2 | 3 | 2.5 | High | Two vendor versions behind; 18 customisations; 1 developer with knowledge |
| APP-002 *(Example)* | 4 | 4 | 4 | 4 | 4.0 | High | Automated deployment; low incident rate |
| APP-003 *(Example)* | 3 | 2 | 2 | 4 | 2.75 | Medium | Unsupported framework; no automated tests |
| APP-004 *(Example)* | 4 | 3 | 3 | 2 | 3.0 | Medium | Stable; high licence cost |
| [APP-NNN] | [1 to 5] | [1 to 5] | [1 to 5] | [1 to 5] | [Average] | [H / M / L] | [Evidence] |

Overall is the simple average of the four dimensions in this example;
state any weighting you use instead. Record technical debt items in the
Tech Debt Register (`architecture/tech-debt-register`).

## 4. Integration landscape

<!-- Guidance: Show how applications exchange data and where the integration is fragile. Questions: which interfaces carry business-critical flows, how are they built and monitored, and what fails? Pitfall: drawing only the interfaces that someone remembers; use logs, middleware configuration and firewall rules. -->

```mermaid
flowchart LR
  PORTAL[APP-002 Order Portal] -- REST, real time --> ODN[APP-001 Order Desk North]
  ODN -- nightly file --> BILL[APP-004 Billing Central]
  PRICE[APP-003 Pricing Engine] -- database link --> ODN
  ODN -- message queue --> WMS[APP-009 Warehouse system]
  BILL -- SFTP file --> BANK[External bank]
  BILL -- batch extract --> DWH[APP-012 Data warehouse]
```

| ID | Source | Target | Business flow | Pattern | Technology | Frequency and volume | Monitoring | Known issues |
|---|---|---|---|---|---|---|---|---|
| IF-001 *(Example)* | APP-002 | APP-001 | Customer order submission | Synchronous API | REST over HTTPS | 700 per day, peak 90 per hour | Endpoint health check only | Timeouts at month-end |
| IF-002 *(Example)* | APP-001 | APP-004 | Orders to invoicing | File transfer | Nightly CSV over SFTP | 1,400 records per night | None; failures found next morning | Re-runs need manual cleanup |
| IF-003 *(Example)* | APP-003 | APP-001 | Price lookup | Direct database link | Database link | Continuous | None | Tight coupling blocks upgrades of either side |
| IF-004 *(Example)* | APP-001 | APP-009 | Fulfilment requests | Asynchronous messaging | Message broker | 1,500 per day | Queue depth alert | Poison messages block the queue |
| IF-005 *(Example)* | APP-004 | External bank | Payment and remittance files | File transfer | SFTP with scripted upload | Daily, about 300 records | Script log only | Credential stored in the script (SEC-003) |
| [IF-NNN] | [APP-] | [APP-] | [Flow] | [API / Messaging / File / Database / Manual] | [Technology] | [Volume] | [Monitoring] | [Issues] |

Summary *(Example)*: 31 interfaces identified, of which 12 are file based,
7 are direct database links, 9 are APIs and 3 are manual. Detailed design
of future interfaces belongs in Integration Design
(`architecture/integration-design`).

## 5. Data estate

<!-- Guidance: Record where important data lives, who owns it, how sensitive it is and how good it is. Questions: which system is the source of truth for each data domain? Where is data duplicated or of poor quality? Where must it stay? Pitfall: listing databases without naming the business data they hold. -->

| ID | Data domain | System of record | Copies held in | Volume | Classification | Residency constraint | Owner | Quality issues | Retention rule |
|---|---|---|---|---|---|---|---|---|---|
| DATA-001 *(Example)* | Customer | None agreed; APP-001 and APP-004 both create customers | APP-002, APP-012 | 85,000 customers | Confidential, personal data | Within the EU | Not assigned | About 8 % suspected duplicates | Per privacy policy |
| DATA-002 *(Example)* | Price | APP-003 | APP-001 cache, spreadsheets | 1.1 million records | Internal | None | Pricing manager | Customer-specific prices also held outside APP-003 | 7 years |
| DATA-003 *(Example)* | Invoice | APP-004 | APP-012 | 4.6 million invoices | Confidential | In country of issue (BC-003) | Head of Billing | Good | 10 years |
| [DATA-NNN] | [Domain] | [APP-] | [APP-] | [Volume] | [Classification] | [Constraint] | [Owner] | [Issues] | [Rule] |

Record data definitions in the Data Dictionary (`architecture/data-dictionary`)
and personal data processing in the Record of Processing Activities
(`compliance/gdpr-ropa`) where it applies.

## 6. Infrastructure and hosting

<!-- Guidance: Summarise where the applications run and how current the platforms are. Questions: which data centres, cloud tenancies and platforms are in use, how full are they, and when do hardware, operating systems and databases leave support? Pitfall: missing the shadow hosting run by business units or suppliers. -->

### 6.1 Hosting locations

| ID | Location | Type | Owner or provider | Contract or lease end | Utilisation | Notes |
|---|---|---|---|---|---|---|
| HST-001 *(Example)* | DC-A | Owned data centre | Internal | Lease ends YYYY-MM-DD (BC-004) | Rack space 85 % used | Single power feed in one hall |
| HST-002 *(Example)* | DC-B | Colocation | [Provider] | YYYY-MM-DD | 60 % | |
| HST-003 *(Example)* | Cloud tenancy | Public cloud | [Provider] | Pay as you go | Not applicable | No landing zone; accounts created ad hoc |
| [HST-NNN] | [Location] | [Type] | [Provider] | YYYY-MM-DD | [Utilisation] | [Notes] |

### 6.2 Platforms and lifecycle

| ID | Platform component | Version | Instances | Used by | End of mainstream support | End of extended support | Status |
|---|---|---|---|---|---|---|---|
| INF-001 *(Example)* | Server operating system | [Version] | 64 | APP-001, APP-004 | YYYY-MM-DD | YYYY-MM-DD | Upgrade needed within 18 months |
| INF-002 *(Example)* | Relational database | [Version] | 6 | APP-001 | YYYY-MM-DD | YYYY-MM-DD | Extended support purchased |
| INF-003 *(Example)* | Virtualisation platform | [Version] | 2 clusters | All DC-A workloads | YYYY-MM-DD | YYYY-MM-DD | Licence change increases cost at renewal |
| [INF-NNN] | [Component] | [Version] | [Count] | [APP-] | YYYY-MM-DD | YYYY-MM-DD | [Status] |

Check every support date on the vendor's lifecycle page and record the
page and date checked in the evidence log.

## 7. Security posture

<!-- Guidance: Give a baseline of security outcomes, not a full audit. Questions: which controls are in place, which are missing, and which findings would block or shape the target state? Pitfall: copying a security tool's raw output without judging which items matter for this scope. -->

The table uses the six Functions of NIST CSF 2.0 as a frame. Rate the
current state from 1 (initial) to 4 (well managed), using your
organisation's own scale if it has one, and cite evidence. This rating
describes how well controls work today; it is not the CSF Tier scale
(Tier 1 Partial to Tier 4 Adaptive), which describes the rigour of
cybersecurity risk governance and management. For a full
profile, use the NIST CSF template (`compliance/nist-csf`).

| Function | Current state summary | Rating | Key gaps | Evidence |
|---|---|---|---|---|
| Govern *(Example)* | Security policy exists; no risk owner named for order to cash systems | 2 | Risk ownership, supplier security requirements | Policy library, interview INT-008 |
| Identify *(Example)* | CMDB covers 80 % of in-scope servers; no data classification for DATA-001 | 2 | Asset completeness, data classification | CMDB export, discovery scan |
| Protect *(Example)* | Single sign-on for APP-002 only; shared admin accounts on APP-001 | 2 | Privileged access management, MFA coverage | Access review report |
| Detect *(Example)* | Central log collection for cloud only; data centre logs kept locally | 2 | Log coverage for DC-A and DC-B | SIEM source list |
| Respond *(Example)* | Incident process exists; not tested for order systems | 2 | Exercise and playbooks | Incident procedure |
| Recover *(Example)* | Backups run nightly; restore of APP-001 last tested 3 years ago | 1 | Restore testing, documented recovery objectives | Backup reports |

| ID | Security finding | Severity | Affected | Evidence |
|---|---|---|---|---|
| SEC-001 *(Example)* | Shared administrator accounts on APP-001 database | High | APP-001 | Access review YYYY-MM-DD |
| SEC-002 *(Example)* | Unsupported framework on APP-003 receives no security patches | High | APP-003 | Section 6.2 |
| SEC-003 *(Example)* | File transfer to bank uses a password stored in a script | Medium | IF-005 | Code review |
| [SEC-NNN] | [Finding] | [Critical / High / Medium / Low] | [APP- / IF- / INF-] | [Evidence] |

## 8. Operations and support

<!-- Guidance: Describe how the estate is run and how well. Questions: who supports what, in which hours, under which service levels? How often do things break, and how fast are they fixed and changed? Pitfall: quoting service levels from contracts without checking what is actually achieved. -->

### 8.1 Support model

| Application | Support tiers and teams | Hours | Contracted service level | Achieved (last 12 months) | Supplier |
|---|---|---|---|---|---|
| APP-001 *(Example)* | Service desk, IT North (level 2), vendor (level 3) | Business hours | 99.5 % availability in business hours | 98.9 % | [Vendor] |
| APP-002 *(Example)* | Digital team (all levels) | 24x7 on-call | 99.9 % monthly | 99.93 % | Internal |
| [APP-NNN] | [Tiers] | [Hours] | [Target] | [Achieved] | [Supplier] |

### 8.2 Incidents, changes and delivery

Measure these per application or team where data exists, and say where
it does not. The first two rows are incident measures from service
management, not DORA metrics. The next five rows are the five DORA
software delivery metrics: deployment frequency, change lead time, change
fail rate, failed deployment recovery time and deployment rework rate.

| Measure | APP-001 *(Example)* | APP-002 *(Example)* | [APP-NNN] |
|---|---|---|---|
| Major incidents (last 12 months) | 7 | 1 | [Value] |
| Mean time to restore service for major incidents | 6 hours | 40 minutes | [Value] |
| Deployment frequency | Quarterly release | Several per week | [Value] |
| Change lead time | About 3 months | 1 to 2 days | [Value] |
| Change fail rate | About 30 % of releases need a hotfix | About 5 % | [Value] |
| Failed deployment recovery time | 1 to 2 days | Under 1 hour (roll back) | [Value] |
| Deployment rework rate | Not measured | Not measured | [Value] |
| Monitoring and alerting | Infrastructure only | Application and user journey | [Value] |
| Runbooks and documentation | Partial, outdated | Current | [Value] |

### 8.3 Resilience and recovery

| Application | Recovery time objective (stated) | Recovery point objective (stated) | Last tested | Test result | DR site |
|---|---|---|---|---|---|
| APP-001 *(Example)* | 8 hours | 24 hours | YYYY-MM-DD (3 years ago) | Not achieved: restore took 14 hours | DC-B, cold standby |
| APP-004 *(Example)* | 4 hours | 1 hour | YYYY-MM-DD | Achieved | DC-B, warm standby |
| [APP-NNN] | [RTO] | [RPO] | YYYY-MM-DD | [Result] | [Site] |

## 9. Quality baseline

<!-- Guidance: Measure today's quality so that targets for the new solution start from facts. Questions: how fast, available, usable and maintainable are the key systems, as measured? Pitfall: target-state NFRs written without knowing the current values, so improvements cannot be shown. -->

The rows follow the product quality characteristics of ISO/IEC
25010:2023. Record only measured or well-evidenced values; mark estimates.

| ID | Characteristic | Measure | Current value | Source | Confidence |
|---|---|---|---|---|---|
| QB-001 *(Example)* | Performance efficiency | 95th percentile order save time in APP-001 | 3.8 seconds; 9 seconds at month-end | Application monitoring, last 3 months | High |
| QB-002 *(Example)* | Reliability | Availability of APP-001 in business hours | 98.9 % | Service reports | High |
| QB-003 *(Example)* | Security | Share of in-scope applications behind single sign-on with MFA | 1 of 23 (1 of the 4 applications assessed in detail) | Access review | High |
| QB-004 *(Example)* | Interaction capability | Average training time for a new order desk clerk | About 3 weeks | Interview INT-004 | Low |
| QB-005 *(Example)* | Maintainability | Automated test coverage of APP-003 | None | Code review | High |
| QB-006 *(Example)* | Flexibility | Time to add a new price condition type | About 6 weeks (code change) | Change records | Medium |
| QB-007 *(Example)* | Compatibility | Interfaces using direct database links | 7 of 31 | Section 4 | High |
| [QB-NNN] | [Characteristic] | [Measure] | [Value] | [Source] | [H / M / L] |

Use these values as the starting point for targets in Quality Attributes
(`requirements/quality-attributes`) or the NFR Catalogue
(`requirements/nfr-catalogue`).

## 10. Cost baseline

<!-- Guidance: Establish what the current estate costs per year, so that the business case compares like with like. Questions: what are the run costs by application and category, which are fixed, and which contracts drive them? Pitfall: counting only licences and missing staff, hosting, support and supplier costs. -->

### 10.1 Annual run cost

*Example:* the table covers the four applications assessed in detail;
add the remaining in-scope applications, or a single summary row for
them, before using the total in a business case.

| Cost category | APP-001 *(Example)* | APP-002 *(Example)* | APP-003 *(Example)* | APP-004 *(Example)* | Total *(Example)* |
|---|---|---|---|---|---|
| Software licences and subscriptions | USD 180,000 | USD 20,000 | USD 0 | USD 420,000 | USD 620,000 |
| Hosting and infrastructure | USD 95,000 | USD 60,000 | USD 35,000 | USD 110,000 | USD 300,000 |
| Supplier support and maintenance | USD 70,000 | USD 0 | USD 15,000 | USD 90,000 | USD 175,000 |
| Internal staff (support and change) | USD 210,000 | USD 240,000 | USD 90,000 | USD 160,000 | USD 700,000 |
| **Total** | **USD 555,000** | **USD 320,000** | **USD 140,000** | **USD 780,000** | **USD 1,795,000** |

State the period, currency, allocation rules (for example how shared
data centre costs are split) and the source of each figure. For cloud
spend, report from billing data normalised to FOCUS 1.4 columns, such as
BilledCost, EffectiveCost, ServiceCategory and ChargePeriodStart, so that
costs from different providers can be compared. Use TCO Analysis
(`architecture/tco-analysis`) for multi-year comparisons and FinOps Cost
Review (`ops/finops-cost-review`) for cloud optimisation.

### 10.2 Cost drivers and events

| ID | Driver or event | Effect | Date |
|---|---|---|---|
| CST-001 *(Example)* | Virtualisation licence renewal under new pricing | Expected increase of about 40 % on INF-003 cost | YYYY-MM-DD |
| CST-002 *(Example)* | Extended database support for APP-001 | USD 30,000 per year until upgrade | YYYY-MM-DD |
| [CST-NNN] | [Driver] | [Effect] | YYYY-MM-DD |

## 11. Organisation, skills and sourcing

<!-- Guidance: Record who builds and runs the estate and under which contracts. Questions: where are skills thin or concentrated in one person? Which contracts lock in a supplier or renew soon? Pitfall: ignoring notice periods that decide when a change is possible. -->

### 11.1 Skills and key-person risk

| Area | Team | People with the skill | Key-person risk | Notes |
|---|---|---|---|---|
| APP-001 customisations *(Example)* | IT North | 1 | High | Retiring in 18 months |
| Integration middleware *(Example)* | Central integration team | 3 | Medium | Also supports other programmes |
| Cloud platform *(Example)* | Digital team | 4 | Low | |
| [Area] | [Team] | [Number] | [H / M / L] | [Notes] |

### 11.2 Contracts

| ID | Supplier | Scope | Annual value | End date | Notice period | Exit or lock-in notes |
|---|---|---|---|---|---|---|
| CTR-001 *(Example)* | [Vendor of APP-001] | Licence and support | USD 250,000 | YYYY-MM-DD | 6 months | Data export only in proprietary format |
| CTR-002 *(Example)* | [Colocation provider] | DC-B hosting | USD 120,000 | YYYY-MM-DD | 12 months | Early exit fee applies |
| [CTR-NNN] | [Supplier] | [Scope] | [Value] | YYYY-MM-DD | [Period] | [Notes] |

Review licence terms that affect the target state with Software Licence
Review (`compliance/software-licence-review`).

## 12. Pain points and risks

<!-- Guidance: Collect the problems the business and IT experience, and the risks the baseline carries if nothing changes. Questions: what hurts most, for whom, and how often? Which risks are time-bound? Pitfall: listing symptoms without linking them to the components that cause them. -->

### 12.1 Pain points

| ID | Pain point | Who experiences it | Frequency or scale | Linked components | Source |
|---|---|---|---|---|---|
| PNP-001 *(Example)* | Orders from the portal time out at month-end | Customers, order desk | Every month-end, about 150 failed submissions | APP-002, IF-001, APP-001 | Monitoring, interview INT-002 |
| PNP-002 *(Example)* | Invoice runs fail silently when the nightly file is late | Billing team | About twice a month | IF-002 | Incident records |
| PNP-003 *(Example)* | Price changes take weeks because they need code changes | Pricing team | Every new price condition type | APP-003 | Change records |
| [PNP-NNN] | [Pain point] | [Who] | [Frequency] | [APP- / IF- / DATA-] | [Source] |

### 12.2 Risks of the current state

| ID | Risk | Likelihood | Impact | Time horizon | Linked findings | Owner |
|---|---|---|---|---|---|---|
| RSK-001 *(Example)* | APP-001 cannot be restored within the stated 8 hours after a site failure | Medium | High | Now | FND-003, section 8.3 | @head-of-it-operations |
| RSK-002 *(Example)* | Loss of the single APP-001 developer stops customisation changes | High | Medium | 18 months | Section 11.1 | @it-north-lead |
| RSK-003 *(Example)* | Data centre lease ends before workloads are moved | Medium | High | YYYY-MM-DD | BC-004 | @infrastructure-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Horizon] | [IDs] | [@owner] |

Carry risks that need active management into the RAID Log
(`project/raid-log`) or the Risk Register (`compliance/risk-register`).

## 13. Findings and recommendations

<!-- Guidance: Turn evidence into a small number of clear, rated findings, each with a recommendation the target-state work can act on. Questions: what are the five to fifteen things the sponsor must know? Pitfall: dozens of findings of equal weight, or recommendations that are really designs. -->

### 13.1 Severity scale

| Severity | Meaning |
|---|---|
| Critical | Blocks the target state or exposes the organisation to an unacceptable risk now |
| High | Must be addressed by the target state or in the first transition step |
| Medium | Should be addressed; affects cost, quality or agility |
| Low | Improvement opportunity |

### 13.2 Findings

| ID | Finding | Severity | Confidence | Evidence | Recommendation | Answers | Owner |
|---|---|---|---|---|---|---|---|
| FND-001 *(Example)* | Order capture is spread over three platforms with no shared customer master | High | High | Sections 3, 5 (DATA-001) | Define a single customer master and system of record before platform consolidation | AQ-01 | @enterprise-architect |
| FND-002 *(Example)* | Nearly two thirds of integrations (19 of 31) are file based or direct database links, mostly without monitoring | High | High | Section 4 | Introduce monitored integration for critical flows (IF-002, IF-003) in the first transition step | AQ-02 | @integration-lead |
| FND-003 *(Example)* | APP-001 recovery objectives are not achievable today | Critical | High | Section 8.3, RSK-001 | Fund a tested recovery solution or accept the risk formally before consolidation starts | AQ-05 | @head-of-it-operations |
| FND-004 *(Example)* | APP-003 runs on an unsupported framework with no tests | High | High | Sections 6.2, 9, SEC-002 | Treat pricing as a priority candidate for replacement or replatforming in the options analysis | AQ-04 | @solution-architect |
| FND-005 *(Example)* | Run cost of the four applications assessed in detail, USD 1,795,000 per year, is 39 % staff and 35 % licences | Medium | Medium | Section 10.1 | Use as the baseline for the consolidation business case; validate allocations with finance | AQ-03 | @finance-partner |
| [FND-NNN] | [Finding] | [Critical / High / Medium / Low] | [H / M / L] | [Sections, IDs] | [Recommendation] | [AQ-] | [@owner] |

*Example check:* staff USD 700,000 divided by USD 1,795,000 is 39 %;
licences USD 620,000 divided by USD 1,795,000 is 35 %.

### 13.3 Quick wins

| ID | Quick win | Effort | Benefit | Owner |
|---|---|---|---|---|
| QW-001 *(Example)* | Add failure alerting to IF-002 nightly file | 2 days | Billing failures found the same night | @integration-lead |
| QW-002 *(Example)* | Replace shared admin accounts on APP-001 (SEC-001) | 1 week | Removes a high security finding | @dba-lead |
| [QW-NNN] | [Quick win] | [Effort] | [Benefit] | [@owner] |

## 14. Gap summary for the target state

<!-- Guidance: If a target state or vision exists, summarise the main gaps between it and this baseline; if not, list what the target-state work must decide. Questions: what must be added, changed or removed? Pitfall: designing the target state here instead of handing over a clear baseline. -->

| Area | Baseline (this document) | Target (from vision or principles) | Gap | Type |
|---|---|---|---|---|
| Order capture platforms *(Example)* | Three regional platforms (APP-001, APP-007, APP-008) | One platform for all regions | Consolidation of two platforms | Remove and change |
| Customer data *(Example)* | No system of record | Single customer master | New capability and data migration | Add |
| Integration *(Example)* | File and database links, no monitoring | Monitored APIs and events | Re-implementation of 19 interfaces | Change |
| Recovery *(Example)* | Restore untested, RTO not met | Tested recovery per criticality tier | Recovery design and testing | Add |
| [Area] | [Baseline] | [Target] | [Gap] | [Add / Change / Remove / Keep] |

Hand the gaps over to the target-state work: the Architecture Vision
(`architecture/togaf-architecture-vision`), the Architecture Definition
Document (`architecture/architecture-definition-document`) and the
Architecture Roadmap and Transition Architectures
(`architecture/architecture-roadmap-transition`) in a TOGAF-based
engagement, or the Solution Options Analysis
(`architecture/solution-options-analysis`) in a project engagement.

## 15. Evidence log

<!-- Guidance: List every source used, so that findings can be checked and the baseline refreshed. Questions: where did each fact come from, how old is it, and who confirmed it? Pitfall: findings that cannot be traced back to evidence after the assessment team leaves. -->

| ID | Evidence | Type | Date or period | Owner or provider | Location | Used in |
|---|---|---|---|---|---|---|
| EVD-001 *(Example)* | CMDB export of in-scope applications and servers | System data | YYYY-MM-DD | Service management team | [Link] | Sections 3, 6 |
| EVD-002 *(Example)* | Discovery tool scan with network dependencies, 30 days | System data | YYYY-MM-DD to YYYY-MM-DD | Infrastructure team | [Link] | Section 4 |
| EVD-003 *(Example)* | Monitoring data: response times and availability, 3 months | System data | YYYY-MM-DD to YYYY-MM-DD | Operations | [Link] | Sections 8, 9 |
| EVD-004 *(Example)* | Supplier invoices and contracts | Documents | Financial year YYYY | Finance, procurement | [Link] | Sections 10, 11 |
| EVD-005 *(Example)* | Stakeholder interviews INT-001 to INT-023 | Interviews | YYYY-MM-DD to YYYY-MM-DD | Assessment team | [Link] | Sections 2, 12 |
| EVD-006 *(Example)* | Vendor lifecycle pages for INF-001 to INF-003 | Public documents | Checked YYYY-MM-DD | Vendors | [URLs] | Section 6.2 |
| [EVD-NNN] | [Evidence] | [System data / Document / Interview / Observation / Public] | [Date] | [Owner] | [Location] | [Sections] |

## 16. Glossary and references

<!-- Guidance: Define terms that business and technical readers may not share, and list the frameworks and standards used. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| Baseline | The architecture as it exists at a stated date, used as the starting point for change |
| CMDB | Configuration management database: the register of IT components and their relationships |
| Gap analysis | Comparison of baseline and target to find what must be added, changed or removed |
| RPO | Recovery point objective: the maximum acceptable data loss, measured in time |
| RTO | Recovery time objective: the maximum acceptable time to restore a service |
| System of record | The application that is authoritative for a data domain |

### 16.2 References

| ID | Reference | Version or date | Use |
|---|---|---|---|
| REF-01 | The TOGAF Standard, 10th Edition, The Open Group | 2025 release (C220, 19 May 2025) with Technical Corrigendum 1 (U254) | Names of the Baseline Architecture and Gap Analysis concepts |
| REF-02 | AWS Prescriptive Guidance, Application portfolio assessment guide for AWS Cloud migration, docs.aws.amazon.com | Checked 2026-10-23 | Portfolio discovery and assessment stages |
| REF-03 | ISO/IEC 25010:2023, SQuaRE Product quality model | Edition 2, November 2023 | Quality characteristic names, section 9 |
| REF-04 | NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 | February 2024 | Functions used in section 7 |
| REF-05 | DORA software delivery performance metrics, dora.dev | Page updated 2026-01-05 | Delivery measures, section 8.2 |
| REF-06 | FinOps Open Cost and Usage Specification (FOCUS), FinOps Foundation | Version 1.4, ratified 2026-06-04 | Cost column names, section 10 |
| REF-07 | [Internal architecture standards and policies] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the baseline and gap analysis concepts of the
TOGAF Standard, 10th Edition (The Open Group) and with the portfolio
discovery and assessment stages of the AWS Prescriptive Guidance
application portfolio assessment guide. TOGAF is a registered trademark
of The Open Group. This template uses only the names of TOGAF concepts
(Baseline Architecture, Gap Analysis) and deliverables; all text is
original. Quality rows use the characteristic names of ISO/IEC
25010:2023 (structure only, no text reproduced); security rows are based
on the public NIST Cybersecurity Framework 2.0 Functions; delivery
measures use the metric names published by DORA; cost columns use names
from FOCUS 1.4. Check the current official version of each source before
use. AWS is a trademark of Amazon.com, Inc. or its affiliates; this
template is not affiliated with or endorsed by AWS, The Open Group,
ISO, NIST, DORA or the FinOps Foundation. Template licence: MIT.