I’m from New York so when somebody in Chicago tells me they have great pizza, I like to say ‘you’re right, it’s great, but that’s not pizza, it’s a casserole.’ Similar ingredients don’t always lead to the same dish, and if we called all dishes with similar ingredients the same thing, we’d be seriously confused when ordering dinner. Our clients often ask us to help them evaluate their current digital platform and platform strategy and like pizza, it’s important to have a shared definition of what the heck a platform is before evaluating its benefits. It turns out there isn’t much of a common definition for the word platform, and it’s often used in very ambiguous ways.

At Nuvalence, we like to think of ourselves as builders so we needed something more concrete and came up with the concept of a Reusable Capability Model, or RCM, as an umbrella term to describe and categorize various types of software abstractions. Before diving into the actual architectural details of constructing digital platforms, we need to start with higher-order conceptual taxonomies. RCMs provide a more nuanced definition for ‘code that encapsulates reusable value.‘ We characteristically define RCMs based on whether they represent:

1. Reusable Code – The client app wants to exercise value encapsulated in the RCM and does so by directly calling functions in their most primitive, technology-specific form. The latter part of that sentence is key. Any invocation of software can be viewed as ‘code reuse,’ but some forms allow you to call code without having to call it in the native stack/language the RCM was created in. This RCM focuses on direct invocation of that code. An example of this is calling a function in an imported library (using native import/library binding semantics) from client code.

2. Reusable Functionality – The client wishing to exercise value encapsulated in the RCM does so by calling the RCM in question in a way independent of the technology that the RCM was implemented in. This allows the client to reuse functionality without having to know anything at all about the code, which is very different and more abstract than the Reusable Code RCM. An example of this is calling a REST endpoint.

3. Narrow Applicability – The RCM in question has a narrow, very specific set of use cases it’s built for. An example of this would be a matrix multiplication library or a framework designed for content management (different scopes but narrow within their scope)

4. Broad Applicability – The RCM in question is more horizontal in nature, not focusing on a specific set of client app use cases but rather in solving a more generalized problem. An example of this would be a lock-free data structure library or an operating system.

5. Invertible Control Flow – The RCM has its own general program flow but delegates control to client applications at key points, allowing the client to inject behavior into the RCM. An example of this would be an RCM responsible for sorting data, with the general sorting algorithm provided by the RCM but delegating the definition of “less than” and “equal to” to the client.

6. First Class Extensibility – The RCM provides clear cut-points allowing for extensibility without modifying the codebase of the RCM itself. This is typically done through some sort of plug-in/aspect cut-point model. An example might be a photo manipulation app allowing 3rd party creation and injection of image filters.

7. Embeddability – In order for a client to use the RCM, it must access the RCM by loading it into the same program space as the client. An example of this would be a client application loading a library into its memory space to call it.

8. Client Code Co-Execution – The client code runs embedded in the memory space of the RCM. An example of this would be downloading an open-source business analytics framework and using it as a “skeleton” so as it contains the client code within it.

9. Client Code Hosting – The client code runs as a separate memory space, logically “on” the RCM. An example of this would be an app running on a cluster technology or on an operating system (admittedly, there is some gray area here)

10. Client Application Awareness (multi-tenancy) – The RCM can uniquely identify dependent client applications accessing encapsulated value it provides, and may optionally “tune” its behavior on a client-by-client basis. An example of this “multi-tenancy” might be an API that offers preferential SLAs to certain client applications and not others, based on this ability to uniquely identify them.

Now that we have these characteristics, we can look at a common set of architecture abstractions and assign values. By doing so, we can start to more crisply define what we mean by each abstraction type. This is important if we want to clearly distinguish between a ‘platform’ and something else. For this write-up, we’ve defined Library, Toolkit, Framework, Service, and Platform RCM models along these ten dimensions. Having a summary understanding of each of these RCMs is important in order to properly interpret our taxonomy:

1. Library – A library is a collection of code that is invokable by a client external to the library itself. That is, libraries are collections of code “activated” by another piece of software that has included that library in its own runtime (e.g. memory space) as an embedded dependency. Generally, libraries have high cohesion.

2. Toolkit – A collection of libraries bound together by scaffolding code with the intent of federating related-yet-different functionality is a “toolkit.” Typically, toolkits allow for the inclusion of subsets of the collection of libraries, and some common code may allow the libraries to interact among themselves once embedded as a dependency by a client application. Generally, cohesion in toolkits is high but lower than any individual library.

3. Framework – Frameworks are macro implementations of the “Template Method Pattern” found in algorithm implementation designs typical to software engineering. A framework promotes reuse by defining an application/architecture skeleton, deferring parts of the application’s execution to custom code defined by a user of the framework. In this RCM model, the “custom code” represents a pseudo sub-application that is merged into the framework at compile and/or runtime. Frameworks promote both functional and architectural reusability.

4. Platform – Similar to a service, a platform is a runtime instantiable software layer. This software layer, however, is a federation of services with the express intent of driving functional reuse across well-delineated boundaries to more than one application. The federation of services is generally loosely coupled but shares a common operational plane, dramatically simplifying consumption for clients external to the platform. Platforms promote functional and architectural reuse with separation of concerns that aren’t possible in either framework RCM type.

These summary definitions are useful for conceptualizing the relationships between RCMs. There are many other RCMs that can be enumerated and defined in this taxonomy (e.g. a Service RCM would be an example) that we may dive into in future posts. Given the aforementioned RCM definitions and equipped with our ten characteristics, we define a taxonomy matrix as follows:

When defining or evaluating a platform architecture, this sort of matrix can help shape a clearer understanding of what characteristics are at play. By doing this, it becomes easier to define what needs to be improved/modified in a platform architecture, and how to communicate about the various traits a specific software abstraction might or might not have.

Hopefully, this helps disambiguate what a platform is and isn’t, at least technically speaking!

One thing I think is really important to note: this definition doesn’t prevent something from being a digital platform economically. Lots of technologies exist and act as hubs that enable various 3rd parties to execute commercial transactions. Measuring whether something is a digital platform in an economic sense is an exercise for a different writeup.

What RCMs are missing and should be enumerated alongside these as part of a broader taxonomy exercise?

Are there any characteristics that you think might be important to include?

When discussing ‘digital platform,’ is it a term that carries two definitions: a technical and an economic one?