Technology Radar Vol. 2
See it here: The My Porsche Technology Radar Vol. 2
What is a Techradar?
Our Techradar is inspired by, follows and uses the tools from Thoughtworks. They have a very good explanation on their website.
How does a Technology Radar help us?
As you may know or remember from previous articles we at My Porsche align many decoupled teams. We are proud of our self-sufficient teams that work on one seamless user experience for “My Porsche”.
To understand the impact a Techradar has on our agile teams we have to look back. Not long ago a central board made the decisions about technologies to be used in all projects. There was no product-thinking for software. A book of standards defined which way to go and what to use. The teams had no choice except the company-wide tool set and methods. Regardless if this set supports a seamless user experience.
We shift responsibility into the teams.
Therefore we now allow the teams to use the tool set that fits the team best. They are free to choose their technology to solve customers’ demands. This is a huge responsibility since the teams have to:
- maintain their own software stack and keep it up to date
- setup a secure cloud infrastructure
- follow our rules to be part of My Porsche (like security is not negotiable, infrastrcuture as code etc.)
We setup teams with less effort.
At the same time we setup new teams in new regions. We can only provide the best user experience when not only our backends are close to the users, but also our teams.
The Technology Radar shows the “trodden path” that worked for existing teams and helped these teams to build their product. New teams participate from that knowledge and experience.
We preserve our knowledge to share it.
By discussing the blips for our Technology Radar we identified a most precious value: knowledge (about what works well and what attempts were in vain). The Technology Radar preserves our knowledge — but only works if we update it regularly. We also like to share this knowledge with the world and are open for feedback.
If you are interested in how we organize our teams, have a look at this article: Decoupled Alignment.
History of our Technology Radar
Creation of Technology Radar Vol. 2
We learned from our first approach (Vol. 1) and introduced the following rules:
- Reduce the number of participants and instead asked for input from all the teams via Email, Slack etc.
- Remove all blips from Vol. 1 that didn’t cross our way in the last 6 months
- Discuss what worked for our teams
- Be more strict what we really set to adopt or trial (based on the discussion above)
These might seem simple and self-evident. But we didn’t follow them in first place.
This time discussions were much better than in our first session. We really took the time to discuss the relevant blips from several team’s perspective. Only if a blip was successfully used in production or resulted in a productive feature in at least two teams, we set it to adopt.
If only one team uses a blip but it really had a huge positive impact during planning and implementing the feature we set it to trial.
Whenever we had the impression that we should use a certain technology to shorten the time-to-market or increase security we carefully put them into assess.
From our regular Tech Sync and Product Owner Sync meetings we identified the blips that are currently on hold.
We also used the Technology Radar to get rid of legacy software or gently push the teams into certain directions. A good example is our self-managed instance of Hashicorp Vault, which we abandoned in favour of a managed service. Managed services have better availability, are monitored permanently and require no administrative resources from our side.
The result is what we expected. The Technology Radar Vol. 2 is right to the point. It contains the right amount of blips to setup your team, your software stack and provide interfaces to build and maintain a product in our ecosystem.
Since we reduced the number of blips we managed to describe all of them.
We created a Technology Radar which is inspired by Thoughtworks and keep it stupid simple: use their template.
Where is Vol. 1?
Technology Radar Vol. 1 was never published. We started with a small group of Tech Leads and the IT Architects to collected all blips that we could think of. Then we discussed the blips, placed them in quadrants and rings — et voila: Vol. 1 was ready by March 2018.
But we missed an important part of the exercise: We did not filter the blips for their importance and also put too many of them into adopt. The result was way to big collection of all our technologies, methods, languages etc. We never managed to add even a short description for the blips.
Vol. 1 did not look like a Technology Radar (and therefore it was never published). We created an internal Confluence page but never invested time to advertise this one. I’m pretty sure, no one ever opened that page.
We decided to wait 6 months until we update the radar, filter and reduce the blips.
Highlights of this edition
Techniques — Public APIs as Default
We really want to decouple our teams but share our data. Therefore we introduced several public API topics in different quadrants — but all in assess. If the teams start to think “API first” it will reduce overhead to plan and develop interfaces for their data.
Techniques — Operations as initiatives
With great power comes great responsibility.
Teams gained freedom (=power) when moving into the cloud, but at the same time were overwhelmed by the amount of operations tasks still required. To make efforts visible to all stakeholders we would like to create initiatives for operations tasks vs. a fixed budget for these tasks.
Platform — Lambda functions (for Apps) & Serverless
We were really impressed how serveless accelerated the speed of developement for backend services — even if the teams had no dedicated backend developers. We are sure this will make a difference in time-to-market for MVPs.
AWS Lambda is currently our tool of choice to go for our Serverless approach.
Languages & Frameworks — Java
Oracle changes their licensing policy which will have an impact on our budget. We therefore would switch to OpenJDK wherever possible. Therefore we set the OracleJDK strictly on hold and set OpenJDK to adopt.
Tools — Træfik
Træfik made it into our Techradar in a very short time frame. It’s surprisingly easy to setup, configure and maintain for the teams. It therefore replaces NGINX in our cloud infrastructure setup. It is perfectly prepared to play with microservices (e.g. circuit breaker, routing, reload-less reconfiguration).
Conclusion
By using the tools from Thoughtworks it is fairly easy to visualize a Techradar. We had the task to collect, discuss and decide on the blips in our My Porsche ecosystem. We learnt from Vol. 1 and made Vol. 2 much more lean and to the point.
There are other tools and methods available to collect all technologies of our teams (e.g. see our software stack at stackshare.io).
But the most important learning from all: We entirely changed the way how we are dealing with techniques, platforms, languages & frameworks and tools. We first evaluate and give the teams the freedom to try it out. Then we sort it out within our regular Tech meetings and bring this up (or not) in the Techradar. We no longer stick to centrally pre-defined project methods, software stacks and limitations imposed by decisions form central boards or books of standards.
