“For every line of code that developers write, they reuse thousands of lines written by someone else. … Each component makes assumptions about the structure of the environment in which it is to operate. Most if not all of these assumptions are implicit, and many of them are in conflict with each other…virtually all of our serious problems can be traced back to places where these assumptions were in conflict” (Garlan, Allen et al., 1995)

Conference Motivation

The integration of computer software systems is a costly (Goodwin 2011) and time-consuming activity and failure has consequences beyond technology. A survey of organisations in 2006 reported that more than half declared that difficulties integrating software systems was an obstacle to expansion (CommServer, 2007). In 2012 a £1.6bn deal to merge two banks failed after two years in a large part because of problems integrating their computer software systems (BBCNews, 2012). Furthermore, the problem of software integration is a technical debt (Nanette et al. 2010) that acts as a constraint on the growth of an organisation because each new software system must somehow work with those already in operation. A new software system can be rejected because the project must bear an overhead that arises from the need to integrate with other software systems.

Computing is ubiquitous and software systems have been an integral part of business for decades. The popularity of technologies such as the Internet, XML (Goodwin, 2011) and SOAP (Dai, Liang et al., 2011) mean that data are regularly exchanged both within and between organizations.

The integration of software systems is not a new problem, so why is it then that software integration remains so problematic and failure continues to occur?

The problem of software integration is multi-faceted. The question of whether to undertake the integration of two software systems is not always a matter of choice on the part of an organisation. There are many reasons for such integration and the drivers come from a number of sources both within and outside an organisation (Dunbrack and Holland, 2008). There are benefits from the integration of software systems and these are not only technical in nature. Fonseca & Rodrigues (Fonseca and Rodrigues, 2011) observe that patients in a hospital will benefit from increased speed and accuracy of clinical decision-making if data is shared between hospital computer systems. There are also risks. Dai et al. (Dai et al., 2011) warn that because each group of software users has their own particular set of requirements, conflicts between these requirements introduce barriers to success.

The problem of software integration is multi-dimensional. We might think of the problem as:
• A problem of data concerned with structure (Goodwin, 2011) and exchange (Dunbrack and Holland, 2008)
• A problem of responsibilities concerned with function and location (Hohpe, 2012)
• A problem of organisation (Abdullah, Mamun et al., 2011) concerned with suppliers (JISC, 2007), software development teams (Silva and Loureiro, 2011) and power (Granlund, 2003)
• A problem of communication (Hohpe, 2012) concerned with standards (Goodwin, 2011) and assumptions (Garlan et al., 1995)
• A problem of cost concerned with best-in-breed (Goodwin 2011) and reuse (Garlan et al. 2009)
• A problem of security concerned with access (Dai et al. 2011) and trust (Frank 2012)

Furthermore, each dimension is not independent. A problem of organization, such as the use of a new software supplier can lead to problems of data, responsibility and communication. A problem of communication, such as the misinterpretation of an interface, or a problem of data, such as the misuse of a data structure, can lead to increase in the cost of software development. Consequently software integration is also a complex problem.

The problem of software integration is likely to continue for the foreseeable future (Garlan et al. 2009). The Internet presents a challenge because the number and variety of connections between software systems will increase. The data exchanged between software systems across the Internet is not under the control of a single group or organisation. Each exchange of data is subject to rules about data structure and data semantics that can change without notice.

Conference Objective

Evidently, software integration is an important activity but there are many such problems and failure is costly. Despite a legacy of projects over decades and the likelihood of continued if not increased connectivity between software systems in the future, there is little by way of a sound theory as to the cause of the problems of software integration and how we might address them.

On the surface the question of how to integrate two software systems appears to be a technical concern, one that involves addressing issues, such as how to exchange data (Hohpe 2012), and which software systems are responsible for which part of a business process. Furthermore, because we can build interfaces between software systems we might therefore believe that the problems of software integration have been solved. But those responsible for the design of a software system face a number of trade-offs. For example the decoupling of software components is one way to reduce assumptions, such as those about where code is executed and when it is executed (Hohpe 2012). However, decoupling introduces other problems because it leads to an increase in the number of connections and introduces issues of availability, responsiveness and synchronicity of changes (Hohpe 2012).

The objective of this conference is to work toward on understanding of these issues, the trade-offs and the problems of software integration and to explore strategies for dealing with them. We are interested to receive paper from researchers working in the field of software system integration.

We solicit both academic, research, and industrial contributions. We welcome technical papers presenting research and practical results, position papers addressing the pros and cons of specific proposals, such as those being discussed in the standard fora or in industry consortia, survey papers addressing the key problems and solutions on any of the above topics short papers on work in progress, and panel proposals.

Industrial presentations are not subject to the format and content constraints of regular submissions. We expect short and long presentations that express industrial position and status.

Tutorials on specific related topics and panels on challenging areas are encouraged.

The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas.

All topics and submission formats are open to both research and industry contributions.

FASSI 2022 conference tracks:

Hot research/industrial areas

Integration-centric design; Maintenance and (safe) evolution; Software quality assurance; Variability modeling; Empirical studies challenges in system integration; Effective live cloud migration; Big Data, Fast Data and Data Lake in system integration; Vulnerabilities in software product lines; Constraints for product lines; Integration via contract Interfaces; Interface-based similarity analysis in component-reuse; Component Interactions impact; Cyber-physical features in system integration; Reusable software strategies; Synchronizing software variants; Evolving software ecosystems; Component semantic similarity analysis; Security variability; Industrial lessons; Customer considerations on post-integration features

Process Integration

Software Dependency; Interfaces; System Integration; Tools and Techniques; Middleware; Communication and Protocols

Data Integration

Data Exchange; Security, Privacy and Trust; Data Modelling and Database Design; Transformation

Organizational Issues

Software Release Management; Software Migration; Third Party Software; Legacy Software; Software Testing; Software Architecture and Standards; Software Project Organization; Team, Organization and National issues

Management and Control

Software Project Management; Costs and Benefits; Software Risk Management; Ownership and Control; Impact Analysis; Stakeholder Analysis; Complexity; Change Management

Modelling & Understanding

Software Modelling; Expert Knowledge; Software Components; Software Understanding; Symptoms; Cause and Effect; Architectural Mismatch; Topology; Reverse Engineering; Multi-Paradigm Modelling; Abstraction; Motivation and Drivers; Assumptions, Awareness and Conflict; Model Transformation

Programming and Design

Software System Design; Software Development Lifecycle; Programming Languages and Concepts; Patterns; Reuse

Applications

Case Studies; Choices and Trade-offs; Lessons Learned