Gaining new capabilities

As Roman described in our first blog post, we are currently in the phase where we gain new capabilities — comparable to those found in the software industry.

Before diving into the effects this change has onto Porsche’s IT system architecture, I want to give a little perspective on the key factor why we want to change.

The car/mobility becomes more and more integrated into the digital ecosystem to deliver the best experience to our customers. This requires a tight integration with all sorts of systems such as phones, calendars, preferred streaming services, social networks etc.

In contrast to a mainly closed system such as the traditional car (which also contains a lot of highly advanced software applications), this ecosystem is not controlled by a single organization — therefore timing and features are not controlled by a single instance. Every participating player needs to adapt to changes outside their control quickly and to seize new business opportunities.

This adaptability and the means to deliver new functionality quickly, fundamentally influenced our system architecture. We started with the systems that provide digital touchpoints with our customers (such as identity management, web portals).

This flexibility was in contrast to the requirements that mainly drove our IT in the past (the need for well-planned, effective, long lasting systems). And we came up with the following rules:

Decoupled — Rather than developing one large system, we have chosen to implement systems that concentrate on a small set of functions. But decoupling also meant that we accept creating similar components twice (something we tried to avoid in the past).

Highly aligned — While the decoupling gives the individual teams greater independence, it is imperative, that we ensure the interoperability between the systems. This goes far beyond purely technical aspects. It also covers non-functional requirements such as supported languages or common standards to enable service and support.

Web standards — Existing web standards are the technical representation of this alignment. The web is an impressive example of highly decoupled services that integrate well. We have chosen to follow this great example.

Evolutionary and demand driven — To prevent our systems from being over-engineered, we invest in flexibility rather than up-front guesswork of future requirements.

Community driven — We integrate with a great number of existing systems and work with a lot of different partners to implement our systems. They all bring specific domain knowledge and experience. We believe that a community of this diversity ensures a reasonable balance between the decoupling and the alignment mentioned above.

What worked well

The chosen approach brought us quite far and showed positive effects on our ability to deliver new functionality quickly.

Our rules work well, but they are not free of contradictions. E.g. our decision to use Kafka for inter-system communication is contradictory to our commitment to open web standards (see Heiko’s Post “Apache Kafka at Porsche”), but in full alignment with our evolutionary and demand driven approach.

The evolutionary and demand driven rule needs to be handled with care. There is the danger of creating solutions on a basis that this not fit for handling a requirement (alas, the German word “frickeln” — does not translate well into English — to tinker is probably close) — so the existing state must be challenged constantly.

We found that the approach to form teams that are responsible for their systems works well. We see that it ensures that everyone works on things he/she knows best. A side-effect is that problems often show-up in the same place where they can be fixed.

What is next

The rules and what we have done so far brought us far but they are only the beginning of our journey. This is what comes next.

The Cloud: When we started the implementation of our systems, we used the existing building blocks our IT-systems were relying upon. These building blocks are the same that can be found in many manufacturing companies: a set of software components (such as Tomcat, Oracle DBs etc.) operated on on-premise hardware. These building blocks cannot be controlled by software — but rather require manual work by those responsible for the services offered by these components. This greatly impediments our ability to refactor our existing services and encourage work-arounds. See Florians post about our cloud journey for our approach on that topic.

Self-service APIs: There will always be communication and thus dependency between our systems. To make sure we can manage them in the future, we need to make sure that every service we create can be consumed via self-service (APIs). Again, we have a great example to follow: Cloud services accessible as self-service made the dependency to infrastructure less problematic.

Fitness functions: The rules above only work in a smaller environment, where their meaning can be taught to new colleagues and evaluated in the community. As described in Building Evolutionary Architectures, the desired state of an architecture could also be made measurable by fitness functions. This (among other metrics) could move us forward in measuring our progress we all feel we have achieved so far.

One of my key learnings is that you as an organisation need to draw some conclusions yourself. There is a lot of great literature, excellent examples and great people to learn from, but there is no such thing as the single blue-print on how to get digital products right. So the things written here are a snapshot (hopefully you find interesting) and will change over time.