This position paper presents professional (rather than social) aspects of distributed software engineering projects in an agnostic manner, as it pertains to country, methodology, and tools. Bartelt et al. state that “the three main significant forces that have pushed global software engineering as a fact of our daily work” are economic, organizational, and strategic; they emphasize establishing proper communication and coordination habits as a key challenge, leading to the need “to (re-)orchestrate the existing communication and coordination cultures of all parties participating.” The authors properly consider “the lack of explicit interfaces” to be a critical issue--maybe even the critical issue--by observing, in particular, that each communication issue and each underspecified component causes increased effort and increased costs. To get there, it is necessary to have a roadmap--the context of these interfaces; the need for such a roadmap ought to have been stressed to a much greater extent. A roadmap is obtained by modeling. To quote from a recent article [1] on (more) social aspects of the problem, modeling--that is, “collect[ing], analyz[ing], and present[ing] complex data in a form that facilitates decision making”--is essential for solving problems of coordination breakdown, and computing people have the know-how to do just that, as also asserted by Dines Bjørner.

Bartelt et al. stress the importance of abstraction, views, and patterns of views, and note that “understanding means a common vocabulary (terminology, ontology) and knowledge of the requirements related to project-relevant artifacts.” They further observe the necessity to determine the existing organizational structure. While vocabulary is clearly not the same as ontology, the need for explicit ontologies (both of the business to be automated and of the organizations cooperating in the project) is indeed critical for success. Otherwise, it is well known that different stakeholders understand tacit assumptions differently, often based on meaningful names or box-and-line diagrams, leading to communication issues and ultimately to project failures. The authors do not mention any frameworks for creating precise and explicit ontologies--also known as business models--that are understandable to all stakeholders; this is a pity. At the very least, an existing international standard such as the Reference Model of Open Distributed Processing [2] could have been mentioned as an excellent framework that provides a system of generic concepts and patterns.