The promise of Web services is enticing: a virtual smorgasbord of business processes ready for your plate. But in many an all-you-can-eat buffet, you don't know where the food is coming from, and the temptation to take more food than you need is strong. If I were talking about food, you'd tell me that you know how to watch your diet and that you eat only in establishments where you trust the food preparation. I suggest that you apply this same strategy to the world of Web-based business process services: Develop an understanding of what services are available and how you can integrate them in your business process model. Your business needs must drive your quest for Web services, not the other way around.
Integrating Web-Based Services
As you begin to explore integrating Web-based services into your business, two separate process tracks exist, at least initially. The first track is modifying your existing business processes, which requires significant investment in a detailed analysis. You need to determine what, if any, parts of your process can be made more efficient or cost-effective if you turned them over to an outside agency. The second track is somewhat easier: creating additional business processes that you build from the ground up by combining internal and external service resources.
An unfortunate catch-22 lurks in this situation. If you can modify your core business processes to work within the Web services model, you'll have a competitive advantage, assuming that the changes have a positive impact on the bottom line. In the current climate of limited IT spending, frozen or reduced staffing levels, and multiple levels of oversight on every spending decision, cutting costs by outsourcing IT tasks can be compelling. But moving parts of your business model to the Web services infrastructure without affecting day-to-day operations is a complex and problematic process. Too much work is involved in this kind of process migration to allow the changeover to be truly transparent. And because the ideal migration situation would be to have the Web services version of your business process run in parallel with the current model, you incur significant costs to reach the point where you can create such parallel operation.
If you decide to follow the Web services path, having a complete understanding of your business process model is crucial. Your inhouse project team needs to include not only IT personnel but also representatives from the departments that are responsible for each business function. The implementation path must be results-driven; knowing the details about each process and using that information effectively is crucial to the success of a project. Of paramount importance is not letting project teams bog down in the minutiae of the process itself; teams must focus on what the results need to be. IT staff can then take that information back to their own group to determine how to achieve the results.
An important point that I can't stress enough is that one person needs to be responsible for the implementation project. In my current position as CTO of a software- development company, I serve as the project head for process-migration projects. A lot of very dedicated, smart people work on the projects, but if we didn't have a spearhead to control the projects (and all their attendant meetings), the process would lose focus. A project head's mission, beyond serving as a technical sounding board for ideas and suggestions, is to make sure that business considerations drive the technical decisions.
The model for creating new business processes with Web services is a little simpler. In terms of business-process development, no real difference should exist between a Web servicesbased business process and a traditional business process. After all, you're simply (well, maybe not so simply) using a service that an offsite vendor provides to replace some percentage of internal development. Indeed, you might already be doing so (e.g., you might be using EDI models or processes).
Common Concerns
Curiously enough, the email I've been receiving about basing business processes on Web services hasn't revealed great concern over data security or the health of the companies that provide Web services (which is not to say that data security and provider viability aren't key concerns that you need to analyze before you commit to a business model). These messages speak to a variety of topics, but they include a couple of common threads.