After reading the paper “Transition to Model-Driven Engineering – What Is Revolutionary, What Remains the Same?” by Jorge Aranda, Daniela Damian and Arber Borici I immediately contacted the authors and asked them to summarize the main lessons learnt from their work in a guest post. I have no doubt you’ll for sure enjoy it. Enter Jorge.
When it comes to MDE, there has been far more ink (or pixels) dedicated to opinions on its purported advantages or disadvantages than to reports of practical experiences of real-life organizations that have started to use it.
A few months ago, my colleagues (Arber Borici and Daniela Damian) and I presented a paper to try to buck that trend. In the paper, we reported on a case study about the attempts of a large organization (General Motors) to transition to model-driven engineering for its software development efforts. The case study is based on a visit to General Motors, where I interviewed people in several different roles involved with software development in one way or another, and on observations of their software development process. (Details on the study’s methodology can be found on the paper itself.)
Four findings in particular stood out. The first has to do with the question of whether MDE actually helps bring software development closer to domain experts—after all, that is one of the advantages it is supposed to have, the ability to shed the complexity of software development so that domain experts can “code” their models themselves. We found that MDE indeed brings software development closer to domain experts. For example, some control engineers were able to delve straight into their models to specify the behaviour they intended their software to have. However, software engineers were still necessary to perform a “middle-men” role for many tasks, mostly having to do with organizational and process-based tasks needed to move along their projects, and with more arcane issues in software development that modelling tools were not equipped to resolve.
The second finding may perhaps be a letdown for MDE enthusiasts. We found that MDE in practice leaves the essential challenges of software development unchanged. It may bring some incremental improvements in productivity, but nothing more. Software development is difficult because it is hard to resolve stakeholder conflicts, to communicate effectively, and to transform a real-world problem into a computer-based representation, whatever the representation’s language may be. MDE does not change these essential difficulties—in fact the software development process at GM remained largely indistinguishable from the one it had before the transition.
The third finding is somewhat of a cautionary tale. While MDE does nothing to address the essential problems of software development, in some cases it may even bring about additional problems that weren’t there before. For some groups within GM, switching to MDE disrupted the organizational structure and altered its balance, creating morale and power problems. Small teams that were previously working effectively saw their dynamics upended: where before MDE one engineer (the control engineer) worked on the “physics” of a problem and another engineer (the software engineer) worked on its implementation, after MDE the control engineer did most of the technical work and the software engineer was stuck with testing, dealing with change review boards, herding work items, and ensuring that the resulting models adhered to the standards of the organization. The first engineer did the cool stuff, the second saw her job transformed into a clerical position. The resentment and morale problems were still a significant issue at the time of my visit, months after the switch to MDE took place.
Finally, we also found that the pioneering state of many MDE efforts mean that the cultural and institutional infrastructure to support MDE is not fully developed yet. Students do not come out of university knowing MDE, tool support still lags significantly in comparison to the capabilities of traditional software development tools, basic problems are still being uncovered and addressed, and so on. Transitioning organizations may find that the advantages of MDE outweigh these infrastructural frictions, but they should expect those frictions to be there when they make the switch anyway.
Of course, readers should consider that this case study arose from limited observations in a single organization—your mileage may vary, and I’d be interested in hearing your experiences. For those considering a transition to MDE, though, I would say that (a) it is a viable proposition, at least in some domains, but (b) it is still a proposition that is organizationally and technically painful.