4.1 Why Understanding Interactions with Stakeholders?

4.1 Why Understanding Interactions with Stakeholders?

Operational architecture, or equivalently operational analysis, intends to precisely understand the interactions among time between the system of interest and the external systems of its reference environment, or equivalently of its stakeholders. Motivations of environment architecture, as already discussed in subsection 3.1, also apply in the same terms – mutatis mutandis – to operational architecture. Exactly as for stakeholder identification, any forgetfulness, misunderstanding or error that could occur during the operational architecture process may indeed have disastrous and costly consequences on a system under development. As previously pointed out in subsection 3.1, one must indeed understand that any function and any component of a system ultimately intends to provide an answer to a stakeholder and thus is always involved in the different interactions that are taking place between the system and its environment (of reference). One can therefore just not design – at least with a reasonable level of confidence – the different functions or components of a system without understanding the missions to which they contribute. Many design mistakes are typically done when designers do not have any precise idea of the various operational contexts in which the system they are developing will be used. We can thus only stress here the imperious necessity of always managing operational architecture in any systems architecture process, which will also allow to bring back “meaning” to the end-engineer who is working on a little part of a large system. Medieval cathedrals – whose construction took centuries – would probably never have been built if all involved workers had not a deep understanding of the global target to which they were contributing …¹In “The announcement to Mary”, a play written by the French writer Claudel whose action takes place in the Middle-Age during the construction of the Saint-Rémi church in Reims – France, two sculptors are working on a little statue located in the front of the church. One asks them what they are doing and they are answering: “we are building a cathedral”.

The decoupling between operational architecture and both functional & constructional architecture is also fundamental. This apparently simple principle is in fact much more subtle than it seems. It typically allows to develop systems that have very different operational architectures, but similar functional & constructional architectures. This is the principle of product lines where one constructs “flexible” systems which have a very large customer diversity – in order to fit as much as possible to the needs of the market – but with a very low technical diversity²This last principle is the basis of diversity management whose purpose is to maintain in configuration among time such flexible architectures.. The idea is to develop a family of systems with a very large number of operational architectures, corresponding to different customer needs, on the basis of 1) standard functional and constructional elements (usually corresponding to everything that the customer does not see) and 2) a limited number of additional specific functional and constructional elements that are capturing the operational – or equivalently here the customer – diversity (and thus the value that is perceived by the customer). Such an approach allows to deliver highly customized products to the customer that are constructed using only standard modules. Many industries – automotive, consumer electronics and even food & beverage³All types of Danone or Nestlé yoghurts are for instance made using the same white mass (standard module #1) and the same preforms, i.e. tubes from which different types of cups are produced through adapted blowing (standard module #2). When one makes a yoghurt, the industrial chain begins by a “generic” type of yoghurt, before adding the specific additives (the specific modules) that are given different flavors to the yoghurts. This principle is called late differentiation: it allows to react quickly when a competitor launches a new product or when the customer taste evolves, since one just need changing the last machines of the industrial chain to adapt without reorganizing the full chain (which takes time and money). – are currently using with success this type of architecture for their products.

Despite of its core importance as stressed above, operational architecture is unfortunately still an analysis which is not well known and often not practiced at all, probably since it may be considered as not enough technical and concrete (engineers usually like to quickly jump into technique …). We thus must emphasize on the value of operational architecture which is – even if apparently not too technical⁴Operational architecture can indeed be seen as an interface between the stakeholder and the engineer worlds, since it offers a language that can be understood both by stakeholders and engineers, which explains its apparent simplicity. – a core technical analysis that can only be done by a systems architect. One shall indeed understand that operational architecture deliverables are structured in order to be easily mapped with functional and constructional deliverables. Thus it is just impossible to perform any operational architecting without understanding precisely its functional and constructional consequences, which can only be done by a technical-minded person, typically a systems architect.

TABLE OF CONTENTS