ACADEMIA Letters

SERVICE-ORIENTED INTEGRATION ARCHITECTURE

FIFTEEN YEARS LATER
Mario Bolo, Instituto Tecnologico de Buenos Aires

a. What was service-oriented integration architecture about?

About 15 years ago, the author published an article (in Spanish) called Service-Oriented In-
tegration Architecture, which had some impact at the time in Latin America. At that time,
he was working as an IT architect at IBM Argentina, and the ideas presented in that article
reflect to some extent the views of that company, but in general, those ideas were shared by
most Service-Oriented Architecture (SOA) solution providers.
The central idea of SOA was to create a set of services, representing the different business
functions of an organization, based on existing applications. That is, SOA did not propose to
change the applications but rather the way to invoke them. What the services were to provide
was a standard way of invoking the business functions of the company, based on the W3C
web services specification, in turn based on XML.
The standard interface of the services was its visible part. Backwards, so to speak, the
services would integrate one or more pre-existing applications, adapting the data formats, the
protocols, and even orchestrating the applications to implement their business logic. This was
the hidden part of the services, which therefore behaved like black boxes: the way to invoke
them and the response they could deliver was known, but not their implementation.
Responsible for all the “magic” described above was the Enterprise Service Bus (ESB),
which thus became the very heart of SOA. The ESB was the component of the architecture in
which all the organization’s services were exposed, and it was responsible for the integration
of the pre-existing applications.

Academia Letters, January 2022 ©2022 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: Mario Bolo, bolomario@gmail.com

Citation: Bolo, M. (2022). SERVICE-ORIENTED INTEGRATION ARCHITECTURE FIFTEEN YEARS
LATER. Academia Letters, Article 4621. https://doi.org/10.20935/AL4621.

1
 The ultimate goal was to create a portfolio of services that represented all the business
functions of the organization. Once that portfolio was in place, new applications for the or-
ganization could be created, just orchestrating the services. By recombining those services,
these applications could quickly adapt to changing business requirements, giving the business
great agility. Ultimately, maintenance costs would be lowered and time-to-market would be
reduced. These were undoubtedly very attractive ideas.

b. Which were the results?

These ideas were partially implemented by many companies and organizations of all kinds,
all over the world, with some degree of success, but organizing the various applications of
a compnay in a SOA is a promising vision which however implies certain difficulties due to
the complexity of the interrelationships between th applications. In fact the difficulties are so
great that, in the long run, many companies found it practically impossible to overcome them.
We are going to refer to some of them below.

Which services does my organization need?

First, there is the difficulty of correctly defining the organization’s services. This issue is
crucial because something that is assumed, but not always made explicit, is that in SOA,
services do not change. A metaphor widely used in those years, compared SOA with a LEGO
game: the services would be the LEGO pieces, and the applications, the things that one builds
with those pieces. Here it is very clear: the pieces do not change, only the way of combining
them changes.
We can take the metaphor even further: most LEGO boxes only offer two or three prede-
fined assembly possibilities with the parts supplied by the box. This is a limitation that we
do not want to have with our portfolio of services, and is useful to illustrate the difficulties
involved with defining the right set of services.
Having a good set of pieces –services– is therefore essential to be able to assemble all
the organization’s applications with them. Services that are too specific, would probably be
useful for some applications, but not for others; too abstract services might not be easily
usable. Which is, therefore, the correct degree of granularity?
There are methodologies that help to face this problem, but they are complex, and not only
because of the difficult technical issues that must be solved. There are also organizational
structure issues. Without going into all the details, it is clear that, by its very nature, the
ultimate goal of SOA cannot be achieved quickly. On many occasions it happened that, after

Academia Letters, January 2022 ©2022 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: Mario Bolo, bolomario@gmail.com

Citation: Bolo, M. (2022). SERVICE-ORIENTED INTEGRATION ARCHITECTURE FIFTEEN YEARS
LATER. Academia Letters, Article 4621. https://doi.org/10.20935/AL4621.

2
years without tangible business results, the SOA project ended up losing the support of the
executives.

The corporate data model and data dictionary as requisites

SOA has another hypothesis that is not always made explicit: we said that, when services
are created from existing applications, the data formats that these applications handle have to
be adapted, because it often happens that different applications handle different data formats.
This involves defining a canonical format for each data item -in other words, a corporate data
model. What we are refering to is the company’s overall data metamodel that, while not
impossible to define, adds a big additional difficulty to SOA projects.
Additionally, different applications often handle different semantics. Notions as basic as
those of customer, or product, do not always mean exactly the same for different sectors of an
organization. So, in addition to a data model, SOA requires a data dictionary that standard-
izes semantics. This is not easy to achieve and has a potential impact on the organizational
culture. Again, problems that are not impossible to solve, but complex, which are added to
the difficulties already mentioned.

From process to data

The last factor we will mention is that, in the last decade, the focus shifted from business
processes to data. The huge amount of data, caused amongst other things by the explosion of
social networks, the Internet-of-Things, and hyperconnectivity (ubiquitous networks, mobile
applications), has configured a type of worker that, rather than being part of a process where
they are assigned tasks, make informed decisions as part of an interdisciplinary team. We
are referring, of course, to the typical worker of the economy of knowledge, made possible by
having all the information just a click away, on any device and in any place.
This does not mean, of course, that the business processes have become obsolete. To
claim such a thing would be crazy. But it can be said that SOA, with its strong link to business
processes that are created by orchestrating services, has long ceased to be in the focus of
executives’ interest, having been displaced by data analytics, both descriptive and predictive,
and associated technologies, such as machine learning.

Academia Letters, January 2022 ©2022 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: Mario Bolo, bolomario@gmail.com

Citation: Bolo, M. (2022). SERVICE-ORIENTED INTEGRATION ARCHITECTURE FIFTEEN YEARS
LATER. Academia Letters, Article 4621. https://doi.org/10.20935/AL4621.

3
c. Conclusion: what is left of SOA today?
In the opinion of this author, SOA was in some sense another silver bullet, that promised to
solve a good part of the problems of information systems and, like so many others before it,
did not live up to its promises.
However, like other similar solutions of the past, SOA left many very good ideas, which
today are considered almost common sense, and have been widely adopted. We will finalize
this short paper commenting some of those ideas.

From services to microservices

It is widely accepted today that, designing applications in a modular way, that is, made up
of loosely-coupled independent modules, has many advantages. For example: it makes in-
cremental development easier; It helps to better balance the load, by allowing the most used
modules, or the most resource-consumer ones, to run on separate virtual machines or contain-
ers; it helps different teams develop different modules independently.
This idea is specially helpful in the current era of business scenario where due to global-
isation the business is expanding with tremendous growth and most companies are having a
number of branches like financial services , educational services , online shopping etc. Com-
panies like these can benefit of a backbone architecture which will govern equally all the types
of businesses and can apply equal rules for accounts, discounts , marketing etc. The best ex-
ample of this service integrated architecture is SAP which is adopted worldwide by thousands
of companies.
Now, in cases like SAP, the problem of the correct definition of services disappears, or
at least is tempered. It can be said that the root of this problem is that services are supposed
to be built from legacy applications. SAP, and other similar applications, on the other hand,
provides a set of services and an integration infrastructure out of the box, which in many
cases become the corporate de facto integration backbone. This approach has been effective
for many companies all around the world.
In smaller scale, in today’s world, applications are developed based on services which
are part of those applications, and therefore tend to be much more specific and granular than
services in a SOA. Microservices based design, widely used today in web and mobile appli-
cations, has a lot to do with the ideas that we are commenting here.

Academia Letters, January 2022 ©2022 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: Mario Bolo, bolomario@gmail.com

Citation: Bolo, M. (2022). SERVICE-ORIENTED INTEGRATION ARCHITECTURE FIFTEEN YEARS
LATER. Academia Letters, Article 4621. https://doi.org/10.20935/AL4621.

4
Loosely coupling
We mentioned above that the modules that make up an application –microservices for instance-
should be loosely coupled; this notion enjoys wide consensus today. The fact that modules
behave like black boxes contributes to loosely coupling: you can completely change the inter-
nal implementation of a module without affecting any other, as long as it continues to respond
to the same interfaces. The loose coupling makes the different components of an application
independent, thus facilitating their maintenance.
Asynchronous communication between modules –for example, through messaging mechanisms–
is another way of decoupling components, since it is not necessary for one of them to be active
when another needs to send some information to it. The issue of asynchronous communica-
tion between services was emphasized by some SOA solution providers, but not by all of them.
Today it is a widely used pattern in microservices-based design.

Standard interfaces
It is widely accepted today that the standardization of interfaces is an excellent practice. Al-
though web services have lost a lot of ground compared to REST APIs, which are much
simpler and more agile, the idea remains essentially the same.

Conclusion
SOA projects involving organizations as a whole are no longer in good health today. How-
ever, many of the ideas of SOA, conveniently aggiornated, remain valid and can be used to
advantage in the development of today’s world applications.

Academia Letters, January 2022 ©2022 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: Mario Bolo, bolomario@gmail.com

Citation: Bolo, M. (2022). SERVICE-ORIENTED INTEGRATION ARCHITECTURE FIFTEEN YEARS
LATER. Academia Letters, Article 4621. https://doi.org/10.20935/AL4621.

5
 Note: a reviewer notes that “given the scalability of applications and the interrelationships
between them, an SOA architecture representing them may seem rigid. Some authors have
worked on the adaptability of SOAs to dynamic environments. It might be necessary to enrich
by integrating into the solution a study on the adaptability of SOA in dynamic environments
and use the solutions recommended by these authors”. The comment is interesting, but a
study of this kind is beyond the scope of this brief article. On the other hand, the author is
somehow skeptical about the adaptability of SOA to dynamic environments, and believes that
the rigidity of SOA is a consequence of the fundamental principles of this architectural style.

References
SOA

Application Integration

BPM

Academia Letters, January 2022 ©2022 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: Mario Bolo, bolomario@gmail.com

Citation: Bolo, M. (2022). SERVICE-ORIENTED INTEGRATION ARCHITECTURE FIFTEEN YEARS
LATER. Academia Letters, Article 4621. https://doi.org/10.20935/AL4621.