.comment-link {margin-left:.6em;}

Sam Lowe's blog on Enterprise IT

Wednesday, August 24, 2005

One Reason Why SAP's ESA Proposition May be a Healthy Step Forward

I recently was at SAP's head office in Germany to hear from them about their ESA (Enterprise Services Architecture) initiative, and it was an interesting session. They are positioning ESA as the unifying concept, an a branded guiding vision overarching their newer Netweaver technology stack, and their more traditional mySAP application suite.

This post isn't really to comment on their particular offering, but what I was most impressed about was that a software vendor, wasn't talking about software, or technology, but about the Architecture of an Enterprise's IT, and the value to a Business of an Architectural approach. Now, of course they are doing this as a means to sell more software, but putting scepticism to one side for a moment, it was an important step.

My reason for saying this is that for a couple of years now SAP has been promoting Netweaver. And in most ways Netweaver is in the same space as lots of the software infrastructure technology vendors' offerings. Accordingly, the Netweaver SOA promotional material and positioning had large parallels to the software infrastructure technology vendors' SOA material and positioning. But ESA is more than that, it acknowledges that SOA is bigger than just a technology buzzword, is bigger than a set of enabling software infrastructure technologies (such as Netweaver) however good.

The point here is that the technology, even if it is created with an architectural approach (e.g. SOA) in mind, will not make that architectural approach happen. It's refreshing to see that coming from a software vendor that is so connected within so many of the world's big Enterprises.

A good example of the shortcomings of the SOA technology focus is the integration vendors, who have been selling the value of SOA for longer than most. The software they provide is just an enabler, and a partial enabler at that, for the SOA approach. Usually such vendors will articulate the SOA concept in generic and abstract terms, and as 'proof' will encourage a small pilot project to prove the value of the architecture. Now I have nothing against using pilots to prove value and contain risk, but those pilots run the risk of being technical proofs-of-concept (the goal being to close the software deal) rather than actually indicative of the SOA objectives, and the value-proposition that needs to be driven throughout the Enterprise.

Enterprise-level Architectures don't come about through technology-led pilot projects, they require Enterprise-level Vision and Leadership, Strategy, Skills, Methods, Governance ... and supporting Technologies. What we must avoid is a technology and buzz-word fixation driving the creation of a new set of legacies.

Technorati Tags:


  • But that's to miss the point of a 'proof of concept' isn't it? It's chicken and egg. Prove a piece as indicative of the whole?

    By Blogger Dennis Howlett, at 1:16 pm  

  • No the point is that the piece is not indicative of the whole, it is just a piece of the whole.

    In other words, the infrastructure technology (e.g. integration) is only one of many factors in delivering the value that SOA promises. It's just a component. The plumbing. And if the 'proof of concept' only proves the infrastucture technology works, then it hasn't proven the SOA concept, it has just proven the technology works.

    This is fine if all the other factors necessary for SOA to deliver value are to be taken care of seperately. But if they're not, and the implied sales-spin of some vendors (that 'the infrastructure technology is the SOA') is believed, then you're running blind.

    By Blogger Sam Lowe, at 12:31 pm  

Post a Comment

via Haloscan

<< Home