Connected Companies require platforms to lead this digital transformation. A set of APIs is a fundamental component of such platforms.
Agile and API’s
Today agile is a much debated principle in many organizations as the agile software delivery process is a fitting methodology to shorten the time to market of business applications. And obviously, API providers are doing their utmost to incorporate agility into their own services and business processes. But in this case, we don’t refer to agility as a software development process. Within the scope of this article we consider the agility of the API or the system as a whole at runtime.
What if the behavior of the API depends on the location where it is invoked? How flexible is the API related to an ever changing usage environment?
These questions need to be answered from an architectural point of view.
As our customers are always connected and eager to use our applications or APIs regardless of the moment, the location and the device used, we need to make sure our API architecture is ready to support this demand. We refer to these parameters as context information. With context parameters we refer to any information that can be used to characterize the situation of an entity. An entity is a person, place or object that is considered being relevant to the interaction between a user and the applications themselves [Dey and Abowd’s]. Using different context types, including location, weather, user activity, sensor data and nearby beacons, your app can better understand your users’ current situations, and use the information to provide optimized and customized experiences.
Customized user experience
The exploitation of contextual information concerning users and devices can lead to a reduction of the interactions customers have to obtain a customized experience. Sensor hardware used for gathering contextual information is highly available. The low-level sensing data, such as physical location, time and heartrate, can be used in order to infer higher-level contextual information, like situations for instance “morning jogging in the park”. The user experience in applications that depends on contextual information can be greatly enhanced by automatically providing contextual information derived from sensor data to these applications. So the link to incorporating the Internet of Things in the solution architecture of a Connected Company sounds like a no brainer.
The most appropriate design paradigm leading to these kind of architectures is service orientation. Services are the building blocks of the service oriented computing platform, each carrying out a specialized task and accessible through standard protocols and interfaces. Applications are formed by composing and recomposing services from the service inventory within the business domain. The main goal is to identify services providing reusable capabilities, being deployed only once and used by several applications. The same is true for APIs, whereby API providers aim at maximized reuse of their APIs.
We can see that both paradigms, context-aware computing and service orientation can help and reinforce each other. A context-aware system has the need to retrieve context information from diverse sources. Services to abstract from raw sensor data are the best choice to deliver contextual information to other parts of the context-aware system. On the other hand, service inventories may benefit from contextual information in order to improve the quality of search results and to be able to deliver highly customized behavior to the consumer of the services. The service discovery process can take advantage of contextual information, being able to present the most relevant service or API to be used in ever changing usage environments.
Paradigms like service orientation, API management and context-awareness will need some extra technologies in order to enable systems to build service compositions in a more automatic way, thus lowering the involvement of a designer or modeler (late (runtime) binding). What we need is a description of the services, IoT devices and possibly also data in a format that can be interpreted by the system itself, without human (designer) intervention. This description will be created using semantic web technologies. Based on these descriptions the system can discover the necessary parts that are able to fulfill the given request of the customer in a (semi) automatic manner.
In a glance
The image below depicts the key message of this blog post. All kinds of inputs are used to sense information about the environment in which the system acts, it translates this information into knowledge in order to adapt its behavior resulting in a more customized experience for both our customers and partners.
In my next blogpost I’ll go deeper into these descriptions and explain how these will can used in the architecture. Realdolmen has some of these components (cfr. SEE4SOA) at your disposal for your architecture and that take exactly these things into account allowing you to concentrate on the business logic in the services and APIs rather than on the underlying components supporting the connection company vision.
Johan Kumps, Solution Architect. For more information about this topic you can contact met at Johan.Kumps@realdomen.com.
Would you like to learn more about how a connected company can work? Contact our expert Roel De Cuyper, Division Manager at The Connected Company, at roel.decuyper@realdolmen.com.
If you would like to learn more about connected companies, read our earlier blogposts:
Become a connected company with these 10 principles
Proximus and IoT: a story about 'getting there together'
Blockchain is more than just a digital currency unit. Some applications that are already available today
CoZo goes mobile
PSD2: challenge converted to an opportunity with Secured Runtime