The story of how a large financial services company adopted contract-driven development. Covering the situation on the ground before adoption and initial skepticism, and how we were able to influence change by demonstrating value and eventually getting people to collaborate over API specifications. Key points covered:
- Contract-driven development (CDD) can help with microservices integration but needs a new collaboration model among stakeholders.
- CDD involves writing and storing API specifications before building applications, which is different from usual practices and may take time to adopt.
- CDD builds on and contributes to a strong test pyramid which requires changes to test composition, strategy and application architecture to improve component testability.
- Start the CDD adoption journey with a few teams first to show its value and identify the necessary changes to your way of working before expanding it to others.
- Use the learnings and data from initial proof of concept to persuade leadership and others to help drive large scale adoption through smooth onboarding experience with contextualized playbooks and utilities for CDD