IBM updates SOMA

Blogger: Anne Thomas Manes

IBM recently published an update of its Service Oriented Modeling and Architecture (SOMA) methodology in IBM Systems Journal. The article has an academic style, and is chock-full of techno-speak, but the information is valuable.

SOMA is the software development lifecycle (SDLC) methodology that IBM Global Services uses in its SOA project engagements. It is based on IBM's patented Unified Method Architecture (UMA), IBM's meta-model that provides the foundation for the Rational Method Composer (RMC). RMC is the Rational tooling that supports the Rational Unified Process (RUP).

As you would expect from a RUP-based methodology, SOMA is a heavyweight, top-down, model-driven, iterative SDLC methodology. The article describes two cases studies --one short case to get a big-picture sense of the process, and one long case to illustrate the process. This graphic shows an overview of the SOMA lifecycle.

According to Tilak Mitra, one of the SOMA guys from IBM:

"The fundamental difference between SOMA as it existed and what it is now, is that the former version had it just as a service modeling and design method. However, now SOMA is a full lifecycle engagement model for project execution."

One other significant difference that I see is the adoption of "service cases" in place of "use cases".

The described methodology seems appropriate for organizations in the early stages of their SOA initiatives. The methodology appears to be missing a major set of capabilities associated with service portfolio management, though. It makes no mention of capturing information about the services in a registry or repository, and it makes only one parenthetical reference to searching a registry for available services. Of course, since it's RUP-based,  the process will generate a huge number of artifacts about the services, but I'm not convinced that the raw artifacts will enable service discovery and reuse of the services. It would be beneficial if SOMA provided some guidance regarding registration and reuse of services in the service portfolio.

The article sprinkles the term "governance" throughout the introduction, but provides no examples of actual governance processes used during the lifecycle.

The described methodology also seems to be very WS-* centric. I'm sure that the methodology could be used to implement RESTful services, but the illustrated case focuses on WSDL and operation-oriented services rather than resource-oriented ones.