Resources
An architecture pattern is a proven, reusable solution to a recurring design problem. Patterns encode what experienced architects have learned: often expensively: about how to solve particular categories of problem in particular contexts. Using an established pattern does not mean copying a solution blindly; it means starting from a position where the forces, tradeoffs, and failure modes are understood, rather than discovering them fresh.
The value of patterns in enterprise architecture practice is not just the individual pattern knowledge: it is the discipline of maintaining a governed pattern library that teams can draw on consistently. When the same pattern is applied consistently across projects, the architecture becomes more coherent, more maintainable, and more legible to new team members. When each project solves the same problem independently, the result is architectural variation without architectural reason.
These patterns are documented for practicing enterprise and solution architects, with particular attention to Sparx EA implementation guidance. Each article covers the pattern in general: context, problem, solution, when to use and when not: and then provides specific guidance for implementing and governing the pattern in a Sparx EA repository, including MDG considerations and EA GraphLink / AI integration notes.
The patterns selected represent the most frequently encountered integration, migration, and design patterns across Sparx Services engagements. They are the patterns we find ourselves explaining and implementing repeatedly, across industries and organisational sizes.
A central integration broker connects all applications, eliminating point-to-point integration mesh. The foundational pattern for governed enterprise integration.
Read the Hub and Spoke Integration Pattern
Legacy system capability is progressively replaced by new implementation, with traffic migrated incrementally until the legacy system can be decommissioned. The pattern for migration without big-bang risk.
Read the Strangler Fig Migration Pattern
Domain-oriented, decentralized data ownership with a shared data platform infrastructure. The pattern for scaling data architecture in large, federated organizations.
Read the Data Mesh Architecture Pattern
System components communicate by producing and consuming events rather than through direct API calls. The pattern for decoupled, reactive, scalable system design.
Read the Event-Driven Architecture Pattern
A monolithic application is decomposed into independently deployable services, each responsible for a bounded business capability. The pattern for achieving deployment agility in complex applications.
Read the Microservices Decomposition Pattern
Technology investment decisions are grounded in business capability gaps rather than technology preferences or project requests. The pattern for connecting enterprise architecture to strategy.
Read the Capability-Based Planning Pattern
A canonical reference architecture is established, governed, and actively reused across project architectures: reducing design variation and accelerating delivery. The pattern for scaling architectural consistency.
Read the Reference Architecture Reuse Pattern
An organization operates two distinct IT delivery modes: a stable, process-governed mode for core systems and a fast, agile mode for digital and customer-facing capabilities: with governance bridging between them. The pattern for managing architectural tension between stability and speed.
Read the Two-Speed IT (Bimodal) Pattern
Security policy is applied based on verified identity and context rather than network location: no implicit trust is granted to users or systems inside the network perimeter. The pattern for modern security architecture in distributed, cloud, and hybrid environments.
Read the Zero Trust Security Architecture Pattern
APIs are designed as first-class products: with explicit contracts, versioning, and governance: before any implementation begins. The pattern for building integration-ready, composable systems.
Read the API-First Design Pattern
Each pattern article includes specific guidance on how EA GraphLink and AI tools (Kernaro AI Hub, Microsoft Copilot, Claude via MCP) can query and reason over pattern implementations in the Sparx EA repository. When patterns are modelled consistently and tagged with MDG-governed attributes, AI tools can answer questions like “which applications are implementing the hub-and-spoke pattern?”, “show me all microservices without a defined API contract”, or “what capabilities are not covered by any reference architecture?”: making the pattern library an active governance asset rather than a static reference.
Maintaining a pattern library is not a one-time documentation exercise: it is a governance capability. The Amplify service covers the work of building pattern governance into your EA practice: establishing a Pattern Library package in the Sparx EA repository, defining MDG attributes for pattern classification and reuse tracking, and building the review process that ensures project architectures are assessed against the library before design decisions are finalized.
Explore the Amplify Service: team coaching, pattern governance, MDG development, Architecture Review Board setup. $45K–$160K depending on scope.
Contact Sparx Services: describe your current pattern governance situation and we will assess the right engagement approach.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.