Getting adoption in integration platforms
Integration platforms and projects have traditionally had challenges gaining adoption. To address that, whenever we work with clients that are undertaking integration work we always look at the project in the context of maximising the opportunities for successful adoption.
Clients who integrate successfully achieve significant benefits to their business, including improved flexibility, optimised business processes and unified views of disparate information systems.
We call this effect ‘positive platform adoption’. This is evident when the investment in an integration platform reduces overtime. Increasingly systems are making use of the integration platform because they see positive business benefit.
Unfortunately, many companies adopting integration platforms experience what we call ‘adverse adoption’, which occurs when the cost to deliver an outcome does not reduce over time. The business perceives little benefit, resulting in minimal adoption of the platform.
Research by Forester indicates that at least 50% of all implementations fall into this category. So how can we avoid this outcome?
The key to getting positive adoption is to recognise that it is almost impossible to affect the red ‘adoption curve’ line directly. Whilst a project may use the platform as it is instructed to in the project’s requirements, broader adoption occurs when the business sees the benefit and wants to further utilise it.
Therefore, the only line that may be directly affected is the ‘investment for outcome’ curve. Adoption occurs when the lines cross. This means that the key to getting adoption is to get the investment for an outcome to drop as rapidly as possible, while still maintaining a quality outcome and producing reusable/repeatable components and processes.
If you can’t force the red line up, then, to get adoption, you must first force the black line down. This will cause the lines to cross, thus achieving positive adoption.
Getting the black ‘investment for outcome’ line to drop rapidly can be achieved by:
- implementing simple technical products first
- focusing on quick wins with real business benefits
- establishing lightweight and appropriate governance
- using experienced resources who understand integration and how to get outcomes
- focusing on solutions that are built mainly lower down in the SOA reference architecture.
Factors that prevent the black ‘investment for outcome’ line dropping are:
- poor choice of technology architectures
- picking initial implementations with poor business returns
- too much governance (initially)
- implementing projects with inexperienced integration teams
- over complicating initial implementations with too many products.
Using the SOA reference architecture to understand investment requirements
One way to understand how to rapidly reduce integration investment requirements is to use the SOA reference architecture as a basis of understanding how to design an integration solution. There are numerous SOA or integration reference architectures out there. The one we would recommend is the SOA reference architecture published by the Open Group, which defines the internationally recognised OSIMM standard for integration delivery.
OSIMM is aligned to TOGAF, which is also published by the Open Group. Hence, it makes the most sense to use in a modern IT environment where TOGAF is being used.
When we look at products clients request, some of those products, like JBoss FUSE, focus on the lower level functions (services and service components). Other products, such as Redhat Service Works, focus on the higher level functions (business processes, consumer interfaces).
The further up the architecture we travel the higher the initial cost, as each layer has a dependency on the layer below it. For example, to implement business processes you must first have the operational systems, service components and services in place. Software vendors often teach many firms that technologies like BPEL and BPMN will save them time and be cheap to implement. However, this is not the case.
These technologies are only cheap to implement after the initial layers are in place. If the project’s objective is achieving quick wins and getting the ‘investment for outcome’ down as quickly as possible, the focus must be initially on the lower layers and keeping the solution simple. These guiding principles form the basis for how we design and deliver systems. You cannot just focus on the technology; you must also critically analyse how you will receive the benefits for the technology in the long term.
What does success look like?
When all these factors come together you get an adoption curve that looks like this. With an early focus on rapid outcomes you can drop the investment for outcome quickly, encouraging adoption. This enables reward, creating further adoption.
When this process starts and the business sees the value, this is the time to encourage further investment as the business now has the appetite. At this stage, consider introducing:
- stronger governance
- better, more capable platforms
- more complex layers of the SOA reference architecture and technologies such as BPEL / BPMN
- revising early projects to improve them based on your learnings.
Getting successful outcomes in integration projects is hard, but not impossible. By initially focusing on quick wins and simple technologies, you can substantially improve your likelihood of success and get positive adoption from your integration platform.
If you have any questions or comments on this article, please leave a message in the section below. Alternatively, please contact me on [email protected]