ACM Computing Surveys (CSUR)
Using style to understand descriptions of software architecture
SIGSOFT '93 Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering
Design patterns: elements of reusable object-oriented software
Design patterns: elements of reusable object-oriented software
The mythical man-month (anniversary ed.)
The mythical man-month (anniversary ed.)
Software reuse: a holistic approach
Software reuse: a holistic approach
Pattern-oriented software architecture: a system of patterns
Pattern-oriented software architecture: a system of patterns
Frameworks = (components + patterns)
Communications of the ACM
Enterprise frameworks characteristics, criteria, and challenges
Communications of the ACM
Building systems from commerical components
Building systems from commerical components
Managing software acquisition: open systems and COTS products
Managing software acquisition: open systems and COTS products
Component Software: Beyond Object-Oriented Programming
Component Software: Beyond Object-Oriented Programming
Building Reliable Component-Based Software Systems
Building Reliable Component-Based Software Systems
Enterprise Application Integration: A Wiley Tech Brief
Enterprise Application Integration: A Wiley Tech Brief
Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects
Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects
Architectural Mismatch: Why Reuse Is So Hard
IEEE Software
Architectural Mismatch: Why Reuse Is So Hard
IEEE Software
Software Architecture in Practice
Software Architecture in Practice
Process Patterns for Software Systems In-house Integration and Merge Experiences from Industry
EUROMICRO '05 Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications
Process Patterns for Software Systems In-house Integration and Merge Experiences from Industry
EUROMICRO '05 Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications
Software systems in-house integration: Architecture, process practices, and strategy selection
Information and Software Technology
Hi-index | 0.00 |
When organizations cooperate closely, for example after a company merger, there is typically a need to integrate their in-house developed software into one coherent system, preferably by reusing from all of the existing systems. The parts that can be reused may be arbitrarily small or large, ranging from code snippets to large self-containing components. Not only implementations can be reused however; sometimes it may be more appropriate to only reuse experiences in the form of architectural solutions and requirements. In order to investigate the circumstances under which different types of reuse are appropriate, we have performed a multiple case study, consisting of nine cases. Our conclusions are, summarized: reuse of components from one system requires reuse of architectural solutions from the same system; merge of architectural solutions cannot occur unless the solutions already are similar, or if some solutions from one are incorporated into the other. In addition, by hierarchically decomposing the systems we make the same observations. Finally, among the cases we find more architectural similarities than might had been expected, due to common domain standards and common solutions within a domain. Although these observations, when presented, should not be surprising, our experiences from the cases show that in practice organizations have failed to recognize when the necessary prerequisites for reuse have not been present.