When Enterprise Architecture and MBSE meet in an Agile Context (part 1)

Introduction

Involved in PLM interoperability for years, I've been at the intersection of different disciplines and communities of knowledge which have more and more to collaborate effectively if willing to achieve the new challenges related to digitalisation.

More precisely, 2 populations can be considered: Engineers working on the Product and Engineers working on Enterprise Information System domain. We will characterized each of them, and then see what occurs when they work together in an agile context. Sparks' Enterprise Architect will be used for our study concerning potential issues when they have to collaborate using heterogeneous Model Base approaches, Tools and Languages.

Product Engineers

The population of engineers have been adopting Computer Aided Design, Manufacturing and Support, relying more and more on Commercial software products On the Shelves (COTS), evolving from the transformation of paper based documents in electronic documents to development of behavioural models allowing to replace the physical mockups by digital one, which can now be used for reducing testing relying on advanced simulations. They are relying more and more on Model Based System Engineering, which implies numerous kind of modelling languages and solutions, being for Mechanical Design, Electronics, Thermodynamic, and many other engineering fields which all require specific representation of the product for their specific purposes. All these representations constitute the overall model of the Product (or Hyper Model, i.e. a consistent set of multiple representations) , which should be consistent: a Product being itself the assembly of various versioned items which can be themselves Standard Parts (e.g. a crew), Equipment provided by a tier (e.g. engine) or finally parts specifically designed and made for the Product (Make or Buy strategy), the models of these parts have to be carefully managed in order to ensure that the model of the overall Product assembles properly models of these parts, properly versioned and managed in configuration. If not, a high risk exists for mistakes coming from usage of models of an inappropriate version, which can be dramatic for critical systems (i.e. endangering people) and for the competitiveness of the enterprise (i.e. work is to be done several times due to the mistakes). One particular engineer population is the one dealing with System Modelling, relying on the SysML (System Modelling Language) which aims at defining for the Product System the expected functions organised as a functional decomposition, the technical solutions to be used in order to ensure these functions the appropriate way (with verification and validation) , the specifications for the solution components to be made or to buy, and then to be assembled when producing them (e.g. Manufacturing processes). The produced system is then to be tested and delivered to the clients, with all what is required for ensuring it can be operated properly (training, usage and maintenance guidelines, etc.). In addition, logistic support is to be ensured concerning availability of spare parts when having to replace wear or broken parts. System Engineers are then considering different Product breakdowns with associated mounting/un-mounting processes, and which are quite different for production and for repair. More and more, due to obsolescence of some parts of the Products (e.g. electronic/communication means for huge Cruise Ships with a many years life), it becomes important to provide ways for upgrading these parts during the life time of the sold products for avoiding quick obsolescence. This is the new challenge which will imply innovation for the System Engineering Processes and creation of new, and sometimes disruptive due to impact of digitalisation, Business Models.

Enterprise Information System Engineers

The population of engineers in the Enterprise Information System domain. They have to provide for each function of the enterprise, being directly related to the Product(s) or to the support, the accurate support in order to ensure the development, the realisation and the operational support of the applicative component constituting the Information System and the Model Factories, e.g. all what support the production of the different required models, being for the Enterprise' Products, for the Enterprise's Processes or for the Enterprise's Ressources. Such population has also been adopting Model Based approach, relying on standards such a the Unified Modelling Language. The UML evolution has been following the practices of the community, starting to support first the design of Software Products, its production and then its support. Considering usage of COTS by Information Department of Enterprise, we can consider they are Enterprise Product Equipment similar: they will be bought, deployed, integrated and configured in order to ensure that the systems of interest (Information System of the enterprise and Model Factories) are properly designed, developed, deployed, enacted and operated with the appropriate support, consistent and efficiency. Of course, it comes with the pressure of cost reduction objectives, of the reduction of the Product development cycles, despite the growing complexity of the COTS and of the COTS market, despite the always accelerating pace of Information and Communication Technologies changes and despite the global uncertainty of the today's economy (we are in a VUCA world - Volatility, uncertainty, complexity and ambiguity). In this context, this population is on an continuous learning mode, with processes which should be easily and frequently reconfigurable in order to be able to adapt to a continuously changing environment. It is probably what is making the success of the "Agile at scale" and "Digitalisation" trends, for which it is sometimes difficult to distinguish between a real need or a fashion. Many enterprises know they have to transform themselves for facing the new emerging challenges. But the path is difficult, and when the needs are not well communicated and undertood, it may lead to dramatic situation. For transformation, they have to rely on external consultants and service providers, who are selling they can support the enterprise for such transformation, but which are necessarily aware about the specific market needs and practices of the enterprises they are supporting. They are themselves following the trends and continuous evolution of the domain, with competing practices and frameworks. It may lead to an even more complicated environment for the Enterprise Information System, bringing more problems than solution if not properly managed. In such a context, Enterprise Modelling and associated practices and standardised processes and languages could help to handle the complexity, and facilitate the communication between the different stakeholders, and in particular the different kind of architects (Enterprise, Domain, Business Process, Solution, Infrastructure), adopting a model based approach for ensuring the global consistency and the convergence with Business Objectives.

Easy collaboration?

One often occurring issue is the following: when the Enterprise Information System population, which uses Enterprise Modelling and ArchiMate, meets the population of Product Engineers which adopted MBSE and SysML, some conflicts may occur concerning the language and methodological framework to use in order to collaborate, each community considering his methodological framework and used language(s) cover all the needs of the two populations. It is unfortunately not the case, as they are not considering the same system of interest, and because their organisational and responsibility boundaries are different, in particular within the today's matrix or networked organisations. A first concrete issue to resolve when the two population meet and have to collaborate concerns the way to deal with Requirement Engineering. What should we use? The application and languages of the first population or of the second population? How to capture the needs? How to describe their respective systems of interest, their functional and physical decomposition, the associated processes of each community, etc? Which common language should be used for their collaboration, when each population's language has some overlap for describing requirements, use cases, user stories or needs? This part of the article is about a study aiming at comparing how the standardised languages of each community, but also the emerging languages coming from Agile at scale or Lean trends, could match together.

The adopted approach

In order to compare how the standardised languages of each community, but also the emerging languages coming from Agile at scale or Lean trends, could match together, the adopted approach is the following. The Software Product EA was selected, as one of COTS belonging to the family of Modelling platforms relying on the Object Management Group's Model Driven Architecture Framework and associated standardised specifications. In addition to support Software Engineering (UML) and System Engineering (SysML) languages, they also support usage of several other Domain Specific Languages, standardised or not. In particular, it includes ArchiMate, for Enterprise Modelling, which is an Open Group's specification, and constitute a de facto standard for Enterprise Architects. It comes with a specification for interchange of ArchiMate Models, which is also supported by Enterprise Architect.

When respectively Enterprise Architects from Enterprise Information system department have to collaborate with System Engineers of a Program, the used tools/language used are respectively in our scenario Sparx Enterprise Architect (EA)/ArchiMate and EA-CAMEO toolchain/SysML. The used standard processes are different. In between, some "agile" tools providing Kanban for User stories.

ArchiMate

EA supports modelling with the ArchiMate language. Two constructs are proposed for dealing with requirements: ArchiMate:Requirement and ArchiMate:Constraint.

ArchiMate specifications for Requirement:

• Definition: "A Requirement represents a statement of need that must be met by the architecture. Requirements model the properties of these elements that are needed to achieve the "ends" that are modelled by the goals. In this respect, requirements represent the "means" to realize goals."
• Category:Motivation
• Examples: "Assign personal assistant", "Provide on-line portfolio service", "Provide on-line information service", "Use open source software"

ArchiMate specifications for Constraint:

• Definition: "A Constraint is defined as a restriction on the way in which a system is realized.This may be a restriction on the implementation of the system (e.g., specific technology that is to be used), or a restriction on the implementation process (e.g., time or budget constraints)."
• Category: Motivation
• Examples: "Application should be realised in Java", "Cost should be below budget", "iPad only version", "Must use MIT license"

If any model element of the previous list can be related to a requirement or a constraint, the two more specialised relations coming from another model element are Influence and Realisation relationships.

For the other Motivation modelling element, no realisation exist, we have only influence relationship. The exceptions are Stakeholder and Gap modelling elements (no typed relations only) and Requirement/Constraint themselves, for which composition, aggregation and specialisation relationship are supported.

In the reverse, Requirement and Constraint can influence objectives, outcomes and principles. They can influence drivers, value, assessments and meanings. They can be composed or aggregated by other requirements or constraints. Finally, they can be related to any other element of the model.

Nothing prevents specialising these relationships through stereotypes (part of the last version of the ArchiMate specification - i.e. 3), even if not supported by all the tools (in particular by Archi). However, it is also possible to tag the relationship with a property capturing the type of the relationship, and then to specialised the relationship with categorisation coming from other languages or from other processes/methodology/framework. In particular, for non functional requirements, many categorisations exist coming from many requirement analysis framework. They can all be captured in the model. Is extending the visual modelling notation in this case very useful? Not so sure, as it creates a risk for having to many symbols to know and to memorise. Some convention may be established consisting in indicating the types of relationship (but also requirements) within the name, using stereotyping notation or using instantiation notation). Another approach could consist on creating views dedicated to capture only requirements of a certain kind. Another approach could consist in using "Grouping", indicating the kind of requirements which are grouped on the visual representation. Finally, if model made available through tools allowing to query based on properties and to create some reports on the base of the queries, It will be easy for users managing many categorised requirements, constraints and their relations with the rest of the model.

All this is (except stereotypes) is realised and exchangeable using Archi and EA. For this reason, I will not recommend using stereotypes. If supported by most of the UML modelling environment (including EA but also most of the UML modelling environment such as CAMEO, Modelio, Mega, etc.), they are not necessarily supported by the other Enterprise Modelling or Management tools. Also, extending the visual language may go against simplicity and interoperability, while tagging with accurate properties responds to the needs without requiring extra development.

The following snapshot shows specialised requirement and constraint with a property RequirementType and a value "Functional". Let's note that Archi allows to filter them on the Models Pane.

The next snapshot shows how it looks like in EA, knowing that this is preserved making import/export based on the open specification for ArchiMate model exchange provided by the Open Group.

EA and the other way for capturing needs and requirements

EA supports other standardised languages allowing capturing requirements (SysML, UAF, etc.). It also proposes by default Domain Specific Languages which are not standardised, but support requirement analysis and support of projects, traditional or based on agile practices (i.e. with Kanban, User stories or Epic).

Below is what is proposed with the Unified Architecture Framework coming from the System Engineering Community. You can see Requirement, Constraint, Business Requirement and Business Constraint modelling constructs.

The previous snapshot shows an EA specific profile for capturing requirements. It provides many other specialised modelling requirement constructs, such as Functional, NonFunctional, Business, User, Architectural, Implementation, Regulatory and Security requirements. It adds a checklist feature allowing to capture if the requirements are atomic, attainable, cohesive, complete, current, independent, modifiable, traceable, unambiguous or verifiable, so most of what is needed for performing a good requirement analysis. It looks like SysML, with some more type of specialised requirement modelling constructs, knowing that SysML as UML is extensible, and could support extension. It also support tagging, as UML.

Other ways exist for capturing functional needs. In UML, it is possible to rely on Use cases, and to contextualise them using actors of business processes to be supported, through a representation of these processes based on Activity modelling with UML.

With Agile methods, the need gathering could be collected through user stories and epics. No standardised language exists for this. In EA, two profiles are proposed, one for project management with as modelling constructs Feature, Use Case, User Story, Epic, Sprint, Task and Changes. They are ways to capture what the stakeholders want to do with or to be done concerning the system(s) to be produced by a project. Another profile related to Kanban is restricted to Change, Defect, Feature and User Story modelling constructs, in order supporting agile and lean approaches.

Let's note that some hierarchy and level of granularity should exist when using Epic, User Story, Use cases and feature. Looking at the different practices, it should reflect the order I adopted in the provided list, going from the more coarse grain to the thiner grain.

A last way exist capturing needs which consists in capturing scenarios, being by using textual description or structured specification with a set of steps.

As illustrated by the two previous snapshots, it is also supported by EA.

Let's note that capturing steps for describing definition of tasks is also a feature of the SPEM language, which is an OMG's standardised language for modelling practices. Let's also note that SPEM is also supported by EA.

SPEM is quite adapted for "methods & tools" teams, having to define how a tool should be used for supporting common practices.

If having to interconnect all these languages, my proposal should be roughly the one described in the following snapshot.

Whatever the language used for capture of requirements, ArchiMate supports capturing all the specialisations by tagging, knowing that the different adopted processes and practices may lead to the usage of many and heterogeneous processes and categorisations to be combined. So when having to aggregate all of them without imposing the same choice for everybody, let's use the simplest set of constructs and reflect the different kind of requirement categorisations with multiple properties, when needed and useful (let's be lean).

When looking at Epics, User Stories or Use Cases, it occurs that they are most of the time textual. Also, ArchiMate, according the level of granularity of the produced views and considered viewpoints, can reflect all of them in a model which is quite suited for reflecting views of Business, Information System and Technology architects, being at Enterprise, Program, Discipline, Process Owner, User or Operator level. It can also according to the produced view, related to architecture or implementation.

So without willing to replace the specific languages of all the implied stakeholders and kind of architects, it shows that ArchiMate is quite accurate for reflecting all the viewpoints and eventually aggregate the different categorisations of requirements used by each of them, ensuring simple way to capture them (annotation) without overloading the visual language to be used.

Within an environment like EA, it is in addition quite easy tracing requirements and needs produced by each of the community, being System Engineers using SysML, Software Engineers using UML or agile community producing User stories and Epics, and associating them to ArchiMate requirements which will derive from them.

What will be quite important is to formalise explicitly the adopted practices, without willing to uniformise it, knowing that in current actual world, it is just an utopia thinking that everything can be uniformed and integrated.

Conclusion

In this article, we described two communities which are using different languages and practices for capturing needs and defining requirements: Product Engineers/Architects and Information System Engineers/Architects. When having to work together, it may lead to some conflicts: which tool to use? Which common language? How to deal with requirement engineering?

We then described how requirements and needs can be captured with ArchiMate and other languages, standardised or not, supporting System engineers, Software Engineers or Agile/Lean project managers. ArchiMate appears a good way for aggregating requirements and needs captured with their approaches, and then to attached them to the different views and viewpoints of all the involved stakeholders, and for any element of the architectural model, at any scale.

On any modelling platform supporting the different languages (EA is only one of them), it should be possible interrelating properly the models but also to aggregate and interrelate the different kind of requirements and needs whatever their source is, in order to check their consistency and accuracy with the motivation of concerned organisations: not only the enterprise but also the program and all the members of the supply chain.

The second part article will describe a generic business scenario and illustration of the practices we can derived from what we learnt in this first article.

Let's follow. Don't hesitate to react and share. If you think this article create value, let's like ant share ;)