Software architecture at a large financial firm

ABSTRACT

System builders have historically used informal software architecture models to understand options, make choices, and communicate with others. Research into software architecture over the past fifteen years has indicated that more precise architecture models may be beneficial. At a large financial firm, we applied precise software architecture techniques on four software projects and this experience has revealed a number of practical issues. We made the following observations across the projects: 1) Architecture models can be used to bridge gaps between business requirements and technology, 2) A small collection of techniques and a detail knob are practical and useful in a variety of projects, 3) Architecture modeling techniques amplify the skills of the architects, 4) A model of domain concepts and relationships is helpful when building architecture models, and 5) It is difficult to know when to stop adding detail to your architecture model. We believe that these observations motivate future research and can help practitioners make software architecture more effective in practice.

References

1. Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley, 1998.
2. John Cheesman and John Daniels. UML Components: A Simple Process for Specifying Component-Based Software. Addison-Wesley, 2000.
3. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Stafford. Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2002.
4. Desmond F. D'Souza and Alan Cameron Wills. Objects, Components and Frameworks With UML: The Catalysis Approach. Addison-Wesley, 1998.
5. Why can't they create architecture models like "Developer X"?: an experience report. In ICSE '03: Proceedings of the 25th International Conference on Software Engineering, pages 548--552, 2003.
6. David Garlan, Robert T. Monroe, and David Wile. Acme: Architectural description of component-based systems. In Gary T. Leavens and Murali Sitaraman, editors, Foundations of Component-Based Systems, chapter 3, pages 47--67. Cambridge University Press, 2000.
7. Christine Hofmeister, Robert Nord, and Dilip Soni. Applied Software Architecture. Addison-Wesley, 2000.
8. Michael Jackson. Problem Frames: Analyzing and Structuring Software Development Problems. Addison-Wesley, 2000.
9. Rick Kazman, Mark Klein, and Paul Clements. ATAM: Method for architecture evaluation. Technical Report CMU/SEI-2000-TR-004, Carnegie Mellon University / Software Engineering Institute, 2000.
10. Jeff Kramer and Jeff Magee. Engineering distributed software: a structural discipline. In ESEC/FSE-13: Proceedings of the 10th European Software Engineering Conference and 13th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages 283--285, 2005.
11. Emmanuel Letier and Axel van Lamsweerde. Reasoning about partial goal satisfaction for requirements and design engineering. In SIGSOFT '04/FSE-12: Proceedings of the 12th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages 53--62, 2004.
12. Martin Ould. Business Processes - Modeling and Analysis for Re-engineering and Improvement. John Wiley and Sons, 1995.
13. Samuel Redwine, Jr. and William Riddle. Software technology maturation. In ICSE '85: Proceedings of the 8th International Conference on Software Engineering, pages 189--200, Los Alamitos, CA, USA, 1985.
14. Jim Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998.
15. Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, 1996.
16. Ian Sommerville. Software Engineering. Addison-Wesley, 7th edition, 2004.

Index Terms

• Software and its engineering

  • Software organization and properties

    • Software system structures

      • Software architectures