Informations
Jobs
About Guidelines, Guidance, Alignment, Independency and Freedom of Choice.
OTTO is moving towards a tech-enabled company. Our software is business-related, not abstract. While complying with the requirements of our buying department, we have succeeded in becoming a great platform for customers, partners and suppliers.
The approach of following Domain-Driven Design (DDD) helps us to keep focus on certain business areas. It implements, from an overall perspective, the cutting concerns and gives us the ability to spin off new teams whenever there is a business area we need to tackle.
For some years now, this approach has been quite successful for creating product teams with a clear business focus and independence to make their own decisions. Dividing our platform into independent business domains and giving teams freedom of choice for technical layers brings about a higher velocity for delivery. We were, however, wondering whether there was a downside to this procedure. It certainly entails a lower level of technical alignment and might result in fewer synergies. When teams work without any technical guidelines, a non-maintainable environment may be the consequence. Hiring developers might prove difficult with each team using entirely different tech stacks. Helping each other out sort of gets impossible, when there are no parallels between teams.
There is a thin line between freedom & flexibility and governance & alignment. We did not want to narrow the corridor for best solutions. A certain level of alignment should help our engineering crew adopt a common language and result in similar (not equal) solutions for common issues.
Inspired by other companies’ tech alignment strategies (including Scout24, john lewis and Zalando), we took up the idea of generating a technical manifest. It should contain few, but clear rules. Whenever technical decisions on a team level are discussed, the manifest gives guidance and support in order to arrive at a decision. It should not be a set of strict rules restricting the freedom of teams to opt for their own solutions. This guidance is meant as support for decision-making, to get faster and adopt a shared mindset.
Participation and contribution by all of our technical staff is the key to making this a success. We had a go at which topics and areas to include in the manifest. To arrive at a generally accepted set of rules, all developers were welcome to contribute and discuss what exactly to include in the manifest. People tend to assume collective ownership of such artifacts, provided every single person has had the opportunity to contribute and has been invited to discuss all topics.
The initial version was created in 2018, when we started our journey in the deepsea. Since then, we have introduced an annual review in order to incorporate changes and cover all topics of interest in the manifest.
The manifest consists of two main segments: values and principles. The values describe our mindset. We wanted to outline which topics are important to us, especially to give non technical people an overview of how we want to work. After several discussions we decided on these five values:
Tech follows Business
We want to push our business, not just develop software. All technical decisions required should relate to business requirements in some way. We love a full team approach when business ideas are developed. We focus on product development and embrace the notion of creating (software) products rather than software artifacts.
Move fast, fail fast
We want to reduce the cycle times in a build -> measure -> learning cycle. With an open failure culture, we strongly recommend trying things out in real life settings instead of debating what might be the best solution. Preserving team autonomy while remaining loosely coonnected should enable teams to deliver increments and to check a feature’s success rate regularly instead of clinging to a static release plan.
Low technical Barriers
Open ore?? accepted standards are widely used to create our products. We like the idea of being supportive and want to keep the barriers low. We offer exchange and support the show-and-tell concept, instructing our staff on how to implement specific common requirements.
Coverage of non-functional aspects
We want to create an environment in which to maintain our software indefinitely, without having to face a huge migration / transformation project in the near future. This is why we request our teams to keep track of non-functional aspects such as scaling and staying up to date with the selected tech stack.
Quality is an indisputable component in our mindset and we do not accept bad quality due to pressure. Building products is seen as a holistic discipline and not done while writing code.
Full ownership and clear responsibility
True to Werner Vogel’s famous quote “You build it, you run it”, the teams are in no doubt about the responsibility they assume. Our teams are responsible for their products during the whole lifecycle. Teams must opt for their own on-priorities: whether to tackle technical issues, optimize for costs or deliver new features.
Besides the values, which are more or less superordinate in describing a mindset, we collected the technical principles we observe in these three areas:
- Architecture
- Operational
- Technology and Practices
Hold on. Does our way of working fit your idea of building ingenious software products? Discover exciting new challenges in our job search.
The full manifest is published here, I will now just pick some of the principles best describing the underlying concept. These principles provide advice to tech teams regarding day to day decisions. When teams are struggling with a topic, these principles might be helpful to come to a conclusion.
Non-Blocking Communication
Technical autonomy is something that makes our systems failsafe and reduces the time to recover. Loose connection in non-blocking communication leads us to implement systems that are more robust. We accept negative aspects including storing redundant data or the inherent risk of showing outdated data to a partner, customer or employee. Event-driven architecture is something we implement instead creating REST communication between systems.
Small and Simple Microservices
The unix approach of doing one thing per service but doing this thing really well is something we want to put in our tech DNA. A microservice implements a business functionality, not a technical solution. A microservice as such may consist of several technical services (e.g. anti-corruption layers, api layers, ui layers) – with all services acting as common business-related microservices. We avoid having services which handle more than just a single business domain.
Cloud Native
With the usage of cloud providers like AWS or GCP we have the chance to minimize our operational (run) efforts. On this basis, we put together a list of priorities dealing with how to select and integrate base services like queues, databases or runtime environments, namely in the following order:
- Prefer cloud services provided by primary cloud provider in team
- If there is nothing available, use offers operated by a third party as Software-as-a-Service Service
- Only if there is nothing to meet our requirements, build or operate your own service within your cloud account in the following priority
a. Self-hosting an active open source solution
b. Self-hosting 3rd party paid solution
c. Self-implementing and hosting a solution
Make Decisions in Public
Cross-Team decisions are often hard to make. We think it is more helpful to clarify cross-team concerns in open discussion and document results clearly and transparently for all those affected. Results put down in writing clarify the consequences instead of having “unwritten” laws followed by each team according to its own interpretation.
Sensible Defaults
Defaults should give an overview of widely used technology. They are helpful, because teams can see which technology is used instead of investigating themselves. You can invest countless working hours into trying out different solutions, and for any technical problem there are quite often numerous promising solutions. We are maintaining a tech radar to provide transparency and offer the chance to get a bigger picture and find out which team to contact regarding specific issues. Changes are incorporated quarterly to keep the list of defaults up to date.
Personally, I have enjoyed the time and work put into discussing the manifest. It points out what is important from a tech perspective and creates transparency for our business people and management listing the concepts we wish to base our work on. I am particularly pleased about the fact that all engineers in our tech community are invited to contribute. This approach gives me confidence, ensuring that the rules set out are both accepted by those affected and also sensible and useful in day to day work for our teams.
If these topics sound interesting to you, we would welcome you to our team.
0No comments yet.
Write a comment
Answer to: Reply directly to the topic
Written by
Marco Hutzsch
(former) Software Engineer at OTTO
Similar Articles
FabianApril 17, 2024Confluent Helps Power a Diverse and Scalable Online Shopping Experience for OTTO
06Find out how OTTO is taking its 10-year-old data infrastructure into a new era with the event streaming platform powered by Confluent and making itself future-proof.DevelopmentOperationsWorking methods- JimMarch 14, 2024
Machine Learning Ops: What It's Like in Practice.
06Get an insight into Jim's work as an MLOps-focused engineer! In this article, he explains how a machine learning product is developed and how you can get started in this discipline yourself.Data scienceDevelopmentMachine learning
