Our company’s name refers to our function — BlockScience is who we are, because “block science” is what we do. At its core, “block science” is a method for solving complex problems by breaking them down into smaller “blocks,” analyzing these blocks (and the relationships between them), and then using the insights that we have acquired and the understanding that we have developed in order to recombine the blocks in a way that has been carefully engineered to safely and sustainably solve the original problem.
In other words, “block science” is a pithy way of describing systems engineering. BlockScience practices a version of systems engineering specialized for complex multi-stakeholder ecosystems — one that seeks to optimize outcomes for all involved, instead of maximizing one stakeholder’s ability to benefit at the expense of other stakeholders. Our animating purpose is to update the best practices of traditional systems engineering — its tools for analyzing complex phenomena, its holistic view of how projects take shape, its rigorous verification and validation procedures, and more — in ways that both account for and incorporate emerging technologies and expanded possibilities that define our ever-changing world.
Traditional systems engineering identifies three primary categories of actors within every project: the project’s stakeholders (those who are invested in the successful completion of the project), its managers (those who are responsible for coordinating the success of the project as a unified system), and its engineers (those who are responsible for deploying subject-area expertise in order to design and implement the component elements of the project’s unified vision). The job of a systems engineer is to clarify and document the goals and constraints that will guide the actions of these actors throughout the life of the project, and to resolve the conflicts between these requirements that inevitably arise over the course of a project’s life-cycle.
At BlockScience, we define stakeholders more broadly than traditional systems engineering, expanding the category to include all who are impacted by a given project, rather than just its sponsors or funders, because we believe that our approach results in both increased accountability and superior design, operations, maintenance, and governance. We also view management not as a separate category of actor whose members control the project entirely from the top down, but as one function among the many that must be engineered according to the specific contextual needs of the project: the function of “coordination,” which can be implemented in ways that distribute power more equitably among the project’s stakeholders.
Model-Based Systems Engineering
In order to expand the subset of stakeholders with the power to meaningfully engage with a given project, BlockScience prefers to practice a form of systems engineering known as Model-Based Systems Engineering (MBSE), which involves the development and deployment of mathematical and computational models to define, simulate, monitor and analyze a project — with a particular focus on forecasting the potential consequences of the critical decisions that must be made as a project is designed, implemented, maintained and governed.
Shevchenko offers a concise explanation of Models-Based Systems Engineering in a blog hosted by the Software Engineering Institute at Carnegie Mellon University:
Model-based systems engineering (MBSE) is a formalized methodology that is used to support the requirements, design, analysis, verification, and validation associated with the development of complex systems. In contrast to document-centric engineering, MBSE puts models at the center of system design. The increased adoption of digital-modeling environments during the past few years has led to increased adoption of MBSE.
Shevchenko goes on to note that “using a digital-modeling approach, a single source of truth for the system is built in which discipline-specific views of the system are created using the same model elements.” Consequently, digital modeling “creates a common standards-based approach to documenting the system that can be programmatically validated to remove inconsistencies within the models and enforce the use of a standard by all stakeholders [… which] improves the analysis of the system and reduces the number of defects that are commonly injected in a traditional document-based approach.”
In short, Model-Based Systems Engineering employs rigorous mathematical and computational modeling techniques in order to arrive at a deeper understanding of how the interrelated parts of complex systems work, and how those parts could be re-engineered in order to work together more effectively. It also presents this understanding in a way that is both more internally consistent and externally accessible than a document-based approach, in order to empower a broader population of stakeholders. Shevchenko’s conclusion is straightforward: “When MBSE is done properly, the result is an overall reduction of development risks.” In our opinion, MBSE also results in a significant increase in opportunities for non-expert stakeholders to understand, and potentially have a meaningful say in, critical design trade-offs at every stage of a project’s engineering life-cycle. Diverse stakeholder input is vital when what is being engineered is an infrastructure or institution (which may also be viewed as socio-economic infrastructure).
How BlockScience Views the Engineering Life-Cycle
In order to understand how BlockScience can contribute to a project at each stage of its life-cycle, one must first understand our general model of the engineering life-cycle — that is, how we conceptualize the developmental stages through which every successful project progresses. Although each project’s particular path through this life-cycle will be unique, the structure of the life-cycle itself remains relatively constant; as such, it is necessary to see how the life-cycle’s stages fit together into a unified whole before one can fully grasp the patterns that guide a project through each stage (and on to the next one).
There are countless ways of representing the “engineering life-cycle” — that is, of representing the developmental stages of a project from a systems engineering perspective — but this array of models ultimately consists of a set of variations on the same essential idea: Projects develop in interdependent stages, and each of these stages comes with its own set of goals, constraints, and processes for navigating between them. At BlockScience, we view the engineering lifecycle as consisting of five stages, each of which involves multiple interrelated functions or processes:
- Ideation and Conceptualization
- Requirements and Design
- Implementation, Integration, and Testing
- Operations and Maintenance
- Governance and Evolution
As a project grows from the seed of an initial idea into the complex ecology of a developed, deployed, and durable system, the decisions made at each stage in the process — and the decision-making processes that drove these decisions — inform what takes place, and even what is possible, during the subsequent stages. The job of a systems engineer is to manage the relationships between these decisions in a manner aware of (and accountable to) the diverse stakeholders with an interest in the outcome. This includes generating detailed analyses of a project’s key decisions, which stakeholders have the ability to influence each decision (and how), and the consequences each decision will have across the entire set of that project’s stakeholders. Low-level decisions about how a component will meet its requirements and high-level decisions about what those requirements ought to be will each involve different stakeholders engaging in different processes — but it is the responsibility of a systems engineer to ensure that the processes for decision-making are designed to incorporate constructive feedback from the relevant stakeholders (that is, those who will be affected by the decision in question).
Our version of the engineering life-cycle is a zoomed-out version of traditional systems engineering’s “Verification and Validation V” which is pictured below.
The model of the engineering life-cycle that we apply at BlockScience expands on the classical “Verification and Validation V” in a number of ways:
As seen above, our “V” has both an expanded head (the Ideation and Conceptualization stage) and tail (the Operations and Maintenance stage) that are given equal weight to the descending and ascending arms of the “V” itself (the Requirements and Design and Implementation, Integration, and Testing stages, respectively). We also view the Governance and Evolution stage as being made up of iterative arcs back over and through the preceding stages — because changes to any system must be engineered as conscientiously as the system itself, in order to avoid destabilizing its functioning in unforeseen and undesirable ways.
Within large projects, each stage is at least partially (and sometimes entirely) dependent on what transpires in the stages that precede it; without milestones to manage co-dependencies, rapid uncoordinated iteration generates thrashing — and has the potential to set off a chain reaction of ever-expanding rework. By taking a holistic view of a project’s developmental trajectory, it is possible to balance “explore and exploit” dynamics — tapping into the benefits of rapid experimentation, while also reducing the risk of harm, as avoiding costly failures and rework cycles.
The above video by Brian Douglas about the benefits of Model-based Systems Engineering clearly shows how parallelism and agility can (and often must) co-exist within a staged development lifecycle, by focusing on the transition from “Definition” to “Execution” — which is analogous to the transition between the “Requirements & Design” and the “Implementation, Testing and Integration” stages of BlockScience’s model of project development.
The Five Stages of the Engineering Life-Cycle
We will now look more closely into each of the five stages that we have identified, in turn:
Stage One: Ideation and Conceptualization
The first stage of every project involves conceiving an initial idea, and developing that idea into a coherent concept: defining the key problem that the project seeks to address, identifying the various stakeholders, and outlining potential pathways to a solution. This stage is not simply about brainstorming; it often involves identifying new capabilities and associated possibilities, building Proofs of Concept (PoCs), and running experiments to validate critical assumptions. By the end of this stage, the foundation for the project has been laid, and broad strategies for achieving its goals have been proposed.
Stage 2: Requirements and Design
After the project has been rigorously conceptualized — once it has a system architecture — it moves into the second stage, which is when its overall concept is translated into a set of specific requirements for success, and a collection of components (parts and processes) is designed to meet these requirements. Identifying requirements involves specifying critical details about how the concept will be brought to life — goals, constraints, and processes are clearly laid out, and the metrics and mechanisms for validating whether the project’s requirements are being met are documented. Once this has been done, those responsible for designing the project iteratively break down its top-level requirements into related sub-problems, characterize the dependencies between these sub-problems, and provide specifications for implementing and integrating the components of the overall system that will address them.
Stage 3: Implementation, Integration, and Testing:
In this stage, the designs from the previous stage are turned into tangible artifacts, as the components are implemented and tested (in parallel, to the greatest possible extent) before they are integrated (iteratively) into the overall system. Integration testing ensures that the system’s components inter-operate as intended, and ultimately assemble into a coherent whole that demonstrably meets the system-level requirements identified in the previous stage. This approach encourages the kinds of flexibility and ongoing refinement that result in the highest-quality output.
Stage 4: Operations and Maintenance
Once the system has successfully been implemented, integrated, and tested, the project is ready to be deployed for use. The Operations and Maintenance stage begins when the project goes live, and involves both operating the system in its real-world conditions and performing ongoing maintenance on the system. The purpose of Operations and Maintenance is to ensure continuous functionality despite modest variations in the operating environment. The Operations and Maintenance stage is tactical in nature as it involves optimizing the performance of the system under the rules and protocols that govern it: identifying and tracking its Key Performance Indicators, monitoring its infrastructure, and creating manuals for — or/as part of training humans in — its safe operation. Preventative maintenance is an essential element of this stage — but so is identifying and handling failures, when they inevitably arise.
Stage 5: Governance and Evolution
If the Operations and Maintenance is tactical in that it involves optimizing the system’s performance under a fixed set of rules and/or relatively constant conditions, the Governance and Evolution stage is strategic; it is about steering the system safely through those times when the existing frame of reference is inadequate. The governing rules and/or operating conditions are in flux. This stage consists of conceptualizing, designing, implementing, and evaluating potential interventions into the project while it is already operating, and there are already stakeholders who have come to rely on it. Governance may take many forms, but regardless of the decision-making processes employed, the actors making governance decisions must be accountable to the various stakeholder groups that their decisions will affect. Enabling a system to evolve is necessary because in the real world the conditions and context around a project invariably change over time. Thus, the “last” stage of our engineering life-cycle involves identifying when changes to an existing system are warranted, and guiding the system through a fresh iteration of the life-cycle aimed at defining and implementing the necessary modifications. Cyborg anthropologist Amber Case has argued that “[a]t a fundamental level, all design is governance.” We at BlockScience agree — and would add that in our modern, digitally-mediated world, good governance is tantamount to ethical engineering practice.
Conclusion
Systems engineering (or “block science,” as we like to say) is the most reliable process that humanity has yet developed for solving complex problems — the ones with too many moving parts to be comprehensible from any single perspective. At BlockScience, we prioritize a model-based approach to systems engineering because it makes it possible to untangle these complex systems in ways that empower a broad group of stakeholders (including those lacking specialized expertise) through modeling, complexity can be made comprehensible to all. In our work, models are not used to appeal to the authority of the algorithm; they are tools for increasing the legibility of complex systems so that the designers, operators, and governing authorities of those systems become more accountable to the stakeholder groups who will be impacted by the decisions they make. Therefore, we favor a model-based approach except when doing so is impractical or in the rare instances where an alternative methodology provides additional insight and increased accountability.
Systems engineering at BlockScience is not just about resolving a specific problem at an isolated moment in time; it’s about stewarding projects over time, as well as addressing any specific issues that arise over the long arc of a project’s life-cycle with awareness of that project’s history, current status, and potential future. We understand the importance of adaptability; no matter where your project might be on its journey, we work to provide holistic, comprehensive guidance to get it to its destination — and to keep it going, once it gets there.
Article by Michael Zargham and Ilan Ben-Meir, with contributions from Nick Hirannet and illustrations by Jeff Emmett.
About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. By integrating ethnography, applied mathematics, and computational science, we analyze and design safe and resilient socio-technical systems. With deep expertise in Market Design, Distributed Systems, and AI, we provide engineering, design, and analytics services to a wide range of clients including for-profit, non-profit, academic, and government organizations.
