Oracle/SAP Battlelines for the Future Enterprise
The big news in the enterprise over the past week has of course been SAP's aquisition of Business Objects. While this definitely marks
another major milestone in the consolidation of the BI industry, there's some questioning on just how important this
will prove to be in the long term.
My personal feeling is that in a few years we may look back and realise that all the BI news obscured the real story of
the day ... James Governor's post on Mashing
up SAP may appear to be an innocent conference write-up, but could be seen as one of the early shots fired in the
ultimate battle between SAP and Oracle for the enterprise
developer (dressed up as "Enterprise Mashups" or "Enterprise 2.0" if you wish).
I'm expecting this to be a key battleground over the next couple of years. By 2009, we'll begin to see full convergence
of the *2.0/RIA trend along with the componentisation/service-enablement of the ERP suites (call it SOA or SCA). This
will herald a new era of enterprise development, where customers will expect to buy and configure standard software
components from Oracle/SAP, but then deploy for use within highly tailored and personalised "user-interaction
environments" (web pages or portals in today's terminology, but on steroids).
If this is the future, then the application back-end risks commoditisation and the vendor that owns the hearts
and minds of the enterprise development community will take the crown. And SIs who make their bacon
implementing enterprise applications have had their warning: one day soon you will wake up and the world will have
changed. Not ready? Sorry, you're out of business.
In this context, Web 2.0 has just been a warm-up lap for taking on the enterprise.
We can see the battle lines being drawn. I think the Adobe-SAP partnership, which has been getting a lot of positive press of
late, may go down in history as way more significant than BO. Events like RedMonk's enterprise
mashup track at the upcoming SAP TechEd in Munich continue to highlight their embrace of the rich internet
application development community.
I like their theme ... "driving accidental awesomeness" ... the future is already here, it’s just unevenly
distributed (William Gibson).
Of course, Oracle has not been silent. One could even argue that just like the Hyperion acquisition prompted SAP to
move on BO, it was Oracle's vision for Fusion Applications got the ball rolling in the first place. As I've blogged before though, Oracle appears to be a little
slow to embrace the implications for enterprise developers ... that is, until Oracle AppsLab hit the scene.
Oracle has done a great deal to attract diverse developer audiences (from PHP to .NET to an interesting category of "non-PHP scripting languages"), but this is
generally not applications-related. Of course it's own application development strategy currently remains firmly
committed to Java and ADF in particular. What will be most interesting is how we see Oracle incorporate the needs of
(non-ADF) "mashup" developers as Fusion Applications become concrete.
So in one sense it appears Oracle and SAP are pursuing diametrically opposed strategies - SAP hunting for communities
to "adopt" and build (like Adobe), whereas the Oracle approach is perhaps a bit more like "build it well, and they will
come". It will be interesting to watch this one play out ...
read more and comment..
Some good books and sounds...
Turns out I'm mainly using my PrataLife blog for music and book reviews.
Thought I'd post a summary here of what I've been through over the past few months..
First, fiction:
- The Paris Option
-
- The Warden
-
- The Pyrates
-
- The Leavenworth Case
-
- The Best Laid Plans
-
- A Different Point of View
-
- HunterKiller
-
- The Ambler Warning
-
- The Extraordinary Adventures of Arsène Lupin, Gentleman Burgler
Non-fiction/technology:
- Software Fortresses
-
- The Weather Makers
-
- Rails for Java Developers
-
- The World is Flat
-
- blink
-
- The Tipping Point
-
- Softwar - An Intimate Portrait of Larry Ellison and Oracle
If there's one single recommendation I'd make, it would be to check out Terry Fallis' The Best Laid Plans. It's a delight - as a (free) podcast novel, and soon I will hopefully have the real, physical book in my hands...
Along the way I've snuck in a few music faves such as Gwen Stefani's The Sweet Escape (also with a mention of Japan's incredible Uplift Spice) and Rush's Exit.. Stage Left.
read more and comment..
Software Fortresses
I forget the first time I became aware of Roger
Sessions. I think a colleague of mine in the .com days might have had him as a lecturer. Certainly I got on
his ObjectWatch newsletter some time back.
I picked up
Software Fortresses - Modeling Enterprise Architectures
from the library
and it is an interesting read. While I don't see too much evidence that the methodology espoused by the book
has been adopted by the mainstream, it is a book that is worth reading for some of the ideas none-the-less.
Principle among these is the idea that system boundaries should be seen in the context of organisational
dynamics. In other words, if your organisation goes for a centralised database structure and that is unlikely
to change in the near term, then it makes sense to model and build your systems that way. This is a great
insight as far as I am concerned. It is too easy to be seduced by the idea that IT folk are hyper-rational
geeks, and forget the reality that we are all just as human as the rest. Anyone who has tried to implement a
system for real can attest to the fact that often it is the human factor that is the primary determinant of
success.
The last chapter ("Postlude") is worth the price of the book itself. Here it lists a series of Top-10s
such as
-
- Ten Important Points about Software Fortresses
-
- Ten Reasons to Adopt the Software Fortress Model
-
- Ten Rules for Software Fortress Design
-
-
- At the enterprise level, focus on treaties (between fortresses)
-
- Define fortresses with the right amount of granularity
-
- Look carefully at your walls (for security implications especially)
-
- Look carefully at your guards
-
- Make sure nobody can exit the fortress except through an envoy
-
- Design infograms to be resilient
-
- Design your fortress to scale
-
- Use only loosely coupled transactions across fortresses
-
- Use tightly coupled transactions only within the fortress
-
- Use asynchronous drawbridges wherever possible
-
- Ten Controversial Ideas within the Software Fortress Model
-
-
- Performance doesn't count (as much as the overall design)
-
- Put security only in the guard
-
- Organisational boundaries are related to fortress boundaries
-
- Tightly coupled transactions shouldn't cross fortress boundaries
-
- We need fortresses within fortresses
-
- The software fortress model should always be used
-
- Turn off database security(!)
-
- Don't share databases across fortresses
-
- Give scale-out priority to scale-up
-
- The model hasn't been proven (but what has?)
-
- Ten Considerations for Evaluating J2EE versus .NET
-
- Ten Observations on the State of the Software Industry
-
-
- The industry has no conceptual model for building enterprise systems
-
- The software industry lacks a coherent vision for flowing transactions through the enterprise
-
- The software industry has a confusing hodgepodge of security capabilities and no model for how they should be used
-
- The software industry is wasting time defining portability standards when what we need are interoperability standards
-
- The software industry does not differentiate among implementation technologies (such as objects), distribution technologies (such as components), and interoperability technologies (such as fortresses)
-
- The software industry has no concept of the difference between the communications that must occur within a system and the communications that must occur between systems
-
- The software industry does not have a common model for interoperability, so different vendors create products that are difficult to glue together
-
- The software industry uses technology-specific terminology for describing what is being done, making it difficult to understand when common approaches are being used (e.g. session beans v. COM+ components)
-
- The software industry assumes that interoperability will be solved by the choice of one single technology that will integrate everything
-
- The software industry frequently provides capabilities that are not only not useful, but downright harmful (examples include entity beans, distributed objects, Microsoft's Transaction Internet Protocol)
-
The book was published in 2003, but I think we see some sign that the challenges expressed by Mr sessions may well be being addressed - such as the wide-spread adoption of SOAP/Web Services. Mr Sessions words do however spell a warning to those who try to overload such technologies with too much intra-fortress baggage.
read more and comment..
BillMonk
I first heard about BillMonk on the Ruby on Rails podcast. It's a really neat concept,
helping you to track and share bills and things you might lend. The podcast is very interesting because it of course
covers the rails aspects as well as the story behind the site itself.
You can use the site stand-alone, but it also has good integration with facebook
- which is what I've been testing with some of my friends.
Well worth checking out if you share a house or often end up splitting meal or vacation bills with friends - or even
just to keep track of movies or books you may lend out.
read more and comment..