├── .gitignore ├── .gitbook └── assets │ ├── hmrc.png │ ├── alilotia.png │ ├── anantpal.jpeg │ ├── eddgrant.png │ ├── img_2032.png │ ├── img_2033.png │ ├── img_2034.png │ ├── img_2035.png │ ├── img_2038.png │ ├── johnlewis.png │ ├── jonbarber.png │ ├── redahmeid.png │ ├── tomgrace.png │ ├── adamhansrod.png │ ├── alilotia (1).png │ ├── aluncoppack.png │ ├── bespoke-paas.png │ ├── brianmason.png │ ├── danhaughey.png │ ├── danmitchell.jpg │ ├── darrenwalker.png │ ├── davehewett.png │ ├── eddgrant (2).png │ ├── jondickinson.png │ ├── matthewraplh.png │ ├── ogonnaiwunze.jpg │ ├── paulodonnell.png │ ├── sammcgregor.png │ ├── stuartgunter.png │ ├── anantpal (1).jpeg │ ├── andysingleton.png │ ├── beccystafford.png │ ├── lyndsayprewer.png │ ├── stevesmith (1).jpg │ ├── stevesmith (2).jpg │ ├── adamhansrod (1).png │ ├── aluncoppack (1).png │ ├── andysingleton (1).png │ ├── beccystafford (1).png │ ├── eddgrant (2) (1).png │ ├── isabellbritsch.jpeg │ ├── katarzynakittel.png │ ├── kulvindersingh.jpeg │ ├── stuartgunter (1).png │ ├── stevesmith (2) (1).jpg │ ├── deployment-indicator.png │ ├── digital-platform-teams.png │ ├── thomasdecadorogranier.png │ ├── expanding-platform-teams.png │ ├── digital-platform-services.png │ ├── screenshot-2020-10-12-at-11.49.12.png │ └── service-catalogue-service-page-wireframe.png ├── by-our-customers ├── README.md ├── hmrc.md └── john-lewis-and-partners.md ├── practices ├── README.md ├── bootstrap.md ├── architecture.md ├── teams.md └── paved-road.md ├── contribute ├── README.md ├── how-to-contribute.md └── contributors.md ├── by-equal-experts └── README.md ├── SUMMARY.md ├── introduction ├── what-is-a-bespoke-platform-as-a-service.md ├── README.md ├── when-to-start-a-digital-platform.md ├── what-is-a-digital-platform.md ├── benefits-of-a-digital-platform.md └── capabilities-of-a-digital-platform.md ├── README.md ├── principles.md └── pitfalls.md /.gitignore: -------------------------------------------------------------------------------- 1 | .idea/ 2 | *.iml 3 | -------------------------------------------------------------------------------- /.gitbook/assets/hmrc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/hmrc.png -------------------------------------------------------------------------------- /.gitbook/assets/alilotia.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/alilotia.png -------------------------------------------------------------------------------- /.gitbook/assets/anantpal.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/anantpal.jpeg -------------------------------------------------------------------------------- /.gitbook/assets/eddgrant.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/eddgrant.png -------------------------------------------------------------------------------- /.gitbook/assets/img_2032.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/img_2032.png -------------------------------------------------------------------------------- /.gitbook/assets/img_2033.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/img_2033.png -------------------------------------------------------------------------------- /.gitbook/assets/img_2034.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/img_2034.png -------------------------------------------------------------------------------- /.gitbook/assets/img_2035.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/img_2035.png -------------------------------------------------------------------------------- /.gitbook/assets/img_2038.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/img_2038.png -------------------------------------------------------------------------------- /.gitbook/assets/johnlewis.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/johnlewis.png -------------------------------------------------------------------------------- /.gitbook/assets/jonbarber.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/jonbarber.png -------------------------------------------------------------------------------- /.gitbook/assets/redahmeid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/redahmeid.png -------------------------------------------------------------------------------- /.gitbook/assets/tomgrace.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/tomgrace.png -------------------------------------------------------------------------------- /.gitbook/assets/adamhansrod.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/adamhansrod.png -------------------------------------------------------------------------------- /.gitbook/assets/alilotia (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/alilotia (1).png -------------------------------------------------------------------------------- /.gitbook/assets/aluncoppack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/aluncoppack.png -------------------------------------------------------------------------------- /.gitbook/assets/bespoke-paas.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/bespoke-paas.png -------------------------------------------------------------------------------- /.gitbook/assets/brianmason.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/brianmason.png -------------------------------------------------------------------------------- /.gitbook/assets/danhaughey.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/danhaughey.png -------------------------------------------------------------------------------- /.gitbook/assets/danmitchell.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/danmitchell.jpg -------------------------------------------------------------------------------- /.gitbook/assets/darrenwalker.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/darrenwalker.png -------------------------------------------------------------------------------- /.gitbook/assets/davehewett.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/davehewett.png -------------------------------------------------------------------------------- /.gitbook/assets/eddgrant (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/eddgrant (2).png -------------------------------------------------------------------------------- /.gitbook/assets/jondickinson.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/jondickinson.png -------------------------------------------------------------------------------- /.gitbook/assets/matthewraplh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/matthewraplh.png -------------------------------------------------------------------------------- /.gitbook/assets/ogonnaiwunze.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/ogonnaiwunze.jpg -------------------------------------------------------------------------------- /.gitbook/assets/paulodonnell.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/paulodonnell.png -------------------------------------------------------------------------------- /.gitbook/assets/sammcgregor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/sammcgregor.png -------------------------------------------------------------------------------- /.gitbook/assets/stuartgunter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/stuartgunter.png -------------------------------------------------------------------------------- /by-our-customers/README.md: -------------------------------------------------------------------------------- 1 | # By our customers 2 | 3 | These are some of the Digital Platforms we’ve worked on with our clients. 4 | 5 | -------------------------------------------------------------------------------- /.gitbook/assets/anantpal (1).jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/anantpal (1).jpeg -------------------------------------------------------------------------------- /.gitbook/assets/andysingleton.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/andysingleton.png -------------------------------------------------------------------------------- /.gitbook/assets/beccystafford.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/beccystafford.png -------------------------------------------------------------------------------- /.gitbook/assets/lyndsayprewer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/lyndsayprewer.png -------------------------------------------------------------------------------- /.gitbook/assets/stevesmith (1).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/stevesmith (1).jpg -------------------------------------------------------------------------------- /.gitbook/assets/stevesmith (2).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/stevesmith (2).jpg -------------------------------------------------------------------------------- /.gitbook/assets/adamhansrod (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/adamhansrod (1).png -------------------------------------------------------------------------------- /.gitbook/assets/aluncoppack (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/aluncoppack (1).png -------------------------------------------------------------------------------- /.gitbook/assets/andysingleton (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/andysingleton (1).png -------------------------------------------------------------------------------- /.gitbook/assets/beccystafford (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/beccystafford (1).png -------------------------------------------------------------------------------- /.gitbook/assets/eddgrant (2) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/eddgrant (2) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/isabellbritsch.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/isabellbritsch.jpeg -------------------------------------------------------------------------------- /.gitbook/assets/katarzynakittel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/katarzynakittel.png -------------------------------------------------------------------------------- /.gitbook/assets/kulvindersingh.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/kulvindersingh.jpeg -------------------------------------------------------------------------------- /.gitbook/assets/stuartgunter (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/stuartgunter (1).png -------------------------------------------------------------------------------- /.gitbook/assets/stevesmith (2) (1).jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/stevesmith (2) (1).jpg -------------------------------------------------------------------------------- /.gitbook/assets/deployment-indicator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/deployment-indicator.png -------------------------------------------------------------------------------- /.gitbook/assets/digital-platform-teams.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/digital-platform-teams.png -------------------------------------------------------------------------------- /.gitbook/assets/thomasdecadorogranier.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/thomasdecadorogranier.png -------------------------------------------------------------------------------- /.gitbook/assets/expanding-platform-teams.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/expanding-platform-teams.png -------------------------------------------------------------------------------- /.gitbook/assets/digital-platform-services.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/digital-platform-services.png -------------------------------------------------------------------------------- /.gitbook/assets/screenshot-2020-10-12-at-11.49.12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/screenshot-2020-10-12-at-11.49.12.png -------------------------------------------------------------------------------- /.gitbook/assets/service-catalogue-service-page-wireframe.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EqualExperts/digital-platform-playbook/HEAD/.gitbook/assets/service-catalogue-service-page-wireframe.png -------------------------------------------------------------------------------- /practices/README.md: -------------------------------------------------------------------------------- 1 | # Practices 2 | 3 | We recommend the adoption of these Digital Platform practices once you’ve passed our [when to start a Digital Platform criteria](https://digital-platform.playbook.ee/introduction/when-to-start-a-digital-platform), and you’ve got at least one Digital Service team. 4 | 5 | -------------------------------------------------------------------------------- /contribute/README.md: -------------------------------------------------------------------------------- 1 | # Contribute 2 | 3 | This playbook is produced through the efforts of [a number of people](https://digital-platform.playbook.ee/contribute/contributors), who have generously shared their experiences for the benefit of others. 4 | 5 | To help ensure this playbook remains relevant and useful, we welcome contributions from anyone. Please see the [contribution guidelines](https://digital-platform.playbook.ee/contribute/how-to-contribute) if you're interested in helping out. 6 | 7 | -------------------------------------------------------------------------------- /contribute/how-to-contribute.md: -------------------------------------------------------------------------------- 1 | # How to contribute 2 | 3 | ## How To Contribute 4 | 5 | If you'd like to contribute, please follow these guidelines: 6 | 7 | * If you'd like to fix some content \(e.g. broken link, typo\), please submit a[ PR](https://github.com/EqualExperts/digital-platform-playbook/pulls) 8 | * If you'd like to suggest a change in content \(e.g. new section,changing the meaning of existing text\), please raise an[ Issue](https://github.com/EqualExperts/digital-platform-playbook/issues) where we can discuss your proposal. 9 | 10 | Please do not submit a PR until the changes have been agreed 11 | 12 | -------------------------------------------------------------------------------- /by-equal-experts/README.md: -------------------------------------------------------------------------------- 1 | # By Equal Experts 2 | 3 | These are additional articles and talks on Digital Platforms, from the [Equal Experts network](https://www.equalexperts.com/our-people/our-network/). 4 | 5 | ## Videos 6 | 7 | {% embed url="https://www.youtube.com/watch?v=kjlrKZVNz5c" %} 8 | 9 | ## Articles 10 | 11 | {% embed url="https://www.equalexperts.com/blog/our-thinking/accelerated-delivery-through-building-digital-platforms/" %} 12 | 13 | {% embed url="https://www.equalexperts.com/blog/our-thinking/so-what-is-a-digital-platform-anyway/" %} 14 | 15 | {% embed url="https://www.equalexperts.com/blog/our-thinking/when-is-a-good-time-to-start-building-a-digital-platform/" %} 16 | 17 | {% embed url="https://www.equalexperts.com/blog/our-thinking/what-are-the-benefits-of-a-digital-platform/" %} 18 | 19 | -------------------------------------------------------------------------------- /by-our-customers/hmrc.md: -------------------------------------------------------------------------------- 1 | # HMRC 2 | 3 | Equal Experts has worked with HMRC on the Multichannel Digital Tax Platform \(MDTP\) for over 6 years. At its peak, MDTP has had over 60 teams and 600 microservices. 4 | 5 | ![HMRC winning Digital Project of the Year at the 2015 UK IT Industry Awards](../.gitbook/assets/hmrc.png) 6 | 7 | ## Case Studies 8 | 9 | {% embed url="https://www.equalexperts.com/case-study/how-hmrc-supported-the-economy-in-four-short-weeks/"%} 10 | 11 | ## Videos 12 | 13 | {% embed url="https://www.youtube.com/watch?v=WDIYgSZ0kCo"%} 14 | 15 | {% embed url="https://www.youtube.com/watch?v=-gcvUM5VhEk"%} 16 | 17 | {% embed url="https://www.youtube.com/watch?v=mVRfTzzumG0"%} 18 | 19 | ## Articles 20 | 21 | {% embed url="https://www.equalexperts.com/blog/our-thinking/operability-hmrc/"%} 22 | 23 | {% embed url="https://www.equalexperts.com/blog/our-thinking/how-equal-experts-helped-hmrc-to-get-covid-19-relief-money-to-people-through-continuous-delivery/"%} 24 | 25 | -------------------------------------------------------------------------------- /by-our-customers/john-lewis-and-partners.md: -------------------------------------------------------------------------------- 1 | # John Lewis & Partners 2 | 3 | Equal Experts has partnered with John Lewis & Partners on the John Lewis & Partners Digital Platform \(JLDP\) since 2017. As of September 2020, JLDP has surpassed 30 teams and 100 microservices. 4 | 5 | ![John Lewis & Partners winning a 2019 DevOps Industry Award](../.gitbook/assets/johnlewis.png) 6 | 7 | ## Case Studies 8 | 9 | {% embed url="https://www.equalexperts.com/case-study/how-to-do-digital-transformation-like-john-lewis-partners/" %} 10 | 11 | ## Videos 12 | 13 | {% embed url="https://www.youtube.com/watch?v=rebXriWO0qw" %} 14 | 15 | {% embed url="https://www.youtube.com/watch?v=Btd80OzsgjI " %} 16 | 17 | ## Articles 18 | 19 | {% embed url="https://medium.com/john-lewis-software-engineering/a-year-in-google-cloud-4586a117f352"} 20 | 21 | {% embed url="https://medium.com/john-lewis-software-engineering/our-award-winning-john-lewis-digital-platform-2d093e03d542" %} 22 | 23 | {% embed url="https://www.equalexperts.com/blog/our-thinking/equal-experts-engineer-chaos-at-john-lewis-partners" %} -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [Overview](README.md) 4 | * [Introduction](introduction/README.md) 5 | * [What is a Bespoke Platform as a Service](introduction/what-is-a-bespoke-platform-as-a-service.md) 6 | * [What is a Digital Platform](introduction/what-is-a-digital-platform.md) 7 | * [Benefits of a Digital Platform](introduction/benefits-of-a-digital-platform.md) 8 | * [Capabilities of a Digital Platform](introduction/capabilities-of-a-digital-platform.md) 9 | * [When to start a Digital Platform](introduction/when-to-start-a-digital-platform.md) 10 | * [Principles](principles.md) 11 | * [Practices](practices/README.md) 12 | * [Bootstrap](practices/bootstrap.md) 13 | * [Architecture](practices/architecture.md) 14 | * [Paved Road](practices/paved-road.md) 15 | * [Teams](practices/teams.md) 16 | * [Pitfalls](pitfalls.md) 17 | * [By Our Customers](by-our-customers/README.md) 18 | * [HMRC](by-our-customers/hmrc.md) 19 | * [John Lewis & Partners](by-our-customers/john-lewis-and-partners.md) 20 | * [By Equal Experts](by-equal-experts/README.md) 21 | * [Contribute](contribute/README.md) 22 | * [Contributors](contribute/contributors.md) 23 | * [How to contribute](contribute/how-to-contribute.md) 24 | 25 | -------------------------------------------------------------------------------- /introduction/what-is-a-bespoke-platform-as-a-service.md: -------------------------------------------------------------------------------- 1 | # What is a Bespoke Platform as a Service 2 | 3 | A Digital Platform is a type of bespoke platform as a service \(PaaS\), built by a [platform team](https://teamtopologies.com/key-concepts) 4 | 5 | > A bespoke PaaS is a set of streamlined tools, processes, and people within your organisation, which form platform capabilities to help your organisation’s teams rapidly meet the needs of your customers. 6 | 7 | There are different types of bespoke PaaS, based on workload. The most common types we’ve seen before are Digital and Data Platforms. We advise your organisation invests in a bespoke PaaS when a clear, homogenous workload starts to emerge across multiple teams. 8 | 9 | ![Two types of bespoke Platform as a Service](../.gitbook/assets/bespoke-paas.png) 10 | 11 | We strongly recommend you host a bespoke PaaS in a single public cloud, using Amazon Web Services \(AWS\), Azure, or Google Cloud Platform \(GCP\). We have deep expertise in all three of those public clouds. Each is an effective foundation for a bespoke PaaS because they offer a tried-and-tested, on-demand, cloud computing platform, with a wide range of reliable cloud services that can be provisioned instantly and billed on a pay-per-use basis. 12 | 13 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | The Equal Experts Digital Platform playbook is our thinking on why, when, and how to build Digital Platforms. A Digital Platform enables an organisation to achieve Continuous Delivery and Operability at scale. 4 | 5 | Our approach is based on first-hand experience building Digital Platforms, and our deep expertise in both Continuous Delivery and Operability. 6 | 7 | ![Teams on a Digital Platform](.gitbook/assets/digital-platform-teams.png) 8 | 9 | We’ve [open-sourced](https://github.com/EqualExperts/digital-platform-playbook) this playbook under a [Creative Commons license](https://creativecommons.org/licenses/by-nc/4.0/), and we encourage [contributions](https://digital-platform.playbook.ee/contribute) to iteratively improve our content. 10 | 11 | ### The lead authors of this playbook are: 12 | 13 | |Photo|Name| 14 | | :--- | :--- | 15 | | ![](.gitbook/assets/img_2034.png) | [Adam Hansrod](https://www.linkedin.com/in/adam-hansrod-22940876/) | 16 | | ![](.gitbook/assets/img_2035.png) | [Steve Smith](https://www.linkedin.com/in/stevesmithtech/) | 17 | | ![](.gitbook/assets/img_2032.png) | [Alun Coppack](https://www.linkedin.com/in/aluncoppack/) | 18 | | ![](.gitbook/assets/img_2038.png) | [Edd Grant](https://www.linkedin.com/in/eddgrant/) | 19 | -------------------------------------------------------------------------------- /contribute/contributors.md: -------------------------------------------------------------------------------- 1 | # Contributors 2 | 3 | We would like to say a massive “thank you!” to our numerous colleagues and clients: the brilliant hive mind of the [Equal Experts network](https://www.equalexperts.com/our-people/our-network/) whose wisdom and experiences have made this book possible. 4 | 5 | **This book is dedicated to you.** 6 | 7 | We would also like to call out some specific colleagues who have contributed. 8 | 9 | [Ali Lotia](https://www.linkedin.com/in/lotia/),[ Anant Pal](https://www.linkedin.com/in/anantkpal/),[ Andy Singleton](https://www.linkedin.com/in/asinglet/), [Beccy Stafford](https://www.linkedin.com/in/rebecca-stafford-a83184a/), [Brian Mason](https://www.linkedin.com/in/brian-mason-3844534/), [Dan Haughey](https://www.linkedin.com/in/danhaughey/), [Dan Mitchell](https://www.linkedin.com/in/daniel-mitchell-b33b6b8/), [Darren Walker](https://www.linkedin.com/in/darrenwalkeruk/), [Dave Hewett](https://www.linkedin.com/in/dave-hewett-b97609/), [Isabell Britsch](https://www.linkedin.com/in/isabell-britsch/), [Jon Barber](https://www.linkedin.com/in/jonbarber/), [Jon Dickinson](https://www.linkedin.com/in/jondickinson/), [Katarzyna Kittel](https://www.linkedin.com/in/kasiakittel/), [Kulvinder Singh](https://www.linkedin.com/in/kulvinder-singh-86358a/), [Lyndsay Prewer](https://www.linkedin.com/in/lyndsp/), [Matt Ralph](https://www.linkedin.com/in/matt-ralph-217b5236/), [Ogonna Iwunze](https://www.linkedin.com/in/ogonnaiwunze/), [Paul O'Donnell](https://www.linkedin.com/in/podconsulting/), [Reda Hmeid](https://www.linkedin.com/in/redahmeid/), [Sam McGregor](https://www.linkedin.com/in/sammcgregor/), [Stuart Gunter](https://www.linkedin.com/in/stuartgunter/), [Thomas de Cad'oro Granier](https://www.linkedin.com/in/thomasgranier/) and [Tom Grace](https://www.linkedin.com/in/theothertom/). 10 | 11 | -------------------------------------------------------------------------------- /introduction/README.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | This playbook defines the principles and practices Equal Experts recommend for designing Digital Platforms. 4 | 5 | > _A Digital Platform is a bespoke Platform as a Service \(PaaS\) product composed of people, processes, and tools that enables teams to rapidly develop, iterate, and operate Digital Services at scale._ 6 | 7 | To be competitive, your organisation must rapidly explore new product offerings as well as exploit established products. New ideas must be validated and refined with customers as quickly as possible, if product/market fit and repeatable success are to be found. 8 | 9 | You might have multiple teams in a brownfield or greenfield IT estate, where your ability to deliver product features is constrained by your technology capabilities. In either scenario, you want your culture, good practices, and speed of execution to scale up as you add more teams. 10 | 11 | A Digital Platform optimised for the delivery of Digital Services might be an accelerator for your organisation – if you can make a multi-year commitment to investment. A Digital Platform isn’t a small undertaking, and requires ongoing funding for you to realise the greatest benefits.. 12 | 13 | ## **Who is this playbook for** 14 | 15 | We’ve created this playbook to help you and your colleagues build a Digital Platform together. It’s for everyone in your organisation, not just software developers or operability engineers. That includes CIOs, CTOs, product managers, analysts, delivery leads, engineering managers, and more. 16 | 17 | We’re strong proponents of cloud-native computing, serverless in all its forms, microservice architectures, and open-source technologies. However, the practices defined here are technology and vendor-agnostic, to allow you to determine the best way to adopt these ideas in the context of your organisation. 18 | 19 | -------------------------------------------------------------------------------- /practices/bootstrap.md: -------------------------------------------------------------------------------- 1 | # Bootstrap 2 | 3 | ## Share a vision 4 | 5 | A Digital Platform vision will help people to understand what you intend to accomplish, and create a powerful framing device for future conversations about platform capabilities. 6 | 7 | We recommend a Digital Platform vision be produced in a short [Inception](https://inception.playbook.ee/) phase, prior to any team staffing. This will help you bring together stakeholders and potential users to clarify the problems you’re trying to solve in your organisation. It’s also an opportunity to agree upon early Digital Platform boundaries and responsibilities. You may even find that a Digital Platform will not achieve what your organisation needs. 8 | 9 | We’ve worked with clients on a number of Digital Platform visions. One example we wholeheartedly recommend is from [John Lewis & Partners Digital Platform \(JLDP\)](https://medium.com/john-lewis-software-engineering/our-award-winning-john-lewis-digital-platform-2d093e03d542): 10 | 11 | > JLDP will empower teams through a frictionless & stable state-of-the-art platform, so that they can quickly deliver innovative & high quality services for our customers. 12 | 13 | This clearly communicates the intent behind the John Lewis & Partners Digital Platform – a desire to rapidly innovate in Digital Service and benefit customers via team empowerment, opinionated user journeys, and the use of the latest cloud technologies. 14 | 15 | ## Measure for success 16 | 17 | All Digital Platform teams and Digital Service teams need to have measures of success on delivery throughput, production reliability, and user satisfaction. We recommend those measures are publicly radiated on an internal website, for all teams and stakeholders to see. 18 | 19 | For all teams, delivery throughput can be measured using the [Accelerate](https://www.amazon.com/dp/B07B9F83WM) metrics of Lead Time and Frequency \(i.e. time to deploy a new feature and the rate of deployment of new features\). Production reliability can be measured using Availability % and Time To Restore Availability. Data collection can be automated for all metrics, via the deployment pipeline and alerting toolchain. 20 | 21 | These measures can be visualised as information indicators in order to show emerging trends and identify teams in need of assistance. For more on this, see [Measuring Continuous Delivery](https://leanpub.com/measuringcontinuousdelivery) by Steve Smith. Below is an example of a team information indicator for delivery throughput. 22 | 23 | ![A deployment indicator](../.gitbook/assets/deployment-indicator.png) 24 | 25 | Measures of user satisfaction will vary across Digital Platform and Digital Service teams. Digital Platform teams that focus on conversations, surveys, and capability analytics will better understand Digital Service teams’ experiences. Digital Service teams can implement customer satisfaction metrics using Net Promoter Score \(NPS\) and customer journey analytics. 26 | 27 | -------------------------------------------------------------------------------- /practices/architecture.md: -------------------------------------------------------------------------------- 1 | # Architecture 2 | 3 | ### Maximise managed services 4 | 5 | Push the commodity cloud services within your platform capabilities into your public cloud provider wherever possible. Treating your public cloud provider as Software as a Service \(SaaS\) not Infrastructure as a Service \(IaaS\) allows your Digital Platform teams to transfer more operational responsibilities, freeing time up for them to focus on higher value activities. 6 | 7 | Using managed cloud services for commodities such as databases and messaging queues equates to outsourcing your operating costs to a low-cost, highly experienced supplier. It results in easier cloud service upgrades, faster security patching, lower recruitment costs, and higher availability for your Digital Platform. 8 | 9 | Maximising managed services can create lock-in anxiety. It’s important to prioritise business agility and Total Cost of Ownership \(TCO\) over lock-in. Lock-in is only a significant problem when a cloud service is a common utility function with a high switching cost, such as a proprietary Oracle RDBMS in the cloud. Alternative cloud services exist with lower switching costs, such as AWS Aurora. 10 | 11 | ### Multi-zone in a single region by default 12 | 13 | The architecture of your Digital Platform needs to be predicated on the availability needs of your Digital Services . In [Site Reliability Engineering](https://landing.google.com/sre/sre-book/chapters/embracing-risk/), Betsy Beyer et al describe reliability as a range from 99.0% to 99.999%, and state an additional nine of reliability requires an order of magnitude more engineering effort. We’ve confirmed this insight with multiple clients. 14 | 15 | Your cloud provider will offer cloud services in regions and zones. A region is a large geographic location. It will consist of multiple logically isolated zones, which host cloud services and are usually physically isolated from one another. We recommend multi-zone single region for your Digital Platform architecture in nearly all scenarios. 16 | 17 | Multi-zone single region will provide an effective balance between Digital Platform reliability and engineering effort for many organisations. Multi-zone usually provides geographic redundancies within a single region, and protects your Digital Platform from zonal failures caused by issues such as power outages. 18 | 19 | It’s important to understand the unique availability characteristics of your cloud provider. Each cloud provider will have a majority of its cloud services per-zone, but some will be per-region. In addition, zones and regions may not behave as expected. For example, as of September 2020, the [zones in a GCP region do not have geographic isolation](https://cloud.google.com/compute/docs/regions-zones). This means AWS and Azure have geographic redundancies within a single region, but GCP does not. It might make multi-region service more compelling if your cloud provider is GCP. 20 | 21 | ### Multi-zone multi-region in some scenarios 22 | 23 | Multi-zone multi-region is justifiable when you’re concerned about: 24 | 25 | * The availability of cloud commodity services provided by a single region 26 | * Geographically distributed customers experiencing higher latencies, the further they are from your single region 27 | * The time to restore your Digital Platform when your single region fails 28 | 29 | Cloud providers currently provide limited support for natively running workloads across multiple regions. The extra complexity added by your bespoke tooling may reduce your overall availability, even as it protects against a single region failure. Some failure scenarios are not improved by multi-region, such as a faulty global rollout of a cloud commodity service. 30 | 31 | We don’t recommend multi-cloud i.e. replicating an entire Digital Platform ecosystem across two different cloud providers. This will force your Digital Platform to use the lowest common denominator of cloud services, and limit reliability to the least reliable cloud provider. Corey Quinn has written a comprehensive explanation of why [multi-cloud is the worst practice](https://www.lastweekinaws.com/blog/multi-cloud-is-the-worst-practice/). 32 | 33 | ### Name for discoverability 34 | 35 | As a Digital Platform ecosystem expands, discoverability becomes crucial. A Digital Service team may need to quickly identify a failing downstream Digital Service, and notify the owning team of the failure. A Digital Platform team may need the ability to locate all Digital Service teams in a particular delivery centre, or all Digital Services with abnormal reliability trends. 36 | 37 | Arbitrary naming conventions for Digital Service teams and Digital Services can be actively hostile to new team members. It can be extraordinarily difficult for Digital Service teams to collaborate with one another, and rapidly locate the right person at the right moment. 38 | 39 | Discoverability can be achieved by ensuring a convention by default is used throughout the entire Digital Platform, in all tools and processes. We recommend the following convention: 40 | 41 | * all Digital Services are named after the product capability they represent 42 | * all Digital Service teams are named after the Digital Services they’re building 43 | 44 | For example, if there is a Digital Service for customer recommendations, both the service and the team need to be named “Customer Recommendations”. 45 | 46 | -------------------------------------------------------------------------------- /principles.md: -------------------------------------------------------------------------------- 1 | # Principles 2 | 3 | We recommend the adoption of these Digital Platform principles once you’ve passed our [when to start a Digital Platform criteria](https://digital-platform.playbook.ee/introduction/when-to-start-a-digital-platform). 4 | 5 | ### Digital Platform as a product 6 | 7 | We believe a Digital Platform must be treated as a product, rather than a project. By that, we mean that for strategic competitive advantage, there must be an organisational mindset of a multi-year investment rather than short-term commodity thinking. 8 | 9 | There needs to be dedicated, multi-year funding from the outset. There also needs to be an empowered Product Manager on the Digital Platform teams, who can prioritise work for new and existing platform capabilities. The Product Manager and their teams will solicit and act on feedback from the Digital Services that are the customers of the Digital Platform. This will help to create a Digital Platform with well-articulated goals and will allow the Digital Platform to be incrementally improved over time. 10 | 11 | ### Collaborate with users 12 | 13 | Digital Platform teams must have a relentless focus on nurturing bi-directional feedback loops with Digital Service teams. They must understand who their users are and strive to meet their Digital Platform needs. 14 | 15 | Digital Platform teams engage in a continuous conversation with each Digital Service team. They must form trusted relationships with multiple team members from each team, in which there is sufficient psychological safety for constructive bi-directional feedback. The Digital Platform teams can then jointly experiment on new platform features with affected Digital Service teams and continue to enhance the Digital Platform as required. 16 | 17 | ### Advertise the Paved Road 18 | 19 | At the outset of a Digital Platform, there will be no Paved Road. Opinionated platform capabilities will gradually emerge from the Digital Platform teams to govern the majority of user journeys for Digital Service teams. It's important people know a Paved Road is on the way. 20 | 21 | Digital Service teams will have the greatest success when they understand that the purpose of a Paved Road is to abstract away low-level platform features, decouple them from Digital Platform teams, and accelerate delivery of Digital Services. Our [Collaborate with users principle](https://digital-platform.playbook.ee/principles#collaborate-with-users) means Digital Platform teams must know about the Digital Service teams but need not know significant details of the Digital Services themselves. 22 | 23 | Publicise the Paved Road intentions, with examples of opinionated user journeys planned for the future. The roadmap needs to explain that Digital Service team feedback will shape the Paved Road, and Digital Platform teams will not support user journeys beyond it. This will help to achieve Paved Road buy-in from Digital Service teams. 24 | 25 | ### Accelerate Continuous Delivery and Operability 26 | 27 | Cognitive load on Digital Service teams stems from user journey complexity, caused by ways of working, technology choices, and/or processes at inter-team boundaries. 28 | 29 | Digital Platform teams need to continuously remove complexity from the Digital Service teams’ user journeys. The goal is to make Continuous Delivery and Operability adoption as easy as possible. One example is gradually standardising a deployment pipeline for building, deploying, and testing a release candidate that automatically runs on code commits. This also applies to the Digital Platform teams themselves. 30 | 31 | {% tabs %} 32 | {% tab title="HMRC experience" %} 33 | Collaboration with Digital Service teams was key to the success of the Multichannel Digital Tax Platform \(MDTP\) at HMRC. At its peak, we had eight Digital Platform teams in London, and 50+ Digital Service teams in five delivery centres across the country. 34 | 35 | We had to strike a balance between listening to the Digital Service teams’ needs, understanding how many Digital Services would benefit from a new platform feature, and occasionally guiding the teams to a different solution if MDTP couldn’t accommodate them. 36 | 37 | We used a range of techniques: 38 | 39 | * We ran regular feedback surveys. We asked Digital Service teams what they thought of MDTP and of their relationship with us as the Digital Platform teams. The first few were uncomfortable for us to read, but as we responded and improved, it got easier. 40 | * We travelled out to the delivery centres regularly. This allowed us to shift into being allies rather than just a group of names on Slack. 41 | * We listened when Digital Service teams had good ideas on what we needed on MDTP. One Digital Service team created a one-click button to create a standard HMRC Digital Service from scratch. We helped them develop it further, then rolled it out as part of MDTP. 42 | * We wrote blog posts advertising new MDTP capabilities, and guidance on how to use the new features. This helped to keep people in the loop about new features coming down the line. 43 | * We trialled new MDTP features with key Digital Service teams in different delivery centres. At one point, we had Digital Service teams approaching us and asking to be part of the trials. We found that people had started to feel some ownership of MDTP, along with us 44 | 45 | ![Beccy Stafford](.gitbook/assets/beccystafford.png) 46 | {% endtab %} 47 | {% endtabs %} 48 | 49 | -------------------------------------------------------------------------------- /practices/teams.md: -------------------------------------------------------------------------------- 1 | # Teams 2 | 3 | ## Prime Digital Platform teams for success 4 | 5 | It’s important that Digital Platform teams are set up for success like any Digital Service team. We recommend the following roles for a new Digital Platform team: 6 | 7 | * A product manager. Works across the organisation, talks to potential users to win hearts and minds, and drives the direction of the Digital Platform. Experience in product development and experimentation is more important than a technical background. 8 | * A delivery lead. Steers team ways of working and encourages a culture of learning and experimentation. 9 | * A technical analyst. Helps the team to slice and dice work items into appropriate sizes. 10 | * 3 x platform engineers. Develop platform capabilities, foster bi-directional feedback loops with Digital Service teams, and provide advice on how to use the Digital Platform. 11 | 12 | This is a recommendation, not a rule. You might need to start out with a smaller team for funding reasons. In that situation, a single person could fill the product manager and delivery lead roles, or delivery lead and technical analyst. It’s important such an accommodation is time limited, to guard against burnout. 13 | 14 | ## Expand Digital Platform teams 15 | 16 | We’ve found the number of Digital Platform teams and their team members needs to gradually increase, as the number of Digital Services increases. We recommend increasing the number of platform engineers, and splitting the Digital Platform team, when you have at least five Digital Service teams. We advocate a division of Digital Platform teams based on your platform capabilities, based on which of them need the most investment at that time. 17 | 18 | We also suggest the following team roles: 19 | 20 | * An architect. Steers technology choices, and teaches Digital Service teams how to steer those choices for themselves. 21 | * A tech writer. Creates consistent, coherent documentation guides for Digital Service teams. 22 | * A user researcher. Helps Digital Platform teams create user personas for Digital Service team members, and steers user experience interviews. 23 | 24 | These additional roles might be combined with some platform engineers into a Platform Enablement team, dedicated to accelerating Continuous Delivery and Operability across the Digital Service teams via productivity tooling. Alternatively, these roles might be folded into existing Digital Platform teams. 25 | 26 | Scale Digital Platform teams based on platform capabilities and the amount of bi-directional feedback loops with Digital Service teams. This increased cost for the Digital Platform must be included in funding discussions, in order to avoid a loss in utility of the Digital Platform. 27 | 28 | For example, a Digital Platform team with a product manager, a delivery lead, a technical analyst, and three engineers. As the number of Digital Services grows, an architect and two more engineers are added. At that point, the delivery lead decides the teams need to split. The product manager decides cloud infrastructure and telemetry are the priorities for the next three months, so those are the two new Digital Platform teams. 29 | 30 | ![Service Team growth driving growth and reorganisation in the platform team around capabilities provided to the Service Teams](../.gitbook/assets/expanding-platform-teams.png) 31 | 32 | ## Whole Digital Platform funding 33 | 34 | Funding for the Digital Platform needs to be continuous, multi-year, and come from a single budget holder accountable for Digital Platform success. 35 | 36 | The two most common Digital Platform expenses are team costs \(team member salaries\) and cloud provider costs \(e.g. AWS EKS bill\). We’ve seen situations where those costs are paid from two different budgets, which causes unnecessary complications: 37 | 38 | * Part-funding of some Digital Platform team members by other operational teams increases key person dependencies 39 | * Part-funding of some Digital Platform teams by a particular Digital Service team reduces product manager accountabilities and causes prioritisation conflicts 40 | * Part-funding of all Digital Platform teams by a particular Digital Service team jeopardises Digital Platform independence and creates warped incentives 41 | 42 | Ideally, the single budget holder is the Digital Platform product manager, as a peer of Digital Service product managers. 43 | 44 | {% tabs %} 45 | {% tab title="EMEA payments provider example" %} 46 | At an EMEA payments provider, we started with a Payment Gateway service, with the vision of building a Digital Platform to host and provide other payment services. We invested time in building telemetry tools, which were embedded into the Digital Platform itself. 47 | 48 | Within a year, we had a Digital Platform where developers were able to roll out new Digital Services services with minimal help from the Digital Platform team. Newly onboarded teams were able to launch new payment services into production in less than a week. 49 | 50 | These practices helped us: 51 | 52 | * Strong deployment pipelines encouraged teams to deploy frequently. 53 | * Deployment dashboards helped teams get feedback on their deployment frequency. 54 | * Embedded telemetry meant teams could debug and analyse payment abnormalities within the Digital Platform or external integration partners within minutes 55 | * Deep integration of incident management tools into Slack reduced context switching and helped teams to collaborate. 56 | * Feature toggle based development ensured teams kept deploying services that were decoupled from business processes 57 | 58 | ![Anant Pal](../.gitbook/assets/anantpal.jpeg) 59 | {% endtab %} 60 | {% endtabs %} 61 | 62 | -------------------------------------------------------------------------------- /introduction/when-to-start-a-digital-platform.md: -------------------------------------------------------------------------------- 1 | # When to start a Digital Platform 2 | 3 | We’ve established criteria below for starting a Digital Platform. These are the minimum criteria that need to be met, before funding is allocated and development work begins. We recommend you revisit these criteria once a quarter in your first year, and once a year after that. This will help you to understand the target architecture of your Digital Platform, and continuously validate the vision for your Digital Platform. 4 | 5 | 1. Multi-year funding 6 | 2. Homogeneous workload 7 | 3. At least one Digital Service team at outset 8 | 4. Empowered teams 9 | 5. Potential for five Digital Service teams 10 | 11 | ## Multi-year funding 12 | 13 | A Digital Platform is a significant investment. It's a strategic asset rather than a cost-cutting liability. It's funded as a product. 14 | 15 | Multi-year funding is a positive signal of a commitment to continuous improvement. Without that commitment, your Digital Platform teams will not be able to redesign platform capabilities to satisfy changing user needs, or leverage new commodity cloud services to reduce costs. 16 | 17 | ## Homogeneous workload 18 | 19 | A Digital Platform is based on a homogeneous workload, created by multiple Digital Services. If different Digital Services have heterogeneous workloads, your Digital Platform teams will be slower to deliver new features. They will have to seek consensus between different Digital Service teams on which platform capabilities need to be enhanced. The user experience for Digital Service teams will be diminished. 20 | 21 | For example, a Digital Platform could support Kotlin microservices and React frontends. A team might ask for data pipelines to be supported as an additional workload type, for a one-off Digital Service. That request would be politely declined by the Digital Platform teams, and there would be a collaborative effort to find an alternative solution outside the Digital Platform. 22 | 23 | ## At least one Digital Service team at outset 24 | 25 | A Digital Platform starts with a minimum of one Digital Platform team and one Digital Service team. This means the first bi-directional feedback loop can be established between teams, and the initial platform features can be quickly validated. 26 | 27 | Your first Digital Service team needs to have completed its [inception](https://inception.playbook.ee/) phase. This ensures the Digital Service workload is sufficiently well understood to begin construction of the Digital Platform. Otherwise, the delivery of new platform features will be slowed down, due to the rework needed to focus on a different workload type. 28 | 29 | A Digital Platform team that starts out without a Digital Service team will fall into the [Premature Digital Platform Team pitfall](https://digital-platform.playbook.ee/pitfalls#premature-digital-platform-team). 30 | 31 | ## Empowered Teams 32 | 33 | A Digital Platform exists in an ecosystem in which Digital Platform teams are free to make their own technology choices. They need to work independently of any pre-approved tools, so they can experiment with new technologies that meet the particular needs of the Digital Service teams. 34 | 35 | In a similar vein, Digital Service teams have freedom within the Digital Platform ecosystem. The Digital Platform teams build platform capabilities with sensible defaults, and Digital Service teams can configure them as necessary. 36 | 37 | There needs to be some pragmatism. Digital Platform and Digital Service teams need to include pre-existing tools when exploring problems. However, the people best suited to make decisions are those closest to the work, and they must not be beholden to an old list of ill-suited technologies. 38 | 39 | ## Potential for five Digital Service teams 40 | 41 | A Digital Platform has multi-year funding linked to a recognition that at least five Digital Service teams are likely to exist in the future. In other words, there needs to be sufficient product demand for at least five distinct Digital Services within your organisation. From our experience of building Digital Platforms with multiple organisations, we believe this is the tipping point at which strategically investing in a Digital Platform is beneficial. 42 | 43 | If there is zero potential for five or more Digital Service teams, we don’t believe a Digital Platform is the right approach. You won’t achieve the economies of scale to validate the multi-year funding. A better approach would be to invest funding and resources directly into your handful of teams, ensuring they can build and operate their services. 44 | 45 | {% tabs %} 46 | {% tab title="O2 Priority experience" %} 47 | O2 Priority is a popular customer loyalty service, and in 2016, it lacked the operational capacity to meet demand. I joined the team with the primary goal of building a new scalable service. We used many of the practices mentioned in this playbook, but we didn't need a full-blown Digital Platform because we only had a single service team. 48 | 49 | Work happened in phases, including automated infrastructure with observability built in, and automated deployment pipelines. These capabilities set the foundation for seamless migration of O2 Priority. The service team went from a deployment frequency of fortnightly to daily, and from an MTTR of days to three hours. 50 | 51 | Looking back, I believe our success was due to: 52 | 53 | * commitment and support from our primary stakeholders 54 | * autonomy to build and run the scalable service using the best tools and technologies available 55 | * feedback from the service team and building to their requirements 56 | * investing in observability and telemetry dashboards 57 | 58 | The benefit to O2 was significant – they increased their ability to create and run loyalty campaigns better targeted to their customers. 59 | 60 | ![Ogonna Iwunze](../.gitbook/assets/ogonnaiwunze.jpg) 61 | {% endtab %} 62 | {% endtabs %} 63 | 64 | -------------------------------------------------------------------------------- /pitfalls.md: -------------------------------------------------------------------------------- 1 | # Pitfalls 2 | 3 | Here’s a list of some of the pitfalls we’ve experienced when building Digital Platforms in partnership with various clients. We’d encourage you to avoid the scenarios listed below. 4 | 5 | ## On-premise Digital Platform 6 | 7 | We’ve worked with several clients who tried to build a bespoke Platform as a Service on premises, as a means to leverage an investment in existing on-premises data centres. It’s proven to be a false economy every time. 8 | 9 | Compared to a cloud provider, an on-premise data centre will suffer from: 10 | 11 | * Slower capability delivery. Creating bespoke capabilities on top of low-level data centre abstractions will take weeks or months longer than in a public cloud. 12 | * Less scalability. One-off, inelastic provisioning that is scaled for irregular peak traffic flows is cumbersome, and expensive. 13 | * Higher maintenance costs. Maintaining and upgrading servers on a regular basis takes time away from platform feature development. 14 | * Higher operational costs. Covering data centre costs such as compute, energy bills, and staffing is expensive. 15 | 16 | The costs associated with managing an on-premise Digital Platform can be exponentially higher than a Cloud Digital Platform. We strongly recommend the use of AWS, Azure, or GCP to underpin a Digital Platform. 17 | 18 | ## Premature Digital Platform team 19 | 20 | We’ve seen well-intentioned organisations start a Digital Platform without a Digital Service team as a first user. A Digital Platform team working in a vacuum can spend weeks or months on platform capabilities with no stated needs from Digital Service teams. As a result, future Digital Service teams have to go their own way, without the economies of scale produced by a Digital Platform built in close consultation with Digital Service teams. 21 | 22 | A Digital Platform team that lacks a Digital Service team can’t form any bi-directional feedback loops. It can’t understand the needs of its users, can’t set a direction for platform capabilities, and can’t validate the platform features that it builds. It’s just building automated infrastructure. This is why we believe [at least one Digital Service team at the outset](https://digital-platform.playbook.ee/introduction/when-to-start-a-digital-platform) as part of the startup criteria for a Digital Platform. 23 | 24 | ## Multi-instance Digital Platform 25 | 26 | In some organisations, each Digital Service team runs their own instance of the Digital Platform, built by a central Digital Platform team. A Digital Platform team member may be embedded in each Digital Service team. Over time, this creates a Digital Platform ecosystem with significant operational costs and major challenges in culture, recruitment, and deploying updates to multiple instances of the Digital Platform. 27 | 28 | Splitting Digital Platform team members between Digital Service teams will divide their focus, leading to large amounts of rework and duplication. As the number of Digital Service teams grows, it will prove difficult to recruit a Digital Platform engineer for each Digital Service team. 29 | 30 | We prefer to have one instance of a Digital Platform run for all Digital Service teams by the Digital Platform teams. We believe this is the most effective way for Digital Platform and Digital Service delivery to happen in parallel. It makes it easier for Digital Platform team members to share knowledge and quickly respond to problems. 31 | 32 | This does mean the Run A Service platform capability needs to ensure Digital Services are partitioned as much as possible to minimise failure blast radius. Partitioning might need some configuration \(e.g. [AWS EKS namespacing\)](https://aws.amazon.com/eks/), or it might come by default \(e.g. [GCP Cloud Run\)](https://cloud.google.com/run/). 33 | 34 | ## Proprietary library hell 35 | 36 | A deployment pipeline will often include an artifact repository to host proprietary libraries, and a container image repository to host release candidates. A container image repository is essential for a container-based Run A Service capability. An artifact repository is not essential. 37 | 38 | An artifact repository can encourage Digital Service teams to extract business logic and/or infrastructure logic into proprietary libraries. Over time, it gradually leads to [dependency hell](https://en.wikipedia.org/wiki/Dependency_hell) at scale, in which deployments are delayed by days or weeks due to painful library dependency changes. 39 | 40 | As an alternative, we’d suggest Digital Platform teams produce a zero-friction Create a Service capability instead of an artifact repository. This will encourage Digital Service teams to produce more runnable monoliths or microservices, instead of proprietary libraries. They can still publish multi-consumer infrastructure logic as open-source libraries, albeit with a separate and entirely independent toolchain. 41 | 42 | ## Industrialised End-To-End Testing 43 | 44 | We’ve worked with many clients to decrease their reliance on automated [End-To-End Testing](https://www.stevesmith.tech/blog/end-to-end-testing-considered-harmful/) in test environments. Continuous Delivery can’t be achieved when a production deployment requires days or weeks of functional testing with third-party systems. 45 | 46 | If a Digital Platform allows Digital Service teams to self-provision unconstrained test environments, it’s easy for Digital Service teams to lapse into functional testing with third parties. As test execution times and determinism are inversely proportional to test scope, such an industralisation of End-To-End Testing makes Continuous Delivery very unlikely. 47 | 48 | We recommend the following instead: 49 | 50 | * Digital Platform teams produce high quality monitoring and alerting in production, and circuit breakers on the wire. 51 | * Digital Service teams are incentivised to monitor live interactions with third parties, and gracefully degrade their services when necessary. 52 | * Digital Platform teams create a curated pipeline with minimal test environments, such as a stubs environment with no end points for automated tests and an integration environment with third-party end points for exploratory testing only. 53 | * Digital Service teams are encouraged to think of live monitoring of third parties as a superior alternative to End-To-End Testing. 54 | 55 | -------------------------------------------------------------------------------- /introduction/what-is-a-digital-platform.md: -------------------------------------------------------------------------------- 1 | # What is a Digital Platform 2 | 3 | At Equal Experts, we define a **Digital Platform** as follows: 4 | 5 | > A Digital Platform is a bespoke Platform as a Service \(PaaS\) product composed of people, processes, and tools, that enables teams to rapidly develop, iterate, and operate Digital Services at scale. 6 | 7 | A Digital Platform will allow your organisation to accelerate its time to market, increase revenue, reduce costs, and create innovative products for your customers. 8 | 9 | A Digital Platform is: 10 | 11 | * _Differentiating_. It empowers your teams to concentrate on solving real business problems by abstracting away organisational complexities and toil. 12 | * _A product._ It’s built incrementally by incorporating feedback from your teams. It accelerates the delivery of Digital Services. It's enduring. 13 | * _Opinionated_. It makes it easy for your teams to build, deploy, and operate Digital Services by providing a curated set of high quality building blocks. 14 | 15 | A Digital Platform is also: 16 | 17 | * _Not a commodity_. It cannot be bought off the shelf, as it must satisfy the specific needs of your organisation. It’s built by weaving together open-source and bespoke commodity tools to create a technology accelerator. 18 | * _Not a project._ It isn’t a one-off development with a fixed end date. It needs to keep changing, as the needs of your teams will change based on their customers’ demands. 19 | * _Not a universal infrastructure platform_. It cannot run all cloud services for all possible consumers without weakening the proposition. It needs to focus on a subset of cloud services to support Digital Service workloads. 20 | 21 | It’s important to remember that a Digital Platform isn’t a silver bullet. It’s a long-term commitment to Digital Services at scale. It’s not appropriate for all workloads, teams, or organisations. For more on this, see [when to start a Digital Platform](https://digital-platform.playbook.ee/introduction/when-to-start-a-digital-platform). 22 | 23 | A **Digital Service** is a software service designed to fulfil a product capability and run on a Digital Platform. Such a service might be a monolith, or composed of multiple microservices. It’s usually based on modern software development principles, such as [12 Factor](https://12factor.net/) or [Secure Delivery](https://secure-delivery.playbook.ee/). It's owned by a single Digital Service team responsible for understanding its customers, and producing a service that meets their needs. 24 | 25 | Here’s a services diagram of a fictional Digital Platform in a retail organisation. It shows eight Digital Services in development within two different retail domains, as well as six platform capabilities within the Digital Platform itself. 26 | 27 | ![Digital Services on a Digital Platform](../.gitbook/assets/digital-platform-services.png) 28 | 29 | ## Bespoke 30 | 31 | A Digital Platform is bespoke. It’s something unique, built solely for the Digital Service teams in your organisation. It’s founded on custom building blocks made by your Digital Platform teams, and commodity cloud services from your public cloud. It’s about people, processes, and tools coming together to form platform capabilities. A public cloud can’t provide you with a Digital Platform out of the box. Nor can an off the shelf product from a vendor. 32 | 33 | There are many advantages and opportunities that come with a public cloud as a foundation for a Digital Platform. An [on-premise Digital Platform](https://digital-platform.playbook.ee/pitfalls#on-premise-digital-platform) is a significant pitfall that should be avoided wherever possible. 34 | 35 | ## Paved Road 36 | 37 | A Digital Platform is a set of [Paved Roads](https://www.oreilly.com/library/view/oscon-2017-/9781491976227/video306724.html). Each Paved Road consists of low-friction, hardened interfaces that comprise user journeys for Digital Service teams \(e.g. build a service, deploy a service, or service alerts\). Those paved user journeys are fully automated and encompass the learned best practices specific to your organisation. 38 | 39 | A Paved Road is built incrementally by Digital Platform teams. Each platform capability is delivered in small increments, and adjustments are made based on user feedback. Over time, as each platform capability becomes more opinionated, the Paved Road becomes wider and longer. [Enabling constraints](https://theitriskmanager.com/2018/12/09/constraints-that-enable/) are used to encourage frequent production deployments and high standards of reliability for long-lived Digital Services. 40 | 41 | A Paved Road eliminates common failure modes, by automating repetitive tasks. It encourages the adoption of Continuous Delivery and Operability practices, such as constant monitoring of live traffic, and steers away from pitfalls such as [End-To-End Testing](https://digital-platform.playbook.ee/pitfalls#industrialised-end-to-end-testing). It challenges Digital Service teams to rethink how they approach particular problems, and contribute enhancements and features back into the Paved Road experience. 42 | 43 | ## Bi-directional feedback 44 | 45 | A Digital Platform is primarily about the people who build it and use it. It exists to satisfy its users’ needs, through technical or non-technical means. The value of its capabilities is derived from the ability of its Digital Platform teams to talk to and learn from its Digital Service teams. It’s the responsibility of the Digital Platform teams to create an ecosystem of bi-directional feedback loops. User feedback allows Digital Platform teams to better understand which technology building block or organisational process needs to be improved, and industrialised so that all teams can benefit. 46 | 47 | For example, feedback from your Digital Service teams might include complaints about a historical, time-consuming change-approvals process in your organisation owned by an overworked change management team. Your Digital Platform needs to provide an automated deployment pipeline that acts as an automated audit trail. If your Digital Platform teams can present a live audit trail that reduces toil for the change management team, their needs might be met by a streamlined, self-service process, in which Digital Service teams peer-review their own change requests. 48 | 49 | {% tabs %} 50 | {% tab title="EMEA payments provider experience" %} 51 | When we built a Digital Platform at an EMEA payments provider, our Digital Service teams reported the change approvals process was a painful bottleneck. It was a manual process via email, with lots of review and sign-off steps. The process existed to provide security and ensure the organisation maintained its PCI DSS compliance. 52 | 53 | We worked with the change management team to understand what was needed to give the same assurance as the manual process. Jira tickets were automatically linked to code changes, and auditing was added to ensure complete traceability for deployments. We even included an automated post-deploy email for change reconciliation. The change management team trusted the new process, and agreed to a much simpler, more traceable change process. The collaboration removed a big source of friction for everyone, without compromising important compliance processes. 54 | 55 | ![Dave Hewett](../.gitbook/assets/davehewett.png) 56 | {% endtab %} 57 | {% endtabs %} 58 | 59 | -------------------------------------------------------------------------------- /practices/paved-road.md: -------------------------------------------------------------------------------- 1 | # Paved Road 2 | 3 | ## Pave the pain points 4 | 5 | It’s difficult to know in which order to add platform capabilities to the Paved Road. An entire user journey such as Test A Service could be paved in one go, resulting in a long and narrow Paved Road that gradually widens. Alternatively, different parts of different user journeys could be paved, producing a short and wide Paved Road that gradually lengthens. 6 | 7 | It’s also difficult to know how much of a platform capability needs to be paved – that is, how much the Digital Platform teams will manage centrally versus how much the Digital Service teams will manage for themselves. More central management means more paving and less boilerplate for Digital Service teams, which can produce tangible benefits: 8 | 9 | * Digital Service teams are freed up to concentrate on Digital Service business logic 10 | * Consistent patterns for builds, testing, monitoring, and alerting can all be rolled out 11 | * The cognitive load for new joiners and movers between Digital Service teams is much lower 12 | * Digital Platform teams are able to silently and rapidly roll out updates 13 | 14 | On the other hand, more central management also means: 15 | 16 | * The technical quality of the Digital Platform has to be of a very high standard, otherwise Digital Service teams are likely to perceive it as a constraint 17 | * Digital Service teams can be unhappy if they have little say in the processes and tooling that comprise their user journeys 18 | 19 | This is why user feedback and experimentation is so important, as with any product development. Digital Platform teams that run small, frequent experiments on platform capabilities, powered by their own hypotheses and user feedback from Digital Service teams will quickly learn which capabilities will be most beneficial. Prioritising the paving of the biggest pain point for a majority of Digital Service teams at that point in time will help all of those teams. 20 | 21 | For example, the Run A Service capability might begin with an opinion that all code must be Kotlin. This would result in a centrally automated Docker image containing a Java Virtual Machine \(JVM\) instance, configured for Kotlin. Over time, the opinions behind Run A Service might include a particular database, a web framework, a metrics pipeline, and more. 22 | 23 | A Paved Road needs to be adaptable. It depends on a malleable platform architecture, with well-defined and testable boundaries for Digital Service teams. Raw cloud services from the cloud provider need to be leaked out in a controlled way, based on where Digital Platform abstractions cannot create additional value and where lock-in switching costs are low. 24 | 25 | ## Intentional friction as guard rails 26 | 27 | Building a Digital Platform is about removing friction from paved user journeys, on behalf of Digital Service teams. At times, that also means adding intentional friction away from the Paved Road, to discourage Digital Service teams from adopting suboptimal practices. 28 | 29 | It’s likely a majority of Digital Service team members won’t have worked on a Digital Platform before, won’t be familiar with Continuous Delivery practices, and won’t have operated a live customer-facing service before. It’s important that guardrails be established to reinforce the opinionated nature of the Digital Platform, and point Digital Service teams towards success. 30 | 31 | Recommendations we’ve incorporated into Digital Platforms include the following: 32 | 33 | * Don’t install a repository for proprietary libraries. This discourages the sharing of internal libraries between teams, and avoids the [proprietary library hell pitfall](https://digital-platform.playbook.ee/pitfalls#proprietary-library-hell) 34 | * Don’t permit automated end-to-end tests in a test environment. This discourages reams of functional end-to-end tests, and avoids the [Industrialised End-To-End Testing pitfall](https://digital-platform.playbook.ee/pitfalls#industralised-end-to-end-testing) 35 | 36 | It may take time for Digital Service teams to understand the purpose of intentional friction. It’s important for Digital Platform teams to engage with Digital Service teams, so they understand the purpose of intentional friction and can offer feedback. 37 | 38 | ## Design for optional Digital Service upgrades 39 | 40 | Inevitably, some enhancements to Digital Platform capabilities will require corresponding updates in at least one Digital Service. 41 | 42 | Update frequency will depend on the quality of those capabilities, and the amount of central management in your [Paved Road](https://digital-platform.playbook.ee/practices/paved-road#pave-the-pain-points). The onus is on Digital Platform teams to build high quality platform capabilities that rarely require Digital Service teams to make changes themselves. Low-quality platform capabilities and little central management could mean Digital Service teams have to perform regular updates. 43 | 44 | Digital Services updates can be designed as either mandatory migrations, or optional upgrades. Mandatory migrations on short timelines can frustrate Digital Service teams, who will have their own delivery timelines to satisfy. Bi-directional feedback loops and trusted relationships can be sorely tested. 45 | 46 | We’ve learned that optional upgrades with longer timelines are less painful for all concerned. The Digital Platform teams need to do as much work as possible without the Digital Service teams. When Digital Service teams need to make changes themselves, it’s the responsibility of the Digital Platform teams to design an optional upgrade framed with compelling benefits for the Digital Service teams. An optional upgrade needs to include a step-by-step upgrade guide, a list of any upgrade dependencies, and a clear offer of assistance. 47 | 48 | ## Enable You Build It You Run It 49 | 50 | Our [accelerate Continuous Delivery and Operability principle](https://digital-platform.playbook.ee/principles#accelerate-continuous-delivery-and-operability) means curated processes on a Digital Platform are clearly opinionated in favour of Continuous Delivery and Operability for all Digital Service teams. 51 | 52 | The production support method of You Build It, You Run It (YBIYRI) refers to developers supporting their own production services. You Build It You Run It unlocks weekly or more frequent deployments for Digital Service teams, as it eliminates any operational handoffs. It also incentivises Digital Service teams to balance their time between product and operational features. The net result is more frequent production deployments, and more reliable live services. To find out more about YBIYRI, read the [You Build It, You Run It playbook](https://you-build-it-you-run-it.playbook.ee/) 53 | 54 | A Digital Platform can be used to promote this practice. Digital Platform teams need to create platform capabilities that make it as easy as possible for Digital Service teams to own, build and run their Digital Services without interventions. Digital Service teams will respond positively to the challenge of operating live services. Digital Platform teams only support their own platform capabilities. 55 | 56 | Organisational pressure may exist on a Digital Service or Digital Platform team to increase throughput. Empowering that team to reorganise itself can help it to cope with demand. One option would be to slice the team in two, based on product needs. 57 | 58 | -------------------------------------------------------------------------------- /introduction/benefits-of-a-digital-platform.md: -------------------------------------------------------------------------------- 1 | # Benefits of a Digital Platform 2 | 3 | A Digital Platform provides the following benefits: 4 | 5 | ## Faster innovation 6 | 7 | * Faster time to launch. Automating and abstracting cloud setup and simplifying governance processes means a new Digital Service can be launched to customers within days. 8 | * Frequent updates. Creating an optimal deployment pipeline allows customer experiments in a Digital Service to be updated on at least a daily basis. 9 | * Increased focus on business problems. Institutionalising new policies that cross-cut departments means uncoordinated and/or duplicated processes can be eliminated, and people can focus on higher value work. 10 | * More business model opportunities. Friction-free, rapid launches of Digital Services allow an organisation to separate its differentiating business functions from utilities and to quickly trial different business models in new marketplaces. 11 | 12 | ## Higher quality 13 | 14 | * Fewer environmental issues. Automating configuration and infrastructure lowers the potential for environment-specific problems. 15 | * More deterministic test results. Centralising automated test executors reduces opportunities for nondeterminism in test suites. 16 | * Faster rollback. Creating an effective rollback system with health checks means deployment failures can be fixed quickly. 17 | 18 | ## Increased reliability 19 | 20 | * More operable services. Providing logging, monitoring, and alerting out of the box increases the operability of Digital Services, and helps users to quickly discern abnormal operating conditions. 21 | * Graceful degradation. Implementing circuit breakers and bulkheads on the wire for third-party systems allows Digital Services to gracefully degrade on failure. 22 | * Improved business continuity. Automating the entire platform infrastructure in the cloud creates new business continuity options. 23 | 24 | ## Improved security 25 | 26 | * Rapid adoption of [security testing tools and techniques](https://secure-delivery.playbook.ee/). The [paved road](https://digital-platform.playbook.ee/introduction/what-is-a-digital-platform#paved-road) eases and promotes adoption of security tools, helping Digital Service teams identify and fix security issues before they reach production. 27 | * Improved security assurance. Standardised tooling allows security assurance to be embedded into the platform, allowing security policies to be defined in code and validated against infrastructure and applications both prior to deployment and continuously at runtime. 28 | * Reduced security engineering overhead. Common security activities \(e.g. continuous vulnerability scanning\) and features \(e.g. secrets management\) are provided as platform features, allowing Digital Service teams to focus on the customer and their specific domain. 29 | * Improved security operations. Centralised telemetry supports security monitoring and alerting within the Digital Platform, providing first responders access to all relevant information when managing security incidents. 30 | * Improved security governance. The [services catalogue](https://digital-platform.playbook.ee/introduction/capabilities-of-a-digital-platform#services-catalogue) increases visibility and promotes security as a first-class citizen of the Digital Platform. This enables Digital Service teams to be accountable for the security of their service, while providing oversight to security governance teams. 31 | 32 | ## Improved ways of working 33 | 34 | * Policy experimentation. Cutting across departments means new policies can be forged in [inceptions](https://inception.playbook.ee/), [Chaos Day testing](https://chaos-day.playbook.ee/), [secure delivery](https://secure-delivery.playbook.ee/), and more. 35 | * Drive new practices. Creating [enabling constraints](https://theitriskmanager.com/2018/12/09/constraints-that-enable/) in user journeys can drive the adoption of new practices, such as restricting shared libraries to encourage decoupled domains for Digital Services. 36 | * Simpler processes. Establishing meaningful Service Level Objectives with an automated alerting toolchain can make You Build It You Run It production support easier to set up. 37 | 38 | ## Advanced technology 39 | 40 | * Use the best available technologies. Standardising cloud building blocks means the best available technology stack can be provided to Digital Service teams. 41 | * Traffic optimisations. Surfacing self-service, elastic infrastructure means Digital Service teams can easily optimise for fluctuating traffic patterns without significant costs. 42 | * Zero downtime updates. Consolidating service runtimes means functional updates can be continually applied with zero downtime for Digital Services. 43 | 44 | ## Reduced costs 45 | 46 | * Economies of scale. Centralising the Digital Service lifecycle means economies of scale can be achieved, as more Digital Service teams can be added without incurring repeat buy/build costs. 47 | * Easier cost management. Centralising self-service touchpoints for automated infrastructure allows infrastructure costs to be visualised and closely managed. 48 | * Positioning security specialists in the Digital Platform teams means security threats can be more easily identified and Digital Services can quickly receive security updates. 49 | 50 | ## Happier, more productive people 51 | 52 | * Lower cognitive load. Abstracting away the Digital Service lifecycle reduces your staff’s cognitive load, reducing lead times to less than 24 hours for a new joiner, a mover between teams, a leaver, or a new Digital Service team. 53 | * Easier to identify talent needs. Splitting business domains into Digital Services helps to highlight which domains are true business differentiators and require the most talented engineers. 54 | * Increased talent attractors. Using the latest cloud technology on Digital Platform and Digital Service teams will encourage talented engineers to join your organisation. 55 | * More recruitment options. Concentrating specialist skills in Digital Platform teams means recruitment efforts for Digital Service teams can focus on onshore/offshore developers, testers, etc. without requiring more costly, specialised cloud skills. 56 | 57 | {% tabs %} 58 | {% tab title="HMRC experience" %} 59 | COVID-19 caused rapid, dramatic changes in society. Within weeks, the UK tax authority HMRC delivered the following Digital Services on its Multichannel Digital Tax Platform \(MDTP\), on tight deadlines and with user demand at levels never seen before: 60 | 61 | * Job Retention Scheme 62 | * Self-Employed Income Support Scheme 63 | * “Eat Out To Help Out” 64 | * Statutory Sick Pay for COVID-19 65 | 66 | Digital Service teams used the MDTP Paved Road to solve these business problems from day one. The teams were deploying services into production within days, resulting in early feedback from real users. 67 | 68 | Policies changed rapidly, allowing teams to iterate on the Digital Services just as quickly. Governance, best practice, and the right levels of abstraction baked into MDTP meant the teams were not risking any new technology problems or security concerns that might delay delivery. 69 | 70 | Each Digital Service interacted with new and old third-party dependencies. Digital Service teams leveraged existing, well-defined interfaces to old systems, and the Digital Platform teams quickly added the new systems as platform capabilities. 71 | 72 | When the Digital Services were publicly launched, the Digital Service teams monitored service behaviours under immense loads, and were able to perform updates within minutes as the reality of user behaviours unfolded. 73 | 74 | The authors of this playbook emphasise the importance of culture in a Digital Platform ecosystem, and at HMRC, the collaboration between Digital Platform and Digital Service teams was our foundation. Teams were able to run at high speed, based on existing relationships and collaboration tools. 75 | 76 | A Digital Platform is never done. In the exceptional circumstances of COVID-19, Digital Platform and Digital Service teams worked side by side, and closer together than ever before. 77 | 78 | ![Kulvinder Singh](../.gitbook/assets/kulvindersingh.jpeg) 79 | {% endtab %} 80 | {% endtabs %} 81 | 82 | -------------------------------------------------------------------------------- /introduction/capabilities-of-a-digital-platform.md: -------------------------------------------------------------------------------- 1 | # Capabilities of a Digital Platform 2 | 3 | A Digital Platform capability combines people, processes, and/or tools. It's provided by a Digital Platform team, to accelerate Digital Service teams. 4 | 5 | A capability such as “Deploy A Service” should be self-service. A Digital Service team must be able to provision, configure, and manage a capability themselves. It’ll encourage your Digital Service teams to be accountable for outcomes associated with their Digital Service. Digital Platform teams can provide sensible defaults out of the box, which Digital Service teams can modify themselves when appropriate. 6 | 7 | The most common Digital Platform capabilities and the corresponding features that could be reasonably expected are listed below. This list isn’t exhaustive, and it isn’t prioritised. Your Digital Platform might need more or fewer of these capabilities, to meet the needs of your Digital Service teams. 8 | 9 | ## Create a team 10 | 11 | * Public cloud authentication and authorisation set up. 12 | * Incident email group set up. 13 | * Single sign-on to all tooling for team members. 14 | 15 | ## Create a service 16 | 17 | * Code repositories set up in version control, with default memory settings etc. 18 | * Selected availability target defined in production alerts and monitoring dashboards. 19 | * Selected deployment target defined in monitoring dashboards. 20 | * Runbook set up in version control, with code repository locations. 21 | * Incident reviews template set up in version control, with team member names and code repository locations. 22 | 23 | Reducing the barrier to creating a service \(that is preset with sensible default values\) enables service teams to focus on delivering value for their users rather than working to matching operability parity with the existing services. 24 | 25 | ## Build a service 26 | 27 | * One click provisioning of curated cloud commodities, such as asynchronous messaging and databases. 28 | * Curated build jobs set up, with opinionated defaults such as 5 min timeouts. 29 | * Container vulnerability scanner configured for container image repository. 30 | * Dependency vulnerability scanner configured for code repositories. 31 | 32 | ## Deploy a service 33 | 34 | * Deployment pipeline of curated environments, with a few environments named by intent. 35 | * Curated deployment jobs setup, with auto-deploy on successful build and auto-rollback on failed deployment health checks. 36 | 37 | ## Test a service 38 | 39 | * Stubbed dependencies and test executors, for automated functional tests. 40 | * Hosted contract testing broker available, or examples of how to setup contract testing in a pipeline 41 | * Predefined load profiles and test executors, for automated load tests. 42 | * Predefined user journeys and test executors, for post-deployment smoke tests. 43 | * Predefined fault injection scenarios and test executors, for Chaos Days and automated chaos testing. 44 | 45 | ## Launch a service 46 | 47 | * Operability assessments, with automated checks and exploratory questions for leading and trailing indicators of operability. 48 | * Automated change requests, and a publicly available read-only audit trail. 49 | * Blue-Green deployments or Canary Deployments for incremental rollouts. 50 | * Dark Launching via feature toggles for customer A/B testing. 51 | * Automated configuration of on-call rota for team members 52 | 53 | ## Run a service 54 | 55 | * Service compute available, such as container orchestrator or functions runtime. 56 | * Vertical and/or horizontal scaling of compute configured for service. 57 | * Checks on release candidate signatures from container image repository. 58 | * Caching on the wire between services, and before downstream dependencies. 59 | * Circuit breakers on the wire between services, and before downstream dependencies. 60 | * Automated database operations, such as migrate schema and database restore. 61 | * Networking functions, such as edge proxies and DNS resolution. 62 | 63 | ## Service logging 64 | 65 | * Structured logging pipeline from service runtime to logs storage. 66 | * Curated logging dashboards showing service traffic and downstream dependencies. 67 | 68 | ## Service monitoring 69 | 70 | * Metrics pipeline from service runtime to metrics storage. 71 | * Service request tracing 72 | * Curated monitoring dashboards showing the [Four Golden Signals](https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals), availability targets, and deployment targets. 73 | 74 | Implementing standardised-but-extendable metrics, dashboards, and alerts for all the services on a platform provides several benefits: 75 | 76 | * reduce the cost of context switching for service team members when working across multiple services 77 | * greater effiency as not every team has to re-invent the wheel to monitor their service 78 | * teams get a basic level of monitoring for free, and can then be encouraged to further customise their service's dashboards to provide richer information 79 | 80 | ## Service alerting 81 | 82 | * Alerts pipeline from alerts manager to incident response system. 83 | * Curated [Service Level Objective](https://landing.google.com/sre/sre-book/chapters/service-level-objectives/) alerts, such as Request Success Rate based on selected availability target. 84 | 85 | ## Service analytics 86 | 87 | * Analytics pipeline from Digital Service frontends to analytics tooling. 88 | * Curated analytics dashboards, such as demographic breakdowns for customers. 89 | 90 | ## Service support 91 | 92 | * Platform health monitoring and a publicly available platform status page. 93 | * Health monitoring of third-party systems. 94 | * Automated incident creation, team notifications, and response channel creation. 95 | * Consistent post-incident review process including live telemetry data. 96 | * One click amendments to scheduled on-call rota for team members. 97 | 98 | Digital Platform Teams aren't the owner of an organisation's incident response process, but they will often have to automate and engineer solutions to help the incident response process achieve better results for their both service team's and their own incidents. 99 | 100 | ## Services Catalogue 101 | 102 | A services catalogue is an information portal, that maximises the discoverability of teams and services on a digital platform. It's powered by machine-readable metadata sourced from version control systems, deployment tools, metrics aggregators, ticketing workflow systems, and machine-readable post-incident reviews. Portal content usually includes: 103 | 104 | * List all Digital Services and their owning teams, in a publicly available catalogue. 105 | * List all Digital Platform capabilities and their owning teams. 106 | * List all curated test environments with described intent. 107 | * Dashboard of recent change requests as an audit trail. 108 | * Dashboard of all recent deployments with per-service and per-date filters. 109 | * Dashboard of all recent incidents with per-service and per-change request filters. 110 | * Deployment indicators for Digital Services and their owning teams. 111 | * Digital Service reliability data, showing availability % and time to restore. 112 | 113 | ![A Wireframe of a Service Page in a Service Catalogue, showcasing information on the service's microservices, SLO's and delivery indicators](../.gitbook/assets/service-catalogue-service-page-wireframe.png) 114 | 115 | An example of a Services Catalogue is [Spotify's Backstage](https://backstage.io/) 116 | 117 | ## Admin 118 | 119 | * Add new joiner to organisation-wide tools and processes on arrival. 120 | * Add new joiner to team tools and permissions on arrival. 121 | * Remove leaver from team and organisation-wide tools on departure. 122 | * Transfer all service setup from one team to another team. 123 | * Delete a service in its entirety. 124 | 125 | {% tabs %} 126 | {% tab title="HMRC experience" %} 127 | I joined the Self Assessment team at HMRC in 2015. In many projects I was involved in beforehand, the developers often didn’t have an opportunity to see their services in use. I find this approach incomplete and unsatisfying. Hence, I was glad when on my first day at HMRC, we reviewed telemetry dashboards as part of our standup. 128 | 129 | The telemetry embedded into the Tax Platform didn’t just help us to debug problems in production. Inspecting how our service operated under real load helped me understand Scala in-depth, which was new for me at that time. 130 | 131 | Business metrics provided constant feedback on how our changes impact user experience. I believe this contributed to a high sense of ownership in the team. 132 | 133 | The ability to customise our telemetry dashboards helped us prepare for the Self Assessment peak in early 2016. Observing the performance of every crucial element of our service under higher load made us confident that our response to a potential failure would be effective. 134 | 135 | ![Katarzyna Kittel](../.gitbook/assets/katarzynakittel.png) 136 | {% endtab %} 137 | {% endtabs %} 138 | 139 | --------------------------------------------------------------------------------