The promise and pitfalls of implementing a Services Oriented Architecture (Microsoft Architect Council)

This is the second outing of the talk I gave at Ark Group’s SOA conference in March 2005, cut for the Microsoft Architect Council. Its own title slide dates and places the delivery — “Presentation to Microsoft Architect Council, Sydney, 3 August 2005” — and I was Head of Architecture, Distribution at NAB throughout. It is reproduced from the PowerPoint, and that makes it necessarily brief: a deck is scaffolding for a person standing in front of it, and the argument lived in what was said between the slides. There are no speaker notes in the file.

The file is the March deck itself, carried forward. It shares the March file’s creation timestamp to the second — the 9th of March 2005, 9.41pm — and its OLE metadata records exactly one more revision, saved on the 13th of June 2005 after twenty-eight further seconds of editing. Those twenty-eight seconds did two things. The title slide’s event line changed from the March conference to the Architect Council. And the March deck’s closing slide — slide 10, “Think of SOA as a religion”, the one with the Messiahs, the Scholars, the Priests and the Parishioners — was deleted, so this version ends at nine slides. Slides 2 to 9 are character-for-character identical to the March deck; the full ten-slide version, religion and all, is at ark-2005. One tell of how small the edit was: the file’s embedded title property still carries the March conference line, because the property was never touched — only the slide was.

The layout notes from the March reproduction apply unchanged, because they are the same slides. Slide 7 carries a highlighted banner reading “Is SOA in danger of being perceived as a Silver Bullet?” which sits directly under the title though it extracts last, and is set here where it appears on the slide. Slide 8 is two columns, “Armageddon” on the left and “Nirvana” on the right, set as a table so the pairing survives. The bullets were a small arrow in Wingdings, set as ordinary list bullets. And the slides’ own slips stand as they were shown: “Mutiple versions of each service” on slide 8, the quotation opened before “acceptance” and never closed on slide 7, “neither have them replaced older bullets” and “prophesized” on the same slide. Nobody proofreads a deck, and the Architect Council saw the same slips the conference did.

Download the presentation (PPT, 109 KB)

1 Title

The promise and pitfalls of implementing a Services Oriented Architecture

Presentation to Microsoft Architect Council, Sydney, 3 August 2005

Chris Tham
Head of Architecture, Distribution
National Australia Bank

2 Agenda

• What makes SOA so attractive to an enterprise?
• The Myth of the “Silver Bullet” – Will SOA succumb?
• What will it take to REALLY implement SOA properly?
• Some potential problems from implementing SOA, and some ideas for avoiding them

3 Just what is “SOA” anyway?

a) “The best thing since sliced bread” – guaranteed to cure cancer, solve world hunger, and retire Third World debt

b) Something to do with SOAP and Web Services

c) What my vendor says will be supported in their “Next Generation” product

d) Yet another meaningless Three Letter Acronym, to be replaced by another fad in 3 years

e) It’s the same thing as (OOP, RPC, CORBA, CICS, …)

f) All of the above?

4 One definition (what my team came up with)

• A Service Oriented Architecture is an application architecture within which key business functions are implemented as re-useable services with well-defined, invocable, interfaces, which can be called in a defined sequence to form business processes.
• Note: the focus is on business processes, not object, functions, data, message … this differentiates SOA from previous paradigms such as object orientation

5 Why should we care? What makes SOA attractive to an Enterprise?

• Easy for the business to understand
  • The notion of structuring functionality as a set of “services” ties in very well with business process re-engineering, and product/services offerings, supply chain, etc.
• Relatively easy to implement
  • Doesn’t require complete rewrite of all systems, tools exist to “expose” functionality from legacy applications as services
• Broad (universal?) industry and cross-platform support
  • Who would have thought the likes of SAP, Oracle, Siebel, IBM, Microsoft would one day sing the same tune?
• Lowers (but does not eliminate) the barriers to heterogeneous interoperability
  • It’s (relatively) easy for a .NET client to invoke a J2EE web service, across multiple development and infrastructure environments
• Doesn’t require all existing applications to be thrown away or rewritten
  • There are techniques to expose functionality from legacy systems as services

6 The challenges of implementing an SOA

• “The difference between a vision and a fantasy lies in the execution”
• It doesn’t matter how “neat” or “clever” or “righteous” the concept is if no one understands or is willing to change
• At the end of the day, it’s about the people, not the technology
• Are you able to get the business to understand and support the concept?
• Can you get senior management buy in and commitment?
• Are you willing to spend the time to take everyone else along the journey?
• How do you address scepticism, the “not invented here” syndrome, and those who don’t see any need to change?
• Is it about revolution, or evolution?

7 The Myth of the “Silver Bullet”

[!NOTE] Is SOA in danger of being perceived as a Silver Bullet?

• A “Silver Bullet” is a concept/idea that promises to revolutionize IT (and cure cancer, … etc.)
• The IT industry is littered with the carcasses of “Silver Bullets” – none of these have become “pervasive” in the way their advocators originally prophesized, neither have them replaced older bullets:
  • Computer language: COBOL, FORTRAN, APL, Ada, Pascal, C, C++
  • Relational data modelling
  • Data warehousing
  • Object orientation
  • Message queuing, object brokers
• “Silver bullets” tend to fail because:
  • Hype and unrealistic expectations about potential impact and benefits
  • Utopian ideals are seldom realisable
  • Many silver bullets are based on an “all or nothing” philosophy – the old way of doing things is invalid, and all systems need to be re-engineered
  • Lack of true “buy in” and “acceptance, lack of change management
• Failures of execution are followed by a tendency to blame the concept (“I never thought it was a good idea in the first place”) and as a result the Silver Bullet is tarnished
• Everyone then moves on to the next Silver Bullet
• As a result, there is deep scepticism at all levels whenever a new Silver Bullet is proposed. This can doom the concept even before it is implemented.

8 Two Possible Scenarios at opposite ends of the spectrum

“Armageddon”	“Nirvana”
There are hundreds, perhaps millions of web services in your organisation – nobody really knows.	The whole enterprise is implemented on a Services Oriented Architecture.
Mutiple versions of each service, but don’t know which ones are used, and by what.	All key enterprise business processes are modelled using BPEL.
Spaghetti Junction: No one understands the complexities of the relationship between systems.	These are implemented using well defined services, with agreed and known usage contracts/service levels.
No one understands the services that support key business processes.	Services are based on consistent XML definitions based on a common object model.
If a business process breaks, nobody even knows which application to fix.	Services are closely integrated with human workflow activities.
Everyone is afraid to change anything because it might break something else.	Business processes and services can be “automagically” and dynamically deployed and provisioned on virtualized hardware.
You are stuck on old versions of packaged applications because you are relying on outdated web services no longer supported by the vendor.	Full round trip engineering between service modelling and service implementation.
	All services are known and well defined.

9 How to avoid Armageddon and get closer to Nirvana

• Evangelise
  • Make sure the business and senior IT management understand SOA, and get buy in and commitment.
  • Even more importantly, make sure everyone else does!
• Governance
  • Think long and hard about balancing between over-policing and anarchy.
• End to end linkage
  • Work out how to link business process design to service definitions to implementation to deployment to operations.
• Understand what your key vendors are doing
  • What is their positioning on SOA? When and how are they going to implement it? Do they have any ideas/commitment on how to maintain/evolve service definitions across major releases?
• Enterprise Architecture suddenly becomes very real, and important
  • Who will maintain the models and linkages between them? Who maintains a catalogue/repository of services?
• Track evolution of standards
  • Don’t get left behind, but at the same time don’t be on the bleeding edge.
• Build a competency centre
  • Who maintains the standards? Who is responsible for providing guidance and mentoring to development teams? Who is responsible for the end to end view of key business processes?

Sources

• The deck, Microsoft Architect Council - The promise and pitfalls of implementing SOA.ppt, 109 KB, nine slides of text on the NAG corporate template — no pictures, no embedded objects, no speaker notes. Its OLE metadata shares the March file’s creation timestamp to the second, then records a ninth revision saved on the 13th of June 2005 after twenty-eight further seconds of editing, 1,032 words against the March file’s 1,153 — and an embedded title property still naming the March conference, untouched by the edit. Reproduced above and available for download at the head of this article.
• The promise and pitfalls of implementing a Services Oriented Architecture, the full ten-slide March 2005 version this deck was cut from, with the religion slide this version dropped — and the delegate feedback that talk earned.
• The Role of Service Oriented Architecture within an Enterprise Architecture, the longer talk I gave the same month at the Enterprise Architecture Conference.