As I write this, I am the General Chair for ICSSP 2019—the 2019 International Conference on Software and Systems Process–which will be co-located with ICSE in Montreal in May, 2019. I am privileged to hold this position and excited to be serving in this role. I am writing here, though, in a strictly personal capacity. I want to try to explain why I was attracted to the topic of process at the start of my career in software engineering and why I have returned to it many times since.

To start, I believe that software engineering is the most interesting area in computer science. There are few things that you can do with, through, or to software that do not reflect, entail, or imply something for some aspect of software engineering.

Beyond that, I believe that process is the most interesting area within software engineering. There are few things that you can do with, through, or to software that do not reflect, entail, or imply something for some aspect of process.

A similar richness of concerns applies to systems engineering and systems engineering processes. Software is part of systems; the development of software and systems are frequently conjoined; and software and systems engineering share similar driving and constraining concerns—function, cost, schedule, quality, safety, and more. And both software and systems pervade our lives today.

But that’s only the beginning of what makes software and systems processes so interesting. In the context of ICSSP, software and systems processes are the domains of interest for research. But the concepts, tools, and practices that we bring to this research are derived from software and systems engineering. In this way a virtuous cycle is established between the domains of study and the methods of study: software and systems engineering drive advances in process engineering, while advances to process engineering drive advances to software and systems engineering. They progress together.

I think of the above as the inward-looking perspective on software and systems processes. We can also adopt an outward-looking perspective. In other words, we can apply the concepts, tools, and methods of software and systems engineering to the study of processes in other domains. And process is important in other domains. With a quick internet search, I was able to find process-related maturity models for enterprises; business; system administration and IT governance; contract management; legal operations; corporate governance; data governance; hospital governance, risk management, and compliance; and pharmaceutical clinical trial design. I do not mean to suggest that maturity models are the end goal of process research, but collectively they reflect the diversity of fields in which process is significant. If law, business, and healthcare as such are not within the scope of software and systems engineering, the application of software and systems engineering to processes in those domains should nevertheless be fruitful.

But we don’t need to stop there. We can zoom out acquire an overview that encompasses the inward and outward looking perspectives. I see this overview as a multidimensional concern space [2]. For example, at a very high level, two fundamental dimensions of concern for an engineering discipline are the problem domain and the solution domain. The inward-looking perspective described above reflects the application of software and systems engineering solutions to software and systems process problems. The outward-looking perspective fixes the solution domain at software and systems engineering but translates the problem domain to processes in other fields.

At the center of my personal process concern space is Lee Osterweil’s idea of software process programming—at its core, a programming-centered approach to supporting software processes [1]. The idea of programming suggests a number of dimensions (even subspaces) within this concern space—languages, artifacts, tools and environments, processes and methods—all for the programming of processes. A concern such as process programming languages suggests a further subspace of concerns analogous to (if not identical with) those for conventional programming languages: syntax, semantics, computational paradigm, language features, level of abstraction, and so on. (These sorts of elaborations were recognized by Osterweil in his original conception of process programming and were widely discussed decades ago.)

Today we can see translations of process engineering along many dimensions of concern. Process representations can be found in the forms of programs and models, structured and semi-structured languages, textual and graphical languages, and restricted and unrestricted natural language. For each of these there is a space of diverse languages. Automated analytic techniques are available now not just for formal languages but for natural languages. The agents that execute the processes may be conventional programs or automated agents; manifestations of artificial intelligence; human beings working individually or collectively; teams or crowds; and organizations and enterprises. The runtime systems that support the execution of processes may include conventional middleware; specialized computational infrastructures; dedicated organizational roles, departments, and services; collaborative communities; professional societies; and governments. The locus of execution can range from a single minute device to globe-spanning networks.

The prospect and pursuit of such translations are what draw me to software and systems process engineering. For me, the discovery, elaboration, exploration, and occupation of a rich and expanding concern space is ultimately what makes process the most interesting topic in software engineering.

References

[1] L. Osterweil. 1987. Software processes are software too. In Proceedings of the 9th international conference on Software Engineering (ICSE ’87). IEEE Computer Society Press, Los Alamitos, CA, USA, 2-13.

[2] Peri Tarr, Harold Ossher, William Harrison, and Stanley M. Sutton, Jr.. 1999. N degrees of separation: multi-dimensional separation of concerns. In Proceedings of the 21st international conference on Software engineering (ICSE ’99). ACM, New York, NY, USA, 107-119. DOI=http://dx.doi.org/10.1145/302405.302457