Platform Components Re-use Strategy

Re-use is one of the most iconic "holy grails" in the IT industry. However, as any seasoned software architect knows, achieving successful re-use depends on the context and requires careful consideration of several key factors.

To validate the correct choice, we must evaluate re-use against clearly defined value drivers that take into account the following aspects:

• Economic: What are the cost savings versus the cost of integrating the re-used component? Will re-use really lead to significant reductions in development time and resources, or will it introduce new complexities that offset any potential gains?
• Flexibility: Is the reused logic flexible enough and appropriate for the context? Will it be able to adapt to changing requirements and evolving business needs, or will it become a rigid constraint that hinders innovation?
• Strategic: Is a custom solution strategically differentiating, or can a more standardized approach be used? Will re-use enable us to focus on core competencies and competitive advantages, or will it divert resources away from high-value activities, losing strategic skills?

In this article, I will delve into some aspects of re-use, highlighting key points and important considerations to keep in mind. I'll explore the benefits and challenges of re-use, and discuss how to strike a balance between the desire for efficiency and the need for flexibility and innovation.

By examining the complexities of re-use through the lens of these three critical factors, we can make conscious choices to unlock the full potential of re-use in our software development endeavors.

Components Granularity

Software reuse can occur at various granularity levels, from libraries to frameworks to platforms, each involving different roles and considerations.

• Library: developers can reuse individual components or utilities, such as logging or encryption libraries, to accelerate development and reduce duplication of effort. This type of reuse is often driven by technical leads or senior developers who recognize the benefits of leveraging existing code to solve specific problems but need to be governed to manage potential risks (E.g.: Log4j vulnerabilities).
• Framework: At this level, application architects may reuse entire application frameworks, such as web frameworks or messaging frameworks, to establish a common architecture and reduce the complexity of building new applications, by adhering to the framework conventions (E.g.: Spring, Angular, ...).
• Middleware: Selecting a general-purpose infrastructure, providing a common technical and operational ground. E.g.: Web/Application Servers (IBM WebSphere, Tomcat, JBoss, ...), Databases (DB2, Postgres, Oracle, ...), and others.
• Enabling Platform: At this level, executives and business leaders may reuse entire cross-industry platforms, such as enterprise resource planning (ERP) systems or customer relationship management (CRM) systems, to drive business agility and reduce costs. This level of reuse requires a broad understanding of the organization's business needs and goals, as well as the ability to integrate the platform with existing systems and processes. E.g.: Salesforce, Siebel for CRM,  IBM Maximo for  Asset Management, and  SAP for ERP.
• Business Platform: Industry-focused solutions, providing specialized workflow and data models, that can accelerate the adoption of industry-specific best practices. E.g.: packages in the Travel and Transportation industry, from more general purpose (Sabre) to railway-specific (DELMIA Quintiq, IVU, Sqills) solutions.

Regardless of the granularity level, software reuse may offer numerous benefits, including reduced development time and costs, improved quality and reliability, and increased consistency and standardization across the organization. However, these benefits must be quantified against the adoption cost and risks through an appropriate selection process.

Selecting Components

When it comes to component selection, it's essential to approach it as a Fit-gap exercise, weighting the solution Requirements against the component Features.

On the Fit side, we need to consider the net Actual Value being provided by re-using the component. On the Gap side, we must focus on the misalignment between Requirements and Features, evaluating both the actual Gaps and the impact of Unnecessary Complexity introduced by integrating non-essential features.

Two extreme scenarios, in which the re-use choice is simple to validate are:

• Focused Component Integration: The re-used component provides a clearly defined subset of the required features, which can be integrated with minimal unnecessary complexity. This is a typical re-use scenario for a common, easily consumable library or service that fulfills a specific requirement in isolation, such as Geocoding APIs or libraries that convert coordinates to addresses.
• Large Platform Adoption: The re-used component provides a full platform, including processes that fully cover the requirements. The benefits of full adoption, with minimal gaps to be filled, outweigh the additional costs of eventual unneeded features.

However, in many real-life situations, the choice is not so clear-cut. In such cases, it's worthwhile to evaluate the underlying flexibility of the integration process to determine the best approach for component re-use.

Integrating components

Here I highlight two common reuse patterns, Library and Framework, very much visible at the code level.

The key difference between the two is that a Library provides very specific features as a service, but does not impose a definite structure to the calling solution. The lock-in in the API definition is limited and can be more easily managed.

On the other side, adopting a Framework requires adhering to the framework conventions that impose an external shape and structure on the application being developed. The benefits of this structure (which can greatly simplify development) must be weighted against a stronger lock-in that is more complex to manage.  

When this dichotomy is at the technical level, the adoption of a commonly used framework that provides technical guidance and best practices is easily justifiable by comparing costs and risks.

As the granularity of re-use increases to the Enabling or Business platform level, organizations must exercise caution when adopting industry solutions. While these platforms may offer cost savings, they can also lead to vendor lock-in, which can be detrimental to their business. If the platform doesn't fully align with the organization's business context or strategic goals, there is a big risk of losing differentiating features and skills. Moreover, organizations may become overly dependent on the platform provider, which can introduce significant risks. For instance, what if the provider discontinues critical features or even the entire platform? This could have a devastating impact on business operations.

Conclusion

By involving the right roles and considering the various aspects of reuse, organizations can unlock the full potential of software reuse and achieve significant business value.

Particular care should be taken on adopting large platforms since this decision has a big potential business impact on competition differentiating skills and capabilities. Here I highlight the need for a decision framework like CBM and Product Engineering, to identify and communicate the correct strategy for each component.