About reuse in an SOA strategy
The reuse of software has always been in mind when developing software in a professional way. We have all tried to guide the design of our software to a level of abstraction and encapsulation that would allow us to reuse it in future projects with null or minimal changes. Functions, macros, classes, user interfaces, controls, help systems, etc. Object Orientation moved the concept of reuse from its “good practice” status to the “basic principle and design goal” state. In fact the OO was an explosion of enthusiasm in the industry because finally it seemed feasible to think of large libraries of classes, with large inheritance hierarchies covering wide areas of scope that could be massively reused in many projects, transforming software development forever.
Unfortunately we all know that this never became a reality, but there is no doubt that the OO raised the reuse to such a basic level of principle, that everything that came afterwards, has taken it as an unquestionable starting point.
In SOA reuse plays a very prominent role. It is at the core of its objectives, for its contribution to decoupling information systems, homogenizing the organization’s system map, and drastically reducing the costs of IT projects. The mere proper use of standards, another SOA principle, has a positive effect on the reuse of services.
But it is easy to get carried away by the rush of reuse, and that is a problem. In an SOA strategy, it is a problem because it is usually a symptom of very abstract services, too abstract. And it makes it difficult to reach any business monitoring system. And outside of an SOA strategy, reuse is often an excuse to abuse the SOA concept.
If an utility or component is reusable, this does not imply that we are in an SOA scenario. In some currents of opinion that I have seen by the network and some ICT professionals, it seems that reuse is the biggest objective and exponent of an SOA strategy, but it is not. Usually, those who think like this are often mistakenly thinking that SOA is closer to the technology than it really is.
We can say that reuse is a necessary, though not sufficient, condition in an SOA strategy.
A very clear example: all operating systems, by definition, include a series of components that are clearly intended to be reused as often as necessary from different applications. For example, a printer driver. Does that mean that operating systems are SOA? Well, of course they are not. Moreover, from my point of view, this assumes a basic error: lowering SOA to a purely technological level, which in itself is a contradiction, since one the principles of an SOA strategy is to separate business from technology.
And it is still totally true that a printer driver, like any other device, is completely reusable, of course it is. Absolutely (and if it is not, what a driver!). There are plenty of examples in many reusable elements: all APIs of any programming language, all drivers of all devices that can be connected to a computer, mobile operating system apps such as iOS or Android … etc, etc.
But forcing the use of the SOA tag for these cases is forcing too much and confusing. The reuse of business services in an SOA strategy is one of the consequences that has the greatest impact on the organization where the strategy is implemented, by homogenizing the components that implement business processes throughout the entire system map, and reducing the costs of IT projects, both for new information systems and for corrective or evolutive maintenance. It is one of the improvements that brings an SOA strategy with greater impact on the ROI of the strategy itself. But by itself, it does NOT define an SOA strategy.
And then what is the correct reuse rate to look for in an SOA strategy? It depends. Basically in an SOA strategy you have to follow what the business states. If business processes show that a pattern or process or event is repeated three times throughout the organization, there it is. If it is repeated twenty times, there it is. And whether it is core business events, infrastructure services, or whatever, it will have to be reused whenever necessary. Here the key is, again, in SOA Governance. It is from there from where each case should be studied and maintain the right approach and proper granularity.