ISVs and Packaged Application Vendors Start Here cont'd...
How Web Services Will Impact the ISV |
| Opportunities and Benefits |
| Will ease customer's integration requirements |
| Providing SOAP/WSDL interfaces may be straightforward |
| Introduce new opportunities for collaborative applications |
| Change deployment options. E.g. Bring new 'service hosting' opportunities |
| Re-engineering Challenges |
| Highlight weaknesses in, or unsuitability of, current interfaces |
| Demand for more real-time behaviour in their apps |
| Need for apps to consume Web Services, not just provide them |
| Converting apps to support emerging enterprise-level Web Service standards for transactions
and process orchestration |
| Remove internal dependencies so that customers can use services at a more granular level
than the whole application |
Independent Software Vendors (ISV) must also make the transition to Web Services. As with any major change, Web
Services presents the ISVs both with opportunities for new business, and challenges in making the transition. Some
considerations ISVs should make include
- Near term, customers will expect to use their existing packaged applications in Web Service Scenarios and
ISVs will need to consider to what extent they need to expose Web Services directly from their application to
enable this.
- Longer term, ISV's must look to see how their products can add real value and deliver ROI to their customers
by being WS enabled. Customers can be expected to consider new packaged applications that exploit Web Services,
and ISVs should evaluate the opportunities this presents them.
- ISVs need to consider how their products are going to participate in more dynamic, collaborative business
processes that will be supported by emerging Web Service protocols.
- The impact on the ISV's business model. E.g. changing from software to service provider. And whether Web
Services introduce new competitive threats from new forms of competitors
- What infrastructure ISVs should use to deliver their Web Services
Many package vendors for example are converting interfaces and technologies initially developed to address
Enteprise Application Integration (EAI) requirements, to support Web Service Protocols. Adapting an existing
interface to support basic Web Service protocols such as SOAP and WSDL should not be too difficult. In many cases
this might be achieved through a simple 'wrapper' that requires little modification of the base software. Elements
of WS-Security can probably be addressed in this manner too.
However, the more complex protocols that are emerging to support dynamic, collaborative business processes,
or that might be considered pre-requisites to 'enterprise level' Web Services, such as transactions, and business
process orchestration, will likely require some level of re-engineering of the software.
Additionally, ISVs must recognise that not only must their software expose Web Services, but will often need
to be re-engineered to consume them too.
In several respects, Web Services will have similar impacts on the ISV as they do end-user organizations.
Activities such as moving to SOA, considering how to best transition their applications to Web Services, and
effecting that change, will contain many of the same actions for both ISV and end-user alike. However, the
nature of ISV applications is such that there will be deltas in comparison to end-user adoption of Web Services.
The prime difference of course is that Web Services may have not just an architectural impact on the ISVs applications,
but also a commercial impact on their business model, on the way in which they deploy software to their customers,
and how they charge for it.
Area |
Roadmap Consideration |
|
Business Integration
Today, incompatibilities are resolved by EAI tools. Web Services will remove the need for protocol conversion,
but not fully resolve semantic differences.
ISVs can reduce their dependence on EAI-like solutions by conforming to standardised business semantics
|
Ensure Compliance with relevant Business Level Standards
Consider participation in industry-body activity setting Web Service standards for your domain
Work with obvious ISV partners in eco-system to develop common business semantics
|
|
Collaborative Solutions
Increased demand from customers to build collaborative solutions will mean few ISV applications can 'stand alone'.
Applications must not just be able to share information via Web Services, but collaborate in common business processes
|
Move to SOA
Ensure proper separation of concerns, so that business process is properly isolated
Prepare for shift to standardised workflow and BPO - e.g. BPEL4WS, WS-Choreography
|
|
Horizontal Applications
Applications not specific to a vertical domain will find themselves the most obvious candidates for deployment
as hosted services, and affected by shifts to On-Demand and Grid based approaches
|
Improve Componentization
Ensure applications are 'location' independent
Applications need to be properly componentised to exploit rapid, on -demand deployment
Internal dependencies need to use Web Services to facilitate distributed deployment
|
|
Platform Independent Solutions
ISVs often base their applications on a platform independent infrastructure they have built or acquired to enable
portability. How will this transition to Web Services?
|
Adopt SOA as Foundation of Platform Independence
ISVs need to carefully evaluate the use of platform specific Web Services infrastructure with regard to delivering
portable solutions
Implementation of SOA principles, a proper service architecture, use of the service bus, and a separated services
layer will improve the ability to deliver platform independent solutions, whilst at the same time exploiting platform
specific features
|
|
Configuration and Deployment
Web Services enable widely distributed applications to be more easily integrated via services. Externally hosted
applications can be integrated to the same level as internal ones
|
Plan for Alternative Deployment Patterns
ISVs need to assess whether they can take advantage of alternative deployment patterns such as providing hosted services.
|
We see the following three basic patterns to the application of Web Services by ISVs
- Traditional Deployment plus Web Services
The ISV delivers the software to the customer who hosts the application in-house.
Web Services are added to the application by the ISV for two reasons
- Internal Services. So that the customer can integrate the application more easily with other internal applications
- External Services. So that the customer can expose the services to their own external customers and business partners
- ASP with Web Services - Hosted Service Provider
The ISV hosts the software themselves, or uses a 3rd party host. The customer then uses the application via its external
Web Services.
Most ISVs do not traditionally host their own applications preferring instead (or more commonly the customer preferring)
to use ASPs if the customer does not want to deploy the application in-house, and there is little reason to believe this would
change.
Whereas traditional ASP was primarily a 'self service' approach with the application being accessed by employees via a
browser interface, the use of Web Services enables the customer to integrate the hosted application into their business processes
as if it was deployed in-house.
- Distributed
A hybrid approach is a distributed pattern in which the customer still deploys part of the application in-house, whilst the
ISV (or their ASP) delivers the remainder as a hosted service. Web Services could be leveraged to simplify the deployment and
configuration requirement in situations where the ISV is responsible for 'feeding' information or rules that must be maintained
on a regular basis.
Figure 1 - ISV Web Service Patterns
- Consuming Web Services
Regardless of the deployment pattern, ISVs will also need to adapt their applications to consume services, not just provide
them. This could be for either
- Business Services - the application will need to consume Web Services provided by the customer's business partners and
their own applications.
- Infrastructure Services - the ISV can leverage infrastructure services rather than having to implement certain capabilities
within their software. Similarly, their customer will want integrate the software with a variety of infrastructure services
provided for example by the underlying platform, Web Service Management products, and external hosted services.
Consuming Web Services will be the more challenging for ISVs. Though they may not be the ideal services, existing interfaces
already exposed by their product can be quickly converted to use Web Service protocols. This may even be provided by a wrapper
layer that removes the need to change the existing software. However, if existing ISV software is to consume external Web Services
it will likely require some re-engineering, which may be significant.
|
