A 14-month engagement spanning Discover, Deploy, and Amplify: establishing a governed Sparx EA repository, achieving TOGAF ADM compliance, and developing an internal architecture team capable of running the practice independently.
UK central government agency with approximately 3,000 staff, responsible for delivering a major digital transformation program affecting national public services. The agency was midway through a multi-year ERP replacement and digital services modernisation when this engagement began.
The agency had no EA capability at the start of the engagement. No Sparx EA installation, no architecture repository, no modeling standards, and no architect headcount beyond a small team of business analysts and solution designers who were performing architecture-adjacent work without the tools or governance framework to do it as enterprise architecture.
This engagement is anonymised. All details have been approved for publication in aggregated form.
The program that prompted the EA engagement was already running when the need for EA governance was recognized. Program managers were making integration decisions: which system connects to which, using which data standards, governed by which change process: without visibility of dependency chains. When a change to one system affected another system downstream, the discovery was often happening in testing rather than in design.
The Cabinet Office had issued TOGAF compliance guidance for major government digital transformation programs. This agency was not meeting it. A TOGAF compliance review was on the horizon, with an 18-month deadline. The program could not wait for the compliance review to motivate action: decisions being made in the interim were creating architecture debt that would be expensive to untangle.
The agency’s approach to architecture documentation was informal and inconsistent. Some program workstreams had produced architecture artefacts in Visio or Word. Others had produced nothing. There was no common language, no shared repository, and no governance process that connected architecture decisions to program delivery.
The Chief Digital Officer had a mandate to fix this and a realistic understanding of how difficult it would be. The agency needed to build a functioning EA practice, not just install a tool.
The challenge had four distinct dimensions, each of which had to be addressed in sequence and with care.
Zero starting point for tooling and governance. Installing Sparx EA and Pro Cloud Server is a task; deploying them with a governed repository structure, appropriate MDG Technology, correct access control, and a package hierarchy aligned to TOGAF ADM is a different order of work. Getting this right in week one: rather than retrofitting governance onto a repository that had already accumulated ungoverned content: was essential.
Zero existing EA skills in the team. The architects who would own and run this practice were either new to enterprise architecture or were experienced in specific domains (solution architecture, data architecture) but not in the governance and modeling disciplines that TOGAF-compliant enterprise architecture requires. Deploying a governed repository without building the team capability to maintain it would produce a tool that worked for the duration of the engagement and degraded immediately afterwards.
Program already running. The digital transformation program was not waiting for the EA practice to be ready. Architecture decisions were happening in parallel. The repository had to be useful quickly: it could not spend six months in setup mode before contributing to program governance.
Cabinet Office compliance deadline. TOGAF compliance was not optional. The compliance review would examine whether architecture work was being done using the ADM, whether an Architecture Review Board existed and was functioning, whether architecture artefacts were produced to a defined standard, and whether the EA repository was governed. All of this had to be in place and demonstrable within 18 months of the program’s start.
A focused four-week assessment covering: the existing technology estate and program architecture landscape; the team capability baseline; the TOGAF compliance gap; stakeholder map and Architecture Review Board governance requirements; and a prioritized roadmap for the Deploy and Amplify phases.
The Discover output included a specific Deploy scope: the exact Pro Cloud Server configuration, the MDG Technology design, the TOGAF package structure, and the repository governance framework: so that the Deploy engagement could proceed immediately without a further scoping phase.
The Deploy engagement established the full EA platform and repository in eight weeks.
Week 1–2: Infrastructure and installation. Pro Cloud Server deployed in the agency’s private cloud environment with appropriate security configuration. Sparx EA client licenses provisioned and distributed. Access control framework implemented: role-based access reflecting the difference between architects who model, reviewers who comment, and program stakeholders who read.
Week 3–5: MDG Technology and repository governance. A TOGAF-aligned MDG Technology package was designed and implemented, covering: ArchiMate stereotypes and tagged values for the three architecture layers; TOGAF ADM phase tagging for architecture work packages; a lifecycle status model for architecture artefacts; and governance attributes: review status, ARB approval flag, program alignment: that could be reported on across the repository.
Week 5–7: Package structure and initial population. A TOGAF ADM-aligned package hierarchy was implemented: Preliminary → Architecture Vision → Business Architecture → Information Systems Architecture → Technology Architecture → Opportunities and Solutions → Migration Planning → Implementation Governance → Architecture Change Management. Program-level architecture artefacts from the running transformation were migrated into the appropriate packages, providing immediate value.
Week 7–8: Handover and team onboarding. The architecture team was onboarded to the repository with practical, hands-on sessions covering the MDG, the package structure, and the governance workflow. Sparx Services produced a repository governance guide specific to this deployment: not a generic manual, but an agency-specific document that the team could use from day one.
Amplify ran concurrently with the program delivery work: Sparx Services architects embedded with the client team rather than working alongside them at arms’ length.
Team coaching and modeling practice development. Weekly working sessions with the four junior architects covering ArchiMate modeling in Sparx EA, TOGAF ADM application to live program work, MDG governance, and review-quality artefact production. Coaching was practical: working on real program architecture, not exercises: and was designed from the start to produce independence, not dependency.
MDG governance development. The initial MDG deployment was a sound foundation. Over the 12-month Amplify period, MDG patterns were extended to cover specific program domains: ERP integration interfaces, digital services components, government data standards: as the program architecture developed and new modeling needs emerged. Each extension was documented and validated by the team, not just implemented by Sparx Services.
Architecture Review Board setup and operation. An Architecture Review Board charter was drafted, reviewed by the CDO, and formally established. Terms of reference, membership, quorum, agenda structure, decision logging, and escalation process were all defined. Sparx Services helped the first four ARB sessions, supporting the agency’s Chief Architect to chair and the team to present. By session five, the ARB was operating without Sparx Services facilitation.
TOGAF compliance preparation. The compliance review preparation was treated as a governance quality exercise, not a documentation exercise. Every ADM phase needed to show not just that artefacts existed, but that they were produced using the defined process, that the repository reflected current program decisions, and that the ARB was functioning as a governance body rather than a formality.
Governed Sparx EA repository live within 12 weeks of engagement start: the combined four-week Discover plus eight-week Deploy timeline met the agency’s program governance needs without delay.
TOGAF ADM compliance achieved for all new program architecture work: every architecture workstream from week 12 onwards followed the ADM, with artefacts produced to the defined standard and stored in the governed repository.
Architecture Review Board conducting structured governance within 6 months: from no ARB to a functioning governance body with charter, regular cadence, and decision log. The ARB’s decisions are recorded in the Sparx EA repository.
4 junior architects developed to mid-level proficiency within 12 months: assessed against ArchiMate modeling quality, TOGAF ADM application, MDG governance competence, and independent artefact production. All four are now running architecture workstreams without Sparx Services oversight.
Cabinet Office compliance review passed: the agency met its TOGAF compliance requirements ahead of the 18-month deadline.
> “We went from no architecture capability to a functioning ARB and governed repository in under a year. Sparx Services built something that our team now owns and runs independently.” > >: Chief Digital Officer
Three decisions shaped the outcome.
Getting the governance right before populating the repository. The temptation in a time-pressured program context is to start adding content immediately and sort out governance later. This invariably produces a repository that looks busy but cannot be trusted: and that requires a painful remediation exercise before it can support compliance review. The four-week Discover phase, which delivered a concrete governance design before a single element was added to the repository, prevented this problem.
Treating team development as a program deliverable. The Amplify coaching program was not structured as training: it was structured as capability development through real work. Architects were developing ArchiMate and ADM competence on the actual program architecture, not on exercises. This produced capability that transferred to program delivery rather than capability that existed in a training context.
Establishing the ARB as a real governance body. Architecture Review Boards in government programs sometimes exist on paper: they have a charter and a meeting cadence, but decisions are made elsewhere and the ARB ratifies them retrospectively. From the first session, this ARB was structured to make real decisions about program architecture: it reviewed artefacts, raised questions, required revisions, and logged decisions that had program-level consequences. The difference between a real ARB and a nominal one is visible in the program delivery outcomes.
If your organization is facing a similar situation: an EA capability that needs to be built from scratch, a TOGAF compliance requirement, or a program running without EA governance: the Discover service is the right starting point. The four-week structured assessment produces a deployment plan, a team development plan, and a realistic timeline.
Explore the Deploy Service: governed repository, Pro Cloud Server, MDG Technology, TOGAF-aligned package structure. $30K–$130K depending on scope.
Explore the Amplify Service: team coaching, MDG governance development, ARB setup, ongoing EA practice support. $45K–$160K depending on scope and duration.
Start with Discover: current-state assessment, compliance gap analysis, deployment roadmap. $25K–$75K depending on scope.
Contact Sparx Services: describe your situation and we will respond with a clear assessment of where we can help.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.