SOA Integration and Methodologies

John Harby is a participant in several OASIS Technical Committees and was co-author of The Middleware Company SOA Blueprints initiative. He is an independent consultant on SOA and middleware in Enterprise scale projects.

Given the substantial investments being made in SOA implementation by large organizations and integrators and the wide variety of implementation technologies, a discussion of implementation methodologies emerged as a topic of interest. Approaches to SOA range from extremely holistic approaches involving business users, centralized IT, governance organizations, competency centers or centers of excellence, and cross-functional groupings. Some of the broader methodologies involve high level business/service decomposition or the integration of operational concerns with development concerns, such as variants of the latest version of the ITIL system.

InfoQ interviewed John Harby on the topic of SOA implementation methodologies. The discussion focused on the narrower issue of SOA development lifecycle methodologies, although the themes of modeling and agility are themes can be applied across the scale of an Enterprise scale.

InfoQ: What are the top three SOA implementation methodologies?

John Harby: The top 3 methodologies I've seen for implementing SOA are:

• RUP based
• Agile, Project driven
• Shlaer-Mellor

InfoQ: Can you describe these approaches?

John Harby: RUP (ed note: Rational Unified Process) seems to have a good approach for designing loosely coupled
services but has more of a project oriented approach rather than enterprise. The initial phase of service identification wasn't
thoroughly addressed.

Project driven can gain strong initial sponsorship but the life of the SOA can become intertwined with that of the project. In the
particular case I experienced the business need for the project evaporated leaving the SOA efforts significantly weakened. However, we
did use an Agile approach on this particular effort. I found this to be very effective especially in areas where the SOA was integrating
existing functionality. Being able to pair the Peoplesoft team member with an SOA team member was very effective. A Scrum based approach
also served to keep the project governance team updated on progress.   

Shlaer-Mellor is an older pre-RUP OO methodology that had some interesting patterns for designing loosely coupled entities (they
called them "domains" but the concepts can carry over to services). We used this in a mid-90's C++/CORBA SOA project for the government. The
clear downside of Shlaer-Mellor is its complexity.

InfoQ: What are the differences between OO methodologies and SO methodologies?

John Harby: Loosely coupled services are not really addressed by most traditional methodologies, especially in the OO sense. OO includes
many relationships that for service internals are fine but going across services are undesirable.

Also, as I mentioned above, building the initial enterprise SOA is not really a "project" per se, rather the effort is equivalent to
many projects all rolled into one. IMHO, most methodologies really are project centric.

InfoQ: Some of the enterprise concerns relate to SOA Governance, what are your views of this?

John Harby: SOA governance is critical especially in larger organizations where group cooperation is required. For instance a large company can
have an ERP, HRMS, SCMS, etc. For each of these systems there can be entire teams assigned to the management of the system. Those team
members may be the only ones in the company who really understand the system.

Since SOA is really a cross-enterprise effort it makes sense to have a high-level governance committee composed of the leaders of each
domain. This insures that everyone approves any efforts that may be required for the transition.

InfoQ: Thanks for your participation, hopefully this will stimulate some discussion and debate on the topic of Implementation Methodologies.