SOA Integration and Methodologies

Posted by Miko Matsumura on Jul 24, 2006

Sections

Enterprise Architecture,

Process & Practices,

Architecture & Design

Topics

SOA ,

Methodologies ,

Architecture ,

Enterprise Architecture ,

Programming ,

Service Design ,

RUP

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.

1. Back to top

   Standard

   by Jeff Thomas

   Is there actually any standard methodology out for building SOAs yet?

   Reply

2. Back to top

   soa community

   by Joost de Vries

   Miko,
   
   I think you want to put this in the SOA community instead of the .Net community....
   
   J

   Reply

3. Back to top

   rup soa

   by Joost de Vries

   I can't determine from this rather short interview wether John Harby is talking about vanilla RUP or wether he's talking about the RUP plug-in for SOA (developerworks) that builds upon the UML 2.0 Profile for Software Services.

   Reply

4. Back to top

   Re: rup soa

   by John Harby

   I was talking about vanilla RUP, sorry that wasn't very clear.

   Reply

5. Back to top

   Re: Standard

   by John Harby

   I don't think there is anything specific. However, I do think they are under development as I actually saw a job ad from IBM stating that they are looking for someone to help create a "RUP methodology for SOA".

   Reply

6. Back to top

   Re: Standard

   by John Harby

   Is there actually any standard methodology out for building SOAs yet?

   
   
   I don't think there is anything specific. However, I do think they are under development as I actually saw a job ad from IBM stating that they are looking for someone to help create a "RUP methodology for SOA".

   Reply

7. Back to top

   Re: Standard

   by John Harby

   Is there actually any standard methodology out for building SOAs yet?

   
   
   I don't think there is anything specific. However, I do think they are under development as I actually saw a job ad from IBM stating that they are looking for someone to help create a "RUP methodology for SOA".

   Reply

8. Back to top

   Re: Standard

   by Jim Murphy

   I think there nees to be a distinction between a SOA based project and an Enterprise wide SOA.
   
   Clearly if I'm working on a SOA based project that involves 1 web site, 4 new services and web service adaptors on existing systems I could take a very project oriented perspective. The project has a managable lifecycle and lends itself to traditional modeling approaches because the lifecycle of all the dependent systems is in step.
   
   If on the other hand I'm contributing a service to an existing, wider SOA that will be consumed in many different application contexts its a very different set of issues.

   Reply

9. Back to top

   Re: Standard

   by John Harby

   My experience involved a large company that wanted to move to an enterprise wide SOA. They decided to do so around a "pilot project" that initially had a great deal of interest. Some business level changes occured that negated the need for the pilot and unfortunately most of the SOA motivation went as well.

   Reply

10. Back to top

    Case studies

    by Jeevak Kasarkod

    Are there any case studies of enterprise wide SOA deployments which describe the methodology used?

    Reply

11. Back to top

    Re: Case studies

    by John Harby

    I don't know of any documented case studies of the "pilot" approach but this company definitely qualified as a large enterprise.

    Reply