In a previous post I talked about alignment and decoupling. Motivated by some mails and questions pointing out this seems contradictory, I want to dig a little deeper on what it means for us.
Remember, that we at My Porsche decided to decouple our systems in a way that teams can develop their functionality independently from others. Our main driver for this is time-to-market — and thus — relevance for our customers.
On the other hand, it is important to ensure that the different services we offer in our digital eco-system are perceived as “one”. The user should not notice that he is switching between services developed by different teams (people who bought a product in a shiny store in seconds and faced hours in support hotlines once having problems with the product they purchased know what I am talking about).
The picture above shows a high-level diagram of our approach to tackle the challenge to balance alignment and team independence. On top you can see the customer — using our services. In the bottom you can see some of our teams offering their services (in grey).
In-between you can see that we develop common standards for cross-cutting concerns we believe are important for a seamless digital experience (in blue). Apart from having a single digital identity and a common UI design, we came up with additional rules & common standards for a seamless digital user experience.
In this article I want to share the different aspects we have identified so far. Adding technical details to the diagram, the picture looks like this (apologies if this is detailed, but for the sake of transparency, I decided to use the very same drawing we use internally):
You will notice that we have identified rules for scoping the product (exposed as services), the conceptual components (in the service and the UI layer) and the interfaces between our products.
Take our messaging product for example. It provides a secure inbox for delivering messages to our customers. When a system wants to deliver a message to the customer, it uses a REST-API in the service layer to submit the message.
The messaging service show the message to the customer via web application that is part of the messaging product in the UI layer. Other products — such as our landing page can use the REST-API to show the number of unread mails — and create a deep link to the UI showing the inbox, filtering etc. Other systems — such as a Backend for Frontend (BFF) for an app could subscribe to a Kafka topic that signals a new message — so that the BFF can send a push notification to a mobile app.
In addition, we have a number of common conventions / requirements to support a seamless user experience. I will list the major ones and state the cost of not having that rule:
Supported Languages and Countries: We have different offerings and texts (e.g. instructions, legal texts) that differ per country. Without agreeing what languages we support in what country, there is the danger that language changes inside a user journey.
Browser support: Without agreeing on the same set of browsers, we cannot ensure that the user does not end up in a dead-end when being forwarded to a system that does not support the browser he started with.
Number of system environments (e.g. development, integration, production): Without agreeing on how many stages/system environments we have on a system level, we will not be able to test user journeys end-to-end because comprehensive test data will be impossible to produce.
Logging & monitoring: Without agreeing on standards on logging and monitoring we will not be able to provide support.
Authentication: Without agreeing on standards for user-authentication, users will have to re-authenticate during their user journey.
UI design / UX: Without standards / samples for user interface design, pages will look different. We ensure this via a UI-Kit that contains ready-to use UI elements (actually this goes beyond UI elements and also includes a common dictionary, translation process etc. to ensure that we use the same terms for things).
Documentation: Without common standards for documentation of our products (think of this as a product catalog) we risk people solving the same customer-relevant aspects twice (e.g. two products offering services how addresses are formatted — leading to incompatibilities when re-using address data across systems).
Networking & Connectivity: Without standards for networking and connectivity (we chose the public internet), we risk situations where we cannot connect systems to each other, because products might have been created in legacy network zones that restrict internet connectivity.
There are other aspects where we believe we need to invest in (e.g. resilience and performance/timeouts), but we haven’t come up with good rules, yet. Which brings me to how we create such rules. The rules are not created by a single governance body. Instead, the product teams identify these rules as they come up. In our guilds (e.g. UX, tech, devops, …) we discuss them — and check if they seem relevant (e.g. the networking rule seems obvious, but we missed that at some point in time). When discussing, we first check if we risk negative user impact if we do not have such a rule. Next, we investigate the status quo, asking why people solved things differently — and finally trying to find consensus for a rule.
Behaviour over inner workings: You will notice that above rules focus on the BEHAVIOUR of a system (old term would be requirements). I am often asked by fellow architects why we do not standardize around the building blocks of the application. They — like myself have been trained to fight redundancy in IT systems.
I strongly believe that redundancy is not bad in general. Accepting redundancy can increase delivery speed. It becomes evil if it contradicts our requirements. Remember, our requirements are: short time-to-marked, highly integrated user experience.
Will a customer notice if we are using mongoDB in one service and dynamoDB in another? I doubt it.
Will we have better time-to-market if we use mongoDB compared to DynamoDB? I believe it depends on a number of factors… factors I believe the developers of a product can judge best.
But what about cost? I believe in the power of the market. If we have the feeling that a variety of databases is too expensive or time-consuming (because each team has to figure out how to solve a particular problem), I am convinced it is best to make an offer to the teams that they are not able to resist. This can come in forms of a trodden path (e.g. we already figured out how to do backups in DynamoDB, this is how we do it and here is the documentation necessary to prove that we comply with data protection laws, we already have set up a contract to order xyz) or by having one team creating a product to solve a specific problem.
If a company fails to make such an offer, but tries to standardize via strict rules and policies, it will remove the motivation for the team offering a service to remain competitive — and eventually will result in higher costs and frustration.
Identifying potential candidates for a trodden path or a product is a challenge on its own and a topic for another post.
So as a summary, in our setup, the “enterprise architecture” must focus on rules and policies around the behaviour of a service, but not for the building-blocks used to create it.