Strategic success of SOA will depend on real sharing of services and software tools

Service oriented architecure calls for company-wide plans to be drawn up.

Service oriented architecure calls for company-wide plans to be drawn up.

Who needs enterprise architecture? You will, SAP customers will, everyone will.

Why? Take a look into the average IT department at any enterprise anywhere around the globe first thing tomorrow morning. What will you see? You will find X number of separate IT projects, each of which can be viewed as a discrete bucket. There will be lots of buckets for enterprise architecture software packages, and a chain of buckets for bespoke software development.

Sure, the size and number of buckets will vary by company, company politics and industry, but each bucket typically has a unique approach to software development, software integration, reporting and system management tools. Some could be SAP buckets, but many won't be.

When you look across those buckets tomorrow morning, you will find virtually no commonality of these tools or the skills needed to drive them. Why? It's just the way software is right now.

But over the next three years,  this situation will change with the advent of the biggest technology shift to hit the software industry in a decade: service oriented architecture (SOA).

Much has been written about the history of the software industry and the universal agreement that SOA will bring real agility and flexibility at long last.

But at the core of SOA is the concept of sharing and reuse, and real sharing means sharing across those buckets. Without the real sharing of services and software tools, SOA cannot be deployed strategically across all buckets.

The only way to facilitate strategic sharing is to set up a holistic view across the buckets and then gradually take out the variation of tools, standards and skills deployed across them.

But how do you get such a holistic view in the real world? Whether you use SAP software or not, the only way to build that view is as a company-wide enterprise architecture plan, using a proven methodology.

This blueprint maps out and defines business processes, services, interfaces and tool standards, potentially down to the supporting infrastructure and overall governance.

SAP has a compelling vision for business-driven SOA across enterprise business software applications, which it calls Enterprise Services Architecture (ESA).

But while SAP also provides its ESA Adoption Roadmap - a pragmatic route to progressively introduce more SAP NetWeaver technology building blocks - it does not constitute the company-wide methodology we have identified as necessary.

Some software suppliers have recently introduced their own enterprise architecture methodology but a true, supplier-independent methodology is what is really needed.

Various industries have introduced their own frameworks or methodologies. Perhaps the most established generic methodology is The Open Group Architecture Framework (TOGAF) standard, for which version 8.1 is available.

Several of SAP's consulting partners have used TOGAF as a starting point to build their own generic methodology for SAP customers, which includes SOA patterns as well as SAP's ESA content and ESA Adoption Roadmap.

Just like any other new technology, SOA can be piloted tactically. But when an enterprise decides to adopt SOA strategically, the fundamental sharing property of SOA will trigger demand for a proven methodology.

SAP customers will find that the company's consulting partners offer the best source of this methodology in order to exploit ESA meaningfully.

They will also discover that to build their blueprint, they will need absolute partnership between business and IT.

In future articles we will analyse the enterprise architecture methodology capability of SAP's consulting partners, and will determine best practice experience for enterprise architecture planning.

Derek Prior is a research director at AMR Research

Read more on Web software