The vision of Service-Oriented Development, beyond Service-oriented Architecture

See AMP Version

We would like in this post to return to the idea, beyond the Service-oriented Architecture, to the vision of Service-Oriented Development because it really is something, considering that many argue that, in IT, there was a before and after SOA Architecture!

And the reason is quite simple because, with the service-oriented architecture (SOA), the developed services found themselves at the heart of the Information Systems architecture, as an interface with both the fundamental applications and the data.

Although this may not be obvious at first glance, many developers have suddenly gained some leeway, freedom of design, some say newly enhanced creativity.

(TRIDENS, 2011)

Indeed, developers have been able to focus all their attention on the specificity of the services to be developed, being less restricted by integration constraints to applications and data; thus, they were able to more easily optimize the functionalities critical to operating their services.

This is one of the direct benefits of service-oriented architecture.

In doing so, they have developed a culture of service-oriented development because in developing services, it is quite natural to distinguish what is common to any other similar service in our business domain from what is specific. We come to categorize the functions of our services in generic and specific types. This is how service-oriented architecture (SOA) gradually takes shape.

And we develop generic functionalities and specific functionalities, more specialized ones, that we could describe as “domain-driven”; specific to a very sharp business-specific area in our business domain and even, specific to a business process in our business.

A very simple example would be a general image recognition service, a medical image recognition service and a facial recognition service for the police.

It is easy to imagine that all these services can interface with hundreds of image banks and have a generic categorization engine and depth, three-dimension, color, shape, human, animal, etc., generic recognition functions.

Thus, it will also be understood very well that the medical image recognition service has a specific organ and human skeleton recognition algorithm that relies on a service of depth, three-dimensionality, colors, shapes, etc., generic recognition functions.

Similarly, it is easy to imagine that the police facial recognition service has specific functions of human faces extrapolation from cross-sectional photos or shaded faces, but which will first rely on generic recognition functions of depth, three-dimensionality, colors, shapes, etc.

Thus, in the vision of Service Oriented Development, we will develop the functions of our services on the basis of this distinction; generic and domain-driven. This dichotomy is fundamental to Service-Oriented Development.

Another equally important concept is the autonomy of a service. Thus, as part of its medium and long-term IT development, a company will develop many services. A good service-oriented development practice is to aim for the complete autonomy of services and functions they develop; namely, that a service can be called by other services or applications and “deliver” without the help of any other application or service. To do this, the functions developed for the service will have to be autonomous, able to execute and deliver their expected outputs without any other need than the expected inputs.

Thus, one could think, in the example of the image recognition service, that the three-dimensionality recognition functions make use of the (autonomous) recognition functions of shapes, colors and depth! This perfectly reflects the spirit and structure of a Service Oriented Architecture.

Service-Oriented Development Vision Creates Service-Oriented Architecture

Thus, the dichotomy between generic and specific functionalities generates so-called generic services that will be reusable and naturally calls for, creating, a layer of services between Information Systems (IT applications) and data.

In a nutshell, Service-Oriented Architecture (SOA) is the result of Service-Oriented Development’s vision and not the other way around.

Service-Oriented Development, Advantages

This way of seeing development, breaking down development into specific and generic features, has a significant advantage; that is, so-called generic (and autonomous) services are, in essence, “reusable” by other departments, divisions, and other services. Thus, they will save time and costs in terms of development costs for the company in the future.

In addition, if they are reusable by other services, as in the case of image recognition services, these services will also have good commercialization potential, revenues.

Finally, since these are services developed with generic features, they should theoretically create no obstacle in terms of updates since they did not require custom development, unlike “domain-driven” features. This can represent potential… substantial savings.

It’s the Vision of Service-Oriented Development That Creates Service-Oriented Architecture

Thus, the dichotomy between generic and specific functionalities generates so-called generic services that will be reusable and naturally calls upon a layer of services between Information Systems (IT applications) and data.

In a nutshell, Service-Oriented Architecture (SOA) is the direct result of the Service-Oriented Development vision and, not the other way around.

Service-Oriented Development, a Cloud Premise…

The other aspect of service-oriented development, the autonomy of a given service (generic or domain-driven), also has advantages.

When a service can exist on its own and “deliver” without the help of any other application or service since it relies essentially on autonomous functions then it is considered a micro-service.

Microservices can easily be hosted in the Cloud and are, therefore, the first step of your business towards the Cloud or if you prefer, a gateway to the Cloud.

Event-driven vs. Domain-driven

Finally, in an ideal world, services developed (generic or domain-driven) are called at the right time for the right reasons but a service does not call itself spontaneously, it is called!

Thus, it is necessary to provide an alert, a “trigger”, a triggering event that will launch or call a service or services; we then speak of “event-driven” functions or applications.

Event-driven applications or functions will call services, and they will be used to govern the exchange (I / O) between the services, systems, and applications of a business.

 

Conclusion

Service-Oriented Architecture (SOA) offers many advantages including significant savings in development costs and offers a financial potential in terms of reuse and commercialization of the services developed.

 

Happy development… no matter your orientation,

Denis Paul & Michel

Leave a Reply

Your email address will not be published. Required fields are marked *