What is a Software Platform?
There are many definitions for this term in computer sciences. In this paper, the term is about software platforms and is used according to a definition that can be found in several papers and books:
“A software platform is defined by a well specified interface that allows other software to be built on top of it.”
So, it is about functionality (and system qualities) that is provided by a set of software which can be used by other software or better, by developers who write the „other software“. When building a platform that is designed to make data reusable, the same applies, because you will require functionality that manages the access to the data, you may want to build services for meta data management or monitor and audit who uses which data to which extend. All functionality that shall be used by other people’s code.
A SW platform can be provided in multiple ways: as a set of binary libraries, as a collection of pure code that can be compiled into a product, as a complete product that is delivered as an installable medium, as software as a service in a cloud environment or in any other provisioning. The point is that the functionality is accessible by other software through a well-defined interface and that the software is managed and updated by the creating department or company. The technical interface in turn also can be provided in different ways: as code level API, as a web-service, via a messaging interface, REST API, you name it. Such a software platform so provides the underlying layer(s) in a system that is more specialized to serve a more concrete business. Think of a pile of pancakes where each pancake serves as the basis for the next on top. So from the top pancake, everything below is considered as „the platform“ that may be constructed of multiple layers.
The difference between just shared libraries, components or services(see OSGI, SOA or CBSE for examples) and a platform is, that the platform has a business scope and aims to support all base functionality within this scope, so it is managed and an actively governed asset that delivers a set of services/features/qualities under one umbrella.
As an example, modern cloud platforms services provide platform functionality in exactly this definition. Services expose APIs which are used to interact with the service, the service implementation is hidden from the user and every service does exactly one thing very well. The key is that all services are crafted to be used by developers to build solutions and higher level services. As you can see for instance in the AWS (Amazon Web Services) portfolio, platform services can be on different levels in a technology stack: Base infrastructure like compute and network, communication middleware for system integration, databases and data storage, data streaming and messaging, data analytics and many more. The same applies for all platforms that are in scope for this article series.
A product or solution of one organization may serve as a platform for the next organization. As long as the layers provide public interfaces to re-use their functionality and they are fully managed by their providers, they can be defined as a platform. Of course, there might be internal platforms (used within a company) and platforms that are open to the public with a business model around the use of shared services.
In the larger context of product line engineering, the platform will provide the common assets that are going to be reused in the products that are developed in the scope of the PLE approach. So, the platform becomes the technical enabler on which the products will be set up.
What is Product Line Engineering?
A very brief introduction into the part of PLE which is relevant for this article series shall be provided. It is intended for those readers who did not yet have contact with PLE before. Because several methods of PLE will be mentioned in this article series, the context shall be outlined beforehand. I want to highlight this, because PLE is a very structured approach to platform development and can be used in other contexts as well.
A general definition of PLE may be:
“A software product line is a set of software intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment and that are developed from a common set of core assets in a prescribed way.”
The main characteristics of a product line so focus on three aspects:
- Business driven: All products and so also the shared assets (platform) are shaped and defined because of market demands and business considerations. A global optimum over all platform based products is in focus, not the individual optimum for any single product.
- Managed variability: There is a clear and explicit process of identifying and managing variability and commonality between products on all organizational levels; and over all phases of the product lifecycle.
- Strategic reuse: Reuse is planned and part of the product strategy and the product portfolio. This also spreads over all products of a product line and so all involved organizations. So, for example, the reuse and its impact is not necessary limited to a single department within a company.
From these very basic aspects it becomes clear that PLE does focus on a broad and global optimization of product portfolio development. It so automatically dives into processes and organizational topics and provides tools for managing and modeling the artifacts that are required to execute such an approach. At its core, the PLE approach relies on a selection of target products and a clean analysis and modeling of the commonalities and the variability among the planned (or existing) products in order to determine the scope of the shared common assets.
You can learn more about Product Line Engineering here: What is PLE | Product Line Engineering.