How to Identify Services for your SOA
Greetings SOA Integration Pundits…
From Wednesday to Friday last week I delivered an in-depth SOA course, with Jason Bloomburg of ZapThink fame, to a group of Architects. Jason refers to this kind of group as an argument as opposed to a swarm, a gaggle or a herd. So, this argument of architects were particularly interested in how would someone identify the candidate services within an organization. This is a typical question since almost everyone who attends this course (Edmonton, Toronto, Illinois and now Calgary) is looking for a checklist that they can add to their SDLC. Well, it's not that simple and yet it is.
I have been identifying services using a technique perfected from a number of engagements, some known as SOA and some just expecting that the integration challenge at hand would be addressed in the most appropriate manner (SOA or not). Let the masses try to build something from these lego blocks but it takes practice and skill (both found at Online) to get it right. The Ninja says, enlighten the masses so they can build upon the success and failures of those doing the enlightening. Regardless, these techniques should be able to help get you started and if you are smarter than the average bear, well, please feel free to be enlightened. So read on SOA Ninja Minions and try these techniques. They work!
Overall, this technique is identified in Online circles as the Community Of Interest (COI) approach and it is a derivative of the sROAD (SOA Rapid Online Application Development) sanctioned methodology. I use the COI approach routinely and it is well received I think. The technique starts with a discovery session or review of functional decomposition diagrams, where high level information needs are attributed to the high level actors in a diagram loosely based on the UML Use Case convention. In fact, each model in this approach is based on UML which I believe is the only way to ensure consistent understanding (you do not have to reinvent the modeling constructs, just use them fit for purpose). I cover this technique in a whitepaper I wrote for the Integration Consortium Global Integration Summit in Boston last year. The paper covered the business of employee provisioning and followed the COI approach. All the diagrams are shown in this paper which is provided as a link on my blogspot.
You may recall that in the past, this diagram was subsequently used to identify Integration Events and then prioritize these events as a way to prioritize the integration project work that needs to be done for our clients. It is not meant for only the prioritization of project work! In fact, it is a multi-talented type diagram and it is uniquely suited to identifying information sharing needs that lead to discussions about the business processes which are lacking sufficient automation or face unique enterprise challenges. This is a key value proposition of SOA – Automate the business process and the integration happens as a by-product. But, in order to understand the business pain and identify the services that should be automated to address this pain, an examination of enterprise information sharing (automated and non-automated) is essential.
It is from a combination of examining the functional decomposition diagrams already in place(hopefully) and a few well placed interviews that services can be modeled/discovered using yet another standard UML modeling construct called Activity Overview Diagrams. I have perfected this approach and the use of this diagramming technique so that the model truly become the communication point between the business and the toolsets that IT will use to implement the SOA solution and the respective services. Please check out the link ‘COI Service Identification’ to view a whitepaper that contains a case study in the use of these techniques and the subsequent build of the solution in a variety of vendor software: BizTalk, Sonic and Tibco. We had teams of Onliners using the design models to demonstrate that regardless of platform, the design remained the same.
While the models that you use on your project may be dictated by the client or your PMO, please consider introducing the COI method and associated models to them early in the project initiation. No matter what UML compliant tool (Erwin, ProVision, Visio, whatever) you have at your disposal; you can create a ‘Service Design Process Model’ if you want to. Do you want to? Can you afford not to?
Regards,
Murray Laatsch
The SOA Integration Ninja
From Wednesday to Friday last week I delivered an in-depth SOA course, with Jason Bloomburg of ZapThink fame, to a group of Architects. Jason refers to this kind of group as an argument as opposed to a swarm, a gaggle or a herd. So, this argument of architects were particularly interested in how would someone identify the candidate services within an organization. This is a typical question since almost everyone who attends this course (Edmonton, Toronto, Illinois and now Calgary) is looking for a checklist that they can add to their SDLC. Well, it's not that simple and yet it is.
I have been identifying services using a technique perfected from a number of engagements, some known as SOA and some just expecting that the integration challenge at hand would be addressed in the most appropriate manner (SOA or not). Let the masses try to build something from these lego blocks but it takes practice and skill (both found at Online) to get it right. The Ninja says, enlighten the masses so they can build upon the success and failures of those doing the enlightening. Regardless, these techniques should be able to help get you started and if you are smarter than the average bear, well, please feel free to be enlightened. So read on SOA Ninja Minions and try these techniques. They work!
Overall, this technique is identified in Online circles as the Community Of Interest (COI) approach and it is a derivative of the sROAD (SOA Rapid Online Application Development) sanctioned methodology. I use the COI approach routinely and it is well received I think. The technique starts with a discovery session or review of functional decomposition diagrams, where high level information needs are attributed to the high level actors in a diagram loosely based on the UML Use Case convention. In fact, each model in this approach is based on UML which I believe is the only way to ensure consistent understanding (you do not have to reinvent the modeling constructs, just use them fit for purpose). I cover this technique in a whitepaper I wrote for the Integration Consortium Global Integration Summit in Boston last year. The paper covered the business of employee provisioning and followed the COI approach. All the diagrams are shown in this paper which is provided as a link on my blogspot.
You may recall that in the past, this diagram was subsequently used to identify Integration Events and then prioritize these events as a way to prioritize the integration project work that needs to be done for our clients. It is not meant for only the prioritization of project work! In fact, it is a multi-talented type diagram and it is uniquely suited to identifying information sharing needs that lead to discussions about the business processes which are lacking sufficient automation or face unique enterprise challenges. This is a key value proposition of SOA – Automate the business process and the integration happens as a by-product. But, in order to understand the business pain and identify the services that should be automated to address this pain, an examination of enterprise information sharing (automated and non-automated) is essential.
It is from a combination of examining the functional decomposition diagrams already in place(hopefully) and a few well placed interviews that services can be modeled/discovered using yet another standard UML modeling construct called Activity Overview Diagrams. I have perfected this approach and the use of this diagramming technique so that the model truly become the communication point between the business and the toolsets that IT will use to implement the SOA solution and the respective services. Please check out the link ‘COI Service Identification’ to view a whitepaper that contains a case study in the use of these techniques and the subsequent build of the solution in a variety of vendor software: BizTalk, Sonic and Tibco. We had teams of Onliners using the design models to demonstrate that regardless of platform, the design remained the same.
While the models that you use on your project may be dictated by the client or your PMO, please consider introducing the COI method and associated models to them early in the project initiation. No matter what UML compliant tool (Erwin, ProVision, Visio, whatever) you have at your disposal; you can create a ‘Service Design Process Model’ if you want to. Do you want to? Can you afford not to?
Regards,
Murray Laatsch
The SOA Integration Ninja
posted by Murray Laatsch at 9:19 AM
0 Comments:
Post a Comment
<< Home