I have often been asked about what type of systems make good candidates for being platformized, and my answer is always “All of them”.

The characteristics of a platform derive not from the nature of the problem it intends to solve, but from the inherent structure of any business space. There are problems that a business wants to solve, and it picks one of the many potential ways of solving it which it deems most suitable for itself. This is the company’s “organization context”. In the technical modelling of the problem space, however, engineers have to deal with real world nuts and bolts of the problem space (the “Domain Context”) as well as the defined business process. This split almost always creates the potential for applying the subtle knife of platformization to any technical design.

In other words, there is dog food everywhere.

Consider a fairly realistic scenario : A team is asked to build a system for sending marketing notifications to customers. The company wants to be a platform centric company. How should this team adopt the the platform design mindset and approach this as two problems : send marketing related notifications via a notifications platform – especially when the latter part is not explicitly stated. How should the team discover the hidden, broader mandate and recognize the platformization opportunity here?

To achieve this split, the team has to perform a very different type of design exercise. They have to analyse the product specification and determine what parts of it are invariants and which parts of it are a function of marketing. This is harder than it appears at first glance because the team is immersed in the organization context for marketing, as are its stakeholders, its product mangers, and its engineering leaders. It is difficult to disengage from this implied context and design platform and product components separately.

Even though the platform is only meant for consumption within the organization and the only know user at this point is the platform owner team itself, the Golden Rule of Platforms says that the platform has to be built as if it was being built by someone outside the marketing notifications team and later they are going to use it just like any other tenant on the platform. As you might imagine, it takes a lot of discipline to draw and hold this line. It helps if the development team temporarily thinks that they are a separate company called “Notifications Pvt Ltd.” and are trying to sell their software to “Marketing Pvt Ltd” and “Payments Pvt. Ltd.”

---

---

“But my job is not to make a platform, I just want to send notifications!” – If you have been thinking this, you are right. In fact, if your organization is in the middle of switching to a platform-mindset, this is probably the most frequently asked question and the biggest source of disgruntlement to engineers.

When we face this question, we need to consider what we are trying to build.

If it is a technical capability, then it stands to reason that we don’t want to build the same thing again and again in the organization. Developers understand this, and technical constructs like authentication etc often get built as platforms spontaneously. Software engineers have been building platforms way before the word was cool. A core part of Unix development philosophy is to have tight programs with well defined purposes, easily connected via pipes – this is also the essence of building a technology platform.

Whatever we building outside of pure technical capabilities, however, we are likely building it in the context of a business and we are building it as per the rules of that business. And the thing with rules of business is that they change. And when they do, it is up to the engineers to design the systems in a way that we can salvage as much as we can and enhance the rest, instead of having to go in for a big rewrite every time. Remember – build momentum, not velocity.

Now we can say “that’s just modularity and good design”, and it would be right. But I propose that we will often find so called modular code to still be dependant on an assumed context in which it is operating w.r.t how and why it will be invoked, how its errors will be handled etc. Our modules are often decoupled in implementation, but dependant in the context of real world use.

Platform design enforces a conscious evaluation of modularity to arrive at a split between what is business opinion and what is technical “fact”. We can apply the same pure-technology mind-set to business problems as well and break it down into what is “core” and what is “opinion”. Applying the product-platform split mindset to every design problem over time will result in diverging rates of change for different components. This means that we will end up changing lesser and lesser code over time to meet business needs.

A common example of this failing, especially common in “internal” platforms, is for the team building the platform to assume itself to be the “centre of domain expertise” and deciding behaviours on behalf of the clients. e.g the “notification platform” team may decide that it is the best judge of who the best provider of notification infrastructure and not allow the users of the platform to make that choice. This may be fine for most use cases, but this simple choice has put the team owning the platform in the path of potential change, and reduced the platform to a product. If a need arises where a variant behaviour is required, the platform APIs will have to be changed in some way, and this might impact existing users.

Had the team chosen to expose an overridable default as the way of choosing notification infra, such a thing could have been avoided. The implementation was clean, but it made assumptions about who can decide what. Every time we find platform teams making business choices beyond. suggested default, there is a good chance that the modularity of implementation is weakened by the assumption of context in which the implementation will run. In platform architecture, we are generally better off exposing more hooks than less.

So the job may not be to send notifications at first glance, but over a longer time scale, the job is to deliver more and more value to marketing business, and anything we can do to easily keep up with evolving requirements is a good thing.

The Golden Rule of Platforms and applying platform thinking to every design problem has other interesting effects too. The layered structure it creates ripples outwards as successive components apply the same principles and a dynamic boundary automatically emerges for the platform. At this boundary, special use-cases continually separate themselves out of the platform and generic capabilities make their way in. This is the kind of dynamic situation where eco-systems and collaboration can thrive and opportunities can be readily leveraged.

This is the edge of innovation.