In most software-based businesses it is quite common to think about platforms. Building an own internal platform that implements the common assets of the business so that new products and solutions can be built faster and cheaper, by reusing features or system qualities, or leverage the data that was collected from previous projects – for internal use or externalized as a platform-as-a-service or software component business. While now many of the classic software platform functions like authorization, authentication, logging, metering, configuration… are mostly available as ready-to-use software and solved, there is an unbroken need for platforms that implement higher level business functions.
Determining realistic economic benefits and risks for a platform approach out of existing solutions, products or unique technology is quite complex and requires a sound analysis of the pains and gains. Even if the functional view indicates a high potential of reuse, the operational and developmental qualities that are required plus the additional efforts to manage dependencies and stakeholders may still be contradicting. At the same time, platforms promise highly relevant business cases when you manage to maximize the re-use of the platform. Scaling to thousands and millions of users is where the goals should be.
When we plan to change the rules for solution and product development within one organization, we are well advised in not forgetting the people which are involved. Considerable efforts should be planned to involve all stakeholders early, to make them part of the decision making and to motivate the approach based on a solid business case for the platform. Developer habitability shall not be underestimated when it is about the acceptance of the platform in the development teams that shall use the platform.
As a rule of thumb, the diverse PLE (Product Line Engineering) literature claims that a software platform feature will cost about 3 to 5 times more as the very same feature when it was developed as direct part of a concrete solution or product. This is due to the increased quality demands and the implemented variability and flexibility. However, this number aims at a green field platform approach where no existing applications must be touched. Extracting existing features from existing solutions may be quicker and less effort might be required if the platform follows the same implementation concepts and uses the same infrastructure. However, this is rarely the case. Typically, a new platform uses innovative or at least more modern infrastructure and concepts so that existing solutions and platforms become less similar on implementation level. With this, the migration efforts on solution side can increase significantly. It is hard to provide a similar rule of thumb for the Payoff Threshold in the case that we want to migrate existing solutions. It all depends on how much structural change is required. The cost for providing the platform will properly not as high as in a green field approach due to the existing code and experience, but the cost to use the platform in existing solutions will out-weight the provisioning cost-savings easily. Still, the approach might form a valid business case and is worth to follow – but the complexities shall not be underestimated.
When organizations build individual software solutions and products over the years, at a certain point in time it seems reasonable to consolidate the existing solutions and extract their commonalities into a shared common asset – called software platform. Or – at an earlier stage, there is so much opportunity in a certain business that the organization believes it needs a central platform to enable a set of solutions, products and business on the horizon. In this case, there may be only a few or even zero existing solutions yet. I have seen multiple approaches that started with a single solution / product; this product was very successful and the business opportunity to do more in that area was significant, so it was decided to build a platform from the single successful product/solution to boost the development of “more like this” products and solutions. A similar situation can be observed when a project or product collected a valuable set of data that now generates the opportunity to build several new services and business around the re-use of that data.
The reasoning is often based on the assumption that the platform – as shared asset that is reused in the existing and to-be-developed systems – must be maintained only once and allows reduction of cost and shorter time to market for new solutions and products. However, the challenges within this approach are often underestimated which may lead to exactly the opposite than the expected cost and time savings. The following articles outline typical pitfalls and challenges and provides best practices of how to approach a change to a platform-based approach successfully. Here, the ideas follow the base assumption that the platform shall be either exposed internally within an organization or externally as commercial service/product.
The idea of cost-optimization through shared software components and shared data by going into a platform approach is also often combined with an approach to reduce the operational cost for the target platform and focus the engineering efforts towards differentiating areas of the platform, away from common base platform functionality. Today’s cloud offerings play a significant role in this kind of approach, because they allow an organization to simply make use of infrastructure and platform services instead of developing them as part of their own platform in-house. This applies to very basic functionality like metering, logging or authentication up to complex services like machine learning and artificial intelligence-based services.
First of all, I like to point out what this article series is not: it is not to explain how to build a software product well from a SW engineering point of view. The art of creating successful software solutions is covered in many books and articles, to which shall be referred at this point. This article is also not a re-definition of Product Line Engineering (PLE) for software products that run in the cloud. This topic is also covered in literature and discussed widely in conferences and expert groups. However, this article tries to highlight the best practices of both disciplines in the area of platform scoping and cloud-based platform development in addition with the aspect of human-centric issues (social and organizational elements) in order to provide a more holistic view on the challenge at hand.
So, I will first provide a general overview on the challenge and the complexity of a platform approach, both: consolidating on existing solutions and as a base for new solutions. Here, the technical complexity and requirements diversity is one central aspect but also non-technical aspects typically lead to severe problems during such an undertaking. Missing acceptance of the approach, unexpected costs, technical problems on the way and a striking resistance of people to abandon their old habits all lead to the fact that many such approaches remain unsuccessful. Secondly, this series will highlight a few best practices to start a platform approach, from the existing PLE frameworks, from software architecture but also from a peoples-cooperation point of view, that help to deal with the complexity and handle the risks. Even for projects and people that are either not aware of PLE or simply do not want to follow a product line approach, some of the PLE methods can be used to strive for a less risky implementation of the platform approach.
As a result of reading these articles, you should develop the idea that building a platform should be considered well. When thinking of all consequences and total cost of ownership, sometimes individual solutions are the better variant. As any technology, platforms are no silver bullets. I will provide some hints that help to make the judgment.