Web Services project roles

The team perspective


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.
Technical leader of the project. Develops the logical and physical layout (structure) of the overall solution and its components.
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:

Product Vendor
Supplies a WS-I-compliant Web services run-time container, and optional service registry and SOAP gateway services.
Takes the development artefacts and installs them in the target runtime environment. Generates stubs and skeletons for the target environment from WSDL and installs them together with the service implementations. Provides JAX-RPC mapping and handler configuration through Web services-specific deployment descriptors.
In charge of the various standard test stages such as integration, load, and acceptance test. Also defines test cases for Web services interoperability and conformance tests.
Designs and implements project-specific scripts, generators, and other utilities. The degree of standardization in the Web services world makes it possble to, for example, develop custom WSDL-, JAX-RPC- or JSR-109-aware tools.
Knowledge Transfer Facilitator
Provides access to subject matter experts and technical instructors who bring in extended knowledge regarding Web services concepts and implementation assets.

Extra roles

Finally, the time has come to define which additional roles you can see on Web services projects:

SOA Architect
Responsible for the end-to-end service requestor and provider design. Takes care of inquiring on and stating the non-functional service requirements.
Service Modeler
Applies data and function modeling techniques to define the service interface contracts including the shemas of exchanged messages.
Process Flow Designer
Investigates explicit, declarative service orchestration (aggregation, composition) possibilities. An optional role.
Service Developer
J2EE developer familiar with Web services concepts and XML. Develops service interface and implementation (provider side) and service invocation code (requestor side).
Interoperability Tester
Verifies that the developed requestor and provider implementations interoperate seamlessly and ensures Web Services Interoperability (WS-I) conformance.
UDDI Administrator
Defines how the generic UDDI data model is customized and populated. An optional role.

Note that our split between extended and extra roles is somehow arbitrary. Both extended and extra roles originate from existing ones (for example, SOA architect and service developer). However, we believe that for the extra roles, the introduction of new names is justified. From now on, we will soleley focus on the extra roles.

Web services-specific roles

Let us now investigate the Web services-specific roles a little further. The following figure shows these roles together with the tasks they perform:

Figure 1. Extra roles in a Web services project and their tasks
Roles and tasks in a Web services project
Roles and tasks in a Web services project

The following table shows how these roles interface with each other, which skills are required to perform in these roles, and which tools are available to the performing practitioners:

Project RolePerformed TasksCollaborates WithPrerequisite SkillsSupporting Tools
SOA ArchitectSolution outline
Requirements analysis
Architectural decisions
Component modeling
Operational modeling
Any other team memberGeneral IT architectures
J2EE technology
XML, XML schema
Web services concepts and platforms, best practices
UML editors, office suites
Service ModelerInterface contract design
WSDL editing (top-down, bottom-up, meet-in-the-middle)
Business Business Analyst
SOA Architect
Service Developer
XML schema and namespaces
J2EE technology
WSDL editors, Java to WSDL generators
Process Flow DesignerBusiness process modeling
Assembly of atomic services into chains (processes)
Service Modeler
Business Analyst
SOA Architect
BPEL4WS, WSDLGraphical flow modeling tools, BPEL4WS generators
Corresponding runtime support
Service DeveloperService provider coding
Service requestor coding
Provide SOAP header handlers if needed
Code documentation
SOA Architect
Service Modeler
Interoperability Tester
J2EE, XML, SOAP, WSDLWeb services wizards in IDEs
WSDL to Java generators
Interoperability TesterWSDL inspection
SOAP envelope tracing
Conformance testing
Service Developers (requestor and provider side)SOAP, WSDL, WSI Basic Profile Version 1.0TCP/IP tunnels and monitors
WSI test tools
UDDI AdministratorUDDI modeling
UDDI population
UDDI administration
SOA Architect, Service ModelerUDDI data model and API knowledge
Database design and administration
UDDI browsers

Regarding the tools discussion, we have assumed that J2EE is the service implementation platform of choice. In case other platforms such as Microsoft .NET are involved, additional skills, tools etc. have to be added to the picture. Furthermore, we have deliberately stayed away from product names until now; as you can imagine, a complete stack of Web services tooling and runtime support is available from IBM as well as the open source community. Start your journey at the Eclipse and the Apache Web services open source projects, and do not forget to investigate the IBM WebSphere Studio Application Developer product and the technology previews available at alphaWorks (see Related topics).

Assignment of People to Roles

Every role addresses a different aspect of the project as a whole. Earlier on we said that one person typically wears several hats, in other words, acts in more than one role. However, projects risk decreases if different people with broad and diverse skills are on board. There are situations in which only such a purposeful cooperation of different people can unveil the crucial issues of the project and lead to a sound solution. On the other hand, the communication overhead increases with each new team member. There is no single and no simple answer to the roles-to-people mapping challenge. There are many different opinions and controversies on how it should be aproached (even the two authors of this article do not always agree!).

Rather than continuing this debate, let us now take a look at a small example. Consider the following scenario: a fictitious company, say from the insurance industry, has decided to build a new set of mid-office business applications for risk and policy management that has to interface with two different back-end systems. Both back-end systems have been built as J2EE applications -- one uses EJBs, the other one only servlets, JSPs, and JDBC to connect to its customer and contract databases.

During the initial stages of the initiated development project, the roles defined above are assigned to team members. In addition to the Web services-specific activities, the standard project tasks and roles are also identified and assigned as well. The following table shows the results of this work breakdown exercise:

Team MemberAssigned RolesCollaborates WithActual TasksSelected Tools
1Project Manager(all team members)Project planning
Ongoing project control
Spreadsheets, project management software
2Business Analyst3Problem domain analysisProcess modeling tools, office suite
3SOA Architect
Service Modeler
Knowledge Transfer Facilitator for Web Services
(all team members)Software and system architecture
WSDL model for service invocations
Rational XDE, WebSphere Studio Application Developer
Harvested experience from other projects
4aService Developer
(Unit) Tester
3, 5, 6Development of risk and policy management service requestors (clients)WebSphere Studio Application Developer
4bService Developer
(Unit) Tester
3, 5, 6Development two service provider implementations (EJB, non-EJB)WebSphere Studio Application Developer
Interoperability Tester
3, 6Integrate and connect components developed by 4a and 4bJUnit, WSI conformance test tools
TCP/IP tunnel monitor
6Service Deployer
System Administrator
Database Administrator
UDDI Administrator
3, 4, 5Take care of the entire runtime infrastructureJ2EE deployment tools, Ant
Product specific administration GUIs

You can see that except for the Project Manager and the Business Analyst, all other team members wear more than one hat. Furthermore, the extra role Process Flow Designer has not been assigned at all, as it is not required in this scenario.

Also note that the example is a rather simplistic one; in real-world project, expect larger teams. We have had good success with team sizes between seven and ten in the core team. It all depends on the scenario at hand; be prepared to split the project into stages in case your work breakdown structure gets too complex to handle. In other words, make sure to plan the project to operate in an iterative and incremental fashion. This gives the team a chance to learn on the job and minizes project risk. In the world of agile development, this principle is called continuous integration.

We do not elaborate any further on the fictitious insurance example here. As a matter of fact, it originates from the book Perspectives on Web Services (see Related topics), where it serves as an end-to-end case study and scenario for the featured reference implementation. This article can be viewed as a small companion to the book -- an extension to its Engagement Perspective if you will.


In any real-world application development project, not just technology can make or break it. Soft facts such as a reasonable work breakdown structure, the right skill mix, and good teamwork are also key to success, many times even more so than the technical solution elements. As Web services are a relatively new technology, a lack of related documented experience in this field can be perceived. There are several Web service-specific roles and other roles well-known from standard development projects receive additonal responsibilities.

Certain additional skills are required, and many tools are available to assist you. The assignment of roles to resources has to be balanced; there is a trade-off between advantages from a high degree of specialization and the related communication overhead. In any case, the "lone wolf" approach certainly does not work for nontrivial projects, and general project management techniques apply to Web services projects just like to any other project.

As members of the IBM services organization, we have had the chance to participate in a number of full-scope Web services projects over the last couple of years. We hoped that with this little article, we could share some of our experience from these projects with you.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=SOA and web services
ArticleTitle=Web Services project roles