SOA for Project Managers
The idea of handling exceptions manually unveils major significance of individuals involved in Service Oriented Architecture based projects as well as various roles they take on. Service Oriented Architecture projects tends to involve a number of familiar project roles, including project management, Business analysis, architecture, development, security, and administration of systems and databases. At the same time, such roles were generally created for different purposes.
A lot of these roles might have different meanings, depending on the views of the Business in question. In order to structure a Service Oriented Architecture project in the correct fashion, it is vital to take into consideration that such roles might be required to evolve in order to match the decomposition and componentization of the applications into services. Moreover, the implementation of a Service Oriented Architecture very well may call for some additional roles to be played. In this article, we will explore the functions of different roles related to Service Oriented Architecture project management.
Roles and their Functions
There is no universal definition for Service Oriented Architecture projections or Information Technology based positions. A lot of positions entail special certification, cognitive tests, or a defined knowledge-base. At the same time, such certifications may not always be able to definitively prove the applied knowledge of a candidate, let alone his or her creativity aspects and skill transference.
Owing to the size of a team, the following factors may differ tremendously depending on the nature of the Information Technology side of the Business: team size, types of work, work load, and subjects in need of solving. As a means of coordinating such factors, project managers must demonstrate the capabilities outlined above beyond mere subject awareness.
Roles are relegated to particular phases of projects and provide definition to an abstract layer that is kept separate from actual job descriptions and assigned human resources. Most of the members of a project team will take on one or even several different roles.
You should start by first identifying the roles that are involved in your particular project – then find the individuals with the right skills to fill them. Services tend to be rather simple and lightweight. This is part of their intrinsic power. With such technological advancement, a lot of systems can be opened up quite readily for collaborative efforts. Along with such new possibilities, however, come a lot of new errors. Service Oriented Architecture projects might very well be a new type of project, but they will probably not be a simpler type of project.
Service Oriented Architecture project teams should be reflective of the specific issues highlighted above and include individuals with the right talents and skill levels. It is highly recommendable to employ a vast array of practitioners whose experience runs in many different platforms, domains of skill, and technical problems.
This is perhaps most vital for the Service Oriented Architecture architect in particular. If the individual is not available to the team, then it would be advisable to have additional part time architects on staff to fill the gaps.
SOA Project Phases
Development projects tend to have a multitude of phases that require different collaborations and skills throughout the life cycle of the project. Service Oriented Architecture projects are no different than development projects in this sense. No matter what choice your Business makes in terms of methodology, the vast majority of projects will include the following phases of development:
- Engineering requirements
- Business domain analysis
- Outline of solution architecture
- Design at high and low levels
- Design and analysis
- Test phases
- Going live
- Maintenance
- Management
Such aspects as service modeling, the choice of SOAP engine, and the organization of interoperability tests serve as the main examples of considerations that are specific to web services. The exact nature of such issues tends to vary. Service modeling, for instance, necessitates different mindsets and skills than the test of interoperability.
The Examination and Adaptation of Roles
Owing to the fact that Service Oriented Architecture projects are just another variance on the old development project model, it should come as no surprise to hear that a lot of well known roles can be defined in a category of existing roles. Some existing roles, however, receive additional Service Oriented Architecture related responsibilities. From the standpoint of Service Oriented Architecture, it is thus necessary to establish new roles. First, however, we should take a look at existing roles.
-The Information Technology Project Manager
The project manager has the overall leadership and management responsibility for the project team. He or she will be responsible for defining and tracking the plans of the project, while simultaneously determining what the work breakdown structure shall be. For a Service Oriented Architecture project, special skills and knowledge will be required in order to perform such a role.
-The Business Analyst
The Business analyst is responsible for harvesting the functional requirements of Business users while providing the team with the appropriate domain knowledge. The Business Analyst has to understand the Business language and have skills relating to the specific domain and industry. When it comes to Service Oriented Architecture, the Business analyst must employ a component Business modeling approach. This technique is utilized to model an enterprise as disjunctive components as a means of identifying opportunities for improvement and innovation.
-The Architect
The architect is responsible for leading the technical side of the project. His or her job will be to develop the physical and logical structure of the overall solution as well as its various components.
-The Developer
The developer is responsible for the creation and testing of software implementation. In Service Oriented Architecture, the role does not differ tremendously, the only difference being the code that is written in Service Oriented Architecture projects, which is composed as services. Thus, the developer effectively becomes a service developer.
-The Security Specialist
This individual is in charge of defining security policies as well as implementing security means in accordance with those policies.
-The System & Database Administrator
This individual deals with the performance of the installation while providing continuous maintenance on the technical side of the infrastructure. This includes hardware, middleware, as well as database and operating systems. Such a role typically falls under the domain of the classic database administrator.
-The Service Deployer
The service deployer deals with the development artifacts, which he or she then installs in the target run time environment, effectively generating stubs and skeletons for the target environment from WSDL and then installing them alongside the service implementations.
-The Service Integration Tester
The service integration tester takes care of the numerous standard test stages like load, integration, and acceptance examinations. The service integration tester also takes care of defining test cases for the interoperability of services as well as conformance tests. Such a role is generally aligned to the architect as well as to the governance bodies, as has been described previously. The service integration tester is essentially the quality assurance role.
-The Toolsmith
This individual is responsible for the design and implementation of scripts, generators, and other utilities that are specific to the project and needed by various components of the Service Oriented Architecture. The degree of web service standardization makes it possible for such tools as WSDL, JSR 109, and JAX RPC to be developed according to custom.
-The Knowledge Transfer Facilitator
This individual is meant to provide access to subject matter experts as well as technical instructors who will bring in more knowledge about Service Oriented Architecture, as well as web service concepts and assets of implementation. By relating the use cases that have been created during the requirements gathering process to this job’s functions, the Knowledge Transfer Facilitator can readily be taken up by so called customer proxies representative of individual service requests within the Service Oriented Architecture.
-The Service Oriented Architecture Project Manager
The Service Oriented Architecture Project Manager plays a very similar role to the traditional project manager. This individual need not only plan for shorter delivery cycles, but also has to establish new models of acceptance. The project manager works with service providers to establish appropriate service level agreements as well as correct resource usage. This job becomes a lot more important once aggregated services begin to be employed.
-The Service Oriented Architecture System Administrator
This individual manages the service level and Business agreements within the Service Oriented Architecture, in addition to taking care of the platform infrastructure.
New Roles
The following roles should also be added to ensure that a Service Oriented Architecture runs smoothly:
- The Service Oriented Architecture Architect
- The Service Model or Designer
- The Process Flow Designer
- The Service Developer
- The Integration Specialist
- The Interoperability Tester
- The UDDI Administrator
- The UDDI Designer
- The Services Governor