Monday, October 18, 2004
The Explosion of Separated Concerns
As discussed in prior posts, I believe that MDSOC is the system development perspective of choice for moving the software industry toward our next capability plateau. However, the road is barely planned, and certainly not paved. There are a number of pitfalls that must be addressed if we are to avoid the sinkholes that lie along our path. Here, I will discuss one of the larger problems, and hint at a means to resolve it.
In a system project of any worthy level of complexity, the number of stakeholders will be high. If we divide them into 2 collections, functional and ancillary stakeholders, we can represent the concerns of our functional stakeholders through a number of well-recognized mechanisms in the realm of requirements gathering and specification. However, the needs of ancillary stakeholders are not so easily expressed. In this group, I would include such entities as project managers, financiers, regulators, and quality reviewers, just to name a few. In isolation, each of these stakeholders presents a collection of concerns that must be addressed in order to consider the project successful. Collectively, they represent a combinatorial explosion of considerations as their needs are taken into account throughout the system's development lifecycle.
Traditionally, this type of system (that is, the collection of stakeholder concerns throughout the SDLC) would be resolved through some form of multivariate analysis. While this approach is certainly valid, there are issues that are not easily addressed. First, there is no clear definition of exactly what stakeholders exist, how they are grouped, and what their concerns actually are. Second, it is certain that many of these concerns are not numerical, and that their relationships are not so easily defined. In fact, it is likely that a significant amount of judgment would be required to resolve conflicts and maximize benefit between these concerns.
There is a technique designed for just such problems. According to a paper on the subject by Tom Ritchey, this approach is:
A Generalised method for structuring and analysing complex problem fields which:
- Are inherently non-quantifiable
- Contain genuine uncertainties
- Cannot be causally modelled or simulated
- Require a judgemental approach
Our approach, then, is to first identify the stakeholders and their concerns. Utilizing Morphological Analysis, we establish (demonstrably) the most effective way to resolve all stakeholder concerns. Finally, we put the determined action plan into place, and viola! Problem solved!
Of course, an approach is a long way from a methodology. There are still many issues to deal with. One of the largest concerns we face is the need to establish the identity and concerns of stakeholders on a per-implementation basis. Is this really necessary, or can we anticipate them, reducing the per-implementation overhead? Another concern involves the question of how consistent the output approach would be with industry practices. It is one thing to find the ideal solution to a particular problem; it is another thing entirely to have to train the whole team on a new approach for each project.
If you haven't already anticipated my response to these issues, then you didn't pay particular attention to my word selection in the previous paragraph. The answer, quite simply, is to define a "Process Management" stakeholder, and express the issues above (along with others not defined here) as their concerns.
All the pieces are in place. Now, if I or others can only find the time to begin the Morphological Analysis activities applied to System Development, I am confident the result will be a significant advance in industry practices.
