Recently I had a conversation — or rather an argument — with a consultant I work with about the best way to implement a solution. Now I have to state upfront that I work with and specify products that support the point I am about to present, but I still think I can present a good case.
The issue and basis of our disagreement was this: When is it good to code and when is it better to use tools to replace code?
The context of the issue is that a large company wanted to pull information out of a couple of legacy applications for CRM users (Siebel in this case) so that the legacy data shows in a desktop application. In this use-case, the CRM application has the ability to pull and incorporate data via web services into the user’s desktop. So the task at hand is to create services that pull the needed information from the legacy applications. Given we are Attachmate and we have service creation tools, this is not a difficult task. The issue was how we wanted to expose the services to the CRM application.
We argued about whether the legacy services should have the needed business context built into them to be used directly, or whether we should keep them more basic (granular) and use a tool to “finish” them–in other words, a tool to orchestrate the services.
I wanted to orchestrate the “granular” services using a graphical tool–preferably a WS-BPEL tool. The consultant argued that he could easily fill the gaps of the legacy services with simple .NET or Java code. And he could do it just as fast without having to buy anything to implement my “toolset” orchestration approach. To this I can only say, “You are right, you can do it, and let’s assume you can do it just as fast, and also that you can avoid a purchase.” Regardless, there is still great benefit to taking a more formal approach by building basic granular legacy services and using tools to build orchestrated services that provide the needed context for the client application.
The reason I will consistently take this approach is not in how fast the solution takes to build — though it is still fast — but, it is in how much better a solution like this can handle changes. First, if we take the consultants approach, we can solve the problem, but we embed the consultant’s skill into the solution, a skill that will be needed whenever changes are needed, if that person is even still around. A tool, especially one with a visual layout, is more self-descriptive in what it is doing.
The following shows two approaches to the same solution. On the left is a tool’s rendering of the process to extract information from a legacy service. On the right is the first third of the code to do the same. While I don’t claim a visual tool’s display saves anyone from needing to look at the details of the process, I do maintain it greatly helps in quickly understanding context and isolating what and where to look when changes are needed. This is an advantage. Another difference in using the tool/orchestration approach is in the inherent abstraction of the legacy services from the needs of the client (CRM) app. The big advantage comes from the use of an orchestration layer itself.
SOA promises re-use, flexibility, agility, leveraging work over and over, and so on. While most of us take this with a grain of salt, there are aspects to this that are tangible. In this use-case, it is easy to see. We can meet the needs of our use-case by creating legacy services with the needed information and tying them directly to the CRM application. Business need solved.
The issue with this approach is related to keeping it current. If the needs of the CRM change, even simple small-scale changes, then we will have to touch and possibly rebuild each legacy service to meet the modified need.
The approach of using a tool differs in this regard. By allowing legacy services to be built more granularly and adding business context through orchestration, when the CRM needs change, we don’t have to touch the legacy services. We can simply modify the orchestration. And if we use an orchestration tool to do our composition, then we can modify the processes using a visually descriptive studio. This approach keeps the work to a minimum and it aids us in working with processes that we may not have looked at for a good length of time.
The case for using a toolset and orchestrating services is simple: You meet your business needs and you simplify your life by inheriting the basic benefits that are promised in an SOA — work (services) is reusable and solutions are flexible.
Think through the way you approach building services, do you build them as single purpose services or wrap code around them because it is expedient?
