Located in San Francisco, The Stencil Group is a focused consulting and analysis firm that works with enterprise software companies to understand their customers' business objectives and IT priorities. The firm's services support product strategy and product marketing needs.
The Stencil Group's current research emphasis on Web services reflects the firm's view that the shift toward service-based computing represents a new, distinct stage in the ongoing evolution of the enterprise software market. IT organizations are realizing significant strategic benefit from this shift, but the impact on software vendors is more complex.
Brent Sleeper is a cofounder and partner in The Stencil Group, and he leads the Stencil Group's Web services research and consulting practice. As a leading independent expert on Web services, Sleeper is the author of many articles and frequently speaks at industry events. Before cofounding The Stencil Group, Brent served in senior roles with e-business consulting firms iXL and NetResponse. Brent also worked with National Public Radio and the State of Texas. He's a graduate of Carleton College.
Sleeper believes that today's Web services field is the result of a gradual technological development process stretching back over the past decade.
I think you can point to specific events, namely the development of SOAP and the development of XML before that. One can even trace the origin of Web services back to the Common Object Request Broker Architecture (CORBA). In other words, there has been an entire ongoing series of technical developments and architectural best practices that have come together in the last couple of years. So it's hard to say exactly when Web services started, because it's part of a revolution that's been going on for ten years or more. On the other hand, you can say that all of these solutions started to reach a critical mass in the last couple of years.
Compared to Web services, CORBA was a difficult, hard-to-use, and ultimately unpopular technology, says Sleeper.
In a lot of ways, CORBA tried to do what Web services are now trying to do. But it was seriously flawed. For one thing, it was very, very complex. Therefore, it only had a few, hard-core organizations that embraced it and started deploying it. Everybody else felt it was too much work and not worth the trouble.
Web services mark a significant improvement over CORBA, says Sleeper.
Compared to CORBA, Web services are solving similar problems—it's all about how you connect multiple systems. In other words, how do you design software in such a way that various elements, or components, execute on different computers and in different organizations over a network? The guiding principle behind most Web services design is to achieve integration in the simplest way possible. Vendors and adopters are both shooting for: "Let's get a couple things right," rather than "Let's try to solve every single problem."
Sleeper believes that Web services represent an opportunity for enterprises to derive greater IT benefits and efficiencies.
Over the past eighteen months, my organization has talked to about 125 IT organizations that are either adopting Web services, or working toward adopting them in one way or the other. What these organizations are telling us is that they have some fundamental IT issues that they believe Web services will help them address.
Perhaps the most direct benefit they expect to receive from Web services is the integration of different systems. From a strictly technical perspective, there are lots of benefits available along the lines of interoperability, particularly the reuse of existing systems. In light of the fact that there are products from various IT vendors that run on different platforms we've come to the conclusion that the only way to deal with these differences is to accept them, instead of trying to pigeonhole all of our IT into just one approach. A single platform isn't always viable; sometimes it's just not realistic.
So how do we deal with the fact that we must live with multiple systems? Well, it's by tying the systems together and connecting them in a way that doesn't cost hundreds of thousands, or even multiple millions, of dollars. Those are the amounts that enterprises have traditionally paid for integration products. The challenge is integration and interoperability—doing it in a way that is cost-effective.
Sleeper feels that Web services have just started entering the IT mainstream.
If you look at classic adoption models, we're certainly on the cusp of moving beyond early adopters and entering the mainstream. But Web services are still in their early stages.
One thing that's interesting about this particular wave of IT is that many of the early adopters aren't your classic technologist types of organizations—companies that are always trying out the latest and greatest. Technologist firms are definitely working with Web services. But one of the things that we were a little bit surprised to recognize is that there's another group of organizations that isn't necessarily driven by the technical issues that typically drive early adopters. We're seeing a much more bottom-line business focus among these organizations.
They're approaching Web services with the idea: "How does this help me change the way I pay for IT?" "How does this make my IT more cost-effective?" "How does this allow me to tackle projects, or initiatives, that I may not otherwise be able to do cost-effectively?" As a result, these organizations aren't really approaching Web services from the classic technologist or IT architecture perspective.
Sleeper sees IBM and Microsoft as two current Web services leaders. But he notes that many smaller companies are also playing a big hand in the technology's development.
A couple companies—IBM and Microsoft—are on the vanguard of Web services. They're the firms that are really pushing the technology. From a marketing perspective and from a standards-proposal perspective, these firms are certainly very aggressive in their practices.
But there's also another aspect to the situation that's recognizable, if you look at current IT trends; there's a much broader Web services movement than the efforts of just these two companies. There are other companies, big and small, even independent developers, that are also promoting Web services as a practical solution. These vendors have been, frankly, the key to some of the early technology developments. For example, SOAP is often credited to Microsoft, which certainly played a role in its development. However, there were also some much smaller companies that were in there working on the SOAP proposal as well.
Powering the rapid growth of Web services is support from both software developers and IT managers, says Sleeper.
Web services' popularity has a sort of grassroots element to it. So many of the early projects that we looked at were really taken up at a developer's own initiative. He had a problem to solve, typically an integration problem, and the individual said, "Hey, SOAP helps me solve this particular problem really well, and it's easy to use!" That kind of grassroots support, bubbling up from down below, laid the foundation for some of the more strategic, top-down stuff we're seeing today.
Sleeper compares today's Web services steamroller to the evolution of another groundbreaking technology.
I compare it to the World Wide Web and the Internet as we know it today. That technology, too, was rolled out in organizations. There was, typically, an independent, innovative, grassroots kind of IT person who said, "Hey, I can put up a Web site, and look how it allows me to share information." That attitude started to snowball. As a result, within a couple of years, having a cohesive Internet strategy became a major IT issue. I think we're seeing that same evolution in Web services today.
Sleeper believes that the benefits of Web services are accessible to just about any enterprise, regardless of its size or focus.
If you look at the minimum requirements for a developer to use Web services, it's open to just about anybody. That's a big part of its appeal, the fact that you don't have to make an up-front investment of multiple millions of dollars in order to make it work.
Yet it's large enterprises that have driven much of the early Web services growth, says Sleeper.
Some of the early case studies show that Web services tend to be driven by large organizations—sort of a classic, Fortune 500-type of company that's trying to figure out ways of making their IT work more cost-effectively with smaller partners. If you look at how EDI rolled out, it was typically only the biggest companies that paid for the technology. As a result, you might have companies like Boeing and Lock-heed joining together via EDI.
More than twenty years ago, EDI emerged as a format for the electronic communication of business transactions, such as purchase orders, invoices, bills of lading, shipping schedules, and payments between organizations. The technology worked well in an e-business world that was dominated by big corporations that relied on value-added networks (VANs) and other point-to-point trading technologies. Yet, a growing number of organizations are gradually realizing that the old war-horse may not be up to the demands of twenty-first century B2B transactions. Ganging up against EDI are the technology's high cost (estimated by analysts at anywhere between one dollar and twenty dollars per transaction), as well as the need for users to maintain extensive programming resources and an elaborate support infrastructure. Lower-cost Web services, however, allow a large enterprise to link to much smaller business partners.
One of the things we're seeing in some of the early-use cases is a company like Boeing not only reaching out to its first-tier suppliers, but also to its second-and third-tier suppliers. You start to get into some of those almost "mom-and-pop" types of manufacturing companies that are further down in the food chain. Now even these small organizations can afford to tie in and use the Web browser as an extranet-type system. They can take that approach and extend it into an automated system. I think that's a really promising development.
Leading-edge Web services development, however, still remains mostly concentrated in the hands of large enterprises, says Sleeper.
Certainly the more complex, more strategic Web services initiatives are being lead by classic, big IT organizations. But they're not the only ones able to use Web services; I think that's what's different this time around.
Although Web services allow enterprises to explore new business opportunities, most early adopters are using the technology to solve existing problems in a cost-effective manner.
For internal integration, a real common use right now is creating interfaces to big, old, legacy mainframe systems that have been around for years, and probably aren't going away. Organizations can use Web services to tie those systems into more modern and, very often, Web-based systems. That's definitely a common trend we're seeing—taking legacy apps and inserting them into the IT mainstream.
Although most early Web services implementations focused on internal integration, adopters are increasingly looking to the technology to serve their external integration needs, says Sleeper.
Today, it's not always internal. Most deployments still are internal—on order of about two-thirds of them. But another third deal with partner-to-partner integration, and that's a significant development.
A common external Web services application is partner-to-partner integration. In particular, we're seeing big company-to-small company integration, and it's being done in a cost-effective way. We're also seeing more organizations using Web services to deal with portals. They're taking all of their automated systems and tying them into a user interface—a dashboard.
Sleeper points to myCIGNA.com, which uses portal technology to provide self-service functions, as an example of how Web services are making life easier for both enterprises and end users.
That's a classic example of how enterprises are using this technology. It's something that would have been very difficult to create before the arrival of Web services. Sure, they could have done it—but only at an enormous cost. That's what's different with Web services—you can do a whole range of applications that may not have been cost-effective with earlier technologies.
In the past, something like myCIGNA.com would have required a lot of custom development work. You could get it done, but it would cost a lot of money. Plus, there was a slew of technical problems associated with earlier portal development technologies. For most organizations, it simply wasn't worth the effort. The return was marginal, and most companies just weren't going to do it.
Web services lower the financial bar for these kinds of projects. The technology might end up saving a company $50,000 in development costs over the long term. That's not a huge amount of money in the eyes of many businesses, but if you can do this sort of development work cost-effectively, the savings add up. With Web services, you can increase the reach and decrease the amount of investment you need up front. This opens the way to an entire new terrain of automation and, in economic terms, a potentially large boost in productivity gains.
Although Sleeper feels that Web services are definitely ready for widespread use, he notes that some technical work remains to be done. He identifies the two most pressing needs:
If you look at surveys of IT executives, certainly on the top of those lists are two prime concerns: "I want to figure out how to deal with security in a systematic way," and "I want to figure out how to deal with a complex, transaction-based system."
Yet Sleeper is optimistic that enhancements to Web services will eventually become available.
The executives I've talked to feel that it's not a question of how today's Web services problems will be solved. It's more like, "When will they be solved?" They're pretty confident the answers will happen.
Despite continuing improvements to Web services standards and software, system design remains a big concern for most adopters, says Sleeper.
Many of the issues executives are currently struggling with relates to specific design processes. In other words, how can an organization design new distributive systems in a way that really meets business needs? Organizations want to know how not to get stuck in the same trap, like they did with CORBA. With COBRA, everything was so fine-grained that it became very technical, and very difficult to create useful business processes.
Executives want to know, "How do I design my Web services applications at the appropriate level of granularity?" That's a term executives often use. They want to match a Web service to a specific step in the business process and get the right degree of correlation. This is, frankly, the toughest issue adopters are dealing with from a technology and design perspective.
Adopters are also struggling with cost and management concerns. Sleeper notes that executives launching an entirely new software development approach usually view the task as a difficult and perilous undertaking.
They're asking, "OK, who can pay for this?" "Who's going to have the bottom-line accountability for making sure the system works?" These are issues that are broader than just Web services, but Web services have a real impact in these areas.
Sleeper believes that, in addition to interoperability, Web services' primary benefits are in the areas of enhanced cost-effectiveness and operational flexibility.
Cost-effectiveness allows IT organizations to automate processes and create applications that may not have been financially feasible before the availability of Web services. As far as flexibility goes, one of the things we're hearing again and again is that enterprises want to be as flexible as possible. They don't want IT to determine what they can do, or can't do, with their business; they want it to be the other way around. They want IT to build and support whatever business opportunity exists. That's one of the real drivers, as well as the philosophical buy-in, to the Web services model—the idea that an organization can distribute systems across business processes. With Web services, we have modular solutions that we can put together and break up, if we need to. So flexibility is important and, from a business perspective, it's been a major benefit.
Sleeper believes that Web services will evolve rapidly over the next few years, changing to meet new business needs and preferences.
There will certainly be an ongoing, evolving stack of technology. If you look at how a lot of the early Web services standards were designed, they're clearly intended to be layered on top of one another. We're going to continue to layer new functions, new products, and new standards on top of that base, and it will always continue—it's probably never going to stop. As new areas are explored, there will always be a new problem and someone will try to figure out how to solve it.
The Web services areas that will change first are the technologies that currently fail to meet enterprises' most pressing needs.
Better security and support for complex transactions are two key areas. These issues need to be addressed via standards and via software products.
There's also an entire range of strategic, very expensive, mission-critical business processes that could benefit from Web services. But I wouldn't yet throw these vital processes at Web services—the technology just isn't there. However, I do believe that solutions will trickle in over the next couple of years. In the meantime, if I'm an enterprise manager, I can start with my simple, less critical processes and obtain some learning and experience.
Sleeper's advice to organizations considering the use of Web services is to advance incrementally.
Don't try to do it all at once. Take a small step, but do get started. There's relatively little risk, and there's a lot to be gained and a lot to learn. But definitely get started.
Also, embrace the idea that you will have multiple software providers helping you. You certainly can buy into one particular vendor's approach, but the real benefit, from an IT perspective, is the concept of interoperability. It's the idea of not getting locked into a single vendor's approach. So, hedge your bets. Force your vendors to get along. Don't let them force you to walk their line.
|
