01
PRODUCT SUITES ARE CONSISTENT
Products within a suite should present as consistent and coherent offerings to our customers.
Products within a suite should present as consistent and coherent offerings to our customers.
We shield our customers from the complexity of Worldpay’s internal systems and structures, and manage that orchestration.
We make it easy for our customer to get it right, and easy for Worldpay to change rapidly and safely, without disrupting our customers.
Product domains span their core functional offerings, value added capabilities, expose insights, provide great developer experiences, are secure and simple to operate.
Each product is designed with a vision, commercial potential, customer experience and lifespan beyond that of the initial provider, downstream systems and scope needs.
All products are built to be self-service to empower internal and external customers, and enable operations at a global scale.
Product roadmaps must account for this and enable incremental achievement of this goal. Where the cost is prohibitive there must be a path towards meeting this aim.
The cost/impact of manual processing should be tracked in the interim.
Our Products speak the language of their domain and fit our tone of voice at all customer touchpoints
We give our line of business teams access to product and customer intelligence and insights through recording and exposing commercial and customer events.
We will move Worldpay towards data-driven product development.
A squad’s product roadmap defines the core services they must build.
Where a non-core service is required and is time-bound by squad deliverable and not deliverable by a third-party or global platform then a squad will self-serve. Squads must prefer third party service offerings that meet NFR’s over in squad solutions that do not align to their product roadmap. Worldpay third parties always get preference over external third parties.
Component creation and reuse is a fundamental enabler and is facilitated by chapter. Components must have and meet acceptable quality levels. Where a component exists and meets those quality levels reinventing is not an option. Our standards dictate critical areas of alignment so that high quality delivery and reuse are possible.
A squad Builds, Releases, Operates (BROs) its own services and clearly defines the service levels and boundaries.
Squads must define and own the end-end capability they expose. Where a boundary is crossed the squad must ensure clear support agreements exist with upstream and downstream systems.
Every consumer must have an effective contract with their dependencies such that they can meet their service levels.
Squads expose their product capabilities and abstract those of their third party suppliers through APIs. This should match our GW2 developer experience by providing access to all of those capabilities and enabling self-service to our customers.
All services that are envisioned to be must be capable of scaling up to meet global needs or have a clear path on their roadmap to doing so. The technical design should enable incremental delivery of global scale.
Service operation should require minimal effort; as demonstrated by automated recovery, self-serve, and actionable alerts. Squads exist to deliver new capabilities to their customers; operations should not impede that mission.
All squads must provide contingency and business continuity capabilities via circuit breaking or have an alternative service provider to enable graceful degradation.
Chapters manage and curate our technology stacks; squads can experiment and feedback changes via chapter.
Quality unites us as a group and is our key enabler for rapid, safe change. Absolutely central to our ways of working are test-driven development, acceptance-test driven development, consumer-driven contract testing, trunk-based development.
We believe technical debt incurs compound interest; it destroys the ability to deliver over time. We support and challenge each other to never cut corners. We cut scope, never quality. We do not take risks in production; when we encounter issues we lean on tests to ensure we can safely resolve issues.
We value our code, and being able to evolve our products quickly and easily over time. We think in terms of Clean Code, KISS and YAGNI. We know the fundamental importance of non-functional requirements as we deliver services that are secure, highly available, scalable and performant.
Our engineers collaborate to define our standards, make our technical decisions and define & refine our tech stack. We take the time to do that as well; 1 day every 2 weeks is dedicated to aligning and improving.
The people and our ways of working are our strength. We invest heavily in that; everyone has a half-day every 2 weeks to spend upskilling. We attend conferences, meet-ups, training courses, and pair up to apply these skills in sprint.
Our squads’ definition of ready centres on the INVEST principles. Our QA shift-left and spend their time working with Product Owners to ensure we’re building the right thing, using specifications by example to flesh out the detail.
We aim for perfection because beautiful code excites us and clean architecture make us proud. We live and breathe continuous improvement. We want every week to be better than the last.