BSP First-to-Market Opportunity
Many businesses are taking advantage of the Web services architecture to become business service providers (BSPs). Before jumping headfirst onto the BSP bandwagon, it's important to understand, articulate, locate, and pilot your service offering. Here's how.
by Stewart McKie
Continued from Page 1
Understanding Your Service Proposition
Few businesses (except those solely in the business of being a BSP) will become a BSP entirely from scratch. Most are likely to base their service proposition on systems already in place or content they already own. Often a BSP will expose existing functionality from an application running on a mainframe (through a Web service "wrapper") or make existing documents and databases accessible through new XML schemas.
Before becoming a BSP, you must identify several factors of your service proposition. These factors, in turn, will determine the level of difficulty you'll have in developing, delivering, and managing your Web service. Some questions to consider include audience, security, and business impact:
- Who is the audience for your service? Can the service delivery be managed within your corporate firewall, or will the service consumers be known entities such as existing business partners? Or is the service for public use and, if so, what will be the impact of its success? A lot of consumers using your on-demand service will create significant need for scalability and availability. Fail them once and your service may be history, in the same way as "three-clicks-or-you're-out" consumers move on to other providers.
- How secure must your service proposition be to protect the service deliverable and delivery process and authenticate the service participants? For example, if you exchange invoices or payments using Web services, you'll want a higher level of security than if you provide flight information to the general public.
- How much business impact does your service proposition have, and does it matter if it goes down, is not available for some time, or fails to deliver every time? For example, is your service proposition essentially a content lookup-type service, or does it play a role in a business process that will fail or bottleneck if your service does not deliver as expected?
- What level of traceability is required for your service proposition? Do you need to know where in its delivery process your service deliverable is? Do you need to know who consumed it or collaborated with it, and when, during the delivery process? Do you need to know when the service deliverable was received or ensure that it was received only once?
BSPs In Action: Den Danske Bank
Den Danske Bank ventured into Web services as part of a larger initiative to "unlock" content and functions from its internal mainframe systems and make them available to a wider audience. A stock quote service was provided in late 2002 for delivering stock prices to Politiken, a leading Danish newspaper. Although the service is free, the bank gets valuable brand exposure to the type of audience it wants to attract to its core retail and corporate banking services.
By using Web services to deliver this kind of service, the service consumer (in this case Politiken) didn't need to build proprietary interfaces to the bank's mainframe applications. Instead, it could use open standards such as SOAP and Web Services Description Language (WSDL), which will be used by other BSPs.
|
|
Understanding your service proposition from these perspectives will give you a better idea of the level of complexity you'll face. This understanding, in turn, will affect the technology choices you make to underpin your service.
Articulating Your Service Offering
Before even beginning to think about developing a Web service to offer as a BSP, you need to create a service description that articulates your potential service offering. Much of this description will be similar to what an information architect would create as a site blueprint prior to the development of a corporate Web site. The description should clearly state facts such as:
- The service audience, proposition, and benefits
- The service inputs and outputs
- How the service will be found and subscribed to
- How the service will be implemented and then managed
- How the service will be funded (that is, your revenue model, if any)
- How the service performance will be monitored
- What criteria will determine the success or failure of your service.
Drafting a service-level agreement (SLA) is also part of the task of articulating your service offering because it helps you describe it from both a customer and commercial perspective. Many Web sites covering the world of ASPs have sample SLAs you can look at to help you kick-start your own. Alternatively, you can just look at how a pure-play technology-centric BSP such as serviceobjects.com articulates its Web service offerings on its Web site.
|
|
Subscribe to the newsletter
|
|
