Enterprise Software

Web services roundtable: Challenges for development managers

Three key industry executives weigh in on the tough choices managers face when moving to Web services.

Welcome to our first roundtable discussion on Web services. Each installment will feature IT executives kicking around issues that arise when moving into Web services, an emerging and powerful trend affecting most software development managers.

Our participants were carefully chosen for their industry experience and knowledge of technology. They include Fred Engel, CTO of Concord Communications, an infrastructure management software company in Marlboro, MA; Carl Sutter, manager of product implementations and customer support at CrownPeak, Inc., a producer of enterprise-level technology in Marina del Rey, CA; and Harry Gruber, CEO, president, and founder of Kintera, Inc., a San Diego-based ASP that raises money for nonprofit companies on the Internet.

So what should Web services achieve and what are its strengths and weaknesses? Our roundtable participants think they know the answer.

There is no shortage of definitions of Web services. The technology marketing spin-masters have had a field day defining, redefining, and lapsing into doublespeak as they deliver garbled definitions of Web services.

According to San Francisco-based consulting company The Stencil Group, Web services represent the following:
  • They’re reusable software components that continue the long ascension of object-oriented design in software development.
  • These software components are loosely coupled. Traditional application design depends upon a tight interconnection of all subsidiary elements. Web services can be accessed programmatically. Unlike Web sites and desktop applications, they are not designed for direct human interaction, and they do not have a graphical user interface. Rather, Web services operate at the code level; they are called by, and exchange data with, other software. They will be incorporated into software designed for human interaction, however.
  • Web services are distributed over the Internet, making use of existing, ubiquitous transport protocols like HTTP.

Let’s get started:

What happened to infrastructure?
Engel: Developers working on the most advanced Web services applications forget about the effects of infrastructure. While Web services hold great promise for improving business performance by making data and applications easily interoperable and customizable to needed functions, those potential benefits can be easily integrated if infrastructure performance takes a hit and requires an increase in IT firefighting. Avoiding this scenario requires forethought on the part of application developers and IT managers, as well as the management tools that can treat the infrastructure Web services to make sure they are running as an integrated whole—from applications and systems to network elements.

Separate development from production
Sutter: I disagree. When you look at cost savings [with] Web services, you have to separate the development from the production. In terms of development time, the savings are akin to moving from custom text-file data transfers to XML. The hard work is still in establishing a data dictionary and getting your business partners to agree to it. Once that’s done, however, XML offers a development cost improvement in that the format and escape characters are standardized and you can buy DOM software components to decode the data without having to write that code. For Web services, having the communications protocols built into the development tools means that time is saved over coding custom, CGI, or DCOM code. But you still have to spend time designing and standardizing on a command structure. And, don’t forget that the production and hosting part of Web services is still in its infancy. Once you build the services, the communications infrastructure needs to include all the things we are used to with EDI and similar systems, such as security, fault tolerance, message queuing, guaranteed delivery, and real-time transactions. All of these systems are just emerging for Web services.

Dangers of a short-term perspective
Engel: Historically, most software developers viewed the world from a short-term perspective. It was about creating a perfect product and then releasing and supporting it. Web services-based applications are almost 180 degrees different. It’s not a business; it’s a service. And, when you design your software, you are much more concerned with maintenance and making sure the service is running around the clock. And it’s got to be compatible with all the other services that interact with it. This could account for the criticism that the costs are not what you think they are. You can’t forget that it requires perpetual maintenance.

Test environments are not representative
Engel: Don’t forget that Web services managers do some very inefficient things. What works in a test environment often dies when you try to scale it. When you look at the systems aspects, the issue is how do you get module A to module B? You’re talking to different machines and you want them to do something reasonable. The difficulty is that you don’t know how the software you are using will affect that need and how to control your project. The horror stories I hear are that power packs turn on their applications and everything stops. A big fight ensues trying to determine why they stopped. There are big issues here. Developers are sensitive to the system issues. They have a complexity budget but they can only keep so much complexity. Their complexity budget is absorbed in making it work. It is absorbed in the wrong place relative to deployment, which often has little to do with making it work. They lack the experience of knowing when to get into trouble and when not to get into trouble. Take SQL: If you don’t want to do a large mass of queries, you shouldn’t be using SQL, which is best for small queries.

Absorbing budgets in the wrong place
Gruber: A major difficulty is budgets are absorbed in the wrong place. In a typical software company, two-thirds of the budget might be allocated to engineering efforts and one-third to Q&A. This is just the opposite of what you should be spending. You might need one-third in engineering and two-thirds in Q&A because there is a lot more complexity in deploying it. A very significant engineering effort is required. Imagine what it takes to run something like this around the clock. Costs are all back-loaded. The problem of being in a virtual environment is you don’t know what works and what doesn’t work. It points up the importance of interfacing properly with your vendors. Sometimes you can build software you think is perfect and it doesn’t match. A problem developers fail to cope with is the customer not only sets the specs for what you need to build these initial reference accounts, but also integration with their other Web service providers. When it comes right down to the proverbial bottom line, you have a notion of Web services as economy of scale. You can’t expect the customer to pay for the entire service because the feature or combination of features is not worth what it costs to support it. You have to support that feature over thousands or hundreds of thousands of customers. It means you must have a significant sales and marketing effort, pointing up another Web development effort.

What’s next?
So, where are we? Web services captured more criticism than praise in our first roundtable. The next installment of our roundtable series will cover ways to achieve ROI with Web services.

Tell us your views on Web services
What do you think about the challenges of implementing Web services? Do you have a question for our roundtable participants? Post a comment below or e-mail here.

 
0 comments