my recent reads..

Oct 12, 2007 Innovation Fusion Web 2.0 SOA

Oracle/SAP Battlelines for the Future Enterprise - take #2

OK, I jumped the gun by about 12 hours when I posted my little pitch on why the battle for enterprise developer mindshare will prove more significant than the recent focus on BI acquisitions by Oracle and SAP.

Now we have the news that Oracle is offering to buy BEA Systems. Long a favourite speculation, its amazing to see it really happen. If this goes through it will basically make IBM and Oracle the two leading Enterprise Java Platform providers.

Certainly Oracle couldn't risk BEA ending up in SAP's hands, and Oracle has long been strategically committed to Java. But holding such a strong hand could be a problem if it leads to a kind of Java-only tunnel vision.
read more and comment..

Oct 12, 2007 Innovation Fusion Web 2.0 SOA

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..

Oct 7, 2007 Deep thoughts Read

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:


Non-fiction/technology:
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..

Oct 7, 2007 TechRead Read

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..