October 30, 2004
Shenzhen is in China about a one hour drive from Hong Kong. It takes more time to get there though since you have to go through immigrations and customs. Yesterday I gave a one day seminar for a telecom company. Before my seminar, one of my colleagues in Ivar Jacobson Consulting had given a week of training in software architecture. Our approach to software architecture is a major improvement to the one in RUP: it is simpler, more systematic, broader and better prepared for the future (such as aspect-orientation). Thus the training was very well received.
In Shenzhen people can have fun. This time we went to a night club area. In Minneapolis we had a hard time to find any place to go to. This time there were almost too many night clubs, everywhere there were night clubs. We were four persons including my female host, and we went to the largest night club I have ever seen. It had everything and it was very civilized: big bar, show after show with performances by famous persons, disco. We had a good time watching the shows and talking. We talked about the future of software development and about life in China and in the Western world. I also discussed what will follow further down in this postcard. It was a very nice night in company of very nice friends.
- o -
I have some interesting quotes for you:
"Imagine a software development project where everything works well together -- the tools, the teams, the platforms, and the processes. You no longer have to imagine." This quote is from the marketing of the new IBM software development platform.
Also consider this one: "With Visual Studio  Team System, process is not just documentation. It also manifests itself as actual tool behavior changes. When you chose the process at project inception, you are also choosing the workflow and work products, which then drive how the system behaves."
These quotes are interesting as they show that the major vendors now are beginning to see the necessity of integrating tools and process. I also like them because I discussed these concepts 10 years ago.
- o -
Back in 1995, I wrote a series of papers about the software engineering process (SEP) and its support environment (SEPSE)*, the vision then was similar in many ways to the vision that Microsoft and IBM is talking about now. To use a bit more modern terminology, let's call it "development platform" instead of SEPSE from now on.
Such a development platform should cover of all the tools required to support a software development process. The tools should be integrated in the sense that they work together to achieve a common overall goal - to build software according to a process - and communicate with each other as necessary. And, there are many tools that must be included, e.g., tools for capturing requirements, modeling, coding, debugging, testing, change/bug tracking, version control, and what have you.
Anyway, a key feature of such a development platform that I discussed is the capability to support a process, including workflow support and modeling support. Quoting: "The SEP enactment tool represents a unique feature as it coordinates the right set of collaborating modeling tools and artifacts for any given task, i.e., it drives the integrated environment for the user."
Now, ten years later, and with ten more years of experience my thinking has matured. Today I am not talking about a "SEP enactment tool" today I talk about Active Process.
There is a huge difference here and I believe that eventually Microsoft and IBM will realize this too and that they need to move beyond what they currently are promoting as process features in their (upcoming) software development platforms.
The difference is that a process enactment tool only provides guidance on the macro level in that it will control which activities that can be carried out by a certain person (given her assigned roles), when the activities can be carried out, e.g., checking that required input models and documents are available and so on. This kind of control is typically based on that users enter meta-data into the system that describes the state of models. An example of such meta-data is the level of stability; a model could be classified as preliminary, ready for review, or approved. This will however, not help you with the real work such as specifying clear requirements, creating good models, writing good code and so.
An Active Process covers all of this but goes beyond it in three major ways. An active process should:
Provide advice that is specific to the system under construction as opposed to just feeding generic descriptions and help texts. This means that the active process must have access to and be able to reason about the content of deliverables and intermediate results of the software development process, not only meta-data entered by users.
Provide advice just-in-time when needed and in an unobtrusive fashion. The developer should never be stopped or hindered by the active process. The choice should be with the individual at all times.
Be self-configuring to become as agile as possible, but no more agile than that. I.e., it should be self-configuring based on the characteristics of the organization (distributed, outsourcing, etc.) and characteristics of the system to be developed (size, criticality, etc.).
Even if IBM and Microsoft are only starting their journey as I started it 10 years ago it is still noteworthy that these companies now are starting to see process and tool support for process as an integral part of their environments. Going forward I think we will see more of this and other vendors will need to follow suit as their offerings will be considered incomplete else wise.
As you may know, Jaczone has been developed and evolved the Active Process concept over the last five years. What we have learned is that this is quite a challenge to get right; however we have come pretty far down the road. And this challenge is what makes it fun!