Feature

Perfect harmony

E-Business Review brought together some key e-business professionals at IBM's Integration Centre in London to discuss e-business integration - why it is so difficult, the problems organisations are having, how much planning can be done for it, and where standards come into play

Defining e-business integration, and why it is so hard to implement

Mike Pomerance:
Integration is all about what companies have to put together internally and externally. You're not just looking at integrating applications and transactions, you're looking at how to integrate information, and how we start putting these pieces together i.e. the newly developed 'networked economy applications' with the legacy applications. Do you do the 'Big Bang', or do it in incremental pieces? [We need to ask] "What is the business need?" and "What is the business going to support?".

Imam Hoque: The reason why things get difficult is that people tend to think of integration very much from a technology point of view. So they start mapping out all the interconnections they have in their business, they try to do it all in just one big go, so the project gets heavily bogged down. You burn all your project budget before you get any business value whatsoever.

Carol Dukes: Part of the problem even starts before that. The technologists tend to ask the business people, "what do you want?". The business people then start to try to describe their entire life, entire world and ambitions and they want to know what's possible or available from a technology point of view. And you end up with an impossible situation. I call it the Tesco problem, because I have the idea of someone rolling up to the front door of Tesco, which has 80,000 or so product lines, and someone meeting them at the door and saying "What do you want?" and the person says, "What have you got?". In small projects, you can probably get around it, by prototyping and doing rapid application development. But it's much harder to do on big, big projects.

Tony Mobbs: If you talk to users, you get their problems, and a wish-list of technology they used, often in their last job. It is usually difficult for them to articulate what they would like to be able to do. Put something tangible in front of them and they can then start to animate what they want or don't want.

Carol Dukes: In the 1980s, Japanese car manufacturers said, "Forget what the consumer thinks. They don't really know. We'll just invent the best thing we can think of that will work, and in 1989, deliver a 1989 car."

Charlie Coode: In a sense, before the consultants get through the door, the problem goes on in every company. You basically had to agree upon a need to get a consultant through the door. You have an IT director, or a chief technical officer, who is probably the only person who knows what's possible.

John Pollock: Part of the problem is a people-related one. As an ex-technologist, I think I intrinsically understand what it is reasonable to deploy IT in. Technology has moved on to the point that many, many more users are very used to technology, for example, using the Internet at home. For us at Legal & General, we haven't found e-integration particularly difficult. I'm an ex-technologist, my director is an ex-technologist and maybe we are tightly integrated in that sense. It may just be about pulling IT out of its black-box environment, and using it as part of the toolset that executives have at their disposal. The technologists' job then becomes one of enabling it to be done cheaply, quickly, reliably and efficiently.

Imam Hoque: But, if you look at some of the real challenges of integration, a lot of the solutions you don't see and touch - they're almost machine to machine. And I agree with Carol, sometimes that is something that the business can't feel. They know the processes, and the technologists know their technology stuff. At Thomas Cook, the technologists had a guess, and they put together a 'Strawman'. And then, in their own time, the business came to chat about these 'Strawmen'. Everyone came up with better, consolidated ideas when both sides understood each other's side of the coin.

John Pollock: Where we have perhaps benefited at Legal & General is that we have not had a grand e-integration vision. We have looked at our business and said, "Where are our business problems? Where can we use 'e' to integrate the back with the front?" And finally, "How can we then deploy that to deliver value or create customer loyalty, or whatever?"

In terms of company structure at L&G, we are quite deeply matrix, and it may be that we are forced into debating and discussing how 'e' actually enters our marketplace, and how you would prioritise the investment in 'e'. It would be easy to say that what I want is a single window on all of the customer data, deploy it on the Web and get the customers doing their own thing. But I don't know yet if the customers will actually do that. So, what can we do that's quick and easy? What about, say, change of name and address for people getting married or moving house? It's cheap, quick and easy, and we can stick it on the Web. Nobody might use it, but it will give us that hook, that starting position to step out from.

On visions, and plans

Charlie Coode: Whatever happens, you need an overall strategy, an overall vision. If you don't have that, you wander around in the dark, not realising 'value'. The Big Bang implementation I think everyone agrees is bad, but you do need an overall vision in place, even before you get someone in to talk to you.

Carol Dukes: The Big Bang vision makes sense on paper, but in practice, we can't work to fixed destinations any more. You always throw it away after two years, five years, whatever. The world doesn't stand still. If you follow that five-year vision, when you get there, your business, your processes, the world, is going to be in a different place.

Charlie Coode: OK, maybe not a destination, but a journey. You've got to state the journey because when you get to a certain point, the situation has changed and you want to evolve it.

Carol Dukes: Yes. Flexibility and the ability to change is important. I think flexibility and the ability to change has to become one of the key criteria.

Imam Hoque: You've got to have a roadmap, because every one of those things you do will become tactical.

Alan Liddle: I'm not sure it's a roadmap, it's an understanding of the capabilities that can be achieved. I think only in the last year or so, has the business got a better understanding of how this technology stuff and this e-delivery can leverage their business. They don't have a terribly firm vision of where they want to go, but they know that the target's over there now, as opposed to some IT director rushing in with a grey box, saying "I've got this whiz-bang stuff".

On standards and elephants

Imam Hoque: From an e-business integration point of view, standards are critical. And I think they're going to go further and further back into the organisation. So, now, you might talk about certain types of financial transactions B2B-wise and the standards are almost there.

Alan Liddle: No, they're definitely not there, and it's a nightmare. There's a good introductory explanation from Andrew Tanenbaum, which is called the Apocalypse of Two Elephants. You have two humps of activity: the business requirements led innovative activity, say, into XML. And then you have the standards to leverage on XML that follow. The second elephant, always has to tail the first. And the second can never get up to or with the first, because it always has to follow its tail. And you are fundamentally dragging the standards from behind.

Charlie Coode: The problem is that you have 10 different elephants in the same park, all walking off in different directions. I participate in some electronic standards in the UK and for the last 12 months, in discussing XML, people have said "XML? Great. Standards? That's a problem," and they finish the meeting. I think RosettaNet is a very good standard but there's a need for a frontrunner to emerge soon, because if it doesn't, we'll go the same way as EDI 10 years ago, and we'll have learned nothing.

Alan Liddle: Maybe we should ask if all the standards aren't set in Seattle? (to general laughter).

Imam Hoque: Fortunately, some of the technologists have spotted that standards don't crystallise, and the only way they do is when one becomes de facto. What they've done is come up with products that allow you to support RosettaNet, Biztalk etc. They have a set of tools that allow you to map different document types together. So, you can put in a generic product and then, even if someone is working to a different standard, you don't need to put in a whole new system, you just configure it differently.

Charlie Coode: Do you drive standards from a technology point of view, or from a business channel or business industry point of view? We're in a position where everybody's just scratching their heads and saying "XML standards - aren't they a problem?". And we and some of the other main suppliers in our industry are now saying, "Why don't we get around the table and just drive the standard down the industry?".

Carol Dukes: Governments can step in too. They can say, "If you want to trade with us, this is the way you'll do it".

Alan Liddle: Many of us our make our money out of gluing separate empires together. Business doesn't operate in a big, single, homogeneous environment. Technology is a bit standards-sensitive, and the cycle-time is so fast. Any chance of the standards catching up are a bit of a killer, and the market is dynamic, so the key is, you have to take your best shot.


Good advice for successful integration

Mike Pomerance: "Ask where is the value and for whom is it being delivered. Look at your business strategy and map your integration roadmap to it. Evolve it too and make sure you deliver. People will take different decisions in the light of recent world events, and the economic marketplace, than they would have taken a year ago."

Imam Hoque: "Avoid the order-taking approach to requirements. You end up doing too much and it's too expensive. Focus much more on problems - do the big-bang-for-your-buck stuff first. Technology can help you build systems that are more flexible and generic than before. Make sure you adopt them."

John Pollock: "Know where you're going, and be prepared to be flexible about how you get there. Don't throw all your investment on a straight-line express train going from A to B. Think pragmatic solutions to real business problems."

Toby Mobbs: "Hard lessons about configuration management, risk management, project management learned on big projects, haven't gone away on e-projects. Dip a toe in the water - start small and grow fast."

Charlie Coode: "Create a clear vision and then implement an incremental approach to it. Don't forget that in the future, you'll have to think about integrating with your customers' systems, and then, with your customers' customers."

Alan Liddle: "There's been a lot of navel-gazing going on in the last six months. If you've worked it out and it is an important, business-leveraged tool, then get on with it.

Carol Dukes: "You cannot spec requirements documents to cover all eventual changes. Separate out the big objectives and the big architectural issues and set them in stone. Then, assume lots and lots of flexibility at the top.


The participants
  • Charlie Coode, e-commerce operations leader, GE Lighting
  • John Pollock, UK services operations director, Legal & General
  • Carol Dukes, co-founder, ThinkNatural
  • Alan Liddle, technical director, Trustis
  • Mike Pomerance, north region executive, IBM Integration
  • Tony Mobbs, principal consultant, IBM Integration
  • Imam Hoque, head of technology, Rubus

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in October 2001

 

COMMENTS powered by Disqus  //  Commenting policy