In the 18^th century, – more precisely, in the 1760s – two Visionaries, Ange-Jacques Gabriel and Blaise-Henri Arnoult, jointed their talents and invented the “reconfigurable space” concept. They answered Louis XV’s wish to provide Versailles with a performance hall suitable for different usages: concerts, spectacles, banquets and balls.

Their vision of a dynamic system was a major breakthrough regarding the static architectures of that time. They were outstanding also managers as they could achieve their project despite tremendous challenges: technical performance, especially acoustic performance, matching the prestige of their royal customer; security constraints as the place was intended to receive more than one thousand people, among them princes and monarchs; reduced funding because of years of external wars; overwhelmingly tight deadline: 22 months from the investment decision up to the delivery date required for the Dauphin’s marriage, the future Louis XVI.

We owe Ange-Jacques Gabriel, an architect in the usual meaning of the term, the shape and structure of the place. However, Gabriel was also a system architect, in the contemporary meaning, who was able to conceive an integrated architecture encompassing all the needs and constraints generated by the many usages.

We owe Blaise-Henri Arnoult, a machinist in the usual meaning of the term, but also a born engineer, the systems’ dynamics enabling transformation from one configuration to another in only a few hours.

At last, thanks to these both intelligences, which were able of thinking beyond the differences of views inherent to their complementarity, the invention of the Opera Royal was possible. Such an invention would definitely qualify today as a breakthrough innovation.

The two visionaries developed technological solutions which express the genius of great inventors, and they also managed the project  successfully, implementing  what is now known as “agile and concurrent methods”. Customer requirements, including those of the king himself, were elicited with the help of mockups. In the same timeframe, the different craftsmen (carpenters, sculptors, lighting specialists …,) integrated directly their expertise into the solution.  Of course, the mockups were made of wood and were not 3D numeric models on computers, but the principles of collaborative engineering reformulated in the XXIth century were already applied by Gabriel and Arnoult.

The adventure is now pursuing thanks to the “Château de Versailles Spectacles” team who, reflecting the same tradition, dares to face the risk of creation.  Today, the team is reviving forgotten musical scores, for our greatest happiness.

EIRIS Conseil sponsors the Royal Opera of Versailles

Five questions about the use of system modeling languages

The SysML modeling language, like any other, provides visual conventions meant to facilitate communication. However, this particular language might turn out to be the one too many, the one prone to impart the instability of a Tower of Babel to an organization. If implementation bypasses some crucial questions, the risk is high. In contrast, asking these questions may be an opportunity to enhance communication among teams.

1- What are the concepts? What are they based on? Are they structured?

These points aim at defining without ambiguity, and then structuring, the organization’s concepts regarding the system. They also aim at questioning relationships, synonymy, and homonymy. In other words, they aim at defining a system meta-model.

The meta-model reflects the culture and language of the organization even when, to ease external communication, turning to international standards is recommended. Norm ISO 15288 is the one to adopt for issues regarding systems engineering terminology.

Fluent communication originates in the common understanding of a shared semantic asset.

A meta-model relevant to the modeling objectives is true to the expectations in both scope and detail. For example, if the objectives are to implement a functional breakdown approach, the concept of function is probably sufficient. If the objectives also aim at considering parameter values in different simulation contexts, then the meta-model should be more complex.

Efficient communication only deals with the concepts it aims to share.

2-  From natural language to modeling language: what is the methodology?

Next, the system meta-model needs to be translated into the modeling language. Appropriate translation rules must therefore be defined between the system meta-model and the meta-model of the language, and the resulting modeling rules must be defined as well.

In addition, model construction should be driven by a methodology structuring the textual documentation associated with the graphic modeling elements — the description fields of the elements—. Otherwise, the models might quickly turn into incomprehensible jumbles of boxes and arrows. This point is of the utmost importance, because the descriptions in the natural language capitalize the reasoning of the teams and the memory of the models.

Modeling does not preclude writing; it brings additional means of expression.

At the same time, a good methodology deals with relationships management. It optimizes delegation of relationship management to the tools to make it as transparent as possible for the users: It is easy to create links, but manually maintaining consistency between links throughout a project’s progress can prove to be very expensive.

It also deals with implementation on tools and addresses user friendliness by customizing model templates and user interfaces.

Modeling is a means to facilitate coherent thinking; it is not tool manipulation skill.

3- What about spreading the methodology across teams?

The production of modeling rules and methodology is the responsibility of experts who perfectly master the intricacy of meta-modeling. However, using the methodology in projects is the task of engineers whose expertise and project objectives are the building of robust system architectures. Besides, a good methodology is not enough. The teams must make it their own, and success calls for a communication based on practical examples taken from the organization’s field of activity.

Any means of communication may be considered: training (e-learning or conventional), handbooks, knowledge management systems…

Modeling calls for methodological learning and the provision of the means to learn.

4- By the way, what is a model? What is the connection with collective expertise?

A model is both an organized set of semantic units—the modeling elements—and the links between these units, the latter also conveying meaning. Although a model is much more than a collection of visual diagrams, the diagrams are parts the model. These specific modeling elements highlight the different subsets of links—and therefore intellectual connections—for different points of view.

In systems engineering, a collaborative discipline by definition, it is not possible to build a model behind closed doors even if the pen, or rather the mouse, is placed in the hands of a limited number of persons. A model records and expresses the results of interdisciplinary workshops. When a model is about to be finalized, complementarity among the diagrams can be checked. Beyond the diagrams, the consistency of the entire model testifies to the coherence of the collective thought.

A model is means to capitalize collective thinking and evaluate the maturity of projects.

5 – Is a model a deliverable? For whom? To what end?

A model capitalizes the results of many activities of system definition processes. The same model may become enriched from one evolution to the next throughout a project. Who says “activity result” says “deliverable”. Who says “deliverable” says “intended users”. Intended users are numerous in a system’s definition but few, most probably, will have a calling for learning a specialized modeling language. Models, though, allow for extraction of views in different formats, including the traditional formats of office automation. When model organization and customization are conceived to retrieve views specified in concert with the users, then the communication of knowledge can be adapted to their varied needs.

A model is a knowledge retrieval base of views adjusted for communication needs.

Françoise Caron, EIRIS Conseil.

This paper is the first of a series of three focusing on MBSE deployment. To be notified of the next publications, please consult EIRIS Conseil’s LinkedIn page.

Home

A Web search for “systems engineering” brings up some 15,400,000 entries, which is just shy of the number for “Agatha Christie.” Needless to say, the field has acquired a kind of celebrity!

An innovative, collaborative approach

Like any engineering approach, systems engineering leads to invention and innovation. However, it is pre-eminently based on multidisciplinary.

An approach which facilitates human and technical interactions

Systems engineering is essential in the development of “complex systems.” These are objects whose proper functioning depends as heavily on interactions as on the individual behaviors of each of the systems’ components: both interactions with the environments and among the components.

Just like the objects it aims to produce, the approach relies on exchange, the exchange of ideas and information inherent in any collaborative project. The quality of a system is a direct reflection of the quality of the interactions among the teams who built it: internally and also externally, with all the other project stakeholders.

A systemic company approach to effect change

The approach is deployed to effect the change needed to achieve the Company’s strategic goals. Its success criteria are the answers to the questions, “Why use the approach?“, “What is our final objective?”, “What would the efficiency gains be?”.

Because the approach aims at taking the best possible advantage of all the practices linking the different trades into a collaborative endeavor, it is indeed a systemic approach.

The EIRIS Conseil solution: changing the paradigm one verifiable stage at a time

If the systems engineering approach is deployed without clear Company objectives, it will meet with no success … for a lack of success criteria. If supporting expertise, such as requirements management, modeling, or configuration management, is deployed without a comprehensive plan, the risk for incoherence is not managed.

To enable our clients to reach their objectives while managing the risks, we have developed E_Talea®. A staged, integrated approach, E_Talea® accompanies the client through change from interim goal to interim goal until the final objective is reached. Please discover on our Web site the 5 keys to the E_Talea® solution, i.e., the 5 levers able to move to greater success both complex systems and the companies that produce them.

Françoise Caron, EIRIS Conseil