Oracles announcement of the Oracle Application Integration Architecture,
code-named Project X, might have sounded like good news to customers
gathered at the International Oracle User Groups (IOUG) Collaborate user
forum in Las Vegas yesterday.
But in point of fact, the announcement was hardly just another exercise in
altruism. Over the past year or more, Oracles president Charles Phillips
has been sounding conciliatory words to the client base about protecting investments,
and not requiring forced migrations. But there are cold hard business realities
that are driving Oracle to make more nice with its installed base.
The first fact of life is that, when you have a large enough customer base,
youll attract more flies with honey and that maintenance can become quite
a lucrative business. Mike Greenough, who brought SSA Global back from the dead
prior to its sale to Infor, made that point quite forcefully when faced with
a similar agglomeration of product lines. Until then, conventional wisdom was
that maintaining multiple incompatible lines would drain the business. But once
you have accumulated such a large chunk of the market and so many product lines,
the costs of convergence get far outweighed by the revenue potential of simply
maintaining and gradually enhancing them.
Anyway, with Y2K over, customers hardly in the mood to rip and replace once
more.
Sure, Oracle could make a lot more money if its customer base (grown much fatter
through acquisition) would migrate to some future Fusion application. But even
were Oracle to continue pressing full steam ahead with Fusion apps, that product
is so many years away that it would face pressures from two constituencies:
shareholders that demand continued quarterly growth, and a huge installed base
that demands better functionality and interoperability now.
Thats why SOA has become for most corporate customers more than a technology
buzzword. And thats also why Oracles so-called Project X might try
to accomplish what has so far eluded cross industry organizations like the Open
Applications Group (OAG): defining a set of common business objects so one enterprise
system could exchange its customer object or order-to-cash process with another.
The dilemma with standards is that, the higher you go up the stack, the more
contentious standards efforts become. At that point, thats where enterprise
software vendors contend their value add kicks in. Consequently, it is far easier
to define headers for web service descriptions than it is to define a business
process. Just look at the acceptance of Oasis with web services standards compared
to, say, the Workflow Management Coalition, when it has tried to standardize
representations of processes and workflows.
So on this go-round, why should Oracle be able to pick up where OAG has left
off? We have enough of an installed footprint that this could become a
de facto standard, remarked Paco Aubrejuan, Oracles vice president
of application strategy.
About the Author
Tony Baer is a Senior Analyst at Ovum, covering application lifecycle, SOA, and IT Service Management. Tony is a well-published IT analyst with over 15 years background in enterprise systems and manufacturing. A frequent speaker at IT conferences, Baer focuses on strategic technology utilization for the enterprise. Baer studies implementation issues in distributed data management, application development, data warehousing, and leading enterprise application areas including ERP, supply chain planning, and customer relationship management. As co-author of several books covering J2EE and .NET technologies, Baer is an authority on emerging platforms. Previously chief analyst for Computerwire's Computer Finance, Baer is a leading authority on IT economics and cost of ownership issues.
More by Tony Baer
1
Solution Center Resources