IT Directions

This is the tenth in a blog series on the Future of Programming.  Last time I presented a diagram of a "collaborative process pattern", and claimed that this pattern is enough to bring large software projects under safe management control, by structuring the way you handle the continual revision to the development process that inevitably arises when different people are responsible for different aspects of the design.  Please refer back to the last post for the diagram itself.  This time I will start to explain how the diagram can help you.

To understand the pattern fully, it is necessary to interpret the diagram from three different perspectives:

1. Management
2. Participant
3. Solution

Let's start with the management perspective. This is based on the Human Interaction Management (HIM) principle known as separation of control.  Part of this concept is to divide management responsibilities into executive control (setting goals and responsibilities) and management control (monitoring and supporting the work itself).  Executive control comes from above - management control comes from within.  We also need the HIM concept of REACT, an acronym describing the breakdown of any work activity into 5 stages:

1. Research - find out what you need about the domain;
2. Evaluate - apply this information to the work in hand;
3. Analyze - decide from the options available;
4. Constrain - plan the work;
5. Task - do the work.

There is a lot more to separation of control and REACT than suggested here, but that will do for now.  Applying these ideas to the diagram:

• At the overall level, the Overall Sponsor is the Sponsor Role embodying executive control, while the Domain Sponsor and Overall Design Authority together embody management control. The Overall Design Authority has the Research, Evaluate and Analyze activities, while the Domain Sponsor has the Constrain activity. The Task work is not shown as a single activity, but split between Domain Sponsor and Overall Design Authority, and consists of work assignment and work validation respectively.
• At the domain level, the Domain Sponsor is the Sponsor Role embodying executive control, while the Domain Manager and Domain Design Authority together embody management control. The Domain Design Authority has the Research, Evaluate and Analyze activities, while the Domain Manager has the Constrain activity. As above, the Task work is not shown as a single activity. In this case it is split between all three Roles Domain Manager, Designer and Domain Design Authority, and consists of work assignment, design work itself, and validation of that design work respectively.

As the process unfolds, the Role Activity Diagram will be refined to include sub-components of each high-level activity depicted at the initial stage.  This can be done without contravening the controls established at the start - the pattern is fractal, i.e., it can be applied at a more and more detailed level without change to its structure.

The second way to interpret the diagram is from a participant's perspective. There are three Roles at the overall design level, and another three at the level of each specific design domain or discipline (database design, user interface design, security engineering, and so on). There is a degree of correspondence between these levels that indicates that the model is natural:

Overall design level:

1. Overall Sponsor: Acknowledges that the problem is real and kicks off the solution process
2. Domain Sponsor: At the request of the Overall Sponsor, initiates work in each of the design domains, coordinates the separate streams of work, and reports on progress
3. Overall Design Authority: Responsible for the integrity and quality of the whole design (this Role gives permission for the integration of the specific solution)

Domain design level:

1. Domain Manager: At the request of the Domain Sponsor, assigns expert resource to the problem as it applies to a specific domain, then facilitates and supports this work
2. Designer: Participates in the collaborative activity to develop a domain-specific component of the solution
3. Domain Design Authority: Responsible for the domain-specific aspects of the integrity and quality of the design (this Role gives permission for the domain-specific components of the solution to be released for integration into the overall design)

Different Roles, such as 1 and 3 at each level, may well be performed by the same person. However, since Role Activity Diagrams do not include Users, this is not shown explicitly. What we gain from the Role Activity Diagram with respect to process participants is an overall context for each person's work. This is done in a simple and effective way by the Role Activity Diagram, from which it is immediately obvious how each person's work relates to that of the others, who communicates with whom, and who is dependent on whom.

For instance, it is clear that a domain solution cannot be submitted until each component of that solution has not only been prepared, but has also been "Declared Complete" by the corresponding Domain Design Authority. Further, it is not even possible to submit a domain solution component that has not been approved. Submission can only be done in tandem with the Domain Design Authority, as part of a single interaction that also involves approval - a review meeting, perhaps.

TAKE AWAY

Complex problems - such as large-scale software development - do not have to have complex solutions.  The way forward is to apply abstraction: remove distracting detail, and generalize the situation, so as to arrive at clear and simple patterns underpinning all such situations.

The pattern shown in the Role Activity Diagram is such an abstraction.  In HIM terms, it is a collaborative transaction.

Next time I will explain the third and final way to read the Role Activity Diagram - from a solution perspective - and show how to get started with applying these principles in order to safely manage the development of your own software solutions.  No matter how large and complex your development process appears to be, there is always a simple way to manage it safely.  You just need to look at things from the right angle.