Features and Capabilities
Cars and Roads
Cars are owned by (or shared with other) riders, Their utility is transporting people from source to destination. Roads are shared resources, their utility lies in supporting vehicular movement. Good roads facilitate higher vehicular speeds, cause less wear and tear to cars, provide better safety, and can reduce travel time.
Building and maintenance costs of roads are amortized over time and vehicles. A good road system provides options for routes and costs(tolls).
Roads have a wonderful property, they can be combined in different ways on different routes. A builder of roads will have little or no idea of the routes cars plying on them have employed.
Building roads without anticipation of vehicular utilization is a waste. Building roads at the start of a journey is too late. Road construction should factor in utilization parameters and should precede vehicular movement.
“Cars and Roads” is a useful metaphor in software development. Features and capabilities map to cars and roads respectively.
Stakeholders are interested in features and feature implementation requires capabilities like security, persistence, configuration management, and transaction management. The functional and non-functional requirements of features have to build on the foundation provided by underlying capabilities. Otherwise feature development will be slow, if not unviable.
Semi-formal definitions
A feature is a service or function that meet(s) the need(s) of a stakeholder. Features may also be described as parts of a product that provide notable value to the user.
A capability is a technical ability of the platform that supports the expansion of business and can be crucial for driving business features.
Status Quo
Software developers are good at adopting capabilities, usually, these capabilities are developed by other teams and are domain agnostic. There are significant opportunities and challenges in the building of domain-specific capabilities.
Capability Mindset
Consider the following code snippet, which calculates simple interest on a bank account.
float interest (float principal, float rate, int months){return (principal * rate * months) / (12 * 100)
}
while the variables principal, rate and months have semantics defined at the business level, for the operators * and /, they are just numbers.
capabilities might operate at the same level of abstraction as the features, or might provide simpler levels, which the features need to map to.
Capabilities should be parameterizable as explained in the Fat server, Thin Client post. Parameterized capabilities can support a diverse set of features.
In most real-world applications, features need to work with a multitude of capabilities, while capabilities themselves might be dependent on other capabilities. Note that, capabilities never have dependencies on features.
Capability-driven designs tend to have the following meta structure.
One can see the following flavors
- limited interaction between features
- high fan-in from features to capabilities
- interaction between capabilities
- context-specific orchestrators providing abstractions to interact with capabilities
Orchestrators
Orchestrators can be imperative or declarative. In the case of the latter, they can be implemented as DSLs.
Orchestrators appear in multiple domains, like Haxl in Data access, Ansible in machine provisioning, Big Data, Camunda in workflow management
The development of domain-specific orchestrators is an underexplored area in software development and is expected to provide significant cost-to-benefit ratios.
