=Paper=
{{Paper
|id=Vol-2248/paper2
|storemode=property
|title=Modeling Information Systems as Systems of Systems
|pdfUrl=https://ceur-ws.org/Vol-2248/paper2.pdf
|volume=Vol-2248
|authors=Paolo Salvaneschi
|dblpUrl=https://dblp.org/rec/conf/ciise/Salvaneschi18
}}
==Modeling Information Systems as Systems of Systems==
https://ceur-ws.org/Vol-2248/paper2.pdf
Modeling Information Systems
as Systems of Systems
Paolo Salvaneschi
University of Bergamo, Dep. of
Management, Information and
Production Engineering and
Salvaneschi & Partners
Bergamo, Italy
paolo.salvaneschi@unibg.it
Copyright © held by the author
Abstract—Large industrial information systems are In this paper, we describe an industrial experience where
composed of dozens of inter-operating software applications. we apply the concepts of SoS to the management of the
Each of them implements a relatively independent set of information system of a large retail company.
functions but also participates to business processes involving
more applications. Applications may be COTS acquired from The application of SoS concepts has been mainly in other
different vendors or custom-developed. The network of them areas [2] than industrial information systems, even if e-
evolves and grows in time. Many development groups/vendors commerce applications (part of the information system of our
manage the network. All these characteristics support the idea case study) are considered a typical example of SoS [3].
that large information systems may be interpreted as Systems of
Systems (SoS) and that this view may provide value to IT Section 2 discusses how information systems share the
managers. In the paper, we present an experience report of SoS characteristics of SoSs to be considered as SoSs. We contend
concepts application to the information system of a large retail that the SoS view may advance the state-of-the-art of
company. In this System of Systems, a critical problem is the information systems management.
absence of documents providing SoS views of the whole Section 3 presents the information system that is subject
information system: the set of applications, their relationships of the study.
and the impact of business processes on the network of
applications. To mitigate the problem, we developed a set of In section 4 we define the research question this work
models using the minimalist approach (the selection of the answers: how to develop and maintain a knowledge base of
minimal set of documents based on a cost/benefit analysis) and the most important aspects of the whole information system
the ArchiMate modeling standard and tools. A static view at the abstraction level of a SoS. To this aim, we developed a
(software applications and relations) and dynamic views model of the information system.
(business processes and their interaction with software
applications) model each business area. We discuss the current Sections 5 and 6 define the modeling technique and tool,
use and benefits of the models and the forecast improvements. exemplify the content of the model and discuss how the
model was developed.
Keywords—Information System, System of Systems, ADLs,
Archimate Section 7 describes how different stakeholders used and
get benefits of the model.
I. INTRODUCTION Section 8 concludes, discusses the scope of the industrial
Large industrial information systems are composed of experience and the possible improvements. Finally, Section 9
dozens of inter-operating software applications. The provides an overview of related work.
applications may be custom-developed or COTS components
acquired from the market and, if needed, adapted. Each II. INFORMATION SYSTEMS AS SOS
application delivers functions implementing a specific set of Information systems share the characteristics of SoSs ?
business activities, but the business processes flow through
more applications. The set of applications evolves and grows Nielsen [3] claims that a SoS is characterized by the
in time and usually different development groups or vendors following dimensions:
drive the evolution process, each working on parts of the ₋ Autonomy of constituents: a constituent system’s
whole system. behavior is governed by its own rules while also
We suggest that the application of concepts of Systems of participating in the SoS.
systems (SoS) may be useful to the management of such type ₋ Independence: the capacity of constituent systems to
of systems. operate when detached from the rest of the SoS.
Systems of systems are described as a collection of ₋ Distribution: constituent systems are dispersed so that
relatively independent but interconnected systems [1] where some form of connectivity enables communication or
a strong central control of evolution may not exist and the information sharing.
global behaviors (both desirable and undesirable) emerge
from the interaction between the composing systems. ₋ Evolution: SoSs are long lasting and subject to change,
whether in the functionality, the quality of that
functionality, or in the structure and composition of useful knowledge supporting global understanding of
constituent systems. applications relations and behaviors. This causes extra costs
in the specification phase of an evolution project due to the
₋ Dynamic Reconfiguration: the capacity of an SoS to effort required to collect knowledge from people and
undertake changes to its structure and composition, available documents. This also causes costs due to reworks
typically without planned intervention. caused by the delivery of changes not completely and
₋ Emergence of Behavior: emergence refers to the correctly analyzed during the specification phase.
behaviors that arise as a result of the interaction of The above considerations show that large industrial
constituents. information systems may share a large part of the properties
₋ Inter-dependence: refers to the mutual dependency that stated by Nielsen [3] for SoSs.
arises from the constituent systems having to rely on We support the idea that a SoS view of industrial
each other in order to fulfill the common goal of the information systems has value for the information systems
SoS. managers, business analysts, architects, developers and
₋ Inter-operability: refers to the ability of the SoS to testers. Therefore, is not enough to apply software
incorporate a range of heterogeneous constituent engineering concepts, practices and tools to single
systems. applications and systems. We need to apply an engineering
approach at the larger scale of the whole information system
A large information system is composed of many as a System of Systems.
software applications (custom, COTS, adapted). We may
interpret each application as a “component” of a system In the following case study, we apply these ideas to a
architecture (according to the paradigm of components and specific information system.
connectors description of a software architecture) at a larger The case study deals with the problem of maintaining a
scale than the architecture of a single application. Various documented knowledge of the information system at the SoS
servers host the applications and the information system may level of abstraction. At this level, the system is viewed as a
cooperate with others information systems (for instance network of software applications and systems and business
suppliers and clients). All these servers are typically processes emerge because of relations between these
geographically distributed (Distribution). systems.
From the functional point of view, applications are The aim of the study is not only to present a specific case
relatively independent functional entities (Autonomy of but also to show how this approach may improve the
constituents and Independence) but inter-operate with other management practice of information systems.
relatively independent applications (Inter-dependence and
Inter-operability). Business processes may be orthogonal to Lack of documented knowledge is a common practice in
many software applications. Each software application may information systems, but the problem is typically considered
implement a set of functions and share part of them with at the level of single applications or projects [5].
various business processes.
We show that this knowledge level does not consider
Information systems are subject to an evolutionary critical aspects that are arising from the complexities of
process (Evolution). Evolution projects (for example the modern information systems. Therefore, the explicit
evolution required by a change in a business process or a consideration and modeling of the SoS level mitigate critical
new process) may involve many applications. In this case, problems of information system evolution and may advance
the specification and design documents of the project define the state-of-the-art of information systems management.
a set of local changes generating a global desired behavior
(Emergence of desired behaviors). Consequently, designing III. CASE STUDY
and implementing changes require the understanding of
many existing applications and their relations. The The case study concerns the information system of a
evolutionary process, composed by a sequence of local large Italian retail company. The company manages about
changes, may also produce global undesired changes like the 100 physical stores and an e-commerce store. The
“architectural erosion” [4] or undesired behaviors (another information system is composed of about 70 applications and
type of Emergence). 2 large databases. About one-half of applications is custom-
developed (about 1.500.000 LOC of Java-JSP and RPG
If we consider the management aspect, projects may code). Software products acquired from vendors and
involve more development teams or COTS providers. adapted/integrated compose the remaining half.
Projects run concurrently and are managed in a relatively
independent way. Each project team follows a “local Examples of the constituent software
optimum” goal with limited interactions with the remaining applications/systems: selling in a physical store, manage e-
parts of the system not included in the project. Therefore, it commerce orders, transport management, warehouse
is difficult for the IT management to have a global control of management.
evolution. During the years, the amount of COTS/adapted
From a cognitive point of view, each development team applications increased and the global landscape of the
or provider has a local knowledge related to a subset of architecture moved from a shape similar to repository-style
applications. Consequently, none of the teams has a (databases and a cloud of applications working on the
reasonably complete knowledge of the whole information databases) to a shape more similar to a network.
system. Even if the specification and design documentation Consequently, the number of business processes
of each application is of sufficient quality, it does not offer a involving more applications and the number of projects with
more than one development team or vendor increased. (for example porting an application on a new software
During the last year, out of 54 evolutionary projects, 21 were infrastructure requires the understanding of the interacting
composed of more than two different organizations, with the applications) or the design of the architectural solution to
maximum of 7. implement a business process change.
This evolutionary process increased the problems caused The development team will use the model to understand the
by the lack of a global view of the information system (a SoS high-level view of structure and behaviors of the systems to
view). Projects requiring the implementation or change of modify. The testing team will also use the model to
business processes need the cooperation of different teams. implement the testing scenarios.
Each development/vendor team has a local knowledge (a
specific application or a limited set of applications), but is V. THE MODEL
difficult for each team to have a deep understanding of the
interactions implementing the business processes. Business In this section, we describe the characteristics of the
process analysts have difficulties to specify the required implemented model.
changes, because the global model of business processes and
their interaction with the information system components is A. Minimalist documentation
fragmented into many documents and oral tradition. Testers IT organization developed the documentation system
have the same problems. using a minimalist approach [6] and the method defined in
The IT organization established an “Architecture office” our previous work [8]. The method select a minimal set of
whose aim is to develop feasibility studies, design the documents that can support the information system actors
changes and deliver architectural and technical standards for during the evolution process.
each development team or vendor. This office too needs a The basic idea of the minimalist documentation is that
global view of the information system. knowledge is a property emerging from a system where
The management of the information system evaluated people and documents interact. Documents do not require
that the priority to mitigate these problems was the being “complete” (rich of details in each part), it is sufficient
availability of documented knowledge concerning the set of that they be “good enough” [7]. For example, developers use
applications, their relationships and the impact of business an architectural document as a “landscape” for understanding
processes on the network of software applications (a model where to read the details in the code.
of the whole information system at SoS level). The aim is During the evolution phase, we must update each
that the organizations running the projects will share this document and this need generates a cost. Even the lack of a
knowledge and the different stakeholders involved in the document may generate a cost: the effort of software
information system evolution will use it as reference. understanding during the evolution. A minimal set is a set of
documents showing the most efficient cost-benefit ratio of
IV. THE GOAL the maintenance cost of the documents and the costs that can
The information system maintains a wiki-based be generated if the documents are not available. Details of
documentation system storing the most important knowledge the cost-benefit selection rules may be found in [8].
for each application and the data models, but the Therefore, we select and maintain only this set of documents
documentation models each application as a relatively during the evolution.
independent system and the interaction with other systems is For example, an architectural model (a document with a
limited to definition of interfaces. low number of pages) has a limited cost of maintenance
We focused our work to add a new layer of (measured in number of pages) whereas the lack of this
documentation based on a model of the most important model may generate a high cost required to extract the
aspects of the whole information systems architecture at the architectural knowledge from code. Consequently, we should
abstraction level of SoS. maintain this document during the evolution.
The model will support each project with global views of On the contrary, for example, a detailed specification of
the whole set of components and behaviors implementing the interactive screens (many pages) has a high cost of
information system. maintenance whereas his absence generates a low cost (the
programmer may understand the specification observing the
Different group of users can benefit of it: behaviors of the implemented software product). Therefore,
₋ Business process analysts we should not maintain this document during the evolution.
₋ Information system architects To select the SoS models, we followed the same
minimalist approach used for the existing documentation.
₋ Development teams
The selection was decided during the meetings with
₋ Testers people of the “Architecture office”. They decided that the
most important documents at SoS level (using the
Business process analysts and information system architects
cost/benefit criteria previously considered) were the SoS
will use the model to understand the existing business
architecture and the relation between the main business
processes and their implementation in the various systems
processes and the architecture. They judged the cost of
composing the whole information system. The model will
developing and maintaining these documents significantly
support the feasibility studies to evaluate the effort required
less than the costs caused by the need to recover the
for implementing a new or changed business process. It will
necessary knowledge and the extra costs caused by poor
also support the impact assessment of technological changes
knowledge during each evolution projects.
The first step was to list the more important business ₋ A static model describing the software applications used
areas. Examples of business areas are: inside the business area (components) and the relations
between the applications (connectors). The modeled
₋ Selling in the physical store; relations are data flows between components (only the
₋ Selling in the e-commerce store; flows of the specific business area).
₋ Supply chain; ₋ Dynamic models describing how the set of components
and connectors implement the main business processes
₋ Manage product data and prices. of the area (activities of components and flows of data
For each business area, we developed: between activities).
Fig. 1. Static model of the business area “Selling in the e-commerce store”
Fig. 2. Static model of the business area “Selling in the e-commerce store” - detail
For example, fig 1 shows the static model of the business management system, 3 ‒ warehouse management system and
area “Selling in the e-commerce store”. Boxes are software 4 ‒ operational database) collaborate exchanging the data
applications (components) and arrows are connectors. The flows described by oriented arcs. The remaining two systems
label of each connector is the name of the data flow. The (5 ‒ technical assistance for the sold products and 6 ‒ courier
business area includes 28 software applications. 13 of them service) are part of other information systems.
(boxes with white background) are external to the
organization. Each system is a relatively independent component and
has its own functions and role in the organization, but the e-
Fig 2 shows a detail of the model. In this fragment, four commerce business processes emerge from the interaction of
systems (1 ‒ order management system, 2 ‒ transport the constituent systems.
Fig. 3. Dynamic model: “Buy with the e_commerce site, pick and pay in the physical store”
Fig. 4. Dynamic model: “Buy with the e_commerce site, pick and pay in the physical store” - detail
During the evolution, both the functions of single abstraction but is “good enough” to help people
systems and the business processes emerging from the understanding the business process.
interaction of more systems may evolve.
For this static model, we developed 41 dynamic models B. Tool
describing the most important business processes We implemented the model with the tool Archi [10]. The
implemented by part of components and connectors of the tool allows defining a database of model elements (for
static model. example components and relations) and apply different
Figure 3 and 4 show one of the dynamic models “Buy in views to the database. Fig 5 is the global static view. This
the e_commerce site, pick and pay in the physical store” and view includes all the components of the different business
a detail of the model. The model represents one of the areas with their data flows. We may query and navigate the
behaviors emerging from the interaction among the set of model to explore the model elements, relations and attributes
constituent systems of the SoS. Considering all the (name-value pairs) associated to them.
application of fig.1, eleven of them cooperates for this
business process. VI. MODEL DEVELOPMENT
Each swim lane is associated to the component on top of We developed the model with the “Architecture office”,
the diagram (a subset of the static model). Rounded boxes a team of three people, the most experienced professionals of
describe activities of the business process. Some activities the information system with the widest available knowledge
are labeled with the activity content, while some others are on the existing systems and business processes. The
not specifically identified. Labelled arrows are data flows. development also involved three experienced people of the
Additional icons add information about the control flow (for testing team that accumulated, during the testing projects, a
example interactive activity ‒ the “OP” icon or periodically significant knowledge of systems and business processes.
scheduled ‒ the “T” icon). The model describes a partial Another important source of knowledge was the
ordering (from top to bottom, from left to right) of the documentation system that maintains the basic knowledge
application data flows. The ordering is partial due to the icon for each application composing the information system. This
“T” that identifies a timed schedule with the time constraint was specifically useful to define the interfaces of each
not defined by the model. According to the minimalist application.
approach the model is not complete at a defined level of
Fig. 5. Static view of the whole information system
The development required about 60 days distributed in Were these models enough to represent the studied
a period of about six months. SoS?
A significant problem we found during the The static and dynamic models were judged, during the
construction of models was that, due to the fragmentation development phase, the priority knowledge of the SoS.
of knowledge, even the architecture office people and the
testers had problems in defining precisely all the business Obviously, the idea of maintaining only a minimal set
processes and the interactions between systems. of documents has its own assumptions and limitations.
Consequently, in many cases, we designed a draft of the These limitations come from the decision to select the
model and verified/improved it with the help of project modeled knowledge according to cost-benefit criteria and
leaders knowing specific parts of the information system. reduce the maintenance effort of the model during the SoS
Therefore, the development required many review cycles evolution.
to verify and refine the models. For example, static models only define data flows and
The result was a body of knowledge previously not lack of views for technical information (the
available. No single development team or expert had these implementation views of connectors). Consequently, for
example, the model does not provide the information if a
integrated views of applications and business processes.
flow of data is implemented by a simple invocation with
parameters or the execution of a complex publish-
VII. LESSONS LEARNED subscribe pattern delivered by the enterprise bus.
Are there real evidences that the models delivered
significant benefits to the management of the information VIII. CONCLUSION
system?
In the paper, we presented the development of models
The model in now used by the “Architecture office” for of an information system based on the view of Systems of
the feasibility studies. The office interacts with business Systems. In our experience, this type of models showed
people requiring business processes changes, new significant benefits for the management of the information
functionalities or new processes. system evolution.
The model allows the understanding of the existing We developed the first version of the model with a
business processes and the implementation of them into the limited cost and we estimate that the periodical updating of
systems and is the basis to design the changes and evaluate the model will require relatively moderate costs.
the impact. A more detailed knowledge related to each
system may be found in the pre-existing documentation On the contrary, we estimate that the availability of the
system. model saved significant extra costs of many projects due to
the lack of this knowledge.
Previously, the analysis required a costly and risky
work of collecting fragments of knowledge from different Furthermore, a significant question is the scope of our
people to reconstruct the set of involved systems and their experience. We studied a single information system of a
interactions. specific industrial sector. Beside direct experience, we base
our confidence that the presented results can generalize to
The development teams had benefit of the model. It is other information systems on the following considerations.
now the basic documentation to understand the systems
and the required changes. The IT organization also used The experience concerns a large information system
the model for training new development teams (for that is representative of many others. It includes many
example in the e-commerce business area). The inclusion software applications, large databases and a growing set of
in complex projects of a new working group was difficult. COTS-based components. In this context is usual the
New people slowly accumulated a more global knowledge cooperation of different teams internal to the IT
from the experience of implementing changes of SoS parts. organization, outsourced to external software houses or
Now a new team is trained through the explanation and coming from product vendors.
discussion of the SoS models. This decision mitigated the The difficulty of maintaining a useful documentation of
difficulties, increased the new team’s efficiency and the information system and the knowledge fragmentation
reduced the risk of code defects caused by poor knowledge is a widespread and recognized problem by the IT
of the whole context. managers. Consequently, the SoS-based explicit
The testing team also used the process models. For knowledge we presented may mitigate a common problem
example, the models of the business area “Selling in the e- in industrial information systems.
commerce store” were the reference to develop a set of Furthermore, we think that the real problem for a
about 100 automatic non-regression scenario-based tests. widespread use of these approaches based on the SoS point
A set of test cases verifies each modeled process (the test of view is not the cost. The cost of developing and
procedures run each of the 41 dynamic models with some maintaining the models is low if compared to the extra
variations of input data). Each test case follows the process costs caused by the lack of this knowledge (costs of
through all the involved systems, from an initial set of understanding the existing software, costs caused by poor
input data (for instance an order from a customer) to the quality of the developed solutions and need of reworking).
complete interaction (and intermediate verifications) with The key point is the management culture and the need to
all the systems. introduce more mature management approaches based on
sound software engineering practices and cost/benefit through leveraging of information technology systems has
evaluations. been early recognized [16]. In spite of that, as far as we
know, the application in the context of industrial
A future improvement could be the use of models and information system is not a common practice.
tool to control the growing complexity of the information
system structure. One of the aims of the architecture office What is significant in our experience report is not the
is to publish the design rules of the information system use of novel concepts, methods or tools, but the example of
architecture and to enforce their adoption. Therefore, the application of SoS to a field that can strongly benefit. Our
office can use the models and the tool to control the experience report is specific, but the structure of the
architectural erosion during the evolution process. information system and the management problems coming
from the complexities of many interacting and relatively
For example, we can navigate the structural models to independent software applications are common to many IT
measure the coupling between components. We also may departments of other industrial sectors.
add technical attributes to the data flow oriented arcs. A
useful information may be the type of connectors. This can
allow controlling the design rules for the choice of REFERENCES
connectors, discovering violations and refactoring the [1] J. Boardman and B. Sauser, “System of systems - the meaning of
architecture. of”. In Proceedings of IEEE/SMC Int. Conf. on System of Systems
Engineering, pp. 118-123, 2006.
Clearly, this is not an easy task. If we examine figure 5, [2] I. G. Vargas, T. Gottardi, and R. T. Vaccare Braga, “Approaches
in this architecture, even if the local systems are carefully for integration in system of systems: a systematic review”.
designed, the resulting SoS does not support none of the In Proceedings of the 4th International Workshop on Software
basic good design principles (for example cohesion and Engineering for Systems-of-Systems (SESoS '16). ACM, pp. 32-
38, 2016.
coupling rules) we teach in university courses of software
[3] C. B. Nielsen, P. G. Larsen, J. Fitzgerald, J. Woodcock, J. Peleska,
engineering. “Systems of Systems Engineering: Basic Concepts, Model-Based
Techniques, and Research Directions”. In ACM Comput. Surv. 48,
IX. RELATED WORK 2, pp. 1-41, 2015.
[4] B. Merkle, “Stop the software architecture erosion”. In Proceedings
Software engineering architectures developed a rich set of the ACM International Conference Companion on Object
of concepts, practices and tools [11]. SoS research Oriented Programming Systems Languages and Applications
extended these concepts to environments where the Companion, OOPSLA ’10, ACM, pp 295–297, 2010.
delivered functionalities and processes result from the [5] D. Oprea, G. Mesnita, The Information Systems Documentation -
composition and interaction of many relatively Another Problem for Project Management. Managing Information
in the Digital Economy: Issues and Solutions. In Proceedings of the
independent systems [12]. 6th Ibima Conf., Khalid S. Soliman, ed., pp. 332-338, IBIMA, 2006
In software intensive SoSs, that is SoSs in which [6] J. M. Carroll, “The Nurnberg Funnel: Designing Minimalist
software plays an essential role in design, development, Instruction for Practical Computer Skill”. MIT Press, Cambridge,
MA, USA, 1990.
and evolution, it is recognized that an adequate
[7] A. Rüping, “Agile Documentation - A Pattern Guide to Producing
representation of SoS software architectures is important Lightweight Documents for Software Projects”, John Wiley &
[12]. In this context, different architecture description Sons, 2003.
languages (ADLs) have been proposed like UML or [8] P. Salvaneschi, “The evolution of Information Systems a case
SysML [13]. The definition of the most suitable ADLs for study on document management”. In Proceedings of IEEE 27th
SoS is still a research subject [12]. International Conference on Software Maintenance, ICSM,
Williamsburg, VA, USA, pp 428 - 437, 2011.
In the area of enterprise information systems [9] ArchiMate® 2.1 Specification 2012-2013 The Open Group.
architectural frameworks, as for example TOGAF [14], http://www.opengroup.org.
were developed enterprise models considering various [10] https://www.archimatetool.com/
aspects of the enterprise: business functions and processes, [11] P. Kruchten, H. Obbink and J. Stafford, “The Past, Present, and
data, software applications and the underlying technical Future for Software Architecture”, IEEE Software, Vol. 23, Issue
infrastructure. Archimate [9] is a standard modeling 2, pp. 22-30 , March-April 2006.
language to support the description, analysis and [12] F. Oquendo, “Software Architecture Challenges and Emerging
visualization of enterprise architectures, taking into Research in Software-Intensive Systems-of-Systems”, Proceedings
of Software Architecture 10th European Conference, ECSA, pp. 3-
account multiple aspects of architectural frameworks. In 21, 2016.
our industrial application, we used this modeling language [13] M. Guessi, E. Cavalcante, L. B. R. Oliveira, “Characterizing
to apply the concepts of SoS to the considered information Architecture Description Languages for Software-Intensive
system. The reason of the choice was that the language is a Systems-of-Systems”. In Proceedings of IEEE/ACM 3rd
recognised standard in the information systems community International Workshop on Software Engineering for Systems-of-
and has expressive power to model different aspects like Systems SESoS '15, pp 12-18 2015.
business processes and software architectures. These [14] TOGAF® Version 9.1, http://www.opengroup.org
aspects are important for the different users of the models: [15] FP7 CSA Road2SoS (Roadmaps to Systems-of-Systems
Engineering): Survey on Industrial Needs and Benefits of SoS in
business analysts, information systems analysts, architects, Different SoS Domains: Multi-site Industrial Production
developers and testers. Manufacturing, Multi-modal Traffic Control, Emergency and Crisis
Management, Distributed Energy Generation and Smart Grids.
Application of SoS, originally identified in the defense http://road2sos-project.eu/
environment, is now much broader and still expanding [16] P.G. Carlock, R.E. Fenton, “System-of-Systems (SoS) Enterprise
[15]. The relevance of SoS concepts for any organization, Systems for Information-Intensive Organizations,” Systems
public or private, seeking to attain competitive advantage Engineering, Vol. 4, No. 4, pp. 242-261, 2001