| CIO Blogs
IT Blog Awards |
Subscribe
Recent Posts
- Gartner and the Hype Cycle of Emerging Technologies
- Model the power to influence. The new generation of CIOs: ‘Walk in the Shoes’ of the Leaders that Drive Change and Business Growth!
- Foraging for Information versus Marketing
- The Fallacy of separating Web development from IPv6
- Cuil bursts onto the semantic search scene
- iPhone 3G, and Mozilla show user adoption to new levels of Power
- A Business Model or Architecture for Web 2.0
- Innovation Brief
- Socio-Technical Systems not IT Systems (‘The Dreyfus Moment’)
- Business Technology not Information Technology
Navigate
Search the blog
« Chat with a Robot who has an un-predictive personality! | Main | What do they know that we don’t? »
7 Ways to scare EAI experts (part II)
Well, it’s already a few weeks ago that we discussed three viewpoints on integration that may help to unfreeze your local Enterprise Application Integration expert. I stated that integration is actually something you want to avoid: it’s not a mission in life by itself; it’s merely a prerequisite to do exciting things in business, enabled by systems and information. If you can avoid integration and still achieve the same, do so by all means. Furthermore, it was pointed out that excellent integration tools are now available on the market, both in open source and as industry-strength, commercial packages. Don’t waste a second of your precious time building and maintaining homebrewed, non-standard solutions. Finally, I suggested to first focus on your data governance before even considering fancy projects around web services and that almighty Enterprise Service Bus.
Two weeks of time with arguments like that! You must have witnessed some changes in the behaviour of your integration experts next door. If by any change this is not the case, please have a look at four additional opening lines that are bound to help them break on through to the other side.
4. It comes with SAP
If your organisation’s appetite is in enterprise application packages, there’s a good chance that there is a healthy attitude towards standardisation and simplification. Hold that thought: please note that all major package platforms nowadays come with built-in integration architecture and middleware. And it’s all based on open standards. SAP is executing on an interesting strategy with the NetWeaver Exchange Infrastructure module and likewise, Oracle created Fusion Middleware as the integration fundament for their, well, rich and diverse application portfolio (they sort of missed my first point of ‘avoiding integration in the first place’, then again they are certainly in control of the data). If you are searching for a shortcut to getting your integration architecture and platform up to speed, you may want to have a good look at what’s inside that ERP box.
5. Just put it in the server rack
Talking about boxes: until not so long ago we used to describe commoditising middleware through a metaphor: 'if only setting up an integration platform was as easy as plugging in a black box'. The thing is, it’s no longer a metaphor. When it was announced under strict non-disclosure to Capgemini more than two years ago, we were absolutely fascinated by the concept of Cisco’s Application Oriented Networking: everything you need to connect services across the network built in on a board that slots into a data centre switch or edge router. Security, transformation, content-based routing, business rules, XML handling and authentication: it’s all in the appliance. And other suppliers, such as IBM and Intel, are quickly catching up. It’s a good unfreezing strategy, touching that neat, little device and simply ask yourself if life in Integration Hell would lighten up with a box like that in your server rack. Yeah, probably.
6. Amazon does it for you
Still not convinced that integration is quickly becoming a commodity that you just don’t want to be bothered with any longer? Amazon may be holding the key to your spiritual conversion. And it’s not even yet another book I am suggesting (why did nobody ever write ‘EAI for Dummies’ in the first place?). Actually, selling books through a website is so 2001. Nowadays, that is only one of the 35 product categories Amazon is offering. Much more interesting is their portfolio of Web Services, which include the Elastic Compute Cloud and the Simple Storage Service. All built on a robust infrastructure that doesn’t need to prove it self. Also quite relevant is the Simple Queue Service, which enables organisations to safely and quickly exchange messages at a rate of $1 for 5000 messages. One day you are buying a book, the other day you are using your same Amazon-account to rent an integration infrastructure. A true commodity and certainly ‘on demand’, I might add.
7. Only vertical matters
In the end, all you want to achieve is meaningful, boundaryless information flow, both inside and outside the corporation. It is truly a good sign if the main occupation of an integration expert is with vertical industry standards. Apparently, you’re assuming that all the hardware, software and basic interfaces are simply dealt with. Now it’s a matter of getting all the players in your ecosystem lined up to do something useful with all that wealth. I’m not claiming that is easier to create a vertical standard like Meat & Poultry XML (or e-Forestry Industry Data Standards) than it is to implement an integration infrastructure. But it’s certainly in an area closer to business, the place where we want to be with IT, remember. Reverse the cycle; think vertical standards first. The rest is just satisfying prerequisites.
TrackBacks
TrackBack URL for this entry: http://www.capgemini.com/cgi-bin/blog/mt-tb.cgi/66
Listed below are links to weblogs that reference 7 Ways to scare EAI experts (part II):
» Nzlive com propecia rally new zealand. from Propecia.
Initial effects of propecia. Propecia. About propecia online information uk. Buy propecia. [Read More]


Comments
# on September 26, 2006 11:06 PM, carl said:
I am really not understanding your message here...
I my opinion, if you want to avoid integration, as you say, then you want to avoid change. If you plan and design your enterprise architecture and system landscape with that in mind, you will loose when youre organization dont manage to introduce a new technology fast enough. its an illusion to think that one application, for instance SAP, can solve all your business problems in all your business areas. you have to have different kind of applications using different kinds of technologies to be competetive. then these applications also of course need to be integrated to solve horizontal business problems.
So, I really did not get the message here, please clarify!
# on September 27, 2006 11:16 AM, Ron Tolido said:
@Carl: You are so right: organisations will innovate, enabled by new technologies and solutions. The point is: many don't have the headroom to innovate in the first place, because they are burdened by having to integrate their legacy and core systems over and over again. My claim: if you simplify and consolidate your core, commodity systems well enough (thus avoiding costly integration work) you create the room you need to innovate at the market-facing edges of the organisation. You will indeed see more heterogeneous technologies there, but even then, open standards will help us to avoid being caught up in integration issues. Hope this helps?
# on September 29, 2006 7:15 PM, Big4 said:
Andy, thanks for your response on our blog. We have recently commented on CapGemini stock here
http://bigfouralumni.blogspot.com/2006/09/cap-gemini-s-now-has-to-deliver-for.html
Investors are looking for performance...as you CTOs create and implement innovations at clients, it helps the firm grow profitably
# on March 24, 2007 12:15 AM, reamon said:
4. It comes with SAP
"...all major package platforms nowadays come with built-in integration architecture and middleware. And it’s all based on open standards."
Take that with a grain of salt. Yes, open standards are embraced by all integration tools. Have you ever tried to change tools? It's hard. Now try to change tools once you've adopted a tool that's engrained with your ERP.
"...SAP is executing on an interesting strategy with the NetWeaver Exchange Infrastructure module and likewise, Oracle created Fusion Middleware as the integration fundament for their, well, rich and diverse application portfolio..."
I'm not sure how interesting the SAP strategy is--it's a pretty old one that has been executed by many companies. And it's one SAP has executed multiple times--ask all the Business Connector folks if they feel abandoned or not. Oracle has tried multiple times too. Bottom line: Give app vendors that bundle in integration a look-see, but be very aware of what you're buying into. I dunno the licensing of the NetWeaver components but the SAP BC could be used in integrations only when SAP was one of the end-points.
"If you are searching for a shortcut to getting your integration architecture and platform up to speed, you may want to have a good look at what’s inside that ERP box."
Be wary of adopting a tool simply because you have it. It's a great idea to include the "bundled" tool in a selection process, but don't just select it without critical analysis. Shortcuts usually aren't.
5. Just put it in the server rack.
This seems like a fine idea for commodity integrations. For strategic integrations (one's that provide a competitive advantage), probably not.
"...ask yourself if life in Integration Hell would lighten up with a box like that in your server rack. Yeah, probably."
I'd reduce that to a "maybe" rating. Unless it replaces things, then it's yet another component to add to an already crowded portfolio.
6. Amazon does it for you
Some types of integration are becoming a commodity. Absolutely. Such integrations are great candidates for farming out to the Amazon's of the world.
Are all integrations a commodity? Even if you adopt standards, does it do all you need? Why are there several e-commerce standards? Why have you customized the e-commerce standard you're using?
7. Only vertical matters
"Reverse the cycle; think vertical standards first. The rest is just satisfying prerequisites."
Absolutely. Couldn't agree more. The business process must always be considered first.
The prerequisites aren't trivial, though, even though we'd love to dismiss them as "simply dealt with."