Products and services are the lifeblood of businesses and it is vital for businesses to innovate continuously to stay relevant or become obsolete by the competition. To sustain this rapid phase of change, businesses require evolvable systems and platforms. To meet this need, businesses must embrace platform based thinking to support a product driven strategy.
This post was inspired by the presentation “The Magic of Platforms” by Gregor Hohpe where he discusses why one should invest in one. It is a great presentation for technology strategists and architects.
Platforms are a collection of systems that work together with a consistent experience to deliver a set of capabilities. The power of a platform is its consistency and low barrier for consumers to use it. Platform offers “task” services for the consumers to innovate. A task service is a standardised and consistent interface that performs a complex task.
Platforms go beyond infrastructure platforms such as Cloud systems. For example, there are merchandising platforms, e-commerce platforms, content publishing platforms and payment platforms. The bestway rationalise a platform is through the lens of Software-As-a-Service (SaaS) principle where the system absorbs complexity that allows you the consumer to innovate using it.
Platforms and Frameworks
Frameworks are usually realised through shared libraries or runtimes that provide a set of steps to realise a task or a workflow. There are web automation frameworks such as Selenium, unit testing frameworks such as NUnit, XUnit or JUnit. Frameworks are dissimilar to platforms and a platform may leverage numerous frameworks internally to implement various actions or tasks. Frameworks are mostly code or runtime constructs whereas platforms purpose-oriented and business capability driven.
Using platforms
Platforms centralise complexity and make it reusable. Complexity in software may be due to the business domain or how it is constructed. Complexity does not automatically disappear by introducing a platform, however it is possible to encapsulate complexity in the platform. For example, coordination between different tasks (a workflow) can be encapsulated in the platform but the definition of the task can be left for the consumer of the platform. A good example of this is AWS Step functions service where you define the tasks and the platform schedule and execute them.
Platforms promote consistency and standardisation. Consider an API offered by an organisation and chances are that you may struggle to use it if each endpoint uses different semantics. Gregor explains this aspect using “fruit salad” over “fruit basket”. The “fruit basket” is where the capabilities are on offer but they are not homogeneous whereas “fruit basket” binds all capabilities into a consistent experience. That means from a consumer perspective, you may only require a fork to enjoy a bowel of fruit salad!
Platforms evolve but at a slow phase which is by design. You may not force your consumers to adapt the new version of the platform as frequently as the products that are on offer. The point here is deciding what goes into the platform and how it may be used by the consumers which requires thought and sufficient feedback. This is where consumer feedback and consumer experience take the centre stage. It is also where Product Management can play a pivotal role.
Platforms are built on other platforms. For example, a payment processor may build their services and capabilities on platforms provided by payment schemes such as Visa, Mastercard or American Express. From an infrastructure perspective, you may also decide to build on a Cloud platform and supplement your needs and requirements by creating new services (e.g. automated VM provisioning but with certain tags and images).
A key aspect to consider when layering on a platform is about seeking opportunities to leverage native capabilities on the underlying platform. Gregor uses the concept of “sinking” or “floating” platform. Sinking platforms continue to use the custom capabilities despite the same or similar capability being present in the underlying platform whereas “floating” platforms leverage the underlying platform when the missing capability is available at a later date. For example, AWS Keyspaces for Cassandra now offer multi-regional replication whereas previously users needed custom replication strategies such as messaging to transfer data between regions.
Robust platforms are modular so that the platform itself can evolve. If the platform is a monolith, then challenges with managing such a platform may emerge; adversely impacting the ability to evolve. So, platforms themselves must be modularised so that the constituents systems or components can evolve and new ones added without impacting the entire platform. For example, Datalex offers an airline merchandising platform with a number of modules and customers can decide whether to use an in-house pricing system or use the solution offered by the platform.
Platforms are opinionated as they address a particular need. Platforms exist in a context and the context may dictate the requirements. For example, e-commerce platforms such as Hybris require the business to adapt certain constructs such as “warehouse”, “price” etc. Furthermore, the platform may determine what tools, programming languages, integration patterns that an organisation may use.
Platform champion
Rome was not built in a day as much as Platforms are not built in a day. It requires long term strategy, vision and a mission. But above all, it is the consumer experience that drives platform strategy in an organisation. Platform strategy requires strong sponsorship or champions at the highest level because without the right focus and investment it may bring more complexity rather than addressing it.
The principle of platforms was well articulated by Peter Gillard-Moss at ThoughtWorks as “platforms are a means of centralising expertise, while decentralising innovation to the customer or user”.
Inhibitor
There is a myth that a capability must be introduced first in the platform before providing it to the consumers. Recalling that platforms evolve slowly compared to products that use it, there may be situations where a capability may need to be built in isolation due to various delivery or technology limitations. One could argue that it is a waste of resources and may hold the business to ransom. This is exactly the short term mentality that derails organisational progress as building the capability outside the platform may offer valuable consumer feedback, early access to market before porting the capability to a long lived platform. Temporary expansion is acceptable over years of pain and paying the opportunity cost. This is where platform leadership and product strategy is essential to chart the roadmap for the future.
Last words
Platforms are a sign of maturity and commitment to a product line. Embedding platform driven thinking and building, supporting and nurturing is the right thing to do for an organisation to succeed and setup for the future. Absence of this strategy may lead to resentment, disappointment and unhappy customers and losing out to the competition. It is now time to huddle around and define the platform strategy and bring value to internal and external stakeholders.