Continued from Part One
What's it like to be in the trenches of building a Web service for a world-spanning enterprise? In this second part of a two-part column, I'll take you inside a Web services development project at UPS, called TradeAbility.
Getting started on the application
As I explained in part one, UPS decided to build a Web services application that would allow individuals and businesses to more easily engage in international trade, and that could be used to integrate directly into a company's business processes and infrastructure.
But application development at a large company like UPS is not an island, and needs to be coordinated with other departments and company needs. So the first step in the development process concerned scheduling. UPS releases enterprise-wide upgrades twice a year, and the TradeAbility application was slated for the January 2005 release.
Once that was done, the work began in earnest. And most of that work was not actually technical in nature. In fact, said Geoff Calmers, UPS application project manager who oversaw the project, actual coding is usually the least difficult part of a development task of this size. Much more difficult is matching the business needs to the technical requirements, and creating a scheme that everyone can agree on.
"UPS is a very collaborative environment," Calmers said, and so a team was organized to develop the business requirements for the new TradeAbility product. The team included staff from marketing, business, development and IT, and the brokerage side of UPS. Included were people from several different levels of each group, so that the broadest set of concerns could be addressed.
Once the team was assembled, a document detailing the business requirements was created and agreed on. Each of those requirements was prioritized, so that the most important requirements could be addressed first, and the less important ones added later, if need be. Based on that document, actual functional requirements were built based on the business needs.
Next came the planning process, in which risks were identified, and the resources for the project were allocated. Once that was done, the actual coding work began.
No coding problems
One might expect on a project of this size and complexity that the actual coding of the application would prove problematic. But Calmers said that in fact, that was by far the easiest part of the implementation.
"Designing the code and implementing it was straightforward, without any real problems," he said. Once the business and functional requirements were in place, the coding was clear-cut, and did not hold any surprises; no large roadblocks were encountered.
However, during the process, large and small design decisions had to be made along the way, and the accumulation of these decisions could have a major effect on the ultimate success of the project. Every step of the way, Calmers said, decisions had to be made that would affect the application's interoperability. "Interoperability was the sleeping giant, the elephant in the corner," he said. "We worked hard to make the application as broadly interoperable as possible, and tested it on many platforms. There are a lot of design choices you have to make along the way, and at every step, we went for maximum interoperability."
Assessing the project
When asked where most of his team's energy went to in the project, Calmers said, "We focused on quality of the service, and making sure it scaled right. Quality assurance was rigorous, and load testing was rigorous. Aside from the planning process, that's where most of the difficult work took place. On a very complex system like this, most of the energy is focused on making sure it would work the way the customer wanted."
The most difficult part of the project, he said, "was serving the business needs and making sure that we had a product that was going to be easy for our customers to use. As in any implementation of this scale, we were working against a background of a changing marketplace, and also the changing opinions of what the customers said they needed. We solved that problem by making sure the customers were heavily involved in the project all the way through.
"We sweated bullets over getting it right, but in the end, the real energy and concerns were not about the technology itself -- it was making sure we got the business needs right. In the end, it went so well, that it was actually kind of anti-climatic … it worked, and so it was on to the next project."
The planning paid off; the TradeAbility product launched to 31 countries on a single day, and went off without a hitch.
The bottom line
In the end, the success of a development project isn't measured by how smoothly it went. Rather, it's measured by how well it helps the business. And according to Gary Huff, marketing director of new product development for UPS, TradeAbility has already proved itself, even though it only launched within the last several months.
"From a business standpoint, it's been a success," he said. "We've seen more international volume, and it's helped customers grow their international businesses. And it'll help us internally because it will mean less maintenance costs as well."
Preston Gralla is an expert on Web services and is the author of more than 20 books, including How the Internet Works. He can be reached at preston@gralla.com.
