Vanguard Magazine

www.vanguardcanada.com FEBRUARY/MARCH 2020 29 defence systeMs methodologies were proposed in differ- ent fields (organizational design, business strategy, system/industrial engineering, business process reengineering, software engineering) to create or evolve enter- prise systems. These methodologies tend to be complementary, and they are mostly based on a sequence of analysis, steering, design and transition phases as illustrated in Figure 2. The design phase produces a To-Be EA which becomes the blueprint for the construction/procurement, test- ing and deployment of a reengineered DES in the transition phase. Once the new system is born, continual local improve- ments are made to try to adapt the DES/ ITS to evolving needs. However, with time, because of technological advances, completely new needs, new threats, etc., legacy systems become obsolete and one must engage in new major reengineering and transition initiatives. These initiatives often give rise to large and costly projects lasting several years (above a moderate size threshold, larger projects often display dis- economies of scale). The resulting delays and rigidities are counterproductive and preclude adaptiveness. This explains why these classical approaches are severely criti- cized and organizations are seeking more agile development methodologies. The rigidity and inertia of conventional approaches come mainly from the fact that phases are performed sequentially, often by different actors, so it is difficult to go back and change direction when new informa- tion about needs, ally/enemy strategies and PESTLE trends become available. This is exacerbated when the DES-of-interest is sizeable and when documentation stan- dards and preservation means are deficient or fuzzy, which hinders fast EA changes and reuse. To be able to adapt quickly to emerg- ing evolutionary shifts, ED phases must be decoupled. This is possible only if the monitoring, analysis, steering, design and transition information produced is shared in a common formal memory, as shown in Figure 3. This memory takes the form of an ED-Repository (EDR) that contains the previously defined EAR and BBR, as well as any other ED deliverables necessary to empower evolved designs in time (factor trends, plausible future scenarios, diagnosis, strategic directions, cost-benefit-risk evalu- ations, transition plans, knowledge transfer material). The EDR must be congruent with the EA-Framework, but it does not have to be monolithic. It can be split and distributed in selected strategic units. These strategic units then become the depository of the ED information of the DESs under their authority. DESs are part of larger systems (alli- ances, GC, DND, etc.) and they embed smaller systems related to an enterprise unit or cutting across several units. A re- engineered DES-of-interest can be at any level in this continuum, and it may focus on specific capabilities. When adopting an agile ED approach, DESs-of-interest are smaller and directly related to what needs to be changed to adapt. Any facet of their positioning, orientation or EA can be re- modeled by collaborative multifunctional teams as new substantiated information becomes available. The coherence and integrity of the design elements modeled is enforced by adhering to the EA-Frame- work and by preserving successive changes in the EDR to allow the reconstruction of views at selected points in time, and not by producing EA documents sequentially as imposed by a compulsory engineering process. The transition can then be made gradually for small DES-of-interest and even allow changes in design during con- struction. If the EA is well generalized at the conceptual and logical level and real options are available, physical level design and personalization decisions can be post- poned and finalized by multifunctional development teams during the transition. Note, however, that the approach does not preclude the assignment of several adjacent development activities to a larger project if necessary. The EA models produced at the con- ceptual and/or logical level do not have to be very detailed. They aim mainly to pro- vide a common language (ontology), to identify and shape reusable patterns, and to give a holistic picture of the function- alities and structures required to achieve value-creation, mission assurance, interop- erability and generality. The optimization of material and data structures is also a concern at this level. By thinking globally, analysts, strategists and engineers working as a collaborative team on cross-functional service value chains (and not on siloed ac- tivities) reduce the design space and pro- vide guidelines for physical level design decisions. At the physical level, teams of engineers, builders and operators act lo- cally, under the directions of higher-level EA-views and with the help of proven building blocks, to quickly implement ser- vices, applications and structures that are simultaneously synergic, interoperable, user-friendly and conductive to superior service recipients' experiences. This short article sketches the elements of an agile strategic planning and enter- prise engineering approach to adapt DESs and ITSs as needed in our complex, tur- bulent and fast-changing world. We hope the ideas introduced provide a lens though which this challenging competency can be mastered. The views expressed in this text are those of the authors and not that of DND-CAF or the Government of Canada (GC) Alain Martel is professor Emeritus at Université Laval in Quebec City and he is a former CAF officer. Sophie Martel is a Master of Engineering and she is a former CAF officer (CD). The EA models produced at the conceptual and/or logical level do not have to be very detailed. They aim mainly to provide a common language (ontology), to identify and shape reusable patterns, and to give a holistic picture of the functionalities and structures required to achieve value-creation, mission assur- ance, interoperability and generality.

• Cover