The Key Characteristics of Platform Components
- Built first and then reused forever: Should be built agnostic of specific business needs and then used for addressing business needs
- Externally programmable: Must expose hooks to build custom specific experiences on top of it.
- No exemptions to rules 1 and 2
–JEFF BEZOS
Prefabrication of building components is not a new concept in the construction industry. A repeatable, cheaper, reliable and proven set of platform components can ease the challenges typically encountered in a custom build.
It would be an understatement to say that the technology industry is the quickest to grasp learnings from other industries. It is this sense of inheritability that has spawned many principles where hardships and learning from one technology group have been packaged, labelled and delivered to other group facing similar problems.
Software libraries packages as jars, header files and executable have helped the modern software engineer leverage the full benefit of abstraction of complex logics. It has enabled them to focus solely on solving the business problem at hand, by reusing an already available solution in innovative ways.
Using platform components solves the same problem on a slightly larger scale. At multiple instances, organizations offer a portfolio of product, which often experience an intersection of problem statements between them. As product and development teamwork in organizational silos, a duplication of solutions emerges for the same problem. Moreover, the solutions that emerge tend to be very customized and focused on the immediate market the product is targeting.
The requirement of the infinite need to maintain, upgrade and enhance takes place in those few seconds during the conceptualization of a custom solution. In other words, platform components focus on reducing the entropy caused by new development projects.
Collating the existing challenges in a common repository and considering them intellectual property can address a significant challenge. Namely, the current “deprivation” witnessed in solutions can be catered to. This thought is not new and has been widely used in the industry under various names – micro-service architecture, component-based software engineering (CBSE), modularization etc. However, the measurement of compliance to the needs of the stakeholders remains an unresolved challenge.
Once these aspects have been addressed, the bigger question is defining a solution housing characteristic acceptable by a plethora of stakeholders – each of whom share the bond of common needs.
This is easier said than done. However, by following the Platform Component Concept model (PC2M), we have defined a guiding principle for any new initiatives the organization is going to invest in.
What is PC2M?
PC2M is essentially a tool to manage expectations and aspirations of various stakeholders for whom the challenge is being addressed. These include: –
- Management representing the organization’s interest and who hold the purse strings.
- Product managers representing the market who have identified the problem, albeit from various sources and with different rationales.
- Technical team which needs to appreciate the value being delivered by the solution, as against being in a state of inertia of developing separate solutions.
The tool seeks to provide rationale and constrains, whilst defining the KPIs within which the solution is being designed.
Why should the KPIs of a platform component be defined?
A single component will NEVER solve the nitty-gritty of every stakeholder’s demand. If, however, we are able to package and measure the solutions being offered, against an agreed set of criteria, conflict management and business cases can be fairly easily justified. In other words, PC2M can well be considered a code of conduct of platform components with little or no exceptions.
Defining the PC2M
- Platform Component: A platform component is a defined set of common features which can be plugged into and configured for various scenarios spanning multiple products
- Concept Model: A concept model is a guideline that sets out the specific skills, knowledge characteristics and behavioral requirements that enable an individual to perform their job successfully
PC2M is a three-tier model providing value to a group of stakeholder at each level.
Complete
When a problem is resolved the solution offered must explain the how the solution resolves the challenge. An incomplete solution can result in a power struggle between products, while neglecting the big picture of platform components. This can soon turn into various products branching out the platforms components and converting them to product components.
A complete solution gives the confidence to product managers that the problems of the market they have highlighted have been addressed.
Configurable
The idea of a platform component (PC) stems from the fact that products in a domain quite frequently have common characteristics. There should hence be a common development and maintenance practices around the same. The platform component (PC) users should be able to configure the component with the attributes and dimensions according to the ecosystem (read product) within which the component is supposed to work in.
Reusable
At the heart of PC2M model is the reusability aspect of components. When an organization wishes to venture out in a new area of the domain, the component(s) must provide the basic infrastructure using new use cases that can be delivered at lightning speed while building upon the configuration hooks featured in the previous sections. Imagine plugging a component which has been tested with other use cases in defined boundaries in real world is able to deliver value from the word go. Provided the addressed market remains constant. It is a guarantee of not only higher profit but also of confidence.
Incorporates Industry Best Practices
While we may venture out to discover the problems of the market, good solutions might already exist. Robust industry knowledge of the trends and technological innovations comes in handy while trying to solve new problems. It is always easier to stand on the shoulders of giants and take a leap, as opposed to trying to jump off the ground.
Certified
Certification refers to act of providing an official statement attesting to an achievement. From a platform component standpoint, the types of certifications must be embedded in the proposal of solutioning. Certification provides the necessary confidence that the component being developed is thought through and not only by the individual involved in the solutioning process.
Certification may include but may not be limited to
- Validation
- Verification
- Security Certification
- Process Compliance certification
- Regulatory certifications
- Benchmarking certifications
NFR compliant
In the race for functional completion, solutioning is often has an oversight in the non-functional areas. While a functional solution provides confidence to the product management teams, NFR provides assurance for the technical teams who are consuming the component. The system integrators (SI) expect hygiene to be inbuilt into the product solutions. When doubts are raised, the confidence of SI and technical implementation is lowered. Auditing capability, data retention, maintainability, extensibility etc. are expected to be out of the box.
Defined Boundaries
The definition of the PC helps to derive the boundaries within which it will operate in. Requirements from a particular product must not disturb the boundaries within which the PC was envisaged to operate. This is because boundaries help limit the clutter, set expectations and create a levelled playing field for all products.
While defining the PC, a major question to be asked assuming the PC was an independent entity is, “What is the Platform Component in the Business of?”
Documentation
An essential part of having a component which will be used by multiple products is to have sound documentation. This is not only intuitive, but simple as well. A defined set of documents which product requirements, interfaces, design ensures the SI journey remains smooth. With setups of sandboxes, SDKs and crisp documentation, the technical team will remain enthusiastic and motivated. In cases where significant code level digging is required, technical teams are generally dissuaded to use a new component.
Interface Driven
The platform component is meant to be used by a lot of products. Unless the component is clear in its interfaces the products cannot use it seamlessly. The intuitiveness of the interfaces should be such that products are able to build use case around their requirements with minimum efforts. The interfaces must there be clearly defined to cater to the simplicity of their design while hiding the enormous complexity in the backend.
As an ending note, the PC2M model does not describe what we don’t already know. The thought behind the same is to articulate and measure what we know. This is to manage the expectations of a platform complement and project its true value. Whilst solving the challenges it was meant to.
This article is also available on Medium via https://medium.com/@mfs.techblog/the-platform-component-concept-model-935ea43a409a
