Apply today for a FREE subscription to CIO Magazine!
Thu, Jan 19, 2006 14:34 EST
|
Posted by: Christopher Koch Blog: Koch's IT Strategy
Current Rating: |
"I’m not saying it’s impossible, but it’ll be really, really hard to be successful." That’s how a Forrester Research analyst described the task Oracle faces in integrating all its recent enterprise software acquisitions in this BusinessWeek story.
It got me thinking about how the traditional vendor strategy for enterprise applications--big, integrated suites as a bulwark to assert dominance over customers’ software buying patterns--is increasingly at odds with the emerging thinking on enterprise architectural strategy: SOA.
In the last century, the vendor strategy pretty much lined up with thinking on architecture: standardize as much as possible to reduce integration headaches. That was great for vendors. If you owned the majority chunk of a customer’s enterprise software architecture, you got two big advantages: First, the suite was so big and complex that the customer had little incentive to get rid of it over the long term, which meant guaranteed streams of revenue in the form of maintenance fees, which could be raised incrementally over time; second, you got a critical advantage in selling them new software: fear of integration problems and management complexity if they bought stuff from someone else.
But today, the dominant architectural trend, SOA, is diverging from the vendor strategy. SOA says the enterprise application infrastructure is almost irrelevant. Technology is constructed according to services specified by the business, not by processes contained within an enterprise application vendor’s software box. In this scenario, enterprise applications become just a piece of the service, yet another component of a larger business process such as an insurance claims process that links a jumble of functions and data inside ERP, CRM and old mainframe legacy systems. The vendor of the applications doesn’t matter anymore; the linkages between them become the important thing. Why replace all your old mainframe systems with enterprise software suites if you can cheaply and quickly link all the old stuff together into services using web services and integration middleware?
In this sense, the vendors’ integration strategies become more important than the features of their software suites. Of course, both of the dominant enterprise software vendors, Oracle and SAP have begun offering integration middleware to go along with their big software suites. Yet both are sticking with the big, integrated software suite vision. Indeed, Oracle has pledged to meld all the best of all its different acquisitions together into something greater: Fusion.
But that begs the question: Why? Why try to integrate or build something that serves all the diverse interests of all the customers that bought Peoplesoft, Oracle and J.D. Edwards when the emerging SOA strategy is telling your customers that it’s okay to have diversity in your software portfolio?
And SOA isn’t just popular with CIOs. In many companies, business people--the same people who bought the enterprise application software suite pitch back in the last century--are pushing the SOA strategy pitch in this century. They want linked business services and flexible new workflows and processes--software architectures and infrastructures are less important to them than ever.
Which gets us back to that word that the Forrester analyst danced around: "impossible."
I’ve heard that word used before in a similar kind of conversation: Oracle’s attempt to integrate software from four different vendors together into a seamless ERP package for the consumer packaged goods industry, called Oracle CPG, in the late 90s. In this article, I wrote about how time-consuming, complex and expensive that effort was. Granted, integration tools and techniques have improved since that time, and Oracle now owns the software it is trying to integrate, which eliminates the organizational boundaries that hampered the CPG effort, but getting software written by different developers at different companies to integrate at a really foundational level is, well--here’s what an ERP analyst told me for the Oracle CPG story: "It’s impossible to try to integrate four pieces like that from different vendors into a single product."
Of course, Oracle doesn’t have to integrate all the acquisitions together in the technical sense. It has other options. It has an anxious herd of CIOs all paying maintenance fees on different enterprise software packages who could be coaxed into upgrading to something entirely new, or buying middleware so they can keep what they have.
But if SOA really takes over, how anxious will those CIOs be for upgraded versions of software they already own? SOA bodes for keeping old software infrastructure around longer.
It seems that if SOA really takes over, the software that links applications together, rather than the applications themselves, will become the most important strategic decision that CIOs make.
What do you think?
New software is driven by a customers needs. Not the customer or the company buying the software, but the users within that company. They are the ones that is pushing the need. If the software vendor cannot meet the need it is often met with a spreadsheet or locally developed tool. The "Big" software companies are struggling because they are not as fast as local "in house" IT shops. In the past, the local IT shops have resulted in hard to manage and maintain systems that had us running to COTS software. Now, the middleware and portal technology have removed the dumpy presentation layer and provided a new look into the business process that the locally developed tool will utilize. The Big boys have been gobbling up these companies because they believe they can buy their way into these organizations. Yes, the landscape is changing, but your perspective is too based on the IT view and not the end user or local IT group view.
Ein Schloss, Ein Wurst, Ein Kopf !jbq
SOA allows us to re-use software and existing business logic. This is similar to patching code. Do it for too long and it becomes a mess.
Before I get slammed for having an IT view, there is a similarity with business processes themselves. The reason BPR was a rage in the 80's was because these processes had accumulated years of incremental changes grid locking them into activities that were never questioned.
Fresh software re-writes and app implementations have been a huge opportunity for businesses to clean up the process act and drive efficiencies.
Layering new software on old will reach a point where the processes will get too cumbersome and the interfaces too dissociated from real requirements. "Why do I have to enter this?" asks the novice. A grizzled old veteran says "I remember when we had that old order processing system when we needed...". Some day, someone will need to sweep the whole lot out and re-do it.
So, trying to integrate a set of ERP products using SOA would be a good quick fix, but may not be a good long-term product management strategy for Oracle or its clients.
One of the questions I have been pondering over is how do you decide what is worth putting out as a service? What will have the longevity to make it worthwhile. I think looking at the statistics of OOP code re-use will give an indicator on how much business users will actually re-use services? After all, how many business users actually re-use existing reports and queries without asking for them to be modified?
Kansst du mir ein Speisekarte zeigen ?xqb
Cool site! I'll be back. destroy game is very good table: http://www.tnmc.org/gnews/pearl.html white is feature of industrious table, white is feature of industrious table