Model- and simulation-based software delivery
August 15, 2020 1454 words 7 minutes to read Last Updated: April 3, 2022
“Organized chaos” may be the best way to describe the software delivery process for many organizations (Cubranic and Murphy, 2001). The complexity and chaos involved in delivery are too much for any one person to handle, with pieces of the “process” scattered across minds, teams, and organizational units. Yet, this process is not even remarkably coherent or consistent. Instead, three processes arise from aggregating all the data:
- The documented process;
- The understood process;
- The actual process.
In most cases, the three do not align. Instead, each gives a distinct perspective on the socio-technical software delivery systems.
The actual value is created from improvements to the actual process, but the improvements will be unsustainable without associated improvements to the documented and understood processes.
Do you practice Continuous Improvement?
Continuous Improvement has spilled over from the manufacturing industry into the domain of software development organizations. This recursive process is designed to capture areas of improvement and provide the support and framework to implement them on a rolling basis.
“We define CI … as a culture of sustained improvement targeting the elimination of waste in all systems and processes of an organization. It involves everyone working together to make improvements without necessarily making huge capital investments. CI can occur through evolutionary improvement, in which case improvements are incremental, or through radical changes that take place as a result of an innovative idea or new technology.”
—Bhuiyan and Baghel (2005, p. 761)
Yet, Continuous Improvement initiatives executed within a context of “organized chaos” are bound to address only a tiny portion of the problem domain and are unlikely to address the real bottlenecks in the software delivery systems.
Why the Theory of Constraints should be integral to Continuous Improvement
Unfortunately, the Theory of Constraints has not spilled over from manufacturing to software development communities. As per LeanProduction, “The Theory of Constraints is a methodology for identifying the most important limiting factor (i.e., constraint) that stands in the way of achieving a goal and then systematically improving that constraint until it is no longer the limiting factor.”
If the Theory of Constraints was in action, we would realize the lack of meaning of many software development initiatives labeled Continuous Improvement projects. A holistic perspective on an organization’s software delivery systems has no substitute, yet acquiring that holistic perspective remains elusive for even the most dedicated executives, observant managers, and ambitious engineers.
Taking a model-based approach
A model-based approach to software delivery provides a foundation, a start, to a holistic conceptualization of the software development organization. Models are flexible – with methodologies, formalisms, and morphisms that can describe an endless variety of socio-technical phenomena. Yet, models retain a robust scientific and quantitative underpinning. Your team is likely already using models – some successfully, some less successfully – across your organization.
Teams can construct models at multiple levels to address perspectives and needs ranging from the operational to the tactical and finally to the strategic. What are some tangible benefits from taking a model-based perspective to software delivery activities?
- Expanded capture of process information,
- Reduced “tribal knowledge” and fragmentation of key information,
- Effective input of information and output of insights,
- Reduced human and technical errors,
- Reduced ambiguity and deltas between the documented, understood, and actual processes
- Improved communications, collaborations, and onboarding,
- Earlier (+cheaper) recognition of “pivot” and adaptation opportunities, costs, and risks,
- More uncomplicated change management initiatives (agility),
- Elimination of biases and subjectivity.
Model-based approaches are at the intersection of a few powerful and popular inclinations. The trends include data-driven decision making, cross-disciplinary thinking, the “shift left” push towards activities early in the software delivery lifecycle, and the real-time, “continuous” flow of ideas, commits, artifacts, and assets.
An example of the “model-based perspective” was described by López, et al., (2015) for Open Source Software (OSS). Every organization defines its own OSS adoption goals and identifies the actions involved to achieve these goals. i* is a goal and agent-oriented framework suggesting approaches to represent, model, and develop rationales about socio-technical systems (Yu, 1995). It can provide a means to represent the needs and expectations of OSS adopters and characterize OSS adoption strategies.
The strategies range across a broad spectrum of actions (López, et al., 2015, p. 3-4):
- OSS Acquisition: using existing OSS code without contributing to the underlying OSS project/community.
- OSS Integration: actively participating in an organization in an OSS community with the purpose to share and co-create OSS.
- OSS Initiative: initiating an OSS project to establish a community around it.
- OSS Takeover: taking over an existing OSS project/community and controlling it.
- OSS Fork: creating an independent version of the software that is available from an existing OSS project or community.
- OSS Release: releasing bespoke software as OSS, without regard to whether an OSS community takes it up or forms around it.
The i* language encompasses a suite of constructs used to model these strategies. One of the six potential examples for modeling a particular OSS strategy would look like Figure 1.
Combining models with time-based simulation
While a model-based approach to software delivery provides substantial value in its own right, the icing on the cake and a key value driver is the ability to exercise those models within a simulation. We can again look to the manufacturing industry for inspiration, where simulation has been used since the 1950s to predict and improve processes and bottlenecks through the manufacturing lifecycle. A simulation adds business value through its “low cost, quick analysis, low risk and meaningful insight that it may provide, improving thus the understanding of the influence of each component” (Mourtzis, 2020, p. 1927).
Accounting for time via simulation allows the team to capture the dynamics, complexity, and nuances that underpin enterprise software delivery processes. This way, rapid experimentation can be executed using models before real-life experiments are implemented in the organization. Real-time simulations can provide insight into emerging bottlenecks, high-risk subsystems, and trends in performance, cost, security, or compliance.
Software delivery simulation as the next competitive advantage in software
The most significant, first wave of unicorn startups and SaaS companies are now reaching middle age. First-mover advantages have settled, and the software industry has now reached (perhaps a steady-state) of a hyper-competitive landscape. Innovation and novelty softened the blow in years gone past. Still, we are now faced with the unpleasant reality that software has a shallow barrier to entry, and competition can arise in any market – with emerging and eastern markets exhibiting aggressive trajectories.
“Software is eating the world,” yes, but getting a slice of the pie is more challenging than ever before.
Organizations should look to unique business models, tangential industries, and unconventional forms of differentiation as sources of innovation in the coming years (Chow, 2008). Industry 4.0 is upon us, and simulation is one of the nine technology trends transforming industrial production (Boston Consulting Group, 2022):
- Additive Manufacturing,
- Augmented Reality,
- Autonomous Robots,
- Big Data and Analytics,
- The Cloud,
- Cybersecurity,
- Horizontal and Vertical System Integration,
- The Industrial Internet of Things,
- Simulation.
While manufacturing is a mature industry, the parallels in modern software production are evident. Much can still be gained from the lessons already learned in (and currently transforming) manufacturing.
Next steps
Model-based software delivery has a foothold in current industry-leading practices, leaving you poised to get a foot in the door on the future of software organizations’ competitive advantage. Leverage the Software Delivery Simulator to anticipate and manage future bottlenecks and optimize delivery processes, thus saving time and money.
Part of the Digital Manufacturing & Design Technology Specialization at Coursera is the MBSE: Model-Based Systems Engineering Course. Enrollment in the course is free. A more expensive approach would be to enroll in the Object-Oriented Systems Engineering Method (OOSEM) Accelerator™ MBSE Methodology Training Course taught by the author of SysML Distilled, Lenny Delligatti of Delligatti Associates.
References:
Bhuiyan, N., & Baghel, A. (2005). An overview of continuous improvement: from the past to the present. Management Decision, 43(5), 761 – 771.
Boston Consulting Group. (2022). Manufacturing-Industry 4.0. BCG. https://www.bcg.com/capabilities/manufacturing/industry-4.0
Chow, Y. (2008). Information Technology Innovation. The Permanente Journal, 12(4), 65-69.
Cubranic, D., & Murphy, G. C. (2001). The ramp-up challenge in open-source software projects. Department of Computer Science, University of British Columbia.
López, L., Costal, D., Ayala, C. P., Franch, X., Annosi, M. C., Glott, R., & Haaland, K. (2015). Adoption of OSS components: a goal-oriented approach. Data & Knowledge Engineering, 99, 17-38.
Mourtzis, D. (2020). Simulation in the design and operation of manufacturing systems: state of the art and new trends. International Journal of Production Research, 58(7), 1927-1949.
Vorne Industries. (2021). Lean Production: The Theory of Constraints (TOC). https://www.leanproduction.com/theory-of-constraints/
Yu, E. (1995). Modelling Strategic Relationships for Process Reengineering. Doctoral Dissertation. Computer Science Department. University of Toronto.