Moving to Advanced SOA

Patterns and Guidelines for Starting with SOA and Moving to Advanced SOA by Yefim V Natis

Yefim, as always, delivered a solid road-map around SOA consumption patterns.

SOA Use Pattern 1: Multi-channel Applications - multiple business channels consuming a service-oriented application.

SOA Use Pattern 2: Composite ApplicationsComposite Applications - multiple applications creating a single application for business channels.

SOA Use Pattern 3: Busienss Process Orchestration (People and Services Interacting) - multiple applications orchestrated, using services, to support a single business process.

SOA Use Pattern 4: Service Oriented Enterprise - New functionality is delivered to the Enterprise - not new applications. Consumers are not connected to services - but to the infrastructure.

SOA Use Pattern 5: Federated SOA - Further recognition of the complexity of the enterprise. Not a recommended pattern. This is often the result of mutliple business units creating their own SOA methodologies and infrastructure (SAP Net-Weaver, Microsoft .net, IBM Websphere, Oracle SOA Suite, etc. all maintaining their own independence and operational platform in an enterprise).

Ed's Take:

Yefim theorizes that these patterns could / should exist independently in any major enterprise. In almost eight years of being a SOA practitioner and leader of SOA implementations in major enterprises, I would strongly disagree that these patterns are independent and might go so far as to say that they are not "patterns" but part of a larger common set of Enterprise Integration considerations. Every major enterprise I've worked at, actually implementing SOA initiatives, has had BPM initiatives, has had multiple platform vendors and competing business units with their own vested vendor relationships and commitments to vendors, is responsible (at a project / initiative level) for delivering applications to business units, and has multiple channels consuming a business critical application. There is value, however, in understanding that each of these are "Considerations" around a SOA implementation. In other words, let's understand the channels that will consume the SOA-ized application, let's understand the source systems, let's understand our integration platform, and let's understand future consumers of those services that the new SOA initiative will deploy, before we begin the SOA initiatieve.

Yefim nailed a few of the "Things to Avoid" in getting started with SOA.

The first "nail on the head" came with Yefim giving a 'holla to the "danger of forgetting the data" (hence the need for recognition of the importance of MDM as well as BPM with SOA initiatives that we've recognized for years).

The second "nail" came with the 12th Gartner restatement of the "danger of starting too big (with your SOA projects)" (the only people crazy enough to do a major SOA project as a first SOA are those that have completely outsourced anything beyond a SOA business case to some IBM team of 40 people that will spend the next 3 years deploying your new, great, grand major SOA initiative with a time and material contract using their "new" SOA Suites that are actually rebranded packages you bought four years ago).

The third "nail" came with the "anarchy vs dictatorship" recommendation. While Yefim's anarchy vs dictatorship was ridiculous (seriously, there is never a pure anarchy or pure dictatorship in any enterprise but its dramatic and people seem to swallow it for some reason), Yefim did point out that people and organizational alignment was critical to moving SOA initiatives along. Again, nothing new in this statement, but this is something that, even after being said for five years, seems to draw "oooooohs" and "aaaaaahs" from techies who think ws* is the coolest thing about SOA.

Best new Gartner Acronym in this session - NIH Syndrome (Not Invented Here Syndrome).
NOTH - ing Factor (Nail on the Head - ing): 50%