If you think implementing technology is difficult, try changing someone’s behavior!

 

Last week I began the discussion about Digital transformation requiring integration modernization.  This week I will continue the topic with a focus on the Process and People aspects – probably the harder part.


people & process, technology, and architecture

 

A Quick Recap

In the prior blog we discussed business initiatives that most companies are executing today – digital transformation, increasing agility, cloud adoption, etc.  This is causing a need for increased integration to marry the data from disparate sources.  This increase in integration workload cannot be contained using the same centralized integration methods and small number of experts that have been used previously.  The need to decentralize integration tasks is required.  This changed requires technology and architecture, but also changes to people and processes.

 

Wherefore SOA?

Having been in IT for several decades I have seen the pendulum swing between centralized and decentralized control multiple times.  Now we are swinging from the centralized Service Oriented Architecture (SOA) era to the decentralized “agile” integration era.  But remember what drove SOA to come along!  It was decentralized integration that resulted in a complex point to point set of integrations.  To describe the need for SOA, we used pictures like these:


integration architecture complex connection diagram

child with bowl of spaghetti upside down on head

 

 

 

 

 

 

The challenge and critical success factors are to not recreate the issues that drove the need for SOA as we move back to a decentralized integration approach.  We need good parenting.

 

Technology Helps

As discussed in the prior blog, newer technology and architecture help solve this issue.  We can provide APIs as building blocks which provide loose coupling between the consumer and provider.  All the forms of integration (from IBM) – API, Application integration, messaging, events, and file transfers are implemented via a microservice architecture, support multiple clouds/on-premise, are cloud agnostic, and can be managed from an individual location of your choice.  Kubernetes and Istio provide microservice cluster management and a service mesh that also helps with loose coupling.  This provides a good set of tools.

 

So, the technology is there, now we need to change the behavior of both the central IT organization and the distributed business application developers to use the new tools appropriately.  How will the business developers know what to do?  Will Central IT enable them to do it or try to maintain control (and slow things down)?

 

Good Parenting

People use the techniques that have worked for them before.  So, central IT has maintained control of the integration because they remember the chaos before SOA.  Business developers (who may not even know they are doing integration) would think that a direct connection to whatever data source they need is probably the best option.  Simply supplying the tools without enablement is likely to end in poor results,

 

A good parent is not going to just give a child a bunch of tools (toys) that they have never used before
Boy putting knife in electric outlet
and walk away.  Bad things can happen!  Like a good parent, the integration experts need to introduce one tool/technique, explain its usage and the benefits in using the new approach and mentor the business developer’s efforts to drive success.  Establishing a repeatable approach where the business developer no longer needs the central IT organization to execute this pattern. And finally, maybe the most difficult step, leave them alone to do it.  Step in when there are questions or problems, but do not continue to do the integration work that has been moved outward.

 

Based on your business developer needs you can choose the first tool to use.  I will start with APIs as an example.  Creating a set of consumer-oriented APIs, explaining how to use the developer portal to understand what is available, how to try the APIs, sign up and consume the APIs, could be the first step.  Explain that central IT can create new APIs quickly if there are additional business assets needed.  Then let the business developers try it.  As things progress, check in to make sure the business developers are being successful, correcting issues, etc.

 

Following the first success, the business developer may find a new situation – say a partner does not have an API or the ability to use one of ours, but is supplying a large file and our application needs to read the individual records in the file.  Or, the marketing department wants to react to a situational opportunity (i.e. event) based on the customer location and the weather.  An opportunity to introduce another integration capability!  Repeat the enablement and on-boarding for the business developer.

 


Do the hard work to make it simple
For this to be successful, the central IT organization needs to follow my primary governance recommendation – “make it easy for the developer to do things the right way, and hard for them to do things the wrong way”.  Set up the integration capabilities so they are easy to consume and use.  If you find that the developers are not being successful, iterate to make it even easier or add more assistance until they are self-sufficient.

 

Digital business has a tremendous financial reward ($20 trillion of market opportunity, or 25% of global GDP, to be realized over the next five years per IDC1).  I started this discussion last week with this statement from Gartner, “Integration has become an obstacle to success because traditional, centralized and systematic integration approaches cannot cope with the volume and pace of business innovation.2   To address this integration bottleneck and drive our business success we need a combination of technology, architecture, people, and process.

 

To understand more about IBM’s thoughts on Digital Business and the API Economy visit the IBM API Economy website.  IBM API Connect is IBM’s complete foundation to Create, Secure, Manage, Test, and Monitor APIs.  You can find more information about IBM API Connect at the API Connect website.  And you can also experience a trial version of API Connect.

 

If you have questions, please let me know.  Connect with me through comments here or via twitter @Arglick to continue the discussion.

 

1IDC MaturityScape Benchmark: Digital Transformation Worldwide, 2017

2Gartner-Modernizing Integration Strategies and Infrastructure Primer for 2018

 

 

Join The Discussion

Your email address will not be published. Required fields are marked *