Home > Articles > Web Services > SOA

This chapter is from the book

4.5 SOA Project Roles

The notion of handling exceptions in a manual fashion brings to light the key significance of people involved in SOA projects and the roles they might play. SOA projects involve many familiar project roles: project manager, business analyst, architect, developer, security specialist, and system and database administrator. However, these roles were created for different purposes and might have different inherent meanings based on the organization's viewpoint. To appropriately structure an SOA project, you need to consider that these roles might need to evolve to match the componentization and decomposition of the applications into services. In addition, implementing an SOA might also call for some additional roles.

In the following sections, we explain the functions of roles, and then we discuss roles versus skills in a project, followed by the phases in the project where these roles might apply. We then describe how these roles can be extended under SOA, as well as the new roles that follow. Finally, we examine some of the interactions among the various roles in SOA projects.

4.5.1 The Function of Roles

There is no single, global, standard definition of all IT jobs, not to mention SOA projects. Many jobs require certifications, a defined knowledge base, or cognitive tests; however, these certifications cannot always truly prove a candidate's applied knowledge, skill transfer, and creativity aspects. Because the team size, the workload, the types of work, and the subjects needed to solve IT problems vary greatly across companies, industries, and geographies, flexible teams with some specialist members are necessary. To coordinate such teams, the leaders (the architects and project managers) have to demonstrate the aforementioned capabilities beyond mere subject knowledge.

In this book, we use the notion of roles because doing so brings some order to the chaos. Roles are related to project phases and define an abstraction layer separate from actual job descriptions and assigned human resources. All project team members take on one or more roles.

Roles are a common concept in project management and design methodologies. The role concept establishes a commonly understood vocabulary, which has proven to be a powerful instrument at project-initiation time. A role does not imply that a specific individual person must execute the tasks that are associated with the role; instead, it implies an identity (an individual, a team, an organization, and so on) that fulfills that part of the process.

4.5.2 Roles and Skills

Identifying the roles involved in your project will certainly help, but finding the right people with appropriate skills is crucial. Services typically are technologically lightweight and simple; this is part of their power. With this technology, islands of heterogeneous systems can be more easily opened up for collaboration. However, along with these new possibilities come new sources of errors. SOA projects may be a new kind of project for your organization, but chances are they will not be a simpler kind of project.

An SOA project team setup should reflect these specific issues with the inclusion of appropriate skill levels and talents. We highly recommend a mix of practitioners who have experience with different platforms, different technical problems, and different skill domains. This is especially important for the SOA architect. If such a person is not available to the team, it would be feasible to have additional (part-time) co-architects to fill the gaps.

4.5.3 Project Phases

Development projects have different phases, requiring different skills and collaborations throughout the lifecycle, and SOA projects are no different. Independent of your organization's choice of the individual methodology used (waterfall approach or others), most projects will generally include the following development phases:

  • Requirements engineering
  • Business domain analysis
  • Solution architecture outline
  • High- and low-level design
  • Analysis and design (today mainly OOAD and DB design)
  • Various test phases (such as unit, integration, system, and acceptance tests)
  • Going live
  • Maintenance
  • Management

Aspects such as service modeling (for example, using a coarse- or fine-grained interface), choice of SOAP engine (IBM WebSphere SOAP, Apache Axis, or Apache SOAP 2.3), and organizing interoperability tests are primarily examples of Web service–specific considerations. The nature of these issues varies. For example, service modeling prerequisites a different skill and mindset than interoperability testing.

4.5.4 Examining and Adapting Roles

The following sections look into a model that shows how existing roles work in SOA development projects. For presentation purposes, we divided the roles in our model into two categories—existing roles and new roles—followed by a discussion on the integration of both categories.

Because SOA projects are just another type of development project, it is not surprising that we find a lot of well-known roles that we can define as a category of existing roles. However, some of the existing roles receive additional SOA-related responsibilities. From our SOA project experiences, we saw the need to establish new roles, which are listed as the new roles section. Please keep in mind that these are general descriptions of roles rather than detailed job descriptions.

4.5.5 A Look at Existing Roles

Let's start with the six roles you may have seen (or participated as) on different technical projects: the project manager, the business analyst, the architect, the developer, the security specialist, and the system and database administrator. Note that this list is certainly nonexclusive, and it is not always applicable to every organization. Therefore, we have limited the list to the most prevalent roles that will later apply to SOA projects.

4.5.5.1 The IT Project Manager

The project manager has the overall management and leadership responsibility for the project team. He or she defines and tracks project plans and determines the work breakdown structure. For an SOA project, certain additional skills and knowledge are needed to best perform this role, as described in Section 4.5.5.11, "The SOA Project Manager."

4.5.5.2 The Business Analyst

The business analyst harvests the functional requirements of business users and provides domain knowledge to the team. He or she must understand the business language and have industry- and domain-specific skills. In an SOA approach, the business analyst should use a component business modeling approach, a technique for modeling an enterprise as disjunctive components in order to identify opportunities for innovation or improvement.

4.5.5.3 The Architect

This is the technical leader of the project. The architect's task is to develop the logical and physical layout (structure) of the overall solution and its components.

4.5.5.4 The Developer

The developer creates and tests the software implementation. In SOA, the role is not significantly different, with the exception of the code written in SOA projects, which is written as services. This turns the developer into a service developer.

4.5.5.5 The Security Specialist

The security specialist is responsible for the definition of security guidelines (policies) and the implementation of security means adhering to these guidelines. The domain for this role is described in Chapter 8, "Securing the SOA Environment."

4.5.5.6 The System and Database Administrator

This role performs the installation and provides ongoing maintenance on the technical infrastructure: the hardware, operating and database systems, and middleware. Certain aspects of information integration under SOA were described in Chapter 3, "Architecture Elements." This role typically falls into the domain of the classic database administrator.

4.5.5.7 The Service Deployer

The service deployer takes the development artifacts 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, and provides JAX-RPC (Java API for XML-based remote procedure calls) mapping and handler configuration through services-specific deployment descriptors.

4.5.5.8 The Service Integration Tester

The service integration tester is responsible for the various standard test stages such as integration, load, and acceptance tests. He or she also defines test cases for services interoperability and conformance tests. This role is aligned to the architect and to the governance bodies, as previously described. It is the quality assurance role.

4.5.5.9 The Toolsmith

The role of toolsmith is responsible for designing and implementing the project-specific scripts, generators, and other utilities needed by various aspects of the SOA. The degree of standardization in the Web services world now makes it possible, for example, to develop custom WSDL-, JAX-RPC-, or JSR-109-aware tools.

4.5.5.10 The Knowledge Transfer Facilitator

This role provides access to subject matter experts and technical instructors who bring in extended knowledge regarding SOA, on-demand, and in most cases, Web services concepts and implementation assets. By relating the use cases created during requirements gathering to the functions of this role, this role can easily be taken by so-called customer-proxies that represent individual service requests within the SOA.

4.5.5.11 The SOA Project Manager

This role is an evolution of the classic project manager. The SOA project manager not only needs to plan for much shorter delivery cycles, but he or she must also establish new acceptance models. The project manager has to work with service providers to establish the appropriate service-level agreements and resource usage. This role becomes more important with increased use of aggregated services (those that are composed of other services).

4.5.5.12 The SOA System Administrator

In this role, in addition to managing and monitoring the platform infrastructure, the system administrator also manages the business and service-level agreements within the SOA.

4.5.6 A Look at New Roles

In addition to the revised roles, there are other roles involved with SOA projects: the SOA architect, the service modeler or designer, the process flow designer, the service developer, the integration specialist, the interoperability tester, the UDDI administrator, the UDDI designer, and finally, the services governor.

4.5.6.1 The SOA Architect

The architect role evolves into an SOA architect, a mediator between business and technology. More than a structural architect, as in the role of a classic software architect, the SOA architect acts more like a city planner, with a higher-level view. This person plays a dynamic business-to-IT adaptation role to transform the ideas and concepts of business operations into terms and concepts available in the IT infrastructure. In this role, the SOA architect is responsible for the end-to-end service requestor and provider design and takes care of inquiring about and stating the non-functional service requirements.

4.5.6.2 The Service Modeler or Designer

A service modeler applies data and function modeling techniques to define the service interface contracts, including the schemas for messages during an exchange. The service modeler works with the SOA architect to create these contracts.

4.5.6.3 The Process Flow Designer

In place of an integration specialist, this role investigates the explicit, declarative, service orchestration (aggregation, composition) possibilities. It concentrates on the technical process flows that support given business processes. It is an optional role in most cases.

4.5.6.4 The Service Developer

The service developer is typically an enterprise developer, expert in programming models such as J2EE and familiar with Web services concepts and XML. The role develops service interfaces and implementations on the provider side and service invocation code on the requestor side of service interactions. The service developer is probably the best-equipped role today. An SOA development environment focuses on providing tool-based support for designing and deploying service-based components.

It is the role of the SOA architect to ensure that the SOA developers are not overemphasizing the use of technology. It often becomes easy to expose any piece of logic as a service but at the cost of ignoring best practices for defining the granularity of these services, thus impacting overall performance and manageability. For example, you can easily turn a useful, simple, calculation function into a service so that it can be called from numerous other services.

A service developer using WS-* and J2EE standards-based tooling might also have some subroles:

  • Web Services designer and programmer, with implementation skills in J2EE, C++, or .NET
  • Legacy integration and adaptation designer, with services-enabled adaptation skills

4.5.6.5 The Integration Specialist

Integration specialists are mediators and users of both the service modeler's and the process flow designer's work. They typically have a broad-based technical knowledge in the integration field because they will need some understanding of SOA systems, enterprise integration means, business processes, and applications coded in Java or other languages. Tools like WebSphere Business Integration Workbench™ allow the person in this role to compose complex systems of available services.

4.5.6.6 The Interoperability Tester

The interoperability tester verifies that any developed requestor and provider implementations will interoperate seamlessly. Another primary activity is to ensure Web Services Interoperability (WS-I) conformance and industry standard conformance.

4.5.6.7 The UDDI Administrator

The UDDI administrator defines how a generic UDDI data model can be customized and populated with services. This is, in most cases, an optional role. It also depends on whether UDDI is chosen as the standard or there is an alternate proprietary data model in the organization. In this case, there might be another similar role, often part of the IT governance body, that acts as administrator.

4.5.6.8 The UDDI Designer

There might be the need for a UDDI designer who is responsible for planning, designing, and building the UDDI registry where services are published and announced for the various levels of the SOA.

4.5.6.9 The Services Governor

This is an important new role that has the cross-enterprise responsibility, on the SOA governance team, to validate and select the business services most appropriate for the given enterprise and then identify who owns them. This role can be played by either SOA architects or business analysts when working in the SOA governance team.

4.5.7 Integrating Existing and New Roles

These new roles originate from existing ones (for example, SOA architect and service developer). However, we believe that for the new roles, the introduction of new names for these roles is justified. Each of the roles addresses a different aspect of the project as a whole. Earlier we stated that one person typically wears several hats, in other words acts in more than one role. However, a project's 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 individuals 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 or simple answer to the roles-to-people mapping challenge. There are many different opinions and controversies regarding how it should be approached. As previously mentioned, the assignment of individuals to these various roles depends on the situation, the skills and experiences available, and the scope of the project.

Rather than entering a debate about what is the optimal formation, consider the following scenario: A fictitious company in the insurance industry has decided to build a new set of mid-office business applications for risk and policy management, and the set has to interface with two different backend systems. Both backend systems have been built as J2EE applications: one uses EJBs and the other uses only servlets, JSPs, and JDBC to connect to its customer and contract databases.

During the initial stages of the development project, the roles defined in the example are assigned to team members. In addition to the Web services-specific activities, the standard project tasks and roles are also identified and assigned. To illustrate how a team setup can look, Table 4.1 shows an example of selected new roles, their tasks, prerequisite skills, and supporting tools. Additionally, we list the other roles on the team that collaborate with each selected role.

Because the definition of roles depends on the concrete project situation, assignments to the actual people cannot be prescribed in a standardized way; they have to be defined and assigned per the needs of the situation. Assignments can be used by the project manager in cooperation with the SOA architect to create the work breakdown for the project at hand. Further corporate guidelines, restrictions, and best practices are influencing the final project setup and management.

In addition to the previously mentioned roles at the SOA level, there is a complementary list of roles specific to Web services in the developerWorks article, "Web Services project roles," by Olaf Zimmermann and Frank Mueller (2004).

Icon

A.4.3

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020