English | EN 
Based on my work on Beautiful Delivery with autonomous cross-functional teams (for more details, see Use Beautiful Delivery to Speed Up Your Digital Transformation), I will here focus on how the services the teams create work together.
Each team is responsible for implementinga number of services. Some of these services are used by customers or employees, and they are called touch points. Others are created to support the touch points, and those are called the specific services, which in turn use generic services that implement omnichannel logic. Many services use common services and service that help with automation. For more details on the different kinds of services, please see Building a SMART Architecture with Serverless.
Each team is responsible for publishing their services with well-defined and versioned service interfaces, according to the master data model, and with a service level, which unified is referred to as service contracts. The service contracts allows other teams to make use of the services in a predictable way. For more details on microservices architectures, please see Microservices Architectures Are Here to Stay.
As each team is responsible from user needs all the way to run in production, they also control the lifecycle and versioning of the services. Also, as they are free to choose any technology, platform, and tools, these services can live in very different environments. Therefore there is no point in having a central production environment, and thus no need to deploy in such an environment. As there is not one production environment, there is also no need for either staging, test, or development environments. All that remains are just a number of distributed services that have different levels of maturity (versions), and each consumer choose which version to use. For example, a web site that can be deployed quickly and only exist in a single current version on the web, can choose to go with a later version than an app that has to support several older versions of the app at the same time.
To make it easier for other teams to use the services, each team provide a developer portal (or publish in a common developer portal) where the other teams sign up for access keys, and this way the team knows who the consumers are, and can treat them as their customers. The team will also monitor (usage, performance, etc) and capture feedback from the consumers of their services. This approach makes it natural to use external services in the same way, and also to allow external parties to use the team’s services via a public API. The result is that all teams and services can play a natural part in the end-user’s (i.e. customer’s) ecosystem of value.
