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 services—based 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).
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.
The first concern that readers have been expressing is over the reliability and availability of the Internet connection between service provider and customer. Disasters—major and even minor ones, natural or otherwise—can cause significant Internet service interruption and affect many ISPs in a particular region of the country. In such cases, the traditional wisdom—which recommends that you have multiple independent Internet connections for backup—can prove insufficient if all your provider choices go through the same choke point. The second common concern of readers has been about the dearth of service level agreements (SLAs) and Quality of Service (QoS) guarantees by budget providers of Internet connectivity (primarily DSL and business cable modem services).
Regarding Internet connection availability, I believe you need to be adequately prepared to deal with both likely and unlikely disaster situations that can interrupt service. Whether downtime results from a hurricane or a train wreck, how quickly your business will be up and running again depends on the disaster- recovery plans you've made ahead of time. Yes, the thought of a single point of failure for your business is a scary one, but knowing what you'd do if a truck were to take out a telephone pole that carries your data lines can lessen that concern.
You can resolve concerns about SLAs and QoS by spending your money wisely. Traditional tariff leased-line services (i.e., T1, frame relay, et al.) are available from major vendors with SLAs and QoS agreements to meet your needs. These digital leased lines are more expensive than budget DSL or cable modem service, but the service is guaranteed to be available when you need it. You can also use less expensive connectivity solutions, but you need to take care in implementing them.
Prepare to Jump
Are you ready to jump into the Web services world? Doing so isn't something you should consider lightly, but you need to factor the possibility into your future business-development plans. To gain a greater perspective on Web services, see Darren Mar-Elia, "Understanding the 'Net' in .NET," page 23. Web services aren't going away—you need to plan to deal with them at some point in the future.