« Taking the chaos out of concurrent development | Main | Whatever happened to software engineering? »

This is the eleventh in a blog series on the Future of Programming. Last time I started to explain the diagram of a "collaborative process pattern" that helps 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 previous articles in this series for details. This time I will finish discussing (for now) how the diagram can help you to manage large software developments, by explaining the third and final perspective from which to understand it - the solution point of view - and how to put the diagram into practice as a means of managing ongoing operations.

From a solution perspective, the Role Activity Diagram is divided into two collaborative transactions - one at overall design level, and one at domain design level. Each transaction is bounded above and below by a 3-way interaction. In each case, the interaction at the top represents an exchange of requirements while the interaction below represents an exchange of solutions.

Both the requirements exchanged in the top interaction and the solutions exchanged in the bottom interaction will involve complex, compound objects. A solution interaction, for example, may pass across:

• The final problem statement, now fully developed
• The objects that form the solution, contributed by different Roles
• The models and tests that justify the solution
• A map of the dependencies between all these objects (for use in tracking the impact of changes) and a related approval chart, showing who has approved what. (Both these can be maintained automatically. Whenever a participating Role submits a new version of one of their deliverables, all the approvals that are dependent on the new deliverable are removed and new approval activities are triggered. Processes and object relationships interact - as long as they are both represented.)

In between the upper and lower interactions, each participating Role will carry out various different activities, in order to provide its own part of the solution. The Role Activity Diagram shown here is simplified and omits these activities, as well as the phases into which the activities will be broken during the sub-project. Why?

All we need at this stage is to represent a consensus from the initial meeting on how to proceed with the sub-project. We are not seeking to prescribe exactly what everyone will do to meet the requirements placed on them - just to establish a common ground on how the issue as a whole will be dealt with. What we are interested in initially is to make it clear to all parties what their responsibilities are to the process as a whole. We need to show only who is to do what, how they will deliver their outputs, and what impact each person's work has on the rest of the process.  The diagram effectively models not only the work required, but also the executive and management controls required over the sub-project.

Once the work gets going, it is inevitable that changes will occur to the process shown in the Role Activity Diagram. In particular, the activities in the sub-project will be extended, and broken into distinct phases, and during the course of the sub-project the elements of the diagram will be extended further as required. The project participants will make agreement depictions at overview or detailed levels that not only refine the process, but also allow all concerned to share the consensus reached about next steps.  In particular, the deliverables may change - perhaps certain ones will be altered to include only partial functionality, and the deficit remedied by other means (or just agreed with the customer as a concession against requirements).

It is here that day-to-day management control can be applied, in order to ensure that the process as it unfolds in operation takes place safely, in accordance with any applicable regulations, and with all parties committed to the same manner of proceeding.

Moreover, it will be possible to do this at either level without contravening the executive control applied from above, since it is clear from the diagram how this control is applied - via the application of the REACT pattern. Should the process participants at any time decide that this application was inappropriate, this change can be described in a simple way via a new Role Activity Diagram, and submitted to the appropriate Role for approval.  For instance, suppose that in a particular domain - safety engineering, say - that the Domain Design Authority feels it sensible to share some of his or her Research activity with the Designers of their part of the solution. After discussion with the Domain Sponsor and Designer(s) in question, the Role Activity Diagram can be altered to show the proposed process change, and sent to the Domain Sponsor for official approval.

There is a lot more one can say about such changes, but for now all we need to do is note that the diagram provides a simple means of achieving shared understanding on a new way forward, and of ensuring that this way forward is safely managed.

TAKE AWAY

Perhaps the primary concern for anyone charged with a large-scale software development should be management of faults, issues and other things that in some way force change to the current plan.  It is a law of nature that such changes happen during software development.  With small-scale software development, agile techniques suffice.  With large-scale software development, my experience, both first- and second-hand, is that they don't.  Having separate teams and/or sub-projects operating concurrently changes the situation fundamentally, and you need something more - something industrial strength - in order to cope.

In the last few articles in this series I have outlined a technique that can help with large-scale software development.  In the next - and concluding - article in this series, I will offer some observations on general emerging trends in enterprise software development.  In particular, I will discuss how the adoption of new BPM/SOA tools is bringing with it some extremely dangerous practices.  To find out what they are, and how to avoid them, tune in next time.

Posted by keithhb in Business Process Management • Management • Service-Orientated Architecture |Digg This|Add to del.icio.us