How to win with SOA … third, focus on understanding

While many may understand the notion of SOA by now, very few have any idea how to get there. Truth-be-told, there is no hard and fast rule as to how one builds an SOA in their organization. Clearly, SOA is a situational thing and your mileage may vary.

However, some common patterns are emerging which may assist you in understanding how to implement SOA. Here are a few things to think about when building your SOA, and really where the rubber meets the road in terms of insuring your success…understanding your own issues and requirements.

Understand your business objectives, and define success. Let’s face it; we’re running a business, and the technology you layer into that business should add value. In other words, make for a better bottom line. Thus, it’s very important to define these objectives up front, including what defines success. In essence, we’re leveraging the business case we already defined above.

Define your problem domain. You can’t boil the ocean, thus you must define the scope of your SOA within an enterprise. Most SOAs are best implemented in small steps, such as moving a single division, or portion of a division, to SOA, if needed, instead of an entire enterprise all at once. Small successes lead to larger more strategic successes over time, and you need to establish the demarcation lines at the beginning of the project to provide better focus and understanding.

Understand all application semantics in your domain. You can’t deal with information you don’t understand, including information bound to behavior (services). Thus, it is extremely important for you to identify all application semantics—metadata, if you will–that exist in your domain, thus allowing you to properly deal with that data.

The understanding of application semantics establish the way and form in which the particular application refers to properties of the business process.

Understand all services available in your domain. Services provide behavior as well as information, thus they are service-oriented. The best place to begin with service is with the creation of a services directory. As with other directories, this is a repository for gathered information about available services, along with the documentation for each service, including what it does, information passed to a service, information coming from a service, etc.. This directory is used–along with the now-understood application semantics–to define the points of integration within all systems in the domain.

Understand all processes in your domain. You need to define and list all business processes that exist within your domain, either automated or not. This is important because, now that we know which services and information are available, we must define higher level mechanisms for interaction, including all high-level, mid-level, and low level processes. In many instance, these processes have yet to become automated or are only partially automated.

Select your technology set. Once we have a semantic-, service-, and process-level understanding of our domain, it’s time to pick the technology. Note that many people begin with this step, at their peril. How can we select the right SOA technology for the job without a solid understanding of our requirements? To be successful, this “marriage” of criteria and products often requires a pilot project to prove that the technology will work. The time it takes to select the right technologies could be as long as the actual development of the SOA. A bad choice practically ensures the failure of your SOA, so do your homework here.

Test and evaluate. To insure proper testing, a test plan will have to be put in place. It is really just a step-by-step procedure detailing how the SOA will be tested when completed. A test plan is particularly important because of the difficulty in testing an SOA solution. Most source and target systems are business-critical and therefore cannot be taken offline. As a result, testing these systems can be a bit tricky, but testing needs to be comprehensive, nonetheless.