Web Services project roles
The team perspective
Olaf Zimmermann (ozimmer@de.ibm.com), Senior IT Architect, IBM Enterprise Integration
Frank Mueller (mueller.frank@de.ibm.com), IT Architect, IBM Global Services AMS
Summary: This article describes the many different job roles involved in Web services development projects, what their
goals are, what their tasks are and how they work with each other. It does not go into detail over the actual tasks to be
performed (such as creating a doc/literal service from WSDL); rather it tries to give IT staff of any background overall
guidance on what they should be thinking about when approaching a Web services project. The intention is that this
article can help an IT department figure out how to organize its projects better and plan for the full picture.
Date: 10 Jan 2004
Level: Intermediate
Also available in: Japanese
Activity: 7240 views
Comments: 0 (View | Add comment - Sign in)
Average rating (30 votes)
Rate this article
Web services have passed the days when only a few enthusiasts played around with immature yet highly-praised
technology, struggling to get anything -- even simplistic, unsecured exchanges of basic data structures up and running.
In contrast, during the last two years, the technology has proven its maturity on numerous real-world projects. As a
consequence, many technical leaders nowadays consider Web services to be another powerful part of the enterprise
application and software integration toolbox, ready to be used in their next big project in this area. So, as Web services
usage is spreading over to the "normal" enterprise application project in your organization, you might find yourself to be
part of a Web services project team, even if you have never considered yourself to be one of the enthusiasts mentioned
above. Now, what role will you have to play? Let's find out what's available!
Why bother?
There are several reasons why you should consider reading this article: if you are a project manager, chief architect, or
another technical leader in your organization, you can can find advice on how to structure and staff your first Web
services project. Our collection of roles and responsibilities can serve as input to your work breakdown structure. If you
are a developer just getting started with Web services, you can learn which tasks and tools exist -- and what keywords
you should add to your CV so that your name makes it into the project plan of the next Web services project near you.
Note than this is not an article on developing in teams in general, we focus on the Web services-specific aspects; for
instance, roles you do not find in standard J2EE projects, as well as tools and information sources for the practitioners
assigned to one or more of these roles.
You might be wondering why we decided to write an article that at first glance appears to be a bit dry. Indeed we agree
that applying the technology to solve real business problems is the real fun on any project. However, a good dose of
structure and methodology is key to success, and an unsucessful project is never enjoyable, even if it is circled around
the hottest technology on the planet. So trust us, it is worth making the effort!
Recap: Web services in a nutshell
Web services solutions and service-oriented architectures (SOAs) include service requestor (client) and service provider
(server) implementations, which communicate via SOAP (XML messaging). Web Services Description Language (WSDL)
service descriptions provide the glue between requestors and providers. Optionally, a service broker, for example a
Univesal Description, Discovery and Integration (UDDI) registry, might be involved. The service descriptions and
interactions as well as XML schemas for shared data have to be modeled. Implementations have to be designed,
developed, deployed, and tested. So far, so good; not too surprising, you might say, in case you have visited the
developerWorks Web services zone before. Now, the question is: how does a project team get there?
Project phases and roles
Any development project runs through different phases, requiring different skills and collaborations throughout its
lifecycle. Web services are no exception here. Depending on the methodology used in your environment, you probably
have already come across generic terms such as the following:
Requirements engineering

Business domain analysis
Solution architecture outline
High- and low-level design
Object-oriented analyis and design (OOAD)
Various test phases (such as unit, integration, system, acceptance test)
Going live
Maintenance
Management.
Aspects such as service modeling (for example, coarse- or fine-grained interface), choice of SOAP engine (IBM
WebSphere SOAP, Apache Axis, or Apache SOAP 2.3), and organizing interoperability tests are first examples of Web
services specific considerations. The nature of these issues varies, for example service modeling prerequisites a different
skill and mindset than interoperability testing.
The role metaphor has proven to be very helpful in this context, bringing chaos to order. Roles are related to project
phases and define an abstraction layer decoupling job descriptions and performing resources. All project team members
take one or more roles. A role model is a common construct in project management and design methodologies. The role
concept establishes a commonly understood vocabulary, which has proven to be a very powerful instrument at project
initiation time.
So let's now look into such a role model for Web services development projects. For presentation purposes, we divide the
roles in our model into three categories. As Web services projects are just another type of development project, it is not
surprising that we find a lot of well-known roles here. We define a category of existing roles for them. However, some of
the existing roles receive additional Web services-related responsibilities; we categorize those under extended roles.
Finally, there are new roles with special Web services-related responsibilities, which are listed under extra roles.
Existing roles
Let us start with four roles you all have seen (or taken) on projects:
Project Manager
Has the overall management and leadership responsibility for the project team. Defines and tracks project plan and
work breakdown structure.
Business Analyst
Harvests the business users' functional requirements and provides domain knowledge to the team. Must understand
the business language and have industry and domain skills.
Architect
Technical leader of the project. Develops the logical and physical layout (structure) of the overall solution and its
components.
Developer
A.k.a. code warrior. No need to introduce this role here!
Security Specialist
Responsible for the definition of security guidelines (policies) and the implementation of security means adhering to
these guidelines.
System and Database Administrator
Performs installation and ongoing maintenance work on hardware, operating and database systems, and
middleware.
Note that this list certainly is non-exclusive. We could have mentioned any role without Web services-specific aspects
here, as they all fit into this category. However, we have limited the list to the most prevalent roles to occur in Web
services projects -- this article is not a general project methodology tutorial.
Extended roles
Five standard roles receive additional duties on Web services projects. These roles and their new responsibilities are:
So many people?
Note that any real person can wear several hats. In other words, a single performing resource can take several of the
listed roles. For example, your IT architect might also be reponsible for the service modeling. To map roles to persons is
a main task for the project manager once the work breakdown structure has been defined in the abstract.
Obviously, letting individuals wear several hats works especially well for the top performers in your team. We sincerely
hope you have access to at least one or two of such luminaries!
Product Vendor
Supplies a WS-I-compliant Web services run-time container, and optional service registry and SOAP gateway
services.