Gartner AADI 08 Orlando Wrap Up

Well the conference is winding down and I'm taking an SOA breather to
reflect and exhale. Well I'm actually watching EURO 08 but I am
reflecting.

I have to say that all in all I enjoyed the conference. I especially
enjoyed seeing and meeting the other members of our team. We stay
pretty busy and unless we're together on a job we don't see each other
often.

I was pleased to see that many of the concepts, patterns and processes
presented were not new to me and in fact were things that myself and
the rest of the team already do and apply everyday. Of course there
are always things to learn or new perspectives to discover. I met some
nice folks and had fun in the unsanctioned events as well ;)

Gartner AADI 2008 - Day 3

Gartner AADI - Day 2

Best Practices in Enterprisewide SOA Initiatives presented by Massimo Pezzini

Gartner AADI - The SOA Journey presented by David Lindley

David Lindley from Blue Cross, Blue Shield of Florida presented their SOA journey. One of the many nice things they have done is to create some artifacts that outline their road map and vision. What's even nicer is that they come back to these documents to evaluate their direction and decisions. They have created service request documents, service contracts, documented their service life cycle and put architectural reviews in place for new services requests as well as change requests. The have an intermediary, a registry, a testing solution and a monitoring solution. They defined and published their standards, created development guides for services and even created an EA web portal for all of this information to be disseminated and shared.

This is of course merely the short list of all the work that David and his team have done. They have done a fantastic job of envisioning where they wanted to go and creating the necessary checkpoints and artifacts to get there.

I had the privilege of working with David early last year and while he and his team deserve all the credit for their accomplishments, I'm proud to have been a small part of their efforts. David and the other members of his team are a great example of what can be accomplished when a group of talented and passionate architects get behind SOA.

The other key success criteria required to achieve lasting benefits is enterprise support. It remains to be seen if this criteria is met at Blue Cross. For their sake, I hope they realize what a great team they have and what great work they have done.

Gartner AADI - Service Oriented Development presented by Michael Blechar

Michael described an interest point concerning BPM. When a business unit starts documenting and defining their business process, not only do they start to get value through visibility and repeatability but they quickly start to see the value of SOA. This is due to the fact that once the processes are documented, people will want to fine tune and alter them to accommodate changing requirements or to make them more efficient. They will quickly see that without separating the individual units of work or activities they are not able to achieve this flexibility. Additionally, other units will see the processes and what to utilize them in whole or partially. Again, without the separation and granularity this is not possible.

The bottom line here is that BPM can sell SOA. Thus by supporting and promoting BPM, you will also be exposing the need for SOA.

Gartner AADI – Moving towards Advanced SOA presented by Yefim Natis

An interesting concept is the idea of Software Oriented SOA and Business Oriented SOA. The difference being that one is technology focused and one is not. While it’s never accurate to break things down to only 2 sides, there is some value is evaluating your SOA initiative against this dichotomy.

This difference was noted as a “Thing to Avoid” in Yefim’s morning session here at the AADI conference. A Software Oriented SOA is one which is driven largely by the developers and “techies” as Yefim called them. There is little if any business alignment and services are viewed as software deliverables. A Business Oriented SOA on the other hand blends the technology with the business and views services as business enablers.

The results of these two approaches can and will be drastically different. Without a business focus, most SOA branded activities will ultimately lead to further disconnect and added complexity.

Obviously Yefim’s presentation covered much more than this but this one point resonated with me as I have personally seen instances of both types of SOA initiatives and I think you can guess which ones have been more successful.

SOA Challenges: Silo Service Development

One of the more common things I am seeing these days is the development of services in an application or siloed context. The popularity of and propaganda about web services has made this type of development very popular.

Rather than creating a .NET or Java API as they would have in the past, teams now simply create a Web Service API. Unfortunately, since these services are not being created with a broader picture in mind, there is no focus put on schema development or reuse, namespace management, consistency or versioning, WS-I compliance, top-down design or interoperability.

Essentially what these teams are doing is adding more complexity to their system then they would have had if they created a typical interface. Furthermore they are adding latency and reducing the performance of their system while not getting any of the other added benefits of a more managed service oriented approach.

Additionally, because these projects contain all the traditional tiers (Data, Business Logic and Presentation) they are also responsible for consuming the very web service they are creating. Simultaneous development of a service and its consumer is very difficult without a structured and planned approach. There is no single correct way but typically it involves a defined, solidified interface and a dummy implementation. This allows the consumer development to proceed unimpeded by the service development. The service team can then “release” operations individually and do integration testing on a smaller scale allowing the system to gradually take shape rather than going for the "big bang" integration approach.

Many companies are on this path. Those that have no centralized or organized SOA effort are inadequately prepared to change this behavior. Those that do (yes, even companies who have great SOA stories fall victim to this) need to ensure that NO web service gets created without the SOA team's knowledge and influence. If nothing else, the SOA team needs to be aware of the project and either help the project team align their services with the broader vision or prepare (and plan) for a refactoring effort later on.

SOA Challenges: Schema Management

Everywhere I go I see this challenge. How can you create a network of interactive, useful, business oriented services if they do not speak the same language?

I'm not talking about the format in which data is transferred (e.g SOAP or POX or JSON). I talking about the business specific semantics used to represent the data. Just because two people speak English does not mean they can communicate. They must have a vocabulary they both understand. Have you ever listened to a NASCAR post race interview? I'm pretty sure that's English but I have no idea what they are talking about.

The same is true when developing services.

Web Services are officially the flavor of the month. Every project now at the very least involves a web service API and many utilize web services as their only business tier API. While this is a topic in of itself, as it relates to the topic at hand, this is root of the problem.

A recent post by Jeff Schneider points out this issue and leaves little hope for the traction it is getting. The desire and push to develop services has lead almost everyone to do their leaping before their looking. It is these same people who will eventually proclaim SOA just another passing fancy even though they did little to make it a success.

Of course in order to do this properly, an enterprise needs to provide its teams with the appropriate tools and resources in which it can be accomplished.

To name a few:

• A centralized object repository
• Tools for navigating and extending existing objects (both internally and externally managed schemas)
• A versioning solution
• An environment for hosting and referencing all internal schemas (e.g. http://schemas.mycompany.com)
• Governance around the use and proliferation of namespaces and objects (I'm talking to you EAs)

I am currently evaluating a solution I hope will offer all of these things so I will let you know what I find. Stay tuned...