Architecture Health-check for a National CRM Transformation

Overview

The client — a nationally recognised consulting and advisory firm — had engaged a third-party vendor to design and deliver a SaaS CRM solution as part of a broader core systems replacement programme. With multiple business units dependent on the outcome and significant capital committed, executive leadership engaged Knowble to provide an independent, unvarnished assessment of the solution architecture before the programme progressed further into delivery.

The objective was straightforward: determine whether the architecture was complete, coherent, and fit for purpose — or whether it carried risks that needed to be addressed before more time and budget were spent.

The Challenge

The CRM transformation was a complex, multi-system programme spanning CRM, integration middleware, data migration, and interoperability with no fewer than sixteen component systems. The vendor-produced architecture documentation had progressed to implementation phase, yet the client's leadership had growing concerns about whether the architecture adequately addressed the organisation's operational and strategic requirements.

Key concerns included:

• Whether the architecture had been designed around the needs of all stakeholder groups — not just immediate functional requirements
• Whether critical design decisions had been formally documented with rationale and trade-offs
• Whether the integration architecture was sufficiently defined given the number and complexity of system interfaces
• Whether the programme was carrying hidden architectural risks that could surface during delivery or operations

Our Approach

This engagement is a direct example of Knowble's Architecture Health-checks service — a thorough, independent inspection of critical IT systems grounded in internationally recognised standards and methods.

Knowble applied a formal four-stage assessment method:

• Define — worked with the programme sponsor to establish the assessment scope, objectives, and key areas of concern
• Review — collated and reviewed all available architecture resources, working with the vendor's architects and project participants to clarify the design intent
• Assess — systematically evaluated the architecture against standardised criteria covering completeness, clarity and consistency, stakeholder alignment, and risk profile
• Report — formulated findings and strategic recommendations in a structured report, collaborating with the sponsor to ensure the language addressed leadership's decision-making needs

The assessment criteria were drawn from ISO/IEC/IEEE 42010 (architecture description) and ISO/IEC/IEEE 42020 (architecture processes), combined with the SEI Architecture Trade-off Analysis Method (ATAM) — internationally proven benchmarks that provide objective, credible evaluation regardless of the technology platform.

Key Findings

The assessment revealed significant gaps across the architecture that, left unaddressed, would have compounded through delivery and into operations:

• Incomplete stakeholder identification — key stakeholder groups and their expectations of the solution had not been formally identified, meaning the architecture could not be verified as meeting their needs
• No requirements traceability — despite referencing requirements sixteen times, the architecture contained no traceable link between requirements and architectural components, making it impossible to verify the design satisfied compliance, security, or interoperability obligations
• Undocumented design decisions — of six recorded architecture decisions, four remained undefined, including critical choices around platform components with significant downstream impact
• 29 instances of ambiguity or contradiction — vague statements, unresolved items, and conflicting specifications throughout the architecture documentation, each representing potential delivery delays
• Integration architecture gaps — only 7 of 16 component systems and 10 of 20 known interactions were defined in the architecture, leaving the majority of integration design to be resolved during delivery
• High system complexity — cyclomatic complexity analysis scored 32 (High), indicating significant delivery and maintainability risk across the integrated solution
• Absent recovery planning — no business-informed Recovery Time or Recovery Point Objectives were defined, despite seven interconnected systems requiring coordinated recovery in an outage scenario

Outcomes

The assessment provided the client's executive leadership with the independent clarity they needed to make informed decisions about the programme's direction:

• Risk visibility — five critical architectural risks were formally identified and characterised, giving leadership concrete evidence to act on rather than relying on vendor assurances
• Informed decision-making — the structured findings enabled the organisation to mandate remediation of the architecture before committing further delivery spend
• Strategic recommendations — actionable recommendations were provided to mature the organisation's architecture practice for all future programmes, including adopting a standardised architecture description framework and mandating Architecture Decision Records
• Protected investment — by surfacing these issues before delivery progressed further, the assessment prevented the compounding cost of building on incomplete foundations