Service integration is key for agility

I posted 3 years ago a similar message on this blog. Looking at the different conversations around, I think it is still quite valid. To give it a larger audience, I am reposting it in English

Service integration has been there for a while

Without looking back to IT origins, IT integration has been available for many years : Remote Procedure Call (RPC) for example was proposing some help to integrate systems together.
This proposal has been improved overtime with DCE, Corba, J2EE, Webservices and now cloud APIs

Service integration brings a complete different proposition from data integration which has been used for ages and remains still very popular. It consists in integrating ready to use services instead of integrating raw data. Data complexity is then hidden behind a service. This layered architecture is bringing a lot of benefits out of which reuse is key.

Reuse is the key word

Reuse in IT is a quest of Grail. Over the years many attempts have been seen, most of them being unsuccessful. What service integration is bringing is that systems can be much more independent, cloud bringing this a step further, where the outsourced service is completely independent from the application which is using it. 
This is facilitating integration because the two systems to have no in depth knowledge of data representation, they share a documented well know interface.

Reuse is key because companies have invested over the past, billions in IT systems and they cannot simply throw those legacy systems away because a new technology is popping up ! For the sake of agility, integration is key : no need to rebuild from scratch what has been built before. Instead, reuse is accelerating time to market, development been focused on the new functionality/technology

Service integration saves time

Integrating a legacy system is a good example of how service integration is providing value and agility : legacy systems are delivering proven services and maintain a lot of key data. How to benefit from these assets through new channels like mobile, pads or simply in a web browser ? Should the legacy system been ported on a newer technology ? Porting is both expensive and slow... Building services out of the legacy (keeping in mind the proper granularity) and integrating those services with the new technology/channel is by far quicker and cheaper.

As a concrete example, a bank, in the beginning of the 90's, was owning a financial engine made of more than one million lines of Fortran 66 associated with a large proprietary database. This company was at that time introducing open systems to users which was giving  a much better user experience but lacking the powerful computations provided by the legacy system. The solution which was gradually introduced was to define from the legacy a set of high level abstract interfaces on top of which new applications were built on the open system platform. This was delivering the best of both worlds, user friendliness and advanced computation capacities
More recently, same applies for companies willing to introduce mobile services. All data and services are already there in legacy systems but unavailable to new channels. In insurance industry, car damage insurance benefits a lot from mobility : pictures can be taken on site by the user, garage, expert and fill the file which is maintained on the legacy. Building web services or using any kind of service integration technology on top of the legacy unlocks existing data and services. In that example a mobile app was build using services from the mainframe such as opening and validating a case, adding new information to a case, ... 

Service integration is not a technical matter

This shows clearly that service integration is not (not only) a technical matter. Service integration means that services are defined functionally. In those examples even if the starting point may have come from a technical integration, very soon in the project, the need of a proper definition of a consistent set of services was raised connecting with Enterprise Architecture.
Understanding up front what are the 50 key services an IT system should offer is helping to success in service integration.
Service integration can leverage Enterprise Architecture, implementing concretely services that architects have identified.

Of course one could argue, that leveraging on old technology is creating a huge maintenance problem : how to maintain legacy cobol systems ? and what if these systems are used also by newer applications making them impossible to decommission ? In fact, this argument is more related to life cycle management rather than service integration. If a legacy system is still using old technology it is not because of service integration !
Instead, service integration is providing flexibility isolating producers from consumers and allowing a decoupled life cycle along the value chain. 

Cloud, SOA, Distributed computing, RPC same potential pitfalls !

It is a while since client/server technology has been first introduced. Technologies have been improving with RPC, distributed computing, SOA, ESB, cloud, ... but the same doubts are always around the corner : this technology XY does not work, is not performing, ... even if we have with web2.0, daily, in front of us, a proof that distributed computing and cloud works.

What is the root cause of these concerns ? This is mainly coming from the lack of understanding of what is happening behind the scene. Even with primitive client/technology, developers could ignore what was happening behind their SQL statements or their stored procedures. Network latency, network stacks, marshalling/unmarshalling are more and more hidden from the developer. Therefore, today as in the past, granularity is not so much in focus. This leads to too small or too big services that are either not efficient or not responsive enough. Executing a simple addition through the network has never been and is still not a good idea neither is transferring 1GB of data to call a service.

These problems are also coming from a common pitfall : the lack of IT urbanization. Without a clear vision of the services to implement coming from a functional map of the essence of the information system, services tend to be multiple, redundant and, in one word,  inadequate. If such a map is not defined, it is then very difficult to have any control on the service granularity. As an example, some organizations are using service directories to try to organize and manage the profusion of services that have been created having in mind mainly a technical approach.

To ensure success, a list of services should be defined before hand matching design principles and non functional requirements (like granularity) so that the use of services is performing as expected. This approach is also preventing redundant services which are creating maintenance nightmares... as with more old fashioned technologies!