SOA Collaboration: Separating SOA Team Roles and Responsibilities

The use of infrastructure that offloads project teams from having to build functionality for security, auditing, management, etc. into their projects provides a natural ability to separate the roles and responsibilities in your SOA. SOA collaboration implies that you can have cross-functional SOA teams responsible for each of the following areas: security, compliance, or operations. However, while taking these core SOA responsibilities out of the hands of project teams should shorten project delivery and produce a better overall resulting project, it can also introduce new barriers. The key challenge to SOA collaboration occurs when these cross-functional roles require domain-specific knowledge to complete their tasks. For example:

• A security team member might not know the appropriate authorization rules for order creation versus order cancellation.
• A compliance team member may be tasked with enforcing privacy compliance policy, but not know what schema elements of an XML document require such privacy (for example, an XML element named "socno" might be a social security number, which would require encryption in certain regulatory domains, or it could just as easily represent something innocuous like socket number).
• A deployment team member may know that rerouting across data centers should be used to assure service levels for important customers but that certain operations cannot be rerouted to avoid data replication and consistency problems.
• An operations team member might be tasked with monitoring SLA's, differentiated by customer class, but may not know how to determine in what customer class the requester falls.

One approach to addressing these challenges is to require that these cross-functional teams "loan" members to project teams in order to match appropriate skills to each project. This, however, often creates bottlenecks for project delivery – the project team needs to "wait in line" to get a person allocated to their project, and they team becomes responsible for providing the domain-specific education to the cross functional team member – increasing the risks for project delivery. An alternate approach is to clearly define key domain-specific concepts (e.g. "customer", "order", "personal identity") across the organization. This then allows:

• The cross-functional teams to focus on defining their rules abstractly, independent of any individual service, using the concepts (e.g. "all personal identities must be encrypted").
• The project teams, separately, map their unique data to the concepts (e.g. "This services' XML element <socno> is a personal identity" or "this operation can be rerouted").

By providing this separation, cross-functional teams can define their policies once, yet have them apply globally to all services. Project teams can then be freed from bottlenecks that require cross-functional team members to re-implement the policies for them.

In summary, your choice of SOA infrastructure can dramatically alter your ability to effectively separate these roles. Be cautious to determine what types of domain-specific information are critical in your environment, and evaluate how well the different options enable a clear separation of roles and responsibilities.

For More Information

Learn more about SOA collaboration – and how to divide and manage the responsibilities of SOA teams: watch the free webinar, Implementing a Successful SOA Pilot Program