Tuesday, November 26, 2013

SOA Governance Projects and Organizational Roles

In large organizations building and maintaining services is not a one man job, instead it is a process that touches many people in the organization. Figure 1 is a copy of figure 5.6 on page 95 of the 'SOA Governance' book by Thomas Erl et al.

Figure 1. Common associations of organizational roles with different SOA project stages.

With this many people and roles involved, how to you manage a project like this? Especially since in a large organization you will have many of these project running simultaneously. We would have loved to implement a full project workflow based on the figure 1 process, but two things are currently standing in our way: time and real world input. Who is going to pick up the challenge?

To get you started we created a 'Simplied Project Lifecycle Workflow' demo that implements just 3 boxes; Requirements gathering, Service Design and Service Implementation, with one role responsible for each stage, which are a Business Analyst, SOA Architect and SOA Developer. Each role can be fulfilled by more then one person. In the demo we assigned all three roles to the 'admin' user so we don't have to log in and out as different users all time. The demo uses the workflow shown in Figure 2. Each column represents one of the phases. The first phase being Business Analysis. The hope is this demo provides you with the building blocks to create the real world implementation we talked about earlier.

Figure 2. Simplified Project Lifecycle Workflow.

Some benefits of using this workflow are:
  • Helps your organization with adoption of SOA by following proven processes. It is clear who is responsible for approval.
  • Provides insight in where your projects are.
  • Helps your organization work together in different teams.
  • Audit features allow full history tracking.
  • Released artifacts are in the repository, the artifact is automatically in escrow this way, and documentation and sources are stored along side the binaries all in one place.
Some optional benefits:
  • It is possible to send a BPMN event at the end of the workflow (or from anywhere else), which can kick off a release workflow to automate deployment. Though one could also write a governance query looking for a service implementation artifact with classification #ImplPass.
  • Easy integration with other systems (think bug track systems, or time management systems)

If you want to follow along with the demo you should

1. Have DTGov running; see http://jboss-overlord.blogspot.com/2013/11/bleeding-edge-governance-getting-started.html.

2. Install the Eclipse BPMN2 Modeler into your Eclipse IDE, or you can try the early access JBoss Developer Studio.

Enjoy

No comments: