By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The Web services readiness review: 20 questions to help you identify areas for business and IT process change
A few weeks ago I asked the question "what comes first - the chicken or the egg?" In posing this question I was really just reiterating conventional wisdom that technology innovation always precedes practical application. But as we all know, new technology needs practical techniques and processes that make them usable by and useful to mere mortals.
2002 has been a year of technology advancement for Web services. During this past year we have seen a deluge of technology in the form of platforms, languages, protocols, tools and products BUT, not much real deployment activity. As we move into 2003 many people are saying to me that this is going to be the year that Web services get real. We have the technology, as the saying goes, and as the macro economic situation recovers we are going to see massive take-up of Web services.
But wait a minute. For all you enterprise architects, software engineers, ISV's, integrators and consultants, that have spent huge investment in creating reusable, repeatable, quality software delivery processes - have you adapted your practices so that you don't drop the process quality ball?
Let's ask a few interesting questions:
1. Does your requirements definition process start with the premise that components and services will be acquired from potentially MANY different sources?
2. Do you have a Service Oriented Architecture?
3. If so does it form a coherent foundation for the inevitable shifts to:
a) secure external Services
b) grid and utility computing
c) federated supply and consumption
4. Do you have a well worked trust policy and architecture that assumes multiple sources of service supply? Is this integrated into your service design and test practices?
5. Do you have management processes in place to co-ordinate and configure services (versions, contracts, commitments) which are externally provided, sourced and or consumed?
6. Do you have separate process threads for supplier and consumer activity?
7. Do you have design policies on generalization and specialization? For example, will your published Services be general purpose or situation-specific?
8. What drives your design decisions? Performance or business adaptability? Do your business sponsors understand the (business adaptability and cost) tradeoffs being made?
9. Do you have policies (and organizational coordination and accountability) for business rule implementation at run time?
10. Do you have full traceability throughout your life cycle on the service and related artifacts?
11. Do you have formal contracts between service bearing components?
12. Does your development process maintain real separation between service bearing components (real implementation transparency) such that they are genuine black boxes with formal definition of all dependencies? Are any of your major components informally using local interfaces or have indirect platform dependencies (versions of other products, protocols etc)?
13. Does this separation also apply to your testing process?
14. Do you have formal SLA's at component level?
15. Does your business understand its roles as (variously and concurrently) provider, consumer and intermediary.
16. Does your enterprise understand which business products will become services and vice versa?
17. Are you ready to implement appropriate levels of process integration between software and business product development?
18. Have you established a Web service based bus structure that will support adaptable use and reuse of back end applications independent of platform and organization?
19. Will the Service bus structure easily support outsourcing?
20. Do you treat (screen, manage, monitor) internal and external consumers in the same manner? Do (or will) they use the same service, merely differentiated and varied by context?
How did you score
Of course no one can answer YES to all these questions yet. Not is this list comprehensive; far from it. These and many others are issues that we are going to have to solve in 2003.
Those organizations that have really embraced Component Based Development (CBD), by implementing real separation with black box components, rich contractual interface specifications and supplier/consumer organizational models, will have a solid foundation for service architectures. Others have a way to go.
But even for mature CBD based organizations, there is much to be done. You might consider the service process task like an onion. Formal component techniques sit at the core. But surrounding that essential core are numerous layers of process tasks that address the key difference between components and services - the run time realization and implementation (organization and platform) independence. All the underlying control, choreography and management tasks that have been hidden under the surface need to be externalized, AND made platform-independent.
Summary and links
Finally it's going to be really important to avoid the mistake of assuming that technology alone is sufficient. As we have discovered with software components, just adopting the technology will not deliver the real benefits. Except that this time around services are much more a business issue and lack of readiness in process terms could have a much greater adverse impact.
We have an active Experience Exchange Forum focused on this issue. See what others are thinking; add your questions to the list; make your comments in the Forum.
This is available to ALL registered CBDI members.
Also by happy coincidence I understand that the new book on the Select Perspective process can now be ordered. Many will be fully familiar with the original Select Perspective process, that assisted early CBD ioneers. The new book is titled "Service and Component Based Development: Using the Select Perspective," by Hedley Apperly et al. You can read my Forward and link to Amazon for further details.
There is also an active Forum focused on the rather interesting issue of design policy for services.
In October we published a discussion paper on the process topic. We suggested that while Web services processes will inherit much from CBD, there's much more to consider. This is available to Silver and Gold members.
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.