The Pattern Library

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Foundations Before Features Point AI at tests, CI and documentation before it touches feature work. Before pointing agents at features, use them to repair the foundations: test coverage, trusted CI, current documentation, infrastructure as code. Features start once the safety net holds at machine speed.

Context: You are rolling AI coding tools out to teams with thin tests, unreliable CI or stale documentation.

Problem: AI amplifies what is already there. Weaknesses survivable at human speed are exposed at several times the volume, and generated features arrive faster than anyone can trust them.

Harness over Model Build the system around the model; treat the model as a replaceable part. Put the effort into the harness: context, environments, validation, governance and learning loops. Keep the model behind a stable interface, so a new release can be adopted, evaluated and rolled back without redesign.

Context: You are designing delivery pipelines around language models, and every new release changes what is possible.

Problem: Designing around the model puts the least stable part at the centre. Throughput comes from the tooling around the model, and a system built on one model's behaviour stalls when the next arrives.

Context as Code Version, own and prune the agent's briefing like production code. Keep what agents need to know in the repository: a context file per codebase with only non-default rules, plus decision records and schemas. Give it an owner, version it, and prune what the model already knows.

Context: You are moving to several agents per developer on a shared codebase with its own conventions and history.

Problem: Context files grow into dumping grounds. Teams answer bad agent behaviour by adding more, which makes it worse, while conventions kept outside the repository stay invisible to every agent.

Encode What Only You Know Expose your systems and operational knowledge to agents; the model has the rest. Wrap internal systems as small tool servers owned by the teams that run them, and encode what only your organisation knows: decisions, conventions, vendor constraints, history. Skip anything generic; the model has it.

Context: You are deciding where to invest as agents become able to act across the internal systems of the business.

Problem: Generic engineering knowledge is being absorbed into the models and buys nothing durable. The knowledge that matters exists in no public corpus, and until it is reachable every agent works from a partial picture.

Business Ontology Hold the nouns and verbs of the business as data that specs, designs and agents share. Define the business's entities, relationships and actions as a maintained, machine-readable model, seeded from what exists. Make it the first content of the knowledge layer, so specs, designs, code and briefings share one vocabulary.

Context: You are automating solution design and specification with agents, and each team and tool names the same concepts differently.

Problem: Without a shared semantic model every design language rests on sand. Agents guess at meanings, house names confuse models trained on industry terms, and every consumer re-derives definitions by hand.

Shared Skills Promote personal prompts into versioned skills that every agent inherits. Treat prompts, review lenses and task recipes as shared skills: versioned, owned and backed by evaluation cases. Promote what works from one developer to the team, then to the platform, so every agent gets it.

Context: You have developers with sophisticated personal prompt libraries, and a wider group whose agents run on defaults.

Problem: Prompt craft stays personal. Advanced practice travels from person to person or not at all, quality depends on who ran the agent, and capability in one developer's setup leaves when they do.

Spec-Driven Development Turn intent into a specification that drives the tests, the code and the checks. Turn approved intent into an executable specification: behaviour, constraints, acceptance criteria and risk class, checked by a completeness gate. Derive tests from it, build and validate against it, and change the spec first when behaviour changes.

Context: You are feeding ideas into an AI pipeline as short statements written for humans, and agents generate both code and tests.

Problem: Specs good enough for humans carry too little for agents, so generated code amplifies unclear inputs and rework becomes the main output. Generated tests check the code just written, and confidence falls as coverage rises.

Narrow Agent Contracts Give each agent one job, a small tool surface and a defined handover. Compose the pipeline from specialised agents with narrow contracts: generate, review through one lens, repair, research, document. Each sees only the tools its job needs, returns a defined artefact, and hands over deterministically.

Context: You are moving to several agents per task, and vendors offer general-purpose agents that promise to do everything.

Problem: Broad agents that coordinate among themselves are hard to validate, debug and secure. Oversized tool catalogues degrade reasoning and widen the attack surface, and when one fails nobody can say which part went wrong.

Review at AI Speed Redesign code review for generated code, and enforce the rules in tooling. Write down how AI-generated code is reviewed differently from human code, and put the rules in tooling. Let deterministic checks absorb the volume, keep human attention for intent and architecture, and gate simplicity.

Context: You have moved most developers to agentic tools, and pull request volume has multiplied while senior reviewers have not.

Problem: Reviewers compensate by skimming, trusting the tests or trusting the author. Developers approve code they could not have written, and nobody notices until it has to change and no one knows how it works.

Independent Validation Check the claim outside the context that produced it. Validate every agent's output with a reviewer, human or machine, that never saw the generation session: a contract to find problems rather than confirm success, restricted tools, and artefacts rather than narratives.

Context: You are relying on agents to confirm their own work, often by asking the same model to double-check itself.

Problem: Another model call is not independence. Same context, same assumptions and the same tools produce the generator marking its own homework. "I built it successfully" is a sentence, not a test result.

Validation Wall Layer validation so generation can scale without losing assurance. Build validation as layers every change passes in order: deterministic checks, independent semantic review against the spec, specialist lenses for quality, security and compliance, bounded repair with revalidation, and human escalation for repeated failure.

Context: You are letting agents produce a real share of merged code, and validation now sets the pace for everything downstream.

Problem: Generation scales more easily than assurance. Green CI proves form, not intent, one review step cannot carry the load at machine speed, and unbounded self-correction lets an agent loop until something passes.

Evals as Code Test skills, blueprints and model upgrades with versioned evaluation cases. Keep evaluation cases beside every skill, blueprint and validator, versioned with them and run in CI. Score any change to a prompt, context file or model version against the same cases before it ships.

Context: You are running agents whose behaviour depends on prompts, context files, blueprints and model versions that change independently.

Problem: Without evaluations every change to the agent setup is judged by anecdote. A new model, a rewritten skill or an edited context file can silently degrade output, and blueprint forks are settled by opinion.

Risk-Tiered Supervision Match the supervision mode to the class of change, never to one autonomy setting. Classify changes by risk and give each class its own supervision mode: auto-merge behind deterministic gates, human approval, two-key authorisation, or permanent human release. Relax a class only when its signals earn it.

Context: You are deciding how much autonomy to grant agents across documentation, application code, migrations and regulated systems.

Problem: One autonomy setting is wrong for most of the estate at once. Too loose, and a migration ships unattended; too tight, and humans rubber-stamp trivia at machine speed until the check stops being a control.

Governance by the Path Give every agent its own identity and route every call through one audited gateway. Give each agent its own identity and route every tool call through one gateway that authenticates it, resolves the delegating human, filters tools, injects scoped credentials and logs both. Governance is enforced by the path, never by checklists.

Context: You are letting agents act on internal systems with real credentials, at a volume where nobody can review each action.

Problem: An agent running as its user holds credentials, private data and network access at once, the lethal trifecta. Without its own identity every action logs as the human, and accountability collapses at agent volume.

Humans at the Gates Move people from typing the change to owning intent, acceptance and escalation. Design the human role around the gates: express intent and decide what is worth building, accept the result in the terms it was asked for, and judge what agents cannot resolve. Report back as evidence, never as a diff.

Context: You are redesigning engineering roles as agents take over generation, execution, testing at volume and repetition.

Problem: Left undesigned, the human role degrades into skimming pull requests and babysitting agents mid-run: synchronous, resolvable by the few who can read an agent in flight, and leaving no artefact to learn from.

Learning Pipeline Let lessons into shared memory only after review, scoping and versioning. Treat organisational learning as a pipeline rather than an append. Telemetry and outcomes become candidate lessons; each is reviewed, scoped and versioned before it enters the context that briefs future runs.

Context: You are running agents repeatedly on the same estate, and every run produces findings: what failed, what needed repair, what production did next.

Problem: If lessons evaporate, every run starts from zero. If they go straight into shared memory, one wrong lesson degrades every future run that inherits it. Unreviewed memory is how factories rot.

Software Factory A governed system that turns approved intent into validated change and learns from every run. Run delivery as one system: humans set intent and hold release authority, specialised agents build, review and repair in isolated environments, independent validation checks every claim, and production evidence feeds the next run.

Context: You have solved review, context, coordination and trust one constraint at a time, and accumulated the machinery of a factory along the way.

Problem: Unnamed and unowned, that machinery decays like any other platform. Copied from Stripe or OpenAI it misleads, because their factories rest on years of tests and tooling most organisations lack.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.