Architecture Consistency (AC) aims to align implemented systems with their intended architectures. Several AC approaches and tools have been proposed and empirically evaluated, suggesting favourable results. In this paper, we empirically examine the state of practice with respect to Architecture Consistency, through interviews with nineteen experienced software engineers. Our goal is to identify 1) any practises that the companies these architects work for, currently undertake to achieve AC; 2) any barriers to undertaking explicit AC approaches in these companies; 3) software development situations where practitioners perceive AC approaches would be useful, and 4) AC tool needs, as perceived by practitioners. We also assess current commercial AC tool offerings in terms of these perceived needs. The study reveals that many practitioners apply informal AC approaches as there are barriers for adopting more formal and explicit approaches. These barriers are: 1) Difficulty in quantifying architectural inconsistency effects, and thus justifying the allocation of resources to fix them to senior management, 2) The near invisibility of architectural inconsistency to customers, 3) Practitioners’ reluctance towards fixing architectural inconsistencies, and 4) Practitioners perception that huge effort is required to map the system to the architecture when using more formal AC approaches and tools. Practitioners still believe that AC would be useful in supporting several of the software development activities such as auditing, evolution and ensuring quality attributes. After reviewing several commercial tools, we posit that AC tool vendors need to work on their ability to support analysis of systems made up of different technologies, that AC tools need to enhance their capabilities with respect to artefacts such as services and meta-data, and to focus more on non-maintainability architectural concerns.

The article Architecture consistency: State of the practice, challenges and requirements, written by Nour Ali et al. was originally published electronically on the publisher’s internet portal on May 15, 2017 without open access. The original article has been corrected.

Twelve years ago a group of practitioners and researchers came together to try to solve problems relating specifically to Global Software Engineering (GSE) practice. This paper aims to assess whether the many hundreds of GSE research papers written over this period have had an impact on practice. We conducted semi-structured interviews with senior managers and project managers from ten companies, four of which are large multinationals (three in Fortune 100), four are medium sized enterprises, and two are small startups. GSE research is perceived as useful by industry with all participants stating that studying the subject would improve GSE performance, but all were unanimous in saying they did not read articles on GSE. Practitioners go to books, blogs, colleagues, forums, experience reports of 1-2 pages in length, or depend on their own experience to solve problems in GSE. Controversially, many didn't see GSE as separate from general project management. Practitioners don't want frameworks, they want patterns of context specific help. While dissemination techniques need to be improved, that is not sufficient. Experience-based advice is just as important.

IONA released the first full implementation of the CORBA standard in August 1992, and our first product, Orbix, has become the most successful object request broker, capturing almost 70-percent of this market. It has spawned many follow-on products from IONA and from partner companies. This development followed nearly ten years of research in the area of distributed object systems within Trinity College Dublin, centered on language support for developers of distributed systems.

Many object-oriented programming language implementations have been estcndcd to support persistence, dist,ribut,ion or atomicity by integrating the necessary a,dditional support, with t,he language's runt,ime library.We argue tha.t a better approach is to provide a. Generic Runtime library (the GRT) which imple-ments that part of the support which is independent.of any langua.ge.The GRT should be designed to interfa.ce to a langua.ge'sexisting runtime in such a way that the language's local object reference format and invocation mechanism can be retained.Hence exist.ingcompilers do not necessarily have to be modified, and a range of different object,-oriented languages can be supporkd simultaneously.This a.pproach 1la.s significant merits including: the ease with which a la.nguage ca.n be extended; the sophistication of the underlying support immediately available to a. la.nguage implementer; a.nd the ability to support fine-grain& language interworking.