Modeling and Analysis of Boundary Objects and Methodological Islands in Large-Scale Systems Development
Rebekka Wohlrab, Jennifer Horkoff, Rashidah Kasauli, Salome Maro, Jan-Philipp Steghöfer, Eric Knauss
MModeling and Analysis ofBoundary Objects and Methodological Islandsin Large-Scale Systems Development
Rebekka Wohlrab , − − − , Jennifer Horkoff − − − ,Rashidah Kasauli − − − , Salome Maro − − − ,Jan-Philipp Steghöfer − − − , and EricKnauss − − − X ] Chalmers | University of Gothenburg, Sweden Systemite AB, Sweden {wohlrab, jenho, rashida}@chalmers.se, {salome.maro,jan-philipp.steghofer, eric.knauss}@cse.gu.se
Abstract.
This is the author version of our paper accepted to the 39th International Conference on Conceptual Modeling (ER 2020).The final authenticated version will be available online in the Lecture Notes in Computer Science by Springer.Large-scale systems development commonly faces the chal-lenge of managing relevant knowledge between different organizationalgroups, particularly in increasingly agile contexts. In previous studies, wefound the importance of analyzing methodological islands (i.e., groupsusing different development methods than the surrounding organization)and boundary objects between them. In this paper, we propose a meta-model to better capture and analyze coordination and knowledge man-agement in practice. Such a metamodel can allow practitioners to de-scribe current practices, analyze issues, and design better-suited coor-dination mechanisms. We evaluated the conceptual model together withfour large-scale companies developing complex systems. In particular, wederived an initial list of bad smells that can be leveraged to detect issuesand devise suitable improvement strategies for inter-team coordinationin large-scale development. We present the model, smells, and our eval-uation results.
Keywords: boundary objects · agile development · empirical studies. Large-scale systems engineering companies commonly face the challenge of coor-dination between multiple and multidisciplinary teams (e.g., software, systems,hardware). Especially in large-scale agile development, inter-team coordinationis a recognized challenge [8]. In practice, ways of working are not universal inlarge companies. Teams are surrounded by other organizational parts that do notuse the same methods—and thus become “ methodological islands ” [14]. For in-stance, in a large automotive company, more than 500 teams exist, using diversepractices (agile, waterfall), with complex interdependencies and multiple sup-pliers. Coordination is supported by various artifacts (e.g., written documents,models, backlogs, or code). Furthermore, phone calls, meetings in communitiesof practice, and other mechanisms are used to coordinate concerns around these a r X i v : . [ c s . S E ] A ug R. Wohlrab et al. artifacts. In such a situation, it can be challenging to coordinate knowledgebetween different organizational groupings. Practitioners need to better under-stand the factors causing these groups (or islands) to cluster or form and theeffectiveness of the current ways of supporting communication. For example, isa particular written document between two islands fit for coordination? Is it tooflexible or too rigid? Is it both complex and changing frequently? Is it governed,and do those that govern the document understand its use? Can the currentcoordination situation be understood, made explicit, and improved?In previous studies, we have aimed to characterize these coordination needsby focusing on methodological islands (MIs) and boundary objects (BOs) [14].Boundary objects create a common understanding between groups and can facil-itate inter-team coordination and knowledge management [27]. We have investi-gated the nature and use of these BOs in practice, but we have not yet created amethod to systematically capture BOs and MIs (BOMIs) in a structured way. Tothe best of our knowledge, there is no modeling approach and conceptual modelavailable to specifically address boundary objects and methodological islands.In this paper, we address this gap by proposing a metamodel for bound-ary objects and methodological islands in large-scale systems development. Thismodel is based on empirical data and accounts from ongoing projects [14,25,26].By creating such a model, a complete picture of an organization’s coordinationneeds and boundary objects can be established, analyzed, and used to identifyand mitigate current issues in a more visual and structured way.We evaluated the metamodel together with four large-scale systems compa-nies and describe the corresponding instance models created. We present initialfindings on how the model can be used to identify bad smells and issues.This paper is organized as follows: Sec. 2 presents the background. Sec. 3 de-scribes our metamodel, method and smell description, followed by the evaluationin Sec. 4. Sec. 5 briefly reviews related modeling approaches, Sec. 6 discusses ourfindings and describes threats to validity, while Sec. 7 concludes the paper.
We describe background information to motivate this paper’s contributions.
Boundary Objects.
Boundary objects (BOs) are “ objects which are bothplastic enough to adapt to local needs and the constraints of the several par-ties employing them, yet robust enough to maintain a common identity acrosssites ” [20]. The concept was initially coined in sociology and has proven to beuseful in a variety of domains. Recently, BOs have increasingly been studied insoftware and systems engineering [19, 27, 29].Over the last two years, we have engaged with four large-scale systems en-gineering companies to support them in adopting agile methods and managingimportant knowledge. We used the design science methodology [10] to inves-tigate coordination in large-scale systems engineering, develop suitable designartifacts targeting practical problems, and evaluate them in several iterations. odeling and Analysis of Boundary Objects and Methodological Islands 3
We build upon the findings of this long-term project. In Sec. 4, we describe theparticipating companies in further detail.As part of our work on BOs, we conducted several studies. We analyzedcurrently used artifacts and created guidelines to manage them in large-scaleagile contexts, including concerns related to the level of detail and versioning ofthese artifacts [27]. We found that BOs can belong to several super types (e.g.,Technology, Task, or Planning) [14] and should be managed in groups of repre-sentatives of several teams [27]. Moreover, we studied architecture descriptionsand interfaces as BOs [24, 25]. We found that important dimensions of interfacechange are stability, time to perform a change, criticality, level of abstraction,distance to affected parties, number of affected components, position in the in-terface’s lifecycle, and maturity of affected functions. Moreover, many companiesdescribe information models to capture artifact types and their relations. Theseinformation models also serve as BOs, change over time, and can be used todefine the required degree of alignment of different teams’ practices [26].BOs are commonly used between individuals from several (sub-)disciplines,who refer to concepts with different terminologies [27]. The groups using BOsneed to be properly understood to enable inter-team coordination.
Methodological Islands.
The mix of methods in large-scale organizationsis a recognized challenge [27]. In our empirical study on large-scale development,agile teams were described as “ agile islands in a waterfall ” [14]. This phenomenonis not limited to the discrepancy of agile and plan-driven methods, but a generalissue. Therefore, we use the term methodological islands (MIs) for organizationalgroups using different development methods than the surrounding organization.We identified that MIs can be of different types, e.g., individual teams (e.g.,component teams), groups of teams (e.g., departments), or entire organizations.MIs arise due to several drivers related to business , process , and technology .Based on these studies, we got an understanding of BOs and MIs in large-scale systems engineering. These findings needed to be better instrumentalizedto support practitioners, in particular, using a systematic approach to captureBOs and MIs [14]. Such an approach would constitute a formal treatment todescribe and evaluate coordination needs. In the following, we present our main contributions, i.e., the BOMI metamodel,method, and analysis capabilities provided by the model. We continued our de-sign science approach [10] but with a focus on developing a metamodel, modelingguidelines, and model smells. An overview of the input artifacts and steps of ourmethod is shown in Figure 1. We went through several iterations designing anartifact (metamodel, method, and smells) and performing evaluations of the ar-tifact both locally and with four companies. In the first round, we used ourinformal drawings and lists of collected BO and MIs in practice, along with ourknowledge gathered from the companies, to come up with a first draft of theartifact. The paper authors discussed the artifact and made local improvements.
R. Wohlrab et al.
Fig. 1: Overview of steps of our research methodWe then used historical data gathered from workshops with two of the compa-nies to create trial models of their BOMI situation. After discussion, this causedfurther iteration over the artifact. Finally, we evaluated the design artifact ina focused workshop (see Sec. 4). The four companies we collaborated with aredescribed in Table 1.
To capture our conceptual model, we use a UML class diagram. Other languagescould work just as well, but we choose UML due to its familiarity. The latestversion of the BOMI metamodel can be found in Fig. 2.Based on our past findings, the most critical element of the metamodel is the BO itself (in dark gray). We label this class as an interface, given the nature ofBOs as interfaces between methodological islands. We give this class a SuperType and
SubType , based on our past classification findings [14]. The
SuperType isan enumeration, with a set list of options, while we found an enumeration wastoo restrictive for the
SubType , and leave this as free text (a String).We use our experiences to identify a number of internal BO attributes, includ-ing the Purpose , Level of detail , Frequency of change , Level of modularity and
Maintainability , whether the BO represents Prescriptive knowledge (as opposedto descriptive), which
Lifecycle stage the BO is used in, with an enumerationof four options ( Planning , Operation , Deprecate , Retire ), Representation For-mat (e.g., free text, model, table), the level of
Internal Consistency , and whatTable 1: Descriptions of participating companies.
CompanyA Develops telecommunications products. Separate organizational units existfor sales, product management, and other purposes.CompanyB Develops mechanical products, both for consumer markets and for indus-trial development and manufacturing. The systems are decomposed intoseveral elements, which is also reflected in the organizational structure.CompanyC Is an automotive Original Equipment Manufacturer (OEM). Traditionally,the company has been structured according to vehicle parts (e.g., power-train, chassis, ...), but has undergone restructuring into agile teams.CompanyD Develops high-tech solutions for vehicular systems. Software developmentteams are largely independent of hardware development.odeling and Analysis of Boundary Objects and Methodological Islands 5 <
BOSuperTypes <
BOSuperTypes <
DriverTypes <
DriverTypes <
MIType <
MIType <
LifecycleStage <
LifecycleStage <
HighLow <
HighLow <
DistanceTypes <
DistanceTypes <
BoundaryObject <
BoundaryObject
SuperType: BOSuperTypes
SubType: String
MethodologicalIslandMethodologicalIsland
Types: MITypes * Co-ordinates Between * Co-ordinates Between
StandardTaskTechnologyPlanningValueProduct
Other
TechnologyOrganizational
ProcessTeamsDepartments
Silos (release trains)Organizations
LevelofDetail: HighLowFrequencyofChange: HighLow
Modularity: HighLow
Maintainability: HighLow
Prescriptive: HighLow
LifecycleStage: LifecycleStage
RepresentationFormat: String
RoleRole
Name: String Part of1* Part of1 *1* Responsible/Creates/Reads/Updates/Deletes *1* Responsible/Creates/Reads/Updates/DeletesGovernanceTeamGovernanceTeam Name: String * Governs 111 * Governs Usage (association)Usage (association)
Accessibility: HighLowStability: HighLowUptoDate: String
InternalConsistency: HighLowConnectedness (between MIs): HighLowExternal Consitency (to other BO): HighLow
Criticality: HighLow
FitforPurpose: HighLow * DistanceSize: HighLow
Governs (association)Governs (association)
Versioning: String
Planning
DeprecateOperationRetire DriverType: DriverTypesDriverSubType: StringFrequencyofCoordination: HighLow
CoordinationMechanism: String
Distance Type: DistanceTypesPurpose: StringHighLowMedium
Usage (association)Usage (association)
Accessibility: HighLow
Stability: HighLow
Criticality: HighLow
FitforPurpose: HighLow
Cultural
Organizational
Geographical
Fig. 2: Metamodel for Boundary Objects and Methodological Islands (BOMI)sort of
Versioning information it may have. The last two attributes describe therelationship between this BO and other classes in the model, in this case, Connect-edness of the
MIs using the BO , and how Externally Consistent it is with other BO instances. These attributes are either free text (String) or are described via asimple qualitative scale of High , Medium , and
Low (the
HighLow enumeration).We found that although this qualitative scale can be used for a quick summary,often a more complex description is needed. For example, for architecture de-scriptions, the level of detail of the BO changes depending on the Lifecyle stage.Thus, we find the need to accompany each attribute with a short explanationof the value. We omit this from the current metamodel for simplicity, but notethat the instance models should be accompanied by some explanatory text.A
Methodological Island (in green) contains an enumeration of typesbased on our past findings (
Teams , Silos , Departments , Organizations ). For
MIs ,the relations to other elements are crucial. Organizational
Roles , with role names are part of the
MIs . A
Role is responsible for, or has a CRUD relationship witha BO . The Usage association class between these classes captures how
Roles use
BOs . We can model a BO ’s accessibility for a Role , its
Stability , Criticality , andwhether it is
Fit for Purpose . Ideally, a
Role is part of a MI , and the Role ’sinteraction with the BO is described in the Usage class. In some cases, practi-tioners were reluctant to explicitly model roles and only model
BOs and
MIs ,either because the inclusion of
Roles caused the model to drastically increase insize or because the
Role and MI were similar (e.g., “Development Team” → Roleshould be “Developer”). Thus, we repeat this association class in two places andone can also create a
Usage association between
BOs and
MIs .Our past work uncovered the concept of MI drivers, the reason for the MIdivide. We capture that a
Driver drives an MI , and describe possibly inter- R. Wohlrab et al. esting attributes of the drivers, including an enumerated
Driver Type ( Tech-nology , Process , Organization ), a free-text
Driver SubType , the
Distance Type culture/geography/organization inspired by [3, 11], and the size of the distance.Finally, based on past work [25,27], we find that governance of BOs is crucial.
Roles can be part of a
Governance Team , which governs a BO . For instance, aCommunity of Practice is a potential governance team for architecture descrip-tions [25]. We collect interesting attributes of this relationship in the Governs association class, including the
Coordination Mechanism (e.g., meetings, pro-cesses, standards, tools), and the
Frequency of Coordination .Although other details could be added to this model, we aim for relativesimplicity to better enable instantiation with and by our industrial partners.
As part of our modeling workshops, we created a simple list of guiding questionsbased on our metamodel concepts and attributes, e.g., “Which BO would youlike to focus on?”, “What roles interact with the BO?”, and “Which islands do theroles belong to?”. The full list of questions can be found in our online appendix .These questions are intended to guide in the creation of a BOMI instance model,either led by a modeling facilitator, or independently in a company. To illustrate our model in action, we present an example derived from a workshopwith our industrial partners in Fig. 3. More details about how this example wasderived are provided in Sec. 4. For this example, we again use UML syntax. Indeveloping a BOMI language, we could create a domain-specific visual language,using customized icons or different shapes. Although promising, we leave theexploration of a BOMI-specific visual syntax to future work, and instead use thevisual syntax of UML, with the benefit of familiarity for our industrial partners.In this example, Company A (more detail in Sec. 4) chose to focus on a
UserStory which is a BO that is used in planning, acting as a Backlog Item . Otherattributes include the
Level of Detail , Frequency of Changes , and
RepresentationFormat . In this example, we include extra explanatory text for the attributesin parentheses. Two
MIs , the
Development Team and the
Product ManagementTeam , use this BO for coordination. Developers and
Product Owner roles are partof these
MIs , respectively.
Usage for the
Developer is captured via an associationclass, the attributes indicating that the
User Story is easily accessible, critical,but with low stability, amongst other things. A similar
Usage class capturesusage of the BO by the Product Owner . The
Product Owner is part of a
Forumof Product Owners who make up the
Governance Team for the
User StoryBO . The
Governs association class captures attributes of the governance process,e.g., they coordinate using the JIRA tool and meetings, and coordinate at leastonce per agile sprint. Note that due to time restrictions, this model is incomplete, https://doi.org/10.6084/m9.figshare.12363764.v1odeling and Analysis of Boundary Objects and Methodological Islands 7 <
User Story: BoundaryObject
SuperType: PlanningSubType: Backlog Item
Development Team:
MethodologicalIsland
Development Team:
MethodologicalIsland
Types: Team *Co-ordinates Between0* *Co-ordinates Between LevelofDetail: LowFrequencyofChange: High (Priorities frequently changed, otherwise low)
Modularity: Medium (can have sub- user stories)
Maintainability: Prescriptive: LifecycleStage: Planning
RepresentationFormat: "As a user.." (Text in JIRA)
Developer: RoleDeveloper: Role
Name: Developer *1 * Reads *1 * Reads : GovernanceTeam: GovernanceTeam
Name:
Part of
Part of *Governs *Governs Reads:UsageReads:Usage
Accessibility: HighStability: Low (priorities change)UptoDate: High (during planning stage, low afterwards
InternalConsistency: Connectedness (between MIs):
External Consitency (to other BO):
Low (Not maintained as development continues) Criticality: HighFitforPurpose: High * DistanceSize: : Governs: Governs
Versioning: None DriverType: Organization,
Process
DriverSubType: FrequencyofCoordination: Medium (>= 1 per Sprint)
CoordinationMechanism: JIRA,
Meetings
Distance Type: Purpose:
Product Management: MethodologicalIslandProduct Management: MethodologicalIsland
Types: Team
Product Owner: RoleProduct Owner: Role
Name: Product Owner * Co-ordinates Between0* 2 * Co-ordinates Between 1 * Creates/Updates/Responsible * Creates/Updates/Responsible
Creates/Updates/
Responsible: Usage
Creates/Updates/
Responsible: Usage
Accessibility: High
Stability: Low (priorities change)
Criticality: HighFitforPurpose: High * * Drives* * Drives1 *1* Part of1 *1* Part of Fig. 3: Instance model of BOMI setup for User Stories for Company Athus a blank value for some of the object attributes. We consider how an instancemodel like this could be analyzed in the next section.
Although the process of creating a BOMI instance model is useful to understandBOs and MIs, one can go a step further and use the instance model createdto detect potential issues or “smells” in the BOMI configuration, similar to theidea of smells in models or source code [2, 22]. The idea is that these smells canbe detected and discussed, determining if there is an underlying problem. Thisanalysis and discussion would be conducted by those having a higher-level viewof an organization, e.g., team leaders, project managers. The overall aim is topromote potential beneficial changes in the BOs, MIs, and ways of working.We can detect these smells within a BO, or across relationships in the model.For example, we can detect smells within individual attributes: low modularity,high maintainability, not up to date, not internally consistent, or not externallyconsistent. We can also detect possible smells between attributes, including: hav-ing a high level of detail but a high frequency of change, meaning that frequentchanges may be difficult and involve changing many elements; and being in anearly lifecycle stage (planning) yet being very infrequently changed, or being ina later lifecycle change (deprecate, retire) yet having a high frequency of change.Similarly, with the
Usage association class, smells include not being fit forpurpose, or high criticality with low stability or low accessibility. For instance,in Fig. 3, usage of the BO by both the developer and product owner is critical
R. Wohlrab et al.
Table 2: Example smells in BOMI model instances with OCL expressions.
Type Description OCL Expression
WithinBO Low modularity context
BoundaryObj inv LowModularity: self.
Modularity = Low
Not internally consis-tent context
BoundaryObj inv InternalInconsistency:self.
InternalConsistency = Low
High level of detail andfrequent change context
BoundaryObj inv DetailedHighChange:self.
LevelofDetail = High and self.
FrequencyofChange = High
Later lifecycle and fre-quent change context
BoundaryObj inv LateHighChanges:(self.
LifecycleStage = Deprecate or self.
LifecycleStage = Retire ) and self.
FrequencyofChange = High
WithinUsage Not fit for purpose context Usage inv NotFit: self.
FitForPurpose = Low
High criticality and lowstability context Usage inv CriticalUnstable: self.
Criticality = High and self.
Stability = Low
MissingElements/Relation-ships No governance team context
BoundaryObj inv Governed: self.
Governed → size > BoundaryObj inv Responsible: self.
Responsible → size > BoundaryObj inv Updated: self.
Updates → size > BoundaryObj inv GovernsUses: self.
Governs → forAll(g | g. PartOf → select(r | r. Uses = self) → size > BoundaryObj inv GovernsUses:self.
FrequencyofChange = High and self.
Governs → select(g | g. FrequencyofCoordination = Low ) → size > but the stability is low. Is it acceptable for something so critical to change sofrequently? Looking into the BO, we see the lifecycle stage is planning, so theorganization may argue that high criticality and low stability is unavoidable forkey artifacts like user stories in this early stage. If the artifact was instead in anoperational stage, this situation may pose more of a problem.We can also detect smells at a broader level, e.g., the BO has no governanceteam, or no one responsible for it. Our company partners suggest that thosegoverning a BO should also use it, to ensure that they are aware of how the BOis used. It can also be checked whether there exists someone who can updateand delete the BO. And, if the Usage is critical, or if the frequency of change ishigh, the
Governs class should likely have a high frequency of coordination.We summarize how automatic checking of some of these smells could lookusing OCL expressions [5] in Table 2. In our case, eventual tool support shouldallow the model to be drawn without necessarily following these expressions,capturing reality with smells. These expressions could be checked after a firstversion of an instance model is created. The output of such a check should bediscussed within an organization, to determine if the smell is a problem in reality,and to discuss what sort of changes could be made. odeling and Analysis of Boundary Objects and Methodological Islands 9
The final step in our method was a 1.5-hour online workshop in April 2020to try out the metamodel, method, and smell ideas with seven representativesfrom four companies, described in Table 1. The participants included systemsengineers, requirements specialists, and tooling specialists. During the workshop,we reserved 20 minutes for a review of BOMI concepts and to introduce the newmetamodel using prepared material . We then split off into four virtual break-out rooms for 30 minutes of modeling instance models in focused sessions. Eachroom had at least one researcher and the representatives from one company. Theresearchers went through the guiding method questions from Sec. 3.2 and drewan instance model based on the answers of the participants, sharing their screen.Despite the short time-frame, we were able to get four relatively completemodels (e.g., Fig. 3), with the statistics in terms of element type used shownin Table 3. We opted to focus on one BO at a time; thus, each model had onlyone BO. The modelers were also able to capture 2-5 MIs, 1-5 Usage associationclasses, 1-4 Drivers, and one Government Team and Governs association classper model. Some of the attribute information for each model was filled in, butmany attributes were left blank due to time restrictions.The final 30 minutes (allowing for short breaks) was used to discuss our expe-riences and gain feedback, with several of the authors taking notes. The authorsthen met to share and review our notes, consolidating and discussing experiences.Feedback included that the current typing hierarchy for MIs was often hard toapply, and MIs are often multi-dimensional. To deal with this, we allowed MIs tohave more than one type in the updated metamodel. We also acknowledge thatour current list of possible types ( MIType in Fig. 2) may not be complete. Pre-viously, instead of the
Driver class, we had an Ocean association class between MI s with a driver attribute. We noted in our modeling exercises that MI s can havemany drivers and can share drivers. Thus, we reworked the Ocean associationclass to the current Drivers class. We also made note that most of the attributedescriptions were hard to capture with enumerations (High/Medium/Low) andthat we often needed free text descriptions to capture the subtleties, e.g., fre-quency of change varying depending on the lifecycle stage. Finally, we mademany small improvements to the class attributes. We used all of this feedbackto create the final version of the metamodel presented in Sec. 3. The previousthree versions of the model can be found in our online appendix .Table 3: Element count of four instance models from the workshop. Model BO MI Usage Driver Role Governance Team Governs
C1 1 2 2 1 2 1 1C2 1 3 1 1 5 1 1C3 1 5 5 4 0 1 1C4 1 3 1 2 2 1 10 R. Wohlrab et al.
Our modeling sessions did not give us extensive time to apply the smellanalysis examples as described in Sec. 3.4, and we were also hindered by theincompleteness of some of the instance model attributes. However, we presentedsome draft smells and asked for feedback from the participants. We generallyasked “Can the current issues with the BO be captured in the model?” Althoughthe participants were not opposed to automated checks as described in Sec. 3.4,they were more interested in human-centered manually-detected smells, e.g.,“Can I draw this?” For them, the first and most important smell is whether theparticipants had the knowledge to instantiate the metamodel. Our participantsalso suggested a smell having to do with the complexity of the overall model:“I can draw it, but it is a mess”, indicating that the overall design of theirBOMI situation could be overly complex and poorly thought-out. Therefore,model complexity checks or basic checks such as for cohesion and coupling maybe useful. Our participants also suggested the check that those responsible forgovernance should also be users, and that the governance team should consistof a diverse set of roles or islands, i.e., not just be made up by one type of user.Some of these smells could be expressed formally over the model, as in Sec. 3.4,but others can instead be included as points to consider in the methodology.Overall, our company partners were positive about the experience. Basedon their interest, we are currently arranging longer sessions for two out of fourcompanies, inviting further internal participants knowledgeable about key BOs.
A number of related conceptual modeling approaches have been proposed.
Knowledge Management.
Our work bears similarities to approaches thatfocus on modeling for knowledge management, e.g., [1,21]. Here the focus is oftenknowledge creation, distribution, representation, and retrieval. Our approachcaptures some of these elements in the BOMI metamodel, including the formatof the BO, its purpose, and users. However, our focus is less about capturingimplicit knowledge through a global strategy and more about understanding theway that diverse organizational islands coordinate knowledge through artifacts.Other related work uses patterns to detect potential problems in informa-tion flows, e.g., consecutive transformations, which are similar to our notion ofsmells [18]. Our focus is less on the flow of information but more on effectivecoordination, thus our specific smells are quite different compared to [18].
Agent-Orientation.
Our work bears some similarity to agent-oriented ormulti-agent system modeling which emphasizes the rational behavior of individ-ual agents in a system, e.g., [9,13]. Most of this work has an exchange of resourcesby agents through some form of dependency. Although agent concepts could beused to capture MI, the islands are more like social groupings emerging due tovarious drivers, and often do not act together as a sentient and autonomouswhole. Similarly, BO could be resource dependencies, but our concept of BO isricher, and we place more emphasis on the means of use and attributes of BO,compared to resources in agent-oriented modeling. odeling and Analysis of Boundary Objects and Methodological Islands 11
BOMI is in line with the Comakership organizational pattern [6], with ournotion of smells fitting with the idea of continuous improvement. However, thesepatterns focus on inter-organizational coordination, while BOMI covers inter-team coordination, and BOMI does not make use of i* or intentions, with at-tributes such as “Purpose” in the BO fulfilling this role to a lesser degree.
Communication.
Work in [17] introduces ontologies for collaboration, com-munication, and cooperation, with several elements and components echoed byour BOMI metamodel. However, their focus is not on supporting diverse groupsas with our MI, or on the attributes and specifics of the boundary objects orartifacts. Some of the work which has focused on modeling communication fo-cused on autonomous agents and their protocols, e.g., [7], while we focus oncommunication between MIs, always consisting of humans.
Coordination.
Related work on coordination modeling focuses on coordina-tion between information systems rather than human-oriented MIs [16]. In thisview, coordination between systems can be captured via APIs, a type of BO.Previously, benefits and limitations of languages for capturing APIs have beeninvestigated [12], e.g., i* and e value modeling. Although the focus lay more onthe use and value of APIs and less on coordination between methodologicallydiverse groups, BOMI may still be beneficial for API analysis.Further work is more process-oriented. [23] applies e value modeling, pro-cess modeling, and physical delivery modeling to support cross-organizationalcoordination. ActivityFlow focuses on supporting incremental and flexible work-flow definitions, allowing for workflow coordination between organizations [15].BOMI takes a static, rather than process-oriented view, as our partner compa-nies, with an agile mindset, focus less on workflows and more on practices. Ecosystems.
Work in ecosystem modeling is also related (e.g., [4, 28]), asour BOMI approach can be said to produce a type of ecosystem model; how-ever, existing ecosystem models focus more on external coordination, where theinternal methodologies of a partner are more opaque. Our BOMI models tend tohave a mix of internal and external MIs and BOs, often with a particular focuson supporting diversity in internal ways of working.
We have presented a conceptual model for BOMI, described how we instantiatedit together with four large-scale systems development companies, and derivedexample smells over the instances that can be checked with OCL constraints.Concretely, we have found that the BOMI model allowed us to create initialmodels with a rather low time effort (20 minutes of introduction of generalconcepts plus 30 minutes of modeling). Our participants were positive aboutthe outcome of the session and the initial models allowed us to test our list ofinitial smells. We believe that the described findings are a good starting point toevaluate and tailor the BOMI metamodel further. For instance, tooling, access,and security information could be added to the model, e.g., to facilitate securityanalysis concerning boundary objects.
In this paper, we focused on BOMI-specific smells. General UML smells,e.g., related to the use of names, attributes, or “data clumps” [2], might also beapplicable to BOMI models, and are an interesting area for future work.Moreover, we propose to investigate the creation and use of an expressivedomain-specific visual language and tool support to capture BOMI models. Cur-rently, we rely on UML class diagrams due to the availability of general modelingtools and the existing familiarity with class diagrams. However, there might bestakeholders (e.g., project managers, sales representatives) that are not familiarwith class diagrams and could benefit from a domain-specific language.Finally, we plan to build on these findings to help companies proactivelyaddress coordination issues and facilitate the management of boundary objectsin practice. Concretely, we aim to conceive a constructive method to continu-ously analyze the current situation with key stakeholders, propose actions forimprovement, and mechanisms to assess the impact of implemented changes.
Threats to Validity.
To improve internal validity/credibility , we used aninteractive modeling process with open questions, triangulated the experiencesof the participating companies, and aimed to provide detailed descriptions in thispaper. A cross-company workshop was used to present the intermediate findingsand perform member checking with the participants.A threat to construct validity relates to the nature of the domain we model.The concepts of boundary objects and methodological islands can be misunder-stood and interpreted in various ways. We intended to provide clear definitionsand engaged in a long-term project with the participating companies to ensurea common understanding of the concepts.Considering external validity , we used a sample of four large-scale companiesthat develop embedded systems. We believe this sample provides valuable in-sights, but acknowledge we may have different findings with a different samplingapproach. We describe the companies’ characteristics in this paper to facilitatethe assessment of what findings might be transferable to other contexts.With respect to reliability , the previously acquired knowledge of the partici-pating companies in the project is a potential threat. As stated before, we havepreviously collaborated on boundary objects and methodological islands, whichwill not be the case for other researchers or research contexts. However, the gen-eral notation used in this paper is rather straight-forward and comprehensiblefor other modelers, which facilitates replication. Moreover, we have made theexplanatory material and models available online.
In this paper, we have focused on the challenge of inter-team coordination andknowledge management in large-scale systems development using diverse devel-opment practices. While initial empirical studies existed, there has been a lackof systematic modeling approaches that can support practitioners in modelingtheir current and diverse coordination settings, and analyzing them to identifyissues. To address this issue, we proposed a conceptual model that can be usedto model methodological islands (i.e., groups that work with a different method- odeling and Analysis of Boundary Objects and Methodological Islands 13 ology than their surrounding organization) and boundary objects between them(i.e., artifacts that can be used to create a common understanding across sitesand support inter-team coordination). We presented an initial list of bad smellsthat can be leveraged to detect issues and devise suitable strategies for inter-teamcoordination in large-scale development. We evaluated the conceptual model to-gether with four large industrial companies developing complex systems andpresent our positive evaluation results.We plan to build onto these findings to devise a constructive method support-ing the analysis of coordination issues and suggesting improvement strategies,as well as mechanisms to continuously assess the effect of these strategies.
Acknowledgments.
This work was partially supported by the SoftwareCenter Project 27 on Requirements Engineering for Large-Scale Agile SystemDevelopment and the Wallenberg AI, Autonomous Systems and Software Pro-gram (WASP) funded by the Knut and Alice Wallenberg Foundation.
References
1. Ale, M.A., Toledo, C.M., Chiotti, O., Galli, M.R.: A conceptual model and tech-nological support for organizational knowledge management. Science of ComputerProgramming , 73–92 (2014). https://doi.org/10.1016/j.scico.2013.12.0122. Arendt, T., Taentzer, G.: UML model smells and model refactorings in early soft-ware development phases. Results of the SPES 2020 Project, AP4, UniversitätMarburg (2010)3. Bjarnason, E., Sharp, H.: The role of distances in requirements com-munication: a case study. Requirements Engineering (1), 1–26 (2017).https://doi.org/10.1007/s00766-015-0233-34. Boucharas, V., Jansen, S., Brinkkemper, S.: Formalizing software ecosystem mod-eling. In: Proc. of the 1st Int. Workshop on Open Component Ecosystems. pp.41–50 (2009)5. Cabot, J., Gogolla, M.: Object constraint language (OCL): a definitive guide. In:Int. School on Formal Methods for the Design of Computer, Communication andSoftware Systems. pp. 58–90. Springer (2012)6. Colombo, E., Mylopoulos, J.: A multi-perspective framework for organizationalpatterns. In: Proc. of the Int. Conf. on Conceptual Modeling. pp. 451–467. Springer(2006)7. Dignum, F., Dietz, J., Verharen, E., Weigand, H.: Communication modeling-thelanguage/action perspective. In: Proc. of the 2nd Int. Workshop on CommunicationModeling (LAP 97) (1997)8. Dingsøyr, T., Moe, N.B., Faegri, T.E., Seim, E.A.: Exploring software developmentat the very large-scale: a revelatory case study and research agenda for agile methodadaptation. Empirical Software Engineering (2017)9. Gonçalves, E., Araujo, J., Castro, J.: iStar4RationalAgents: Modeling requirementsof multi-agent systems with rational agents. In: Proc. of the Int. Conf. on Concep-tual Modeling. pp. 558–566. Springer (2019)10. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in information systemsresearch. MIS Quarterly , 75–105 (2004). https://doi.org/10.2307/2514862511. Holmström, H., Fitzgerald, B., et al.: Agile practices reduce distance in globalsoftware development. Information Systems Management (3), 7–18 (2006)4 R. Wohlrab et al.12. Horkoff, J., Lindman, J., et al.: Modeling support for strategic API planning andanalysis. In: Proc. of the Int. Conf. of Software Business. pp. 10–26. Springer (2018)13. Jureta, I., Faulkner, S.: An agent-oriented meta-model for enterprise modelling.In: Proc. of the Int. Conf. on Conceptual Modeling. pp. 151–161. Springer (2005)14. Kasauli, R., Wohlrab, R., Knauss, E., Steghöfer, J.P., Horkoff, J., Maro, S.: Chart-ing coordination needs in large-scale agile organizations with boundary objects andmethodological islands. In: Proc. of the Int. Conf. on Software and System Process(ICSSP’20) (2020)15. Liu, L., Pu, C.: Activity flow: Towards incremental specification and flexible coor-dination of workflow activities. In: Proc. of the Int. Conf. on Conceptual Modeling.pp. 169–182. Springer (1997)16. Norrie, M.C., Wunderli, M.: Coordination system modelling. In: Proc. of theInt. Conf. on Conceptual Modeling. pp. 474–490. Springer (1994)17. Oliveira, F.F., Antunes, J.C., Guizzardi, R.S.: Towards a collaboration ontology.In: Proc. of the Brazilian Workshop on Ontologies and Metamodels for Softwareand Data Engineering. João Pessoa (2007)18. Schneider, K., Lübke, D.: Modeling and improving information flows in the devel-opment of large business applications. In: Software Architecture Knowledge Man-agement, pp. 175–197. Springer (2009)19. Sedano, T., Ralph, P., Péraire, C.: The product backlog. In: Proc. of the 41thInt. Conf. on Software Engineering (ICSE’19). pp. 200–211 (2019)20. Star, S.L., Griesemer, J.R.: Institutional ecology, ‘translations’ and boundary ob-jects: Amateurs and professionals in berkeley’s museum of vertebrate zoology, 1907-39. Social Studies of Science (3), 387–420 (1989)21. Strohmaier, M., Yu, E., Horkoff, J., Aranda, J., Easterbrook, S.: Analyzing knowl-edge transfer effectiveness–an agent-oriented modeling approach. In: Proc. of the40th Annual Hawaii Int. Conf. on System Sciences (HICSS’07). pp. 188b–188b.IEEE (2007)22. Van Emden, E., Moonen, L.: Java quality assurance by detecting code smells. In:Proc. of the Working Conf. on Reverse Engineering. pp. 97–106 (2002)23. Wieringa, R., Pijpers, V., Bodenstaff, L., Gordijn, J.: Value-driven coordinationprocess design using physical delivery models. In: Proc. of the Int. Conf. on Con-ceptual Modeling. pp. 216–231. Springer (2008)24. Wohlrab, R., Pelliccione, P., Knauss, E., Heldal, R.: On interfaces to support agilearchitecting in automotive: An exploratory case study. In: Proc. of the Int. Conf. onSoftware Architecture (ICSA). pp. 161–170 (2019)25. Wohlrab, R., Eliasson, U., Pelliccione, P., Heldal, R.: Improving the consistencyand usefulness of architecture descriptions: Guidelines for architects. In: Proc. ofthe Int. Conf. on Software Architecture (ICSA). pp. 151–160 (2019)26. Wohlrab, R., Knauss, E., Pelliccione, P.: Why and how to balance alignment anddiversity of requirements engineering practices in automotive. Journal of Systemsand Software , 110516 (2020)27. Wohlrab, R., Pelliccione, P., Knauss, E., Larsson, M.: Boundary objects and theiruse in agile systems engineering. Journal of Software: Evolution and Process (5)(2019)28. Yu, E., Deng, S.: Understanding software ecosystems: A strategic modeling ap-proach. In: Proc. of the 3rd Int. Workshop on Software Ecosystems. pp. 65–76(2011)29. Zaitsev, A., Tan, B., Gal, U.: Collaboration amidst volatility: The evolving natureof boundary objects in agile software development. Proc. of the European Conf. onInformation Systems24