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.
Document control
| 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
1. Scope and method
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
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
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
| 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
| 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
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
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
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
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
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
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
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
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
| 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
| 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
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.