In the first part of this series, I pointed out that IT centered programmes that involve the term “transformation” tend to be complex and tend towards failure – failure to deliver the desired outcomes to time, to budget, to end-user expectations. And, I dealt with that which I consider as one of the most important sources of failure – inserting business analysts between those who will be using the technology and those configuring/building that technology.
Integration: The Formidable Challenge of Getting Systems to Work Together as an Ecosystem in a Transformation Programme
Today, I wish to consider, the most troublesome cause of failure: transformation programmes necessarily cover multiple functions, lots of business process, many end users from across the business, and these necessarily require many discrete IT applications (from different vendors) that must talk to one another fluently. Fluently! Nothing less is acceptable to the end users – whether customers of the business or those in marketing-sales-service who are charged with facilitating the interactions/transactions with these customers
How big of a challenge is this? Let’s consider this in terms that all of us, especially those not familiar with technology will understand. Imagine a board of directors meeting – there are seven people there, each speaks a different language, and none speaks/understands the languages spoken by the others. How are these seven directors going to communicate with another and thus work as one to generate that which is expected from a board of directors?
The same is the case for IT systems! There is a multiplicity of systems none of which ‘talk’ to one another yet they must ‘talk’ (integrate) to one another such that ‘conversation’ (data) flows easily/quickly across these systems. How to arrive at this – an integrated solution where all the systems ‘talk’ to one another? How one approaches this challenge determines whether one avoids failure or not.
Here’s One Way to Approach The Integration Challenge
1-Get a bunch of folks together whose title usually includes ‘architect’ as in “solution architect” or “enterprise architect” and get them to agree upon a design and publish a document to the rest of the players – those responsible for configuring/building the individual systems, and those responsible for connecting these systems with one another; and then
2-Walk away sayings something like “Now, you vendors get together amongst yourselves as and when you see fit and figure out the specifications for the interfaces/integrations” thus neither facilitating nor overseeing this vital matter of working out how the interfaces/integrations are going to work (protocols, data that will flow across systems, direction of travel of this data, the mappings between one system and another, error handling…) and dealing with unexpected complications that always arise.
What Happens When You Take This Approach?
If you take this approach then I guarantee (as I have seen it with my own eyes) that you are guaranteeing failure. What does failure look like?
1-Many errors are picked up in the Systems Integration Testing phase, and/or the User Acceptance Testing phase. Considerable rework is required from multiple ‘vendors’. This takes time and effort resulting in Go-Live pushed out further and further, and increasing costs.
2-The ‘vendors’ dodge responsibility and point at others. The client team, including those with ‘architect’ in their title, scapegoat ‘vendors’ instead of taking responsibility for their failure to own/orchestrate/oversee the business of integration – often the most complex piece when you look at transformation in technology terms.
3-End users involved in the User Acceptance Testing rightly become concerned about that quality of the solution. This concern tends to be shared in the wider Business community thus making the challenge of ‘winning heart & minds’ that much greater as few of us have the time or the inclination to give up the familiar and learn the unfamiliar.
4-The Go-Live having been pushed out once, has to be pushed out again. And perhaps again. Then again. And when politics intervenes and the solution must Go-Live then most likely the solution will not be that which was envisaged. It falls short of delivering the desired outcomes: functionality, ease of use, and usefulness to those who use it.
5-Those who make the decisions promise that the deficiencies in the Go-Live solution will be addressed in phase 2. This promise is rarely kept – at least not in the timescales that matter to the end users. It’s rather like sex: after climax, the passion/desire dwindles to nothing – the parties to the game are satiated.
Is There An Alternative – An Effective Approach To Dealing With The Challenge Of Integration?
Yes. What does this look like? I can only tell you what it looks like for me:
1-With regards to that which truly matters to me, I take full ownership – always, no exception- as in I design the play, I orchestrate the play, I facilitate the conversations/thinking that matters, I oversee to ensure that all are doing that which they are responsible for doing;
2-In the domains where I lack expertise, I bring in the experts as in those who have handled the challenge that I am facing and proven themselves. By “bring in the experts” I do not mean the organisation that claims this expertise – rookie mistake. I mean those individual human beings who embody the expertise either as individuals or as individuals that have worked together with one another as one team;
3-Put in place practices that allow me and those who are supporting me in the challenge of handling integration to keep in touch with individual teams/systems – on a weekly basis. Why, so that we know what is happening on the ground and pick up early if team A is doing something regards to system A that is going to mess with that which Team B is doing with system B.
4-Chair a regular Integration Workshop where ALL involved in building the IT solution attend – always, no exceptions. And, in this workshop I ensure that we actually work as opposed to merely talk. By this I mean, that we deal with that which impacts integration – this may just be issues, equally it could be design changes in one system that may impact other systems, or changes in business requirements that impact the design of the systems and the integrations. And one output of the Integration Workshop might me that the integration blueprint published a long long time ago by the ‘architects’ has to be re-worked as it turns out to be flawed in one or more areas.
Does what I suggest sound like hard work? Yes, it’s hard work. Which might explain why it is that so many go for the easier approach – the one I outlined at the start, the one prone to generating a failure.
I thank you for your listening and wish you the best. Until the next time….
Read the original post here.