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. 

MIS : profit or cost center ?

Three years ago, I posted 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

The scope here is not industrial data processing which definitely is part of core business as a plant is. Some companies are therefore organizing IT in two separate groups to manage industrial data processing on the one side and business data processing on the other. The scope of this talk is only business data processing.

Business data processing is coming in two main flavours which look similar but differ quite significantly: cost saving IT and revenue generating IT

Cost saving IT improves existing processes

This IT belongs clearly to support functions and delivers support to bring processes cost down. Examples are accounting, invoicing, inventory management …

Revenue generating IT is core business

This IT is not only providing support but also enables new products and businesses. Therefore it is core. Thanks to its information system, a company can develop innovative products to differentiate itself from competitors. The IT system becomes as important as a plant or any other production means: it is delivering products to customers. In past years, this used to be the case only for few industries: capital markets where products are completely digitalized and managed through IT or mobile telephony where accounting is key to invoice innovative and competitive products.

The more digital we get, the more IT becomes a profit center

The world is changing… since I wrote the original post three years ago, our world has become even more digital. E-commerce is mainstream and obviously there, IT is a key differentiator. Regular products are now sold with embedded digital services: the UPSs of this world are not only delivering packets but also services. Their reputation can be seriously damaged if their IT is off. The same applies for car manufacturers, cars are sold with digital service like telediagnostic, remote assistance which are designed as part of the product.

Managing cost saving IT or revenue generating is totally different.

Of course, in the light of those two examples, one understands that these two different IT cannot be managed the same way. The first one is cost driven, servicing its customer for the minimal cost, potentially impacting quality. Minimizing the cost is often driving to outsourcing and off shoring in order to share cost. This is made possible because cost saving IT is optimizing existing processes, which are supposed to be well-known and documented. Therefore a close relationship between IT and users may not be perceived as a key element.

For revenue generating IT, the approach is completely different: it is not only cost driven. What matters is that the product which is embedding an IT service is delivered in due time, matching clients expectations and bringing added value. This is core business. Of course here as well, external providers could be used but not in a full outsourcing mode as companies need to control their core business. IT part of those products is built in a tight relationship with other parts of the product. Therefore, off shoring is difficult to apply there as it creates an increasing distance within the product team.

Do not get mixed up !

As presented here, those two flavours of business IT look the same but are fundamentally different, approaches and means are dissimilar. Not recognizing those differences creates "hybrid" strategies which may be quite hampering.

When a CIO running a revenue generating IT forgets about his specificities, trying to lower cost through outsourcing and off shoring, he is going on the wrong path. Quite soon, but unfortunately not immediately, outsourcing creates the distance mentioned earlier. Existing teams are not understanding the strategy anymore and get demotivated. IT is then no longer able to bring the value it used to bring to core business.

As a symmetrical case, thinking that one can transform a cost driven IT into a successful revenue generating IT is a mistake. A cost driven IT is very far from core business, has usually not a service oriented behavior and cannot easily cooperate and communicate with other departments to shape a new product. An amazing lot of articles and books dealing with this issue of filling the gap between IT and business are evidences that cost driven IT cannot move to core business overnight!

This is explaining some of the issues we face in IT departments when positioning is unclear, creating huge frustration both on the business and the IT side.

Since I wrote this, I have found a complementary view on the same topic

Trust is IT fuel

Every outage makes IT look bad !

Running an IT system is difficult: whenever an outage is popping up, IT department is looking bad in front of its customer, very often looking for the guilty one. This natural inclination to finger pointing has to be fought as much as possible: it is not improving the relationship with the customer and not improving the system either. No need to say that, from a management point of view, this is creating even more damages: by definition, people are making mistakes and finger pointing will encourage them to cover their position or even to hide facts.

Everyone has been confronted with this very annoying situation in which the whole system is down but every sub component is working fine! This is a typical situation where looking good as an individual is more important than solving the issue the company is facing. Therefore everyone is defending himself instead of collaborating for solving the issue.

Finger pointing does not help solving an issue !

This finger pointing behaviour is generating fear and angst which are blocking any improvement process. Who would be keen on changing something which may generate a problem? Even worse, very often people are hiding failures making it impossible to identify the root cause. I am sure this will ring a bell for many of us: how much time have we spent trying to understand implausible arguments that were trying to hide evidences?

Another negative impact of this kind of lack of trust is that IT tends to fix immediately the outage, overreacting to prove how good it is: “of course, we had an outage but it has been fixed immediately… !”

All these trends are tending to hide or at least not to analyse the root causes of the faced outage, therefore, no improvement is then possible and those outages will occur repeatedly.

Are we sure this will not happen again ?

There is only one question which really matters: "Are we sure this will not happen again?". If this question is enforced by management and users, the focus move dramatically to understanding the root causes and improving the system

IT chains are complex, made of hundreds of components chained one after the other, therefore an outage may come from a root cause which is quite far from the faulty component. First level analysis is definitely not sufficient. Encouraging a deep analysis is not only mandatory to improve the overall reliability but is also breaking the vicious circle of suspicious relationships leading to better efficiency.

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!

Stop building systems supposed to work!

IT systems are complex, made of many collaborative chains. Reliability is of course a key word but resilience should be also considered as a key aspect improving reliability. If potential failures are part of the initial design, resilience and therefore reliability will be greatly improved.

Very often IT systems are designed as if they were working perfectly. This may be true for each single system but as a matter of fact it appears often not to be true globally! Perfection is often out of reach and this input should be considered from the design phase

Systems that are not designed to behave nicely in case of failure create all sorts of issues on downstream systems.

Let's illustrate this by a very common pitfall: a data (file or unitary data) is missing, what should we do? Block the entire process without processing anything or just skip the missing data and process whatever you can, performing a partial rerun when the data is becoming available ?

Of course, the second option seems more sensible but unfortunately rarely implemented even manually through a process.

Just to highlight this point, a little anecdote: once, as an accounting system was computing million of transactions for end of month results, it got blocked because a currency value was undefined. Fortunately, as the process was considered sensitive for the company, a manual check was performed throughout the chain. This failure was detected during the night and the on call manager who had not the faintest idea of the possible value decided to set it to 1€. The process could start again, and the next morning accountants were able to manually fix the impacted transaction. Of course the run was not perfect but more than 99.99% of the goal was reached!

Even more common is the "cron" syndrome. Because open system developers have usually little experience in managing batches, they are not used to the capacities of enterprise wide schedulers. They are implementing batches with primitive tooling which ends up with very rigid chains which are not flexible enough to adjust should a problem arise.

As an example, very often batches are triggered at a given time and not upon a certain condition. Any delay in the upstream is then creating an issue on whole downstream chain. The same applies by the way with return codes which are not always fully implemented. Chaining jobs becomes then a little difficult without clearly knowing the exact status of the previous job.

Regarding batches, it is very common to see a black and white approach: either it runs or not. If not, nothing is produced, the error has to be fixed to rerun the complete batch. This of course does not fit for large batches that take more that minutes to complete. To increase the resilience of such batches, restart points have to be defined within the job logic so that the rerun is only performing the missing computation and not the complete job.

Data quality is not a common concept either: consolidation systems for example, by design, rely on the input coming from potentially hundreds of systems. Statistically, they cannot be right every day as most likely an input will be missing a day or another.

A way of managing such a situation is to implement fall back mechanism trying to estimate missing data, for example based on previous day input, and reflect this in a quality flag which shows how reliable the computed figure is.

In a nutshell, let´s move away from the optimistic approach and let´s build system that are ready to fail, having the needed fallback mechanisms implemented from the design phase!

I am back !

It's a long time since I have written something here!

As I have now many colleagues speaking english, I'll switch to something which will pass for English ...
I'll also try to post on a more regular basis (not so difficult) ...

See you soon