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

SOA and PMBOK - Stop the Madness!

It occurs to the Ninja that most of the old style middle management types who have grown up with projects constantly failing, falling behind or out of control, do not grasp the fundamental shift in thinking that SOA demands. In the minds of these IT relics, SOA is just another sales job to the business to get them to fund the project in which the relics find themselves. Once the project is funded, the architecture is seen as a burden and an overhead and the relics fall back to the traditional Software Development Life Cycle and the well worn path laid out by PMBOK. After all, most projects are just a string of sequential steps roughly resembling: Requirements, Design, Develop, Test, Deploy. Or should I say: Requirements, Design, Develop, FAIL. Or some combination of FAIL and pick your phase.

This is pure madness. If the majority of IT projects fail using the antiquated approach suggested by PMBOK, and they do, why do we continue to jump behind the relics who flog this approach and claim that this time it will be better? We will be agile and we will get sign off this time or we will use an automated test tool. Surely that will prevent the failures of the past. Surely you are one of the relics if this is your belief. Wake up and smell the roses Relic. THE OLD WAY DOES NOT WORK. You proved it, now change!

The fundamental shift in thinking for an SOA based project is that there is no 'throwing the requirements over the fence' attitude. The Business Analysts, representing both the operational and the overall business architecture perspective, are involved in not only the requirements phase of a project but they play a major role in every phase. They are no longer just showing up to write some magical Requirements document and then showing up during Acceptance testing to sign a paper authorizing the garbage that was developed to be slammed into production. They must recognize that change to the business will occur during any/all phases including the development or design phases and they are responsible for recognizing and changing the project scope to react to these changes. These changes are constant and so their involvement is constant. Unless of course, nothing ever changes.

If you think(believe) that Business Analysts need only play bit parts during the initial and final stages of your project lifecycle, look in the mirror. You are probably a Relic. The sooner YOU change or leave, the better for us all.

The SOA Integration Ninja

Governance and Service Orchestration/Workflow

During the 'Delivery Days' presentations on SOA today, Todd was able to condense the message of SOA into a single hour presentation. Very admirable attempt, however, 2 tenants of SOA were not identified as fundamental. So, my Ninja senses tell me to cover these two tenants (Governance and Service Orchestration/Workflow) so that his efforts to not go in vain. I know they were probably just missed because of time constraints.

Governance

All the plans of mice and men are doomed to failure unless someone is willing to execute the plans. Governance is just that. We have a plan to reuse and we say we will, but we never really expand this beyond individual project boundaries because of the autonomous nature of the business units, amongst other reasons. In any case, what mechanisms are in place to ensure governance? Is the Uuber BA and/or an Enterprise Architect within our clients organizations participating on reviews to ensure all the projects are sharing appropriately? Using Registries? Paying homage to the SOA Integration Ninja? How do we ensure vendors follow the rules when we bound them to fixed price contracts with little room for the extra work necessary to understand an environment? Well, we have the means and the technical tools to make amazing leaps in enterprise system connectivity and real value from composite applications, but unless you have the rigor to execute the plan and enforce governance, you will not reap the benefits proposed by SOA. This may not upset you, or your client, because all you both want to do is use the latest buzzword to sell your current initiatives. I know about you. Shame.

Service Orchestration/Workflow

As much as I believe Todd when he makes the ascertation that the Service registry is key to delivering long term benefits from SOA, where this reuse occurs is debatable. Since I like a good debate (non violent but severe) I will take up the challenge. The prospect of having a toolkit of services, which are composible into business processes and controlled through easy to change metadata, is utopian. However, the ideal to remove IT (Developers) from the picture, unless building new services, is not an unattainable goal. Tools exists that allow services to be represented within easy to comprehend workflow models (UML Activity Diagrams) some based on BPEL and whatnot but this value proposition is not about the use of standards like BPEL and BPMN, although important, it is the change in responsibility from IT People to the Business People for Orchestrating their services to meet the ever changing needs of THEIR business. This is certainly not unachievable since several of our clients are combining ESBs and Workflow products like POSSE, K2 and Lombardi to empower the Uuber BAs with not only a design time model of the business but a working production sandbox where the business can orchestrate, change, monitor and manage workflow ALL through metadata that effects the runtime behavior of underlying services. The reuse is present in this arena, allowing the business to reuse Master Data Reference services for validations and call string together individual services, such as: “Add a New User”, “Record Production Volume”, “Send Latency Notice”, “Generate Earnings Report”, for example, many times within multiple Workflows (jobs). Each would run somewhat differently, controlled by the business modifying the metadata to tweak the service to behave in an altered manner. Decision points and enterprise business logic would be reflected in the emerging/running models and even the panacea of BAM (business activity monitory) is possible using this platform since you can visualize where each workflow is by using the same model representation.

Whoops – rambled on their for a bit. So, time to sign off. On a final note, I was very pleased with the presentation made by Todd today. Just add these few addendum items (2 additional tenants covered above) and his material was bang on. Oh yes, and the business granularity of slide 11 or 12 is suspect. You know, the interfaces for the critical service contracts should be business related as opposed to algorithmic since they are being built for eventual orchestration by the now famous Uuber BA in his Workflow tool of choice J

I hope you enjoyed the rare presence of the SOA Integration Ninja himself, at today’s Delivery Day in Calgary. It was my genuine honor to be able to participate. Thank you. If you were not able to attend, the Integration presentation is posted to the Online Sharepoint site under SOA/Integration under the subtopic ‘Goals and Objectives’, I think. If you want it, you will find it dude.

Truth is only evident to the believer.

Murray Laatsch
The SOA Integration Ninja

What is different for the developer when building an SOA solution?

This has always perplexed me. How do I explain the signifigance of SOA to a developer? In essence, it comes down to design specifications and standards such that they are encouraged (forced) to code in a certain fashion. I encourage you to attend Online developer days to hear from a developer, Todd Mackey, about his perspective. He will be comparing the tenant/principles of SOA to those held dear by the OO&AD crowd. The more things change, the more they stay the same.

There are some things that are new and even scare the most agile of architects. They include:

1. Coding for the service to behave in test and production mode, via a metadata flag
2. Event enable the solution such that high level interfaces can be portrayed in WSDL if you decided later that WS was a good idea after all.
3. Expect changing requirements
4. Build for change because it will.

Thats all for now. I will post the work from Todd after he delivers it this Friday.

Later,
Murray
The SOA Integration Ninja

Welcome to the SOA Integration Ninja blog

Welcome to my blog!

I suppose my credentials are important to those that read my rants and so I present them here for that reason only. I am the Canadian Chair of the Integration Consortium www.integrationconsortium.org the current leader of their I-BOK (Integration Body of Knowledge) initiative and a Director of the local Calgary Chapter. As mentioned above, I am a Director with my firm http://www.obsglobal.com/ although I do not post on their behalf, they know I am doing this and they are very afraid :-) I am an affiliate architect with ZapThink, http://www.zapthink.org/ and in that capacity, I co-teach a 3 day SOA Course for the Intervista institute www.intervista-institute.com/soa.html I have delivered SOA and Web Services solutions to many clients and I prefer designing/building solutions to selling, managing or even blogging about them.

While it may seem, from my blog title, that I claim to be a Ninja. This is just partially untrue. I aspire to the tenants of the Ninja practice without resorting to violence. I admire the stealth and the awareness that everyone is motivated by different things and that by recognizing a person’s motivation, the Ninja gains an advantage. As a consultant, I desire every advantage I can get and like the Ninja, I am paid to get the job done and then I disappear, leaving my clients armed and ready to reap the benefits of my work (at least that is my goal anyway).

My target audience are those consultants on my team that are delivering SOA and/or integration solutions to their clients right now. My posts and all the content I provide is meant to assist and guide these consultants to deliver quality solutions. If you are challenged in this regard, read on and if not, in the immortal words of Gilda Radner from Saturday Night Live fame: “Never Mind”.

Enjoy,
Murray Laatsch
The SOA Integration Ninja

Want to see and hear the SOA Ninja, click here: http://www.youtube.com/watch?v=pIbTDLJIy6k