Matching Customer Intent with Provider Capabilities
Combining 5G connectivity with intelligent devices at the edge of the network is creating a framework for building immersive and impactful business solutions. These solutions will transform all types of industries, from agriculture and energy to cities and airports.
For the intelligent edge to reach its full potential, solution providers will need to deliver AI, IoT, computer vision, robots, and connectivity services - at scale. To serve the needs of all businesses, from SMBs to enterprise, these solutions must be tailored to specific customer requirements and desired outcomes – by matching customer intent with provider capabilities. This requires a paradigm shift in the way we compose and deliver solutions to adapt to business needs rather than business adapting to “one-size-fits-all” packaged applications – allowing businesses to control their digital future.
The concept of capability can be defined as “the ability to do something”. Although simple, it is a powerful concept, as it can be used to provide an abstract, high-level view of a product, system, or organization, offering new ways of dealing with complexity. It has been widely adopted in many areas, including in system engineering, where capabilities are seen as a core concept. The concept is considered particularly relevant for the engineering of complex systems-of-systems, which relies on the combination of different systems for achieving a particular emergent capability.
Within a conceptual model for system interoperability, a capability can be defined by associating an action (e.g., sense or sensing) to a concept (e.g., temperature). Each action comprises a unique set of attributes (aligning to the Action concept of Schema.org). For example, a sense action can comprise a value range (minimum, maximum) and precision (step). Beyond a set of top-level actions, a class hierarchy can create any of the more specific actions that may be needed for any given industry or environment.
A capability (e.g., sense temperature) inherits the attributes of its action. A service can be described by applying specific values to the inherited attributes of its capability. For example, a temperature sensing service may have a sensing range from -10 to 60 degrees Celsius, with a precision of 0.5 degrees. These “features” and limitations can be described using a “model” for a sensing capability.
When these capabilities are defined and modeled by a standards organization (SDO), every service based on these standard capabilities become inherently interoperable and interchangeable.
To evolve this solution delivery paradigm shift, SDOs and consortia must adopt models for foundational capabilities including management of the capabilities themselves.
A system can comprise multiple capabilities, and each capability can be offered as a service to other systems in exchange for some value. In ArchiMate, a service is defined as a unit of functionality (capability) that a system exposes to its environment, while hiding internal operations, which provides a certain value.
In a natively digital world, systems will dynamically connect and interact in real-time, forming and re-forming interdependent and interoperable systems of systems to achieve a higher goal or emergent capability. These systems need the ability to connect based on current context and understanding of their own capabilities.
This requires a “matchmaking” mechanism enabling both information and value exchange which does not rely on prior knowledge. Utilizing a universal approach for system interoperability, all capability-based services can be described through a system’s metadata which can be shared and understood by other systems. These services can include primary capabilities (e.g., temperature sensing) as well as supporting capabilities (e.g., data communication, money transfer) enabling both information and value exchange.
Complementary to the concept of capability is the concept of intent which specifies what a system, or the party it represents, wants to achieve. Intent allows a system to express requirements to other systems that may be capable of fulfilling those requirements.
For example, a building management system (System Y) may have a requirement for a temperature sensing capability offered as a service by another system. System Y can express its requirement as an intent, which includes the values and value ranges of the primary and supporting capabilities it requires. A matchmaking (or composition) service can identify a participating system (System X) within a network (or marketplace) with capabilities that best match the requirements.
Systems must be able to express requirements in a way that recognizes capabilities but does not involve details on how those capabilities are realized, enabling constituent systems to understand and act on them. It must allow dynamic changes in the requirements and separate the required capabilities from their realization.
When an intent handler (or matchmaking service) initiates a connection between two systems, metadata from each system, including service attributes, can be shared to define a contract. The contract between the connected systems, and their responsible parties, specifies the rights and obligations associated with services of each system and establishes parameters for interaction.
A multi-level system of systems, based on this approach for interoperability, can enable frictionless and dynamic interactions and information sharing for optimal decision-making and actions that drive high-value, sustainable outcomes for end-customers.