
Transformation pattern library
Transformation patterns
Core transformation patterns for navigating technological waves
- Transformation Pattern 1 (TF-1)
Learn and Explore Probe new frontiers with low-risk research to uncover true potential. Acquire knowledge and assess relevance of emerging technologies with minimal initial outlay to enable informed decisions.
Context: You are considering or encountering emerging technologies that offer unknown value or potential.
Problem: Committing significant resources to unproven technologies prematurely is highly risky and can lead to wasted investment.
- Transformation Pattern 2 (TF-2)
Skunk Works Team Unleash a nimble, independent team to innovate beyond bureaucracy. Insulate a small, autonomous team from bureaucracy to enable rapid experimentation and accelerate learning on novel ideas.
Context: Standard organizational processes and bureaucracy are hindering the rapid exploration and innovation of novel ideas, causing progress to stagnate.
Problem: Promising but unconventional ideas struggle to gain traction or demonstrate value quickly within rigid, slow-moving structures.
- Transformation Pattern 3 (TF-3)
Reduce Cost of Experimentation Make trying new ideas cheap, safe, and accessible. Lower barriers to vital experimentation by implementing accessible sandboxes, cloud resources, and fostering psychological safety, thereby encouraging more trials and learning. SAFE SANDBOX High Risk
Context: You want to encourage vital experimentation with new technologies.
Problem: High costs or perceived risks are deterring teams from trying new things safely and cheaply.
- Transformation Pattern 4 (TF-4)
Critical Systems Provide safe, isolated spaces for exploration and prototyping, allowing teams to experiment freely without impacting critical systems or ongoing work. Create safe playgrounds for innovation without real-world risks. Sandbox Environment
Context: Teams need to explore new technologies or prototype ideas.
Problem: Experimenting directly in production or shared development environments is risky and disruptive to critical systems or ongoing work.
- Transformation Pattern 5 (TF-5)
Prioritize early Proofs-of-Concept on the most critical and uncertain technical aspects of a transformation to quickly validate feasibility or identify roadblocks. Test Hard Things First Tackle the biggest unknowns early to prove viability quickly.
Context: You are initiating a transformation project with significant technical uncertainties.
Problem: Transformation projects can fail or waste significant effort if core technical uncertainties aren't addressed early.
- Transformation Pattern 6 (TF-6)
Execute focused Proofs-of-Concept to gain tangible evidence, quickly validating or refuting a new technology's or approach's practical application for a specific problem. Proof of Concept - PoC Build a small test to quickly prove if a new idea works.
Context: The viability of a new technology or approach for solving a specific problem is uncertain.
Problem: Committing to full-scale adoption of an unproven concept is risky and may lead to misaligned solutions.
- Transformation Pattern 7 (TF-7)
Regularly and engagingly communicate progress and learnings from innovative ideas or early prototypes through demonstrations to build understanding, support, and valuable input. Demo Your Ideas Show, don't just tell, to build support and gather feedback.
Context: Your team is working on innovative ideas or early prototypes.
Problem: Innovative ideas or early progress can lack visibility within the organization, hindering buy-in, feedback, and overall support.
- Transformation Pattern 8 (TF-8)
Maintain a backlog of deferred but promising ideas to retain them as future options for when timing, resources, or priorities become favorable. Ideas Shelf Park good ideas now for future opportunities. Good Idea
Context: Good ideas emerge that are not immediately feasible or do not align with current priorities.
Problem: Valuable ideas might be lost or forgotten if not systematically captured when they cannot be acted upon immediately.
- Transformation Pattern 9 (TF-9)
Develop a robust business case that articulates the rationale, benefits, costs, and risks of a major transformation initiative to ensure strategic alignment and informed commitment. Business Case Justify the leap: prove the 'why' before the 'how'. Business Case C O S T B E N E F I T L E A D E R S H I P
Context: You are considering embarking on a major transformation initiative.
Problem: Proceeding with major transformation initiatives without clear justification can lead to wasted resources, misaligned efforts, and lack of stakeholder buy-in.
- Transformation Pattern 10 (TF-10)
Adopt differentiated funding models (e.g., for core operations, transformation projects, speculative innovation) to appropriately suit diverse initiative needs and risk profiles. Finance Topologies Fund the journey right: match budgets to different innovation needs. Inovation Labs Transformations Operations
Context: Your organization funds various types of initiatives, from stable operations to speculative innovation and major transformations.
Problem: Applying a single, uniform funding model across all types of initiatives can stifle innovation, misallocate resources, or create inappropriate financial pressures.
- Transformation Pattern 11 (TF-11)
Secure active, visible executive backing to ensure the transformation initiative has priority, adequate resources, and crucial support to navigate organizational obstacles. Executive Commitment Anchor transformation with strong, visible leadership support. T r a n s f o r m a t i o n P r i o r i t y Transformation Journey
Context: A major transformation is being initiated or is underway, requiring significant resource allocation and facing potential internal resistance.
Problem: Without strong, visible leadership support, major transformations often fail due to lack of clear priority, insufficient resources, and an inability to overcome organizational obstacles.
- Transformation Pattern 12 (TF-12)
Designate a single, empowered leader (Transformation Champion) to steer the transformation's execution, providing clear ownership and decisive guidance. Appoint Transformation Champion Designate a dedicated leader to steer the change. C H A M P ION NEW WAY OLD WAY
Context: A major transformation effort is underway.
Problem: Diffused responsibility for a major transformation can lead to a lack of direction, accountability, and decisive action.
- Transformation Pattern 13 (TF-13)
Establish a dedicated, cross-functional team to build the initial Minimum Viable Platform (MVP) and establish core new practices for the transformation. Form the Core Team Build the foundation with a dedicated, cross-functional crew. MVP
Context: You are kickstarting a transformation that requires focused effort and diverse skills.
Problem: Existing siloed structures often lack the combined expertise or dedicated focus needed to build an initial platform and establish new core practices effectively.
- Transformation Pattern 14 (TF-14)
Clearly define and widely communicate the strategic vision—the 'why' and 'what' of the transformation—to guide choices and unify efforts across the organization. Vision First Define and share the 'why' and 'what' to unify efforts.
Context: Your organization is embarking on or undergoing a transformation.
Problem: Without a clear and communicated understanding of the transformation's purpose and desired outcome, teams may make misaligned or suboptimal decisions, and efforts can become fragmented.
- Transformation Pattern 15 (TF-15)
Foster an environment where teams feel safe to experiment, admit mistakes, ask questions, and learn openly without fear of blame, which is crucial for progress in uncertain work. Cultivate Psychological Safety Create a safe space to try, fail, learn, and speak up.
Context: Your organization is engaged in transformative efforts involving new, uncertain work and experimentation.
Problem: Fear of failure or negative repercussions in an environment lacking psychological safety can stifle experimentation, honesty, and the learning vital for navigating transformation.
- Transformation Pattern 16 (TF-16)
Utilize the process of building the Minimum Viable Product (MVP) and necessary integrations as a method to uncover practical challenges and validate assumptions through tangible experience. Research Through Action Learn by doing: build and bridge to uncover real challenges.
Context: You are in the early stages of a transformation, planning and designing new systems or integrations.
Problem: Purely theoretical planning often misses real-world complexities and incorrect assumptions, which can lead to flawed designs or unexpected roadblocks later.
- Transformation Pattern 17 (TF-17)
Emphasize designs that favor adaptability during the initial bootstrapping phase of a transformation, allowing for easier changes and deferring heavy optimization until requirements and understanding stabilize. Adaptability over Efficiency Prioritize flexibility now; optimize for performance later.
Context: You are in the initial bootstrapping phase of a transformation where requirements and understanding are rapidly evolving.
Problem: Prematurely optimizing for efficiency with evolving requirements can lead to rigid solutions that are costly to change and quickly become misaligned.
- Transformation Pattern 18 (TF-18)
Build and deliver the smallest possible product version (Minimum Viable Product) that provides real value, in order to enable crucial early feedback and iterative refinement. Deliver the MVP Build the smallest useful version first for crucial early feedback. MVP BAY
Context: You are trying to build a new platform or product as part of a transformation.
Problem: Attempting to build a perfect, all-encompassing new platform from the start often leads to lengthy delays and a final product that is misaligned with actual user needs.
- Transformation Pattern 19 (TF-19)
Apply strict prioritization to the Minimum Viable Platform (MVP) scope, deferring non-essential features to ensure faster delivery of core functionality and value. Thinnest Viable Platform Keep the initial platform lean: core functions only.
Context: You are developing the initial version of a platform during a transformation.
Problem: Scope creep during initial platform development can significantly delay value delivery and overcomplicate the first offering with non-essential features.
- Transformation Pattern 20 (TF-20)
Introduce automation iteratively, starting with tasks and processes that have become stable and proven, and delaying automation for those still in flux and under refinement. Delayed Automation Automate proven processes, not evolving ones.
Context: You are in a transformation phase where many processes are new and rapidly evolving.
Problem: Attempting to automate rapidly evolving or unproven processes too early can lead to wasted effort, brittle solutions, and the need for frequent rework of the automation itself.
- Transformation Pattern 21 (TF-21)
Allow the specialized core team responsible for bootstrapping new capabilities the flexibility to select tools best suited for their novel tasks, even if these tools are not yet existing enterprise standards, in order to accelerate initial progress and innovation. Best Tool for the Task Empower the core team with tool flexibility for novel tasks. STANDARD TOOLKIT Core Team
Context: A specialized core team is bootstrapping new capabilities and tackling novel tasks vital for the transformation's early stages.
Problem: Rigid adherence to existing enterprise tool standards, which may not be suited for novel tasks, can slow down the core team and hinder their ability to innovate or make rapid initial progress.
- Transformation Pattern 22 (TF-22)
Design and implement explicit integration layers or "bridges" to allow necessary communication and data flow between the new platform and established legacy systems during a transformation. Bridge the Old World Connect new platforms to legacy systems for seamless coexistence. OLD WORLD NEW WORLD
Context: A new platform is being developed alongside existing legacy systems that still hold critical data or functionality.
Problem: New platforms often need to coexist and interact with established legacy systems, creating significant integration challenges that can stall the transformation if not addressed.
- Transformation Pattern 23 (TF-23)
Adopt a funding model where resources for transformation initiatives are released in tranches, tied to the achievement of specific, validated milestones, to allow for course correction and mitigate financial risk. Staged Funding Fund transformation in phases, tied to proven milestones. PoC Complete MVP Live
Context: You are funding long, uncertain, and high-risk transformation initiatives.
Problem: Committing large, upfront budgets to long, uncertain transformation initiatives carries high financial risk if initial assumptions prove wrong or if the project veers off course.
- Transformation Pattern 24 (TF-24)
Manage the internal development platform (IDP) with a product mindset, actively seeking developer feedback and iterating on its features to continuously improve its value and usability for its internal customers. Platform as a Product Treat your internal platform like a product, with developers as customers. Suggestions Platform Team
Context: Your organization has an internal platform (IDP) intended to support development teams.
Problem: Treating an internal platform merely as a cost center or an IT project, rather than a product, can lead to poor developer experience, low adoption rates, and a failure to deliver its intended value.
- Transformation Pattern 25 (TF-25)
Formalize a dedicated team to ensure the internal development platform's (IDP) roadmap, operations, maintenance, and evolution are proactively managed and supported. Establish Platform Team Dedicate a team to own, evolve, and support your internal platform. Platform Team IDP
Context: An MVP internal platform (IDP) has proven valuable and needs ongoing development and support.
Problem: Without dedicated ownership, an internal platform can stagnate, become poorly maintained, and fail to evolve with user needs, leading to its eventual neglect or irrelevance.
- Transformation Pattern 26 (TF-26)
Develop comprehensive resources, such as application templates, SDKs, tutorials, and clear documentation (a "Dev Starter Pack"), to accelerate the onboarding and productivity of teams adopting the new platform. Dev Starter Pack Accelerate new team productivity with comprehensive onboarding resources. STARTER PACK PLATFORM WELCOME STATION
Context: New users or teams are adopting a platform and face a learning curve.
Problem: The learning curve for a new platform can slow down team productivity and hinder the overall speed of transformation adoption if onboarding resources are lacking.
- Transformation Pattern 27 (TF-27)
Define and document proven architectural patterns (Reference Architectures) for common scenarios to promote consistency, share best practices, and accelerate development for teams using the new platform. Reference Architecture Guide consistency with documented, proven architectural patterns. REFERENCE ARCHITECTURE
Context: Multiple teams are developing applications or services on a new platform.
Problem: Inconsistent architectural approaches across teams can lead to increased complexity, integration issues, reduced maintainability, and a failure to leverage collective learning.
- Transformation Pattern 28 (TF-28)
Create and maintain a catalog of available internal platform services and shared components, with clear documentation and usage instructions, to improve discoverability and promote reuse among development teams. Internal Service Catalog Make shared platform services discoverable and easy to reuse. Internal Services Authentication API Reports Management Settings Logging Data Storage
Context: Your platform offers a growing number of shared services and capabilities.
Problem: Developers may struggle to discover and effectively utilize available platform capabilities and shared services if they are not easily findable or well-documented, leading to duplicated effort.
- Transformation Pattern 29 (TF-29)
Implement tight feedback loops with initial adopter teams to ensure the platform evolves to meet validated, real-world requirements, rather than building features based on assumptions. Build the Right Thing Evolve the platform based on validated, real-world user needs. PROTOTYPE PLATFORM EARLY ADOPTER TEAM
Context: You are developing or evolving platform features for internal development teams.
Problem: Developing platform features without actively validating actual user (developer) needs can lead to wasted effort and a platform that doesn't effectively solve their problems or improve their workflow.
- Transformation Pattern 30 (TF-30)
Proactively enhance the platform's architecture, performance, reliability, and operational tooling to prepare it for successful broader adoption and increased load from more teams. Prepare for Scale Proactively enhance the platform for wider, reliable adoption. PREPARE FOR SCALE
Context: A platform has been successful with early adopters and is poised for wider organizational rollout.
Problem: A platform that worked well for a few early adopters may falter under the increased load, diverse needs, and operational demands of wider organizational use if not proactively prepared for scale.
- Transformation Pattern 31 (TF-31)
Consciously design team structures and communication pathways to mirror and actively promote the desired target architecture, thereby facilitating the change and adoption of new architectural paradigms. Reverse Conway Maneuver Shape your teams to shape your desired architecture. TEAM REDESIGN
Context: Your organization is adopting a new target architecture (e.g., microservices) that differs significantly from the one reflected in current team structures.
Problem: Existing team structures, which often mirror an old architecture (Conway's Law), can inadvertently hinder or actively resist the adoption and effective implementation of a new desired architecture.
- Transformation Pattern 32 (TF-32)
Roll out the new platform or ways of working to the remaining teams in manageable, planned cohorts, rather than all at once, to ensure better support and smoother transitions. Gradual Onboarding Roll out to teams in waves for smoother, supported transitions. NEW PLATFORM PLATFORM GUIDES TEAMS
Context: A new platform or system is ready for wider adoption across multiple teams in the organization.
Problem: Attempting to migrate all teams to a new platform simultaneously can overwhelm support capacity, create widespread disruption, and lead to a poor adoption experience.
- Transformation Pattern 33 (TF-33)
Systematically decommission legacy components by incrementally redirecting their traffic or functionality to new, equivalent services or modules built on the modern platform. Strangle Legacy Systematically replace old parts with new, until legacy fades. LEGACY SYSTEM NEW SYSTEM DATA
Context: New systems are being built to replace functionality currently provided by existing legacy systems during a transformation.
Problem: Allowing legacy systems to persist indefinitely alongside new ones creates operational overhead, duplicates costs, and hinders the full realization of transformation benefits.
- Transformation Pattern 34 (TF-34)
Maintain essential maintenance, security, and stability for critical legacy systems that still support the business during a lengthy transformation, until they are fully retired or replaced. Protect the Core Keep vital legacy systems stable until fully retired.
Context: During a lengthy transformation, critical legacy systems that still support core business functions remain operational.
Problem: Neglecting critical legacy systems during a transformation can lead to instability, security vulnerabilities, or failures that disrupt ongoing business operations.
- Transformation Pattern 35 (TF-35)
Explicitly address and adapt team structures, operational processes, and organizational culture in concert with technological changes to ensure a more complete and successful systemic shift. Holistic Transformation Transform tech, teams, processes, and culture together. SUCCESSFUL TRANSFORMATION TECH TEAM PROCESS CULTURE
Context: Your organization is undergoing a major transformation.
Problem: Focusing solely on technological changes during a transformation often leads to cultural resistance, process misalignments, and a failure to achieve the desired holistic benefits.
- Transformation Pattern 36 (TF-36)
Track key metrics relevant to platform adoption, team performance (e.g., DORA metrics), and financial outcomes (e.g., FinOps) to provide objective insights into the progress, impact, and success of the transformation initiative. Measure What Matters Track key metrics for objective insights into transformation progress. ADOPTION DORA FinOps Costs
Context: You are managing a transformation initiative and need to assess its effectiveness.
Problem: Without clear and relevant metrics, it's difficult to objectively assess the progress, impact, and success of a transformation, making it hard to make informed decisions or demonstrate value.
- Transformation Pattern 37 (TF-37)
Foster a culture where choices regarding platform evolution, process changes, and priorities are informed by collected data and objective analysis rather than gut feelings or outdated assumptions. Data-Driven Decision Making Let data and objective analysis guide your transformation choices.
Context: Decisions need to be made regarding platform evolution, process changes, or priorities during a transformation.
Problem: Decisions based on gut feelings, historical biases, or outdated assumptions, rather than objective data, can derail transformation efforts or lead to suboptimal outcomes.
- Transformation Pattern 38 (TF-38)
Define clear, standardized modes of interaction and collaboration between teams (e.g., referencing concepts from Team Topologies) to improve flow and reduce friction as new ways of working are adopted. Establish Team Communication APIs Define clear interaction modes for smoother team collaboration. INFORMATION TEAM A TEAM B RESPONSE REQUEST CONNECT
Context: More teams are adopting new ways of working, and their interactions are becoming more complex.
Problem: Unclear or ad-hoc interaction patterns between teams can lead to communication friction, misunderstandings, delays, and inefficiencies, especially as the scale of transformation increases.
- Transformation Pattern 39 (TF-39)
Relentlessly pursue the automation of repetitive tasks such as testing, deployment, infrastructure provisioning, and operations to free up teams for higher-value work and reduce errors. Automation Everywhere Relentlessly automate repetitive tasks across the software lifecycle. TESTING DEPLOYMENT INFRASTRUCTURE
Context: Your teams are engaged in various tasks across the software development and delivery lifecycle.
Problem: Repetitive manual tasks across the software lifecycle consume valuable time, are prone to human error, and slow down the overall transformation and delivery process.
- Transformation Pattern 40 (TF-40)
For stable legacy applications that are too costly or complex to rewrite with little immediate benefit, consider migrating them with minimal changes (lift and shift) late in the transformation process, once the new platform is mature. Lift and Shift at the End Move stable, low-value legacy apps late, with minimal changes. OLD STABLE LEGACY APP MODERN APP MODERN APP MODERN APP OLD DATA CENTER NEW CLOUD PLATFORM
Context: You have stable legacy applications that are part of a broader transformation and platform migration.
Problem: Attempting to rewrite every legacy application, regardless of its stability or the benefit of a rewrite, can be excessively costly, time-consuming, and delay the overall transformation.
- Transformation Pattern 41 (TF-41)
Define clear criteria for completing the main disruptive phase of the transformation, allowing the organization to formally pivot its focus towards continuous improvement on the newly established foundation. Finish the Transformation Declare the main shift "done" to pivot to ongoing improvement. TRA NSFO RMA TION FINIS H LIN E CONTINUOUS IMPROVEMENT PATH
Context: Your organization has been engaged in a major, disruptive transformation effort for a significant period.
Problem: Open-ended transformation efforts without clear completion criteria can lead to organizational fatigue, unclear objectives for the "new normal," and a failure to transition to sustained continuous improvement.
- Transformation Pattern 42 (TF-42)
Embed a culture and regular practices (e.g., Kaizen) for continuously reviewing, measuring, and incrementally enhancing established operations, platforms, and processes to ensure ongoing improvement and efficiency. Continuous Optimisation Embed regular review and refinement into your daily operations. IMPROVEMENT
Context: A new platform or set of processes has been established and is operational.
Problem: Without active and continuous management, even well-established platforms and processes can degrade, become inefficient, or misalign with evolving needs over time.
- Transformation Pattern 43 (TF-43)
For mature systems and platforms running at scale, strategically shift the priority from initial adaptability towards optimizing performance and cost-effectiveness. Efficiency over Adaptability For mature systems, shift focus to performance and cost optimization.
Context: Your systems and platforms have matured, are stable, and are running at scale.
Problem: Continuing to prioritize adaptability indefinitely for mature systems can lead to neglecting crucial performance and cost optimizations, resulting in inefficiencies at scale.
- Transformation Pattern 44 (TF-44)
Focus efforts on fully leveraging the new platform's capabilities to drive concrete business initiatives and ensure that the anticipated benefits and return on investment (ROI) from the transformation are realized. Maximize ROI Actively leverage the new platform to drive tangible business value. REVENUE CUSTOMER SATISFACTION
Context: A new platform and capabilities have been established through transformation.
Problem: The ultimate goal of transformation is business value, which can be lost or underutilized if there isn't an active focus on applying new capabilities to achieve business outcomes post-rollout.
- Transformation Pattern 45 (TF-45)
Enhance the Internal Developer Platform (IDP) to abstract underlying complexities and provide clear, opinionated "Paved Paths" for common tasks, thereby simplifying the developer experience and reducing their cognitive load. Minimize Cognitive Load Simplify developer experience with clear paths and abstractions. BUMPY DIRT ROAD PAVED PATH DEPLOY
Context: Developers are using an Internal Developer Platform (IDP) that may have grown in complexity.
Problem: As platforms grow and offer more capabilities, their inherent complexity can overwhelm developers, reducing their productivity and distracting them from focusing on business logic.
- Transformation Pattern 46 (TF-46)
Encourage and facilitate the reuse of existing platform capabilities, shared services, and reference architectures to promote efficiency, standardization, and prevent duplicated effort. Avoid Reinventing the Wheel Encourage reuse of existing capabilities and shared services. SHARED SERVICES Pre-built Wheel
Context: Teams across the organization are building various applications and features.
Problem: Teams independently building similar solutions or components, without awareness or use of existing shared capabilities, wastes effort and leads to inconsistencies.
- Transformation Pattern 47 (TF-47)
Build robust self-service capabilities into the Internal Developer Platform (IDP) for common tasks like resource provisioning, configuration changes, and deployments to empower developers and reduce bottlenecks. Enable Self-Service Empower developers with self-service access to platform resources. SELF-SERVICE PORTAL Deploy App SUCCESS
Context: Application teams need to provision resources, change configurations, or deploy services.
Problem: Over-reliance on a central platform team for common operational tasks creates bottlenecks, slows down application teams, and hinders agility.
- Transformation Pattern 48 (TF-48)
Implement comprehensive observability by designing systems to emit detailed telemetry (logs, metrics, distributed traces), providing the necessary visibility for effective operations and troubleshooting in complex, distributed environments. Cultivate Observability Gain deep insight into system behavior with comprehensive telemetry. LOGS METRICS TRACES
Context: You are operating complex, distributed systems.
Problem: Understanding the behavior and diagnosing issues within complex, distributed systems is difficult and time-consuming without deep, correlated insight into their internal state.
- Transformation Pattern 49 (TF-49)
Leverage the agility of the established platform to enable the rapid and frequent deployment of small, valuable changes, fostering continuous innovation and responsiveness to market needs. Nurture Incremental Innovation Leverage platform agility for rapid, frequent, small valuable changes. AGILE Feature Feature
Context: Your organization operates in a dynamic market and aims for continuous value delivery.
Problem: Large, infrequent releases carry high risk, delay value delivery, and hinder the ability to respond quickly to evolving customer needs or market changes.
- Transformation Pattern 50 (TF-50)
Utilize appropriate team structures (e.g., inspired by Team Topologies) and allow for increased specialization in key complex domains to enhance efficiency, capability, and depth of expertise as the new paradigm matures. Specialised Teams Utilize specialized teams for deep expertise in complex areas. Data Science Platform Core Team Security Team
Context: Your new operational paradigm has matured, and certain areas have become complex and require deep expertise.
Problem: Generalist teams may lack the deep expertise needed to effectively manage, optimize, or innovate within specific, highly complex areas of the mature platform or system.
- Transformation Pattern 51 (TF-51)
Encourage application teams to innovate primarily on top of the stable and abstracted Internal Developer Platform (IDP), maximizing their delivery of unique business value by relying on the IDP for underlying infrastructure, security, and deployment concerns. Minimize Surface of Innovation Innovate on business value, not on reinventing core platform capabilities. IDP Feature
Context: Application teams are tasked with delivering new features and business value using an established Internal Developer Platform (IDP).
Problem: If application teams spend too much time on underlying infrastructure concerns or rebuilding common functionalities already provided by the IDP, their focus on unique business innovation is diluted.
- Transformation Pattern 52 (TF-52)
Institute regular, structured opportunities for teams to pause from continuous high-paced work, reflect on their recent successes and failures, and plan improvements to foster sustainability and strategic learning. Reflective Breaks Pause regularly to learn, adapt, and sustain momentum. LESSONS LEARNED
Context: Teams are engaged in continuous, high-paced work.
Problem: Continuous high-paced work without dedicated pauses for reflection can lead to burnout, missed opportunities for strategic learning, and a gradual decline in process effectiveness.
- Transformation Pattern 53 (TF-53)
Implement mechanisms and cultivate a culture that encourages systemic knowledge sharing, experimentation, and collective adaptation to build organizational resilience and agility in a constantly evolving technological landscape. Foster Learning Organisation Build systemic ways to share knowledge and adapt collectively.
Context: Your organization operates in a constantly evolving technological and market landscape.
Problem: Without intentional mechanisms for learning and adaptation, an organization's ability to respond to change, innovate, and maintain long-term success is diminished.
- Transformation Pattern 54 (TF-54)
Adopt a dynamic approach to strategy with short-term objectives, regular environmental sensing (market shifts, internal progress), and adaptive planning to allow for timely adjustments in rapidly changing environments. Dynamic Strategy Adapt your strategy with short goals and regular sensing.
Context: Your organization operates in a rapidly changing environment where long-term predictions are unreliable.
Problem: Rigid, long-term strategic plans can quickly become outdated and irrelevant in dynamic environments, hindering the organization's ability to adapt effectively.
- Transformation Pattern 55 (TF-55)
Implement structured "health checkups" at regular intervals for key systems, architectures, and team processes to proactively identify and address potential issues or misalignments. Periodic Checkups Regularly review key systems and processes for proactive health. System Doctor HEALTHY
Context: Your organization relies on established systems, architectures, and processes.
Problem: Over time, even well-designed systems and processes can degrade, become misaligned with current needs, or develop hidden issues if not actively and periodically reviewed.
- Transformation Pattern 56 (TF-56)
Freeze non-essential development on legacy systems slated for retirement, focusing only on critical fixes, to preserve resources for new initiatives and avoid investing in obsolete technology. Minimal Legacy Change Freeze non-essential work on systems you plan to retire. MINIMAL CHANGES ONLY NO NEW FEATURES
Context: Legacy systems are scheduled for retirement as part of a transformation.
Problem: Continuing to invest significant development effort in legacy systems that are soon to be decommissioned diverts valuable resources from the transformation and new initiatives.
- Transformation Pattern 57 (TF-57)
Proactively plan for and redeploy personnel, infrastructure, and budget from wound-down or retired legacy systems to maximize their utility for new priorities and transformation efforts. Free Up Resources Reclaim and redeploy assets from retired systems. Budget Personnel Server Capacity New Initiative Retired Legacy Systems
Context: Legacy systems are being decommissioned as part of a transformation.
Problem: If resources (personnel, infrastructure, budget) tied to decommissioned systems are not proactively and efficiently reallocated, their value is lost, and they may continue to incur costs or be underutilized.
- Transformation Pattern 58 (TF-58)
Execute a planned process to shut down obsolete systems, which includes data archiving or migration, stakeholder communication, and careful management of dependencies to ensure a smooth transition. Sunset Gracefully Plan a smooth shutdown for obsolete systems, managing data and users. NEW SYSTEM Last User Archive Data
Context: Obsolete systems or components need to be decommissioned.
Problem: Simply turning off obsolete systems without a proper plan can lead to data loss, broken dependencies for other systems, and user dissatisfaction or disruption.
- Transformation Pattern 59 (TF-59)
As systems are retired and roles become redundant, manage the associated human resources strategically and sensitively, through reallocation to new roles where possible, or by managing team reductions with clear communication and support. Team Reduction/Reallocation Sensitively manage team changes as systems and roles evolve. Retired Legacy System
Context: Systems are being retired, leading to changes in workload and potentially making some team roles redundant.
Problem: Failing to strategically and sensitively manage the human resource aspect of system retirement can lead to decreased morale, loss of valuable talent, or inefficient team structures.
Waterfall patterns
Legacy waterfall patterns and approaches
- Waterfall Pattern 1 (WF-1)
Invest heavily in initial requirements gathering and design phases to create detailed implementation specifications, aiming for predictable execution based on a comprehensive blueprint. Comprehensive Upfront Design Map every detail first for predictable, stable project execution.
Context: Projects require clear, stable initial direction, and requirements are not expected to change significantly.
Problem: Ambiguity or incomplete understanding of requirements during implementation can derail projects, leading to costly rework and delays.
- Waterfall Pattern 2 (WF-2)
Divide projects into discrete, ordered phases (e.g., analysis, design, coding, testing), with formal sign-offs controlling movement from one stage to the next. Sequential Phase Execution Progress step-by-step: complete one phase before starting the next. ANALYSIS DESIGN CODING TESTING
Context: Projects require structured progression and distinct stages to manage overall complexity.
Problem: Uncontrolled progression or overlapping phases in complex projects can lead to chaos, rework, and a lack of clear accountability at each stage.
- Waterfall Pattern 6 (WF-6)
Integrate separately developed components only near the project's completion, followed by formal system-wide testing of the combined whole. Late-Stage Integration & Testing Combine and test all parts only near project completion.
Context: Project components are developed in parallel isolation by different teams.
Problem: Integration issues between components can be numerous, complex, and discovered very late in the project, risking extensive rework and significant delays.
- Waterfall Pattern 7 (WF-7)
Release the entire integrated system in one large, coordinated deployment event, providing a complete initial offering to all users simultaneously. Big Bang Release Deploy the entire new system all at once in a single event. ON
Context: A new system or a major version is ready for launch, and partial functionality is not desired.
Problem: Deploying many interdependent changes incrementally can be complex or undesirable, but releasing everything at once carries high risk if issues arise post-launch.
- Waterfall Pattern 8 (WF-8)
Increase application capacity by enhancing the resources (e.g., CPU, RAM, disk space) of the existing hardware/server it runs on. Vertical Scaling Boost capacity by adding more power to existing servers.
Context: An application's load is outgrowing its current server resources, leading to performance degradation.
Problem: Applications need more capacity, but horizontal scaling is not being used, and single machines have physical limits to how much they can be upgraded.
- Waterfall Pattern 9 (WF-9)
Structure monolithic application code into distinct horizontal layers (e.g., User Interface, Business Logic, Data Access) to improve separation of concerns and maintainability within a single deployment unit. Layered Architecture Organize monolithic code into distinct horizontal layers (UI, Logic, Data). UI BUSINESS LOGIC DATA ACCESS
Context: You are designing or maintaining a large monolithic application where code organization and separation of concerns are challenging.
Problem: Without clear structural organization, code within a large monolith can become tightly coupled and difficult to understand, modify, or maintain.
- Waterfall Pattern 11 (WF-11)
Multiple application modules directly access a single, shared database schema, enabling easy data exchange and consistency between them. Shared Database Integration Enable easy data sharing via a single, common database. ORDERS INVENTORY CUSTOMERS
Context: You need to simplify data sharing and ensure consistency between multiple modules of an application.
Problem: Direct component-to-component integration for data sharing can be complex to build and maintain, while a shared database creates tight coupling and makes schema changes fragile.
Cloud Native patterns
Cloud native architectural patterns and practices
- Cloud Native Pattern 1 (CN-1)
Structure work into small, frequent software deliveries of valuable increments, often using methods like Scrum or Kanban, to enable continuous learning and risk reduction through early user feedback and adaptation. Iterative Value Delivery Deliver working software in small, frequent bursts to learn and adapt quickly.
Context: You need to quickly deliver value to users and adapt to market changes or evolving requirements.
Problem: Traditional long release cycles delay user feedback, hinder adaptation to changes, and increase the risk of delivering a misaligned product.
- Cloud Native Pattern 2 (CN-2)
Implement automated Continuous Integration/Continuous Delivery (CI/CD) pipelines for building, testing, and preparing code for release. This provides rapid feedback, improves quality, and enables frequent, reliable software delivery. Automated Validation Pipeline (CI/CD) Automate your build, test, and release prep for rapid, reliable delivery. BUILD TEST PACKAGE
Context: You need to ensure frequent code changes integrate correctly and are ready for release without manual delays or errors.
Problem: Manual build, testing, and release preparation processes are slow, error-prone, and cannot support frequent, reliable software delivery.
- Cloud Native Pattern 3 (CN-3)
Break down systems into small, autonomous services that are aligned with business capabilities, allowing for independent deployment, fostering team autonomy, and improving fault isolation. Microservices Architecture Build systems as small, autonomous services for agility and scale. API API
Context: You need to overcome the limitations of monolithic architectures regarding agility, scalability, and team autonomy.
Problem: Large monolithic applications are difficult to update, scale, and manage, hindering rapid development and independent team operation.
- Cloud Native Pattern 4 (CN-4)
Package applications and all their dependencies into isolated, portable container units (e.g., using Docker) to ensure consistent runtime behavior across different environments and simplify dependency management. Containerization Package apps with dependencies for consistent, portable units. LAPTOP CLOUD TEST SERVER
Context: You need to ensure applications run consistently across various environments (development, testing, production) and simplify dependency management.
Problem: Differences in environments and complex dependencies can lead to applications behaving inconsistently ("works on my machine" syndrome) and make deployments unreliable.
- Cloud Native Pattern 5 (CN-5)
Use platforms like Kubernetes to dynamically automate the deployment, scaling, healing, and management of containerized applications through declarative configurations. Dynamic Scheduling (Kubernetes) Use platforms like Kubernetes to automate container management at scale.
Context: You need to manage a large number of containerized applications efficiently, ensuring high availability and scalability.
Problem: Manually managing the deployment, scaling, and health of many containerized applications is complex, error-prone, and inefficient at scale.
- Cloud Native Pattern 7 (CN-7)
Structure teams, potentially using models like Team Topologies, to optimize for a fast flow of value delivery by creating autonomous, stream-aligned teams with end-to-end responsibility and minimizing handoffs. Optimize for Flow (Team Topologies) Structure teams for fast, smooth value delivery with minimal handoffs. OLD STRUCTURE OPTIMIZED FOR FLOW
Context: Your organization aims to accelerate value delivery and improve team efficiency.
Problem: Traditional team structures with many handoffs and dependencies between siloed groups create bottlenecks and slow down the delivery of value to customers.
- Cloud Native Pattern 8 (CN-8)
Utilize Platform Engineering practices to provide an Internal Developer Platform (IDP) that offers automated, self-service capabilities to developers, abstracting infrastructure complexity and increasing their speed and autonomy. Platform Engineering / IDP Provide automated, self-service capabilities via an Internal Developer Platform. IDP NEW ENVIRONMENT CI/CD PIPELINE DATABASE
Context: You want to empower developers, reduce their reliance on central operations for common resources, and ensure consistent tooling.
Problem: Developers are slowed down by manual processes, dependencies on other teams for infrastructure, or inconsistent tooling, hindering their ability to deliver value quickly.
- Cloud Native Pattern 9 (CN-9)
Design systems to emit detailed telemetry (logs, metrics, distributed traces) that provide deep insights into their internal state and behavior, enabling faster issue resolution and proactive system optimization. Observability Design systems to provide deep, actionable insights into their behavior. LOGS METRICS TRACES OBSERVABILITY
Context: You need to understand, monitor, and debug complex distributed systems effectively.
Problem: Without the ability to easily ask questions about a system's internal state, diagnosing issues, understanding performance, and ensuring reliability in complex distributed environments is extremely difficult.
- Cloud Native Pattern 11 (CN-11)
Define and manage infrastructure resources using declarative, version-controlled code (e.g., Terraform, CloudFormation), enabling automated, repeatable provisioning and robust change management for cloud environments. Infrastructure as Code (IaC) Define infrastructure with code for automated, repeatable environments. AUTOMATIONS ENGINE DEV TEST PROD
Context: You need to manage cloud or virtualized infrastructure consistently, reliably, and at scale.
Problem: Manual infrastructure provisioning and management are error-prone, time-consuming, lead to configuration drift, and lack the repeatability and version control necessary for modern environments.
AI Native patterns
AI native patterns for the next wave of innovation
- AI Native Pattern 1 (AN-1)
Design systems where the AI model is the central decision-making component, dictating data flows and interfaces to ensure cohesive, AI-first system behavior. Model-Centric Architecture Design systems where the AI model is the core decision-making engine. AI MODEL Sensor Output User Input Data
Context: You are building a system where AI capabilities are integral and fundamental to its core function and value proposition.
Problem: Treating AI models as peripheral add-ons rather than central components in system design leads to integration challenges, suboptimal performance, and a failure to fully leverage AI's decision-making power.
- AI Native Pattern 2 (AN-2)
Implement a data fabric to unify data infrastructure, automating ingestion, curation, and governance to ensure reliable, high-quality data is consistently available for robust AI model performance and insights. Data Fabric for AI Unify data infrastructure for seamless, governed AI access. CURATION GOVERNANCE AI MODEL
Context: AI systems require access to high-quality, well-governed data from diverse and potentially siloed sources.
Problem: Siloed, poorly managed, or inconsistent data hinders AI model performance, reliability, and the ability to generate trustworthy insights.
- AI Native Pattern 4 (AN-4)
Structure systems as a collection of autonomous, goal-driven AI agents capable of perception, reasoning, and action, enabling dynamic task delegation and specialized, collaborative intelligence to achieve complex objectives. Agentic Architecture Structure systems as autonomous, goal-driven AI agents that collaborate. DATA ANALYSIS AGENT COMMUNICATION AGENT TASK EXECUTION AGENT
Context: You need to address complex tasks or problems that require diverse AI capabilities and dynamic collaboration.
Problem: Monolithic AI models or rigidly defined service orchestrations often lack the flexibility and specialized capabilities needed to handle diverse, dynamic, and complex real-world tasks effectively.
- AI Native Pattern 7 (AN-7)
Embed interpretability tools and methods into AI systems from the outset of their design to clarify their decision-making logic, foster trust, and enable actionable insights. Explainability-by-Design (XAI) Embed interpretability from the start for transparent AI decisions. EXPLAINABILITY LAYER AI
Context: AI decision-making processes can be opaque ("black box"), making them hard to trust, debug, or improve.
Problem: Lack of transparency in AI decision-making hinders user trust, adoption, accountability, and the ability to diagnose or correct errors.
- AI Native Pattern 9 (AN-9)
Enhance generative AI models by having them first retrieve relevant, up-to-date information from an external knowledge base before generating a response, thereby grounding outputs in facts and yielding more accurate and contextually relevant answers. Retrieval-Augmented Generation (RAG) Enhance generative AI with external knowledge for factual, current answers. KNOWLEDGE BASE GENERATED
Context: Generative AI models (LLMs) sometimes produce outdated, incorrect, or unverified information ("hallucinations").
Problem: Generative AI models may lack access to real-time or domain-specific information, leading to responses that are not factually grounded, current, or contextually appropriate.
- AI Native Pattern 10 (AN-10)
Define desired system behavior through high-level, declarative intents, and utilize AI tools to translate these intents into functional code and components, thereby accelerating development and focusing human effort on outcomes. Intent-Driven Development (IDD) Define system behavior via high-level intents; let AI generate the code. Create user login page with secure password hashing function createLoginPage (username, password) { // Generate user login page } Username Password AI Development Assistant
Context: Traditional detailed coding and specification can be slow and laborious, especially for common or well-defined functionalities.
Problem: Manual translation of high-level requirements into detailed code is time-consuming and can introduce errors, slowing down the development process.
- AI Native Pattern 12 (AN-12)
Apply DevOps principles (e.g., automation, CI/CD, monitoring, versioning) to the entire machine learning model lifecycle (MLOps) to ensure reproducible, robust, and scalable model management from data preparation to deployment and ongoing operation. MLOps Lifecycle Management Apply DevOps discipline to the entire machine learning model lifecycle. Data Ingestion Model Training Model Validation Deployment Monitoring Retraining
Context: Managing the complex lifecycle of machine learning models reliably and efficiently is challenging with ad-hoc processes.
Problem: Without disciplined MLOps practices, managing ML models can lead to irreproducible results, deployment issues, performance degradation over time, and an inability to scale operations effectively.
- AI Native Pattern 13 (AN-13)
Skillfully craft, test, and iteratively refine input prompts to effectively guide generative AI systems, ensuring their outputs align with specific needs for accuracy, tone, and content. Prompt Engineering Skillfully craft prompts to guide generative AI for desired outputs. Prompt
Context: You are interacting with generative AI models (e.g., LLMs) to produce specific outputs.
Problem: Generative AI models can be ambiguous or produce suboptimal results if input prompts are not clear, specific, and well-structured, making it difficult to achieve precise, desired outputs.
- AI Native Pattern 14 (AN-14)
Integrate human expert review and validation at critical points in AI-driven processes, especially for high-stakes decisions or ambiguous outputs, to ensure reliability, safety, and alignment before final action or deployment. Human-in-the-Loop Validation Integrate human expert review for critical AI outputs before action. AI
Context: AI systems are making decisions or generating outputs in high-stakes applications where errors can be costly or unacceptable.
Problem: Relying solely on AI for critical decisions can be risky due to potential inaccuracies, biases, or an inability to handle novel situations, making human oversight essential.
- AI Native Pattern 18 (AN-18)
Integrate formal ethical reviews, conducted against defined principles by dedicated bodies or processes, at key stages throughout the AI system development lifecycle to ensure fairness, transparency, and accountability. Ethical AI Review Integration Integrate formal ethical reviews into the AI system development lifecycle. AI Ethical Review
Context: AI systems can have significant societal impact and may perpetuate biases or make unfair decisions.
Problem: Without formal structures for ethical oversight, AI systems may be developed and deployed in ways that are unfair, discriminatory, lack transparency, or cause unintended harm.
- AI Native Pattern 19 (AN-19)
Intentionally design workflows, interfaces, and safety protocols that enable productive, safe, and synergistic collaboration between humans and AI systems, leveraging the complementary strengths of each. Human-AI CollaborationDesign Design workflows for symbiotic, effective human-AI task completion.
Context: Many tasks can be performed more effectively or efficiently by humans and AI working together rather than either in isolation.
Problem: If human-AI interaction is not carefully designed, workflows can be inefficient, unsafe, or fail to leverage the unique strengths of both human and artificial intelligence, leading to suboptimal outcomes.
Anti-Patterns patterns
Common anti-patterns to avoid during transformation
- Anti-Pattern 1 (AP-1)
Proactively engage with emerging transformative waves by applying patterns like Learn and Explore (TF01) and maintaining a Dynamic Strategy (TF54), rather than delaying action until forced by extreme competitive pressure. Strategic Inertia Don't get left behind: proactively adapt to transformative waves.
Context: A transformative technological or market wave is emerging, and early adopters are gaining an advantage.
Problem: Organizations delay adoption of transformative changes due to inaction or complacency, leading to desperate, costly, and often insufficient responses when competitive pressure becomes extreme.
- Anti-Pattern 2 (AP-2)
Mitigate risks by thoroughly applying Learn and Explore (TF01), using Proof of Concept - PoC (TF06), and Testing Hard Things First (TF05) in sandboxes, prioritizing Adaptability over Efficiency (TF17) in early designs. Bleeding Edge Gamble Avoid betting big on unproven tech; explore before you exploit. BLEEDING EDGE TECH
Context: A new and exciting technological paradigm is emerging, but its ecosystem (tools, skills, best practices) is still immature.
Problem: Committing heavily to a new technology before it, its supporting ecosystem, or best practices are mature, is a high-risk gamble that can lead to significant wasted investment, operational instability, and solutions that quickly become obsolete or unsupported.
- Anti-Pattern 3 (AP-3)
Clearly articulate the transformation Vision First (TF14), including a defined target state, diligently Measure What Matters (TF36) to track progress, and formally apply Finish the Transformation (TF41) by setting clear exit criteria to avoid indefinite disruption. Perpetual Transition Define "done" for transformation to avoid endless, exhausting churn.
Context: An organization is undergoing a major transformation effort.
Problem: Failing to define clear end-goals or completion criteria for a transformation leads to a state of "perpetual transition," characterized by endless churn of tools and priorities, preventing a stable new baseline and causing organizational fatigue and wasted resources.
- Anti-Pattern 4 (AP-4)
Recognize the need for Holistic Transformation (TF35). Leadership must articulate the Vision First (TF14), provide Executive Commitment (TF11), and Cultivate Psychological Safety (TF15) to support the deep changes required. Incremental Facade Don't treat deep, disruptive shifts as simple, minor upgrades. NEW TOOLS OLD SYSTEMS & PROCESSES
Context: An organization is facing a disruptive change that requires fundamental shifts in technology, processes, and culture.
Problem: Treating a fundamental, disruptive shift as merely an incremental tool upgrade or a superficial change (an "incremental facade") leads to a failure to address core transformation needs, resulting in superficial adoption and minimal real benefits.
- Anti-Pattern 5 (AP-5)
Ensure Holistic Transformation (TF35) by having leadership establish the Vision First (TF14), providing Executive Commitment (TF11), and Cultivating Psychological Safety (TF15) to foster deep understanding and adoption of underlying principles, not just superficial practices. Cargo Cult Adoption Understand the 'why' behind practices, don't just copy the 'what'.
Context: An organization observes successful practices or transformations in other companies and attempts to replicate them.
Problem: Imitating the visible practices or tools of successful methodologies (e.g., specific agile ceremonies, Cloud Native tools) without understanding and adopting the underlying principles or necessary mindset shifts (cargo cult adoption) yields no real improvement.
- Anti-Pattern 6 (AP-6)
Emphasize Research Through Action (TF16), ensure designs prioritize Adaptability over Efficiency (TF17) in early stages, deliver value iteratively (CN01), and adopt a Dynamic Strategy (TF54) that allows for learning and adjustment. Illusion of Control Embrace emergent strategy; rigid long-range plans fail in uncertainty. Long Range Plan
Context: An organization is embarking on an inherently uncertain transformation process (e.g., adopting novel technologies or entering new markets).
Problem: Applying rigid, long-range planning common in stable environments to uncertain transformations creates an "illusion of control," leading to brittle plans that quickly become irrelevant and hinder necessary adaptation.
- Anti-Pattern 7 (AP-7)
Treat the official offering using Platform as a Product (TF24) principles, provide effective Enable Self-Service (TF47) and Dev Starter Pack (TF26) resources, and offer sanctioned ways to experiment via Reduce Cost of Experimentation (TF03) and providing a Sandbox Environment (TF04). Unmanaged Shadow IT Proliferation Sanctioned experimentation beats chaotic, ungoverned tool adoption. Tool Shack Tool Shack Platform Team Tool Shack
Context: Central IT processes are perceived as slow or restrictive, and business units or dev teams need to move fast.
Problem: Business units or teams independently procuring and using IT solutions ("shadow IT") without governance can lead to a proliferation of unmanaged systems, resulting in integration chaos, security risks, duplicated costs, and operational complexity.
- Anti-Pattern 11 (AP-11)
Ensure the new platform or processes are stable and adequately supported by applying Prepare for Scale (TF30) and Gradual Onboarding (TF32) before attempting widespread adoption. Premature Scaling Scale when ready: ensure a solid platform before widespread rollout. IMMATURE PLATFORM
Context: After initial successes in a transformation, there is a rush to expand the new platform or processes across the organization.
Problem: Attempting widespread adoption before the new platform or processes are stable, well-supported, and mature enough leads to widespread operational issues, inconsistent implementation, and erodes confidence in the transformation effort.
- Anti-Pattern 13 (AP-13)
Actively address workforce upskilling, manage cultural resistance through clear communication and Cultivate Psychological Safety (TF15), and foster necessary mindset shifts as integral parts of the transformation strategy. Ignoring the Human Element Transformation needs more than tech: invest in skills and mindset shifts.
Context: An organization is undergoing a transformation that introduces new technologies and ways of working.
Problem: Underestimating or failing to address the human element—such as the need for workforce upskilling, managing cultural resistance, and fostering mindset shifts—critically undermines the adoption and success of new technologies and processes.
- Anti-Pattern 14 (AP-14)
Establish and widely communicate a compelling and coherent Vision First (TF14), detailing the purpose, target state, and benefits of the transformation to unify efforts and secure stakeholder buy-in. Lack of Clear Vision Without a shared 'why' and 'what,' transformation efforts drift.
Context: An organization is initiating or undergoing a transformation effort.
Problem: Failing to establish or effectively communicate a clear, coherent, and compelling vision for the transformation leads to confusion, misaligned efforts, lack of stakeholder buy-in, and resistance to change.
- Anti-Pattern 21 (AP-21)
Prioritize code quality, regular refactoring, and thorough testing alongside feature development. Allocate dedicated time (e.g., apply Continuous Optimisation TF42) to proactively manage and reduce technical debt. Unmanaged Technical Debt Neglecting quality for speed builds a debt that cripples future agility. DEBT
Context: In fast-paced development environments, there's often intense pressure to deliver new features quickly.
Problem: Consistently neglecting code quality, refactoring, and adequate testing in favor of short-term speed accumulates "technical debt," making future changes progressively slower, more costly, and the system increasingly brittle and unreliable.
- Anti-Pattern 24 (AP-24)
Implement FinOps practices, Measure What Matters (TF36) regarding cloud spend, foster Continuous Optimisation (TF42) for resource usage, and enable self-service with clear cost visibility. Uncontrolled Cloud Costs Govern cloud use: easy provisioning can lead to excessive spending. UNCONTROLLED CLOUD COSTS
Context: Cloud platforms make it easy to provision resources on-demand.
Problem: Failing to implement cost visibility, governance (e.g., FinOps), and optimization practices can lead to excessive and uncontrolled cloud spending due to idle, orphaned, or overprovisioned resources.
- Anti-Pattern 25 (AP-25)
Design the IDP with a Platform as a Product (TF24) mindset, focusing on developer experience and Enable Self-Service (TF47) capabilities to avoid becoming a gatekeeper. Platform as Bottleneck Ensure your IDP empowers developers, not hinders them. IDP
Context: An Internal Developer Platform (IDP) is intended to accelerate development teams.
Problem: If the IDP is overly restrictive, slow to respond to developer needs, lacks adequate self-service capabilities, or is poorly maintained, it becomes a bottleneck that frustrates developers and hinders delivery speed.
- Anti-Pattern 26 (AP-26)
Apply sound architectural principles like Bounded Contexts (from Domain-Driven Design) and use a Reference Architecture (TF27) to guide service decomposition, ensuring services are cohesive and appropriately sized, not excessively granular. Nanoservice Proliferation (Microservice Maze) Avoid over-splitting services; aim for focused, not fragmented. s s s s s s s s s s s s s s s s s s s s s s
Context: Adopting microservices architecture with a focus on making services as small as possible.
Problem: Decomposing services into overly fine-grained units ("nanoservices") can lead to an explosion of artifacts and dependencies, dramatically increasing operational complexity, inter-service communication overhead, and reducing overall system comprehensibility.
- Anti-Pattern 27 (AP-27)
Truly embrace cloud-native principles by re-architecting monoliths into Microservices (CN03) and adopting patterns like Database per Service (CN16), rather than simply packaging old architectures in containers. Cloud Native/ Distributed Monolith Don't just containerize a monolith; re-architect for true cloud benefits. LEGACY LEGACY LEGACY
Context: Migrating legacy monolithic applications to the cloud or container platforms.
Problem: Simply packaging a legacy monolithic application into containers or virtual machines ("lift and shift") without adopting cloud-native architectural principles often results in a "distributed monolith" that incurs high cloud costs and fails to achieve desired scalability or agility.
- Anti-Pattern 32 (AP-32)
Always start with a clear Vision First (TF14) and a supporting Business Case (TF09) before embarking on significant technological shifts to ensure efforts are strategic and purposeful, not accidental. Accidental Transformation Steer change with clear goals, or drift into unplanned chaos.
Context: Significant technological shifts are occurring, or new tools are being adopted within the organization.
Problem: When significant technological shifts occur without strategic direction or clear objectives, the organization undergoes an "accidental transformation," leading to chaotic adoption, wasted resources, and a failure to achieve coherent business benefits.
- Anti-Pattern 33 (AP-33)
Proactively apply the Reverse Conway Maneuver (TF31) and Establish Team Communication APIs (TF38) to ensure team structures support and enable the desired software architecture, rather than hindering it. Conway Conundrum Align teams with architecture, or structure will dictate (and hinder) design. A B
Context: Adopting new software architectures (e.g., microservices) while existing team structures remain unchanged.
Problem: Failing to consider and align team communication structures with the desired software architecture (Conway's Law) leads to misaligned teams that struggle to effectively build, manage, and evolve the new system.
- Anti-Pattern 34 (AP-34)
Evaluate new tools based on strategic fit using Platform as a Product (TF24) governance and select the Best Tool for the Task (TF21) rather than pursuing novelty for its own sake. Shiny Object Syndrome Chase strategic fit, not just the latest tech trend.
Context: The technology landscape is rapidly evolving with many new tools and trends constantly emerging.
Problem: Constantly chasing the newest tools or fads ("shiny object syndrome") without assessing their strategic fit or value leads to frequent disruptions, wasted investment, lack of deep expertise, and a failure to focus on proven solutions.
- Anti-Pattern 35 (AP-35)
Recognize the need for Holistic Transformation (TF35) and actively Cultivate Psychological Safety (TF15) and a learning environment to support the adoption of new methodologies. Culture Clash New methods need fertile ground; don't plant agile seeds in rigid soil. RIGID HIERARCHY CULTURE
Context: Attempting to implement new methodologies (like Cloud Native or Agile) within an organization.
Problem: Implementing new methodologies in an existing organizational culture that is deeply entrenched and incompatible (e.g., rigid hierarchy vs. agile collaboration) causes significant friction, active resistance, and often results in superficial adoption with little real benefit.
- Anti-Pattern 36 (AP-36)
Integrate sustainability into operational practices by Measuring What Matters (TF36) (including energy/carbon), applying Continuous Optimisation (TF42) for resource use, and aiming for Efficiency over Adaptability (TF43) in mature systems. Environmental Impact Neglect Optimize for the planet too; inefficient tech has a footprint. CO ENERGY BILL OPTIMIZED CLOUD SERVER CARBON FOOTPRINT ₂
Context: IT operations, especially in the cloud, consume significant energy and resources.
Problem: Neglecting the environmental footprint of IT operations, such as through inefficient cloud resource usage or overprovisioning, leads to unnecessary energy consumption, a higher carbon impact, and missed opportunities for sustainable practices.
- Anti-Pattern 37 (AP-37)
Integrate Ethical AI Review Integration (AIN18), Bias Mitigation Pipelines (AIN22), and AI Trust Framework Integration (AIN21) into the AI design, training, and operation from the very beginning. Ethical Misalignment & Amplified Bias Embed ethics from the start; biased AI causes real-world harm. ETHICAL REVIEW REJECTED
Context: Developing AI systems that learn from data and make decisions with societal impact.
Problem: Failure to proactively embed ethical considerations and bias mitigation techniques into AI system design, training, and operation can lead to the system perpetuating or amplifying societal biases, resulting in unfair, discriminatory, or harmful outcomes.
- Anti-Pattern 38 (AP-38)
Prioritize and implement Explainability-by-Design (XAI) (AIN07) techniques and tools to make AI decision-making processes more transparent and interpretable. "Black Box" Challenge Demand AI explainability; opaque decisions erode trust. RREJECTED AI
Context: Many advanced AI models make decisions through complex internal processes that are difficult for humans to interpret.
Problem: The opaque "black box" nature of many AI models makes it difficult to understand, explain, or debug their reasoning, hindering trust, accountability, and the ability to correct errors or biases.
- Anti-Pattern 40 (AP-40)
Thoroughly evaluate the maturity, stability, security, and support of AI platforms or algorithms before deploying them in production for critical applications. Apply Bleeding Edge Gamble (AP02) considerations. AI Technological Immaturity Adopt mature AI tools for production; pilot emerging tech cautiously. BETA/ EXPERIMENTAL
Context: The AI field is rapidly evolving, with many new tools, platforms, and algorithms emerging quickly.
Problem: Adopting specific AI platforms or algorithms for production systems before they are robust, secure, scalable, or well-supported ("technological immaturity") can lead to unreliable, unsustainable, or insecure solutions.
- Anti-Pattern 41 (AP-41)
Implement robust data management practices such as Data Fabric for AI (AIN02) and Data-as-a-Product (DaaP) (AIN20) to ensure high-quality, secure, private, and ethically sourced data for AI systems. Data Governance Failure AI thrives on quality data; poor governance leads to flawed AI. GOVERNED DATA POOR QUALITY DATA
Context: AI systems are heavily dependent on vast amounts of high-quality, well-managed data for training and operation.
Problem: Inadequate management of data quality, lineage, security, privacy, and ethical sourcing ("data governance failure") critically undermines AI model performance, reliability, trustworthiness, and can lead to biased or harmful outcomes.
- Anti-Pattern 52 (AP-52)
Focus on collecting high-quality, relevant data with clear purpose and strong governance (see Data Fabric for AI (AIN02), Data-as-a-Product (DaaP) (AIN20)) rather than indiscriminately hoarding all available data. Data Hoarding Collect data with purpose; more isn't always better for AI. DATA
Context: There's a belief that AI models always benefit from having access to more data.
Problem: Excessively collecting and storing data without a clear purpose or adequate curation ("data hoarding") often leads to poor quality inputs, increased noise, compliance risks (e.g., GDPR), and significant storage/processing costs, ultimately hampering effective AI.
- Anti-Pattern 53 (AP-53)
Implement robust orchestration, communication protocols, and governance mechanisms within an Agentic Architecture (AIN04) to ensure AI agents collaborate effectively and their collective behavior aligns with overall system goals. Agentic Chaos Coordinate AI agents; unmanaged autonomy leads to disarray.
Context: Deploying multiple autonomous or semi-autonomous AI agents to perform tasks within a system or environment.
Problem: Lack of clear coordination mechanisms, shared goals, or governance for multiple interacting AI agents ("agentic chaos") can lead to conflicting actions, unpredictable system behavior, inefficiencies, and failure to achieve desired outcomes.
- Anti-Pattern 54 (AP-54)
Intentionally apply Human-AI Collaboration Design (AIN19) to create workflows that leverage the complementary strengths of both humans and AI, ensuring human expertise is valued and integrated, rather than marginalized. Human-Last Collaboration Design AI as a partner; don't marginalize human expertise. AI APPROVE
Context: Integrating AI into tasks currently performed by or involving humans.
Problem: Designing AI-augmented workflows in a way that marginalizes human roles, expertise, or judgment ("human-last collaboration") underutilizes valuable human skills, can demotivate staff, and misses opportunities for synergistic human-AI performance and critical oversight.