Software Architecture

Discussion

• How does software architecture differ from software design?

  Architecture is about high-level abstractions whereas design is about low-level implementation details. Architecture helps us understand the system and how it's supposed to interact with its environment. It involves multiple stakeholders, presents an overall vision that meets quality attributes, and makes a clear separation of concerns. Software architects make choices and give reasons why those choices were made. Typically these choices are made early on in the project and are costly to change thereafter.

  In contrast, software design concerns itself with class methods/properties, data structures, algorithms, actual code, business logic, etc. Certain design methods play well with certain architectural styles.

  It's not easy to define what's high-level or important. They're very much contextual. Whatever these are, a good architect identifies them early on. Architecture is about reducing irreversibility: an architect defines what parts are fixed, what parts can be changed and attempts to minimize the former. Architecture is really a shared understanding of the system design.

  It's been said that "architecture is design but not all design is architectural". Dashofy defined,

  A software system's architecture is the set of principal design decisions made about the system.

• Could you give examples of software architecture?

  

  Pipeline architecture for a compiler (left) and client-server architecture for an information system (right). Source: Hasselbring 2018, fig. 1.

  For a web application, an architect may define the main components: frontend, backend, storage, notifications, etc. She may decide to use Java, MySQL and Hibernate ORM. She may adopt the MVC pattern, or server-side rendering over client-side rendering. She may identify high-level components such as authentication, load balancer and CDN. She may even prescribe Eclipse IDE along with plugins Checkstyle, SonarLint and TestNG.

  For an application server, we may use Java-EE. Functionality is spread across access layer, application processes layer and domain objects layer. Java-EE thus uses layered architecture. An alternative is the service-oriented architecture (SOA). This consists of a service bus to which producers and consumers connect via adapters. While Java-EE focuses on scalability and reliability, SOA focuses on integrability and modifiability.

  While there are API architects, in some projects the solution architect mandates an API gateway and developers detail the APIs. In a team of inexperienced developers, the architect may take on more design-specific tasks.

• What are the key benefits of software architecture?

  

  Architecture yields long-term benefits. Source: Fowler 2019b.

  Creating a good architecture leads to right trade-offs, meeting requirements, reducing risks, and timely deliverables. Skipping architecture may save time towards short-term success. In the long term, rework and delays are quite likely. Poor architecture leads to technical debt, more defects and software that's harder to evolve.

  We often pay more for higher quality products. However, architecture doesn't exercise this quality-cost trade-off. Investing in architecture pays off within a few weeks. Without a proper architecture, we end up paying more later. Software that works as expected has external quality. Architecture is really internal quality that project teams should care about.

  Architecture helps maintain conceptual integrity of the system as it evolves. An architectural model is a living record of original decisions. As new features are added, such a model mitigates architectural drift. Architecture aids knowledge reuse and avoids "reinventing the wheel".

  Architecture can help modernize legacy systems such as migrating to the cloud or integrating AI/ML capabilities. Existing technical debt can be addressed or managed.

• What are some patterns and frameworks in software architecture?

  

  Some architectural styles. Source: Sharma et al. 2015, table 1.

  For common problems, there's no need to solve them from scratch. Architectural patterns can be adopted: client-server, peer-to-peer, event-driven, layered (n-tiered), space-based, service-oriented, microservices, serverless, cloud-native, microkernel, and many more.

  Ford and Richards have analysed and compared some of these patterns with respect to quality attributes. They published these as Architecture Styles Worksheet. For example, a microservices architecture rate higher on agility and fault-tolerance compared to layered architecture. But layered architecture is simpler and cheaper.

  Frameworks bridge concepts to coding blocks. As part of ISO/IEC/IEEE 42010:2011 work, ISO has been collating various architecture frameworks. There are frameworks for IoT, Big Data, security, management systems, communication systems, for the automotive industry, smart grids, and more. Indeed, domain-specific reference architectures are used in many industries. These lead to reusing architectures across products of a product line or family.

• What artefacts does a software architect produce?

  Architecture model is an essential artefact. It captures some or all of the architectural decisions. It's a tangible record of the architecture. Modelling could be informal (slides, diagrams), semi-formal (UML diagrams) or formal. Architecture Description Languages (ADLs) can be used for formal modelling. An ADL is a set of notations, languages, standards, and conventions. It can lead to formal analysis, evaluation, reuse, and automated code generation.

  Software systems can be viewed from different perspectives. Such views are complementary. An architect need to produce many of these views or diagrams: data flows, control flows, state transitions, entity relations, object-oriented hierarchies, data models, message sequences, and more. Another way to classify these views is logical, process, physical and development.

• What processes are applicable for software architecture?

  

  Software architecture design method. Source: Bosch et al. 2000, fig. 1.

  Software architecture is part of the overall discipline of software engineering. Architects need to interact with multiple stakeholders. They need to be clear about product requirements. Non-functional requirements include reliability, usability, efficiency, scalability, maintainability, and more. They should factor in additional constraints such as legal, regulations, costs, time-to-market and talent availability.

  Adopting a programming framework or developer tools such as Springboot or Cocoa implicitly selects an architecture. While developers can focus on design decisions, they need to be aware of the architectures they've adopted. Moreover, an architect needs to address runtime requirements including CI/CD, deployment, scalability and observability.

  Architects deal with architectural models, description languages, analysis techniques, development environments, canonical solutions, and design processes. Architecture establishes the constraints within which application components need to be developed.

  Static analysis of source code can be used to recover or reverse engineer the architecture of legacy systems. Such analysis can also identify deviations between architecture and implementation.

  It's foreseen that AI-enabled tools will automate architectural tasks. Decisions will become more data driven. Automated code generation and testing may help to quickly validate and refine architectures.

• What are some pitfalls in software architecture?

  Working without properly defining quality attributes leads to poor architecture. Asking vendors to create architectures or adopting architectures from another organization are just as bad: architecture needs context and tradeoffs depend on the context. Waiting for the perfect architecture before starting implementation is another pitfall.

  Even the best architecture can be ineffective if not properly communicated. Automated documentation, graphical views and change simulation are some tools that can help. Architects should communicate to upper management in a language they understand. Indeed, organizational structure should evolve to keep up with technological evolution. DevOps and CI/CD are useless if management takes weeks to approve a change.

  Architects shouldn't work in isolation. They should collaborate with everyone, looking out for problem areas before they become serious, giving their inputs, explaining the architecture, and mentoring individuals. These interactions create effective feedback loops towards architecture that's fit for purpose.

  Modelling tools are often inadequate when mapping the code to the model. Architects and their tools ignore software architecture evolution. These limitations can result in drift between architecture and implementation. Architecting should be continuous and an iterative process.

• How can a developer move into the role of an architect?

  

  Some specializations of software architects. Source: Medushevska 2022.

  Developers should move from their narrow focus of specific components or sub-systems. As architects, they should learn to look at the big picture and obtain a holistic view of the entire system. They should resist the urge to write code. A developer may focus on only coding but an architect has to look at requirements, coding, testing, deployments, evolution, and more.

  An architect should be able to take important decisions given the constraints and quality attributes. Because architects interface with many stakeholders, they need leadership qualities.

  Architects straddle both technical, business and interpersonal concerns. A solid technical background is essential for many tasks: spotting trends, planning, assessing risks, and critical thinking. An architect should have empathy and see things from a developer's perspective. This helps when reviewing and mentoring. Overall, an architect who's been a developer for many years and interacted with customers will do well.

  It's been said that software architect is not an independent role. Architecting should be regarded as a skill that developers and agile teams should practice. Architecting should be connected to developing.

• What resources can help learn software architecture?

  Two books published by SEI are Software Architecture in Practice and Designing Software Architectures. To learn about architectural patterns, see Pattern-Oriented Software Architecture by Buschmann et al. (1996). Richards has curated a list of books on software architecture.

  The SEI offers online courses on software architecture. There are also courses on Udemy and Coursera.

  New architects can look at some templates of software architecture documents: Course Registration System and Co-op Evaluation System.

  We may need to evaluate software architectures given a set of quality attributes. Some methods exist: Active Design Reviews, Software Architecture Analysis Method (SAAM), and Architecture Tradeoff Analysis Method (ATAM).

Milestones

1980

From the mid-1980s, practitioners of Software Engineering address architectural concerns to manage the complexity of large projects. They use box-and-line diagram as a tool. The decade ends with a DARPA workshop on the topic of Domain-Specific Software Architectures (DSSAs).

1990

During this decade, architectural patterns, architecture description languages (ADLs), documentation, architecture recovery, tools, and formal methods are studied. Design patterns and architectural styles aid teams with knowledge reuse.

1992

Perry and Wolf publish a paper titled Foundations for the study of software architecture. This is perhaps the earliest use of the term "software architecture" in literature.

1994

Garlan and Shaw of Carnegie Mellon University publish a paper titled An Introduction to Software Architecture. This includes a few architectural styles: pipes and filters, data abstraction and object-oriented organization, event-based, layered systems. In one case study, they propose and compare different styles. In 1996, they publish the book Software Architecture: Perspectives on an Emerging Discipline. This book brings together most ideas of the time.

1995

The IEEE Software Engineering Standards Committee charters the IEEE Architecture Planning Group (APG). It's objective is "to set the direction for the next generation of architecture-related standards and practices for the IEEE." Their work eventually results in the publication of IEEE 1471 Standard in 2000. Also in 1995, Taylor et al. publish Software development using domain-specific software architectures.

Nov
1995

Kruchten's 4+1 view model. Source: Kruchten 1995, fig. 1.

Kruchten proposes the "4+1" View Model. The idea is that multiple views are necessary to address the concerns of different stakeholders. The four views are logical (object-oriented), process (synchronization, concurrency), physical (software-hardware mapping, distributed), and development (software organization)

Sep
2000

IEEE 1471 titled Recommended Practice for Architecture Description of Software-Intensive Systems is approved as a standard. Traditionally, architects considered only hardware issues. This standard addresses this short-sightedness. In August 2001, ANSI makes this an American National Standard. In 2007, this is adopted by ISO/IEC as ISO/IEC 42010:2007.

Nov
2011

ISO/IEC/IEEE 42010:2011 titled Systems and software engineering — Architecture description is published as an international standard. It's an evolution of IEEE 1471. This harmonizes ISO/IEC 42010, ISO/IEC 12207 and ISO/IEC 15288.

References

1. Ahmed, S. 2023. "3 lessons for software developers pivoting into IT architecture." Red Hat, January 9. Accessed 2023-12-20.
2. Barais, O., A.F. Le Meur, L. Duchien, and J. Lawall. 2008. "Software Architecture Evolution." In: Software Evolution. Springer, Berlin, Heidelberg. doi: 10.1007/978-3-540-76440-3_10. Accessed 2023-12-20.
3. Barroca, L., J. Hall, and P. Hall. 2000. "An Introduction and History of Software Architectures, Components, and Reuse." In: Barroca, L., J. Hall, and P. Hall (eds), Software Architectures, Springer, London. doi: 10.1007/978-1-4471-0367-7_1. Accessed 2023-12-20.
4. Bobrica, L. and E. Niemela. 2002. "A Survey on Software Architecture Analysis Methods." Slides, IEEE TOSE, July. Accessed 2023-12-20.
5. Bosch, J., P.O. Bengtsson, and R. Smedinga. 2000. "Assessing optimal software architecture maintainability." In: Sousa, P., and J. Ebert (eds), Proceedings of the Fifth European Conference on Software Maintenance and Reengineering, pp. 168-175. Accessed 2023-12-25.
6. Buschmann, F., R. Meunier, H. Rohnert, P. Sornmerlad, and M. Sta. 1996. "Pattern-Oriented Software Architecture: A System of Patterns." Vol. 1. John'Wiley & Sons Ltd. Accessed 2023-12-20.
7. CAST. 2023. "What Is Software Architecture?" Glossary, CAST. Accessed 2023-12-20.
8. Ford, N. and M. Richards. 2020. "Architecture Styles Worksheet." DeveloperToArchitect. Accessed 2023-12-20.
9. Fowler, M. 2003. "Who Needs an Architect?" IEEE Software, pp. 2-4, July/August. Accessed 2023-12-20.
10. Fowler, M. 2019a. "Software Architecture Guide." August 1. Accessed 2023-12-20.
11. Fowler, M. 2019b. "Is High Quality Software Worth the Cost?" May 29. Accessed 2023-12-20.
12. Garlan, D. and D.E. Perry. 1995. "Introduction to the Special Issue on Software Architecture." IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 269-274, April. doi: 10.5555/205313.205314. Accessed 2023-12-20.
13. Garlan, D. and M. Shaw. 1994. "An Introduction to Software Architecture." CMU-CS-94-166, Carnegie Mellon University, January. Accessed 2023-12-20.
14. Hasselbring, W. 2018. "Software Architecture: Past, Present, Future." In: Gruhn, V. and R. Striemer (eds), The Essence of Software Engineering, Springer, Cham. doi: 10.1007/978-3-319-73897-0_10. Accessed 2023-12-20.
15. Hohpe, G. 2017. "The Architect Elevator — Visiting the upper floors." May 24. Accessed 2023-12-20.
16. ISO. 2021. "Survey of Architecture Frameworks." ISO, October 19. Accessed 2023-12-20.
17. ISO. 2023. "History." ISO/IEC/IEEE 42010, ISO. Accessed 2023-12-20.
18. Kruchten, P. 1995. "Architectural Blueprints—The “4+1” View Model of Software Architecture." IEEE Software, vol. 12, no. 6, pp. 42-50, November. Accessed 2023-12-20.
19. Medushevska, M. 2022. "What Does a Software Architect Do? The Role, Skills, and Duties." Blog, Syndicode, July 20. Accessed 2023-12-20.
20. Mleczko, A. 2021. "Software architecture in software engineering: types, challenges and best practices." Blog, Future Processing, October 26. Accessed 2023-12-20.
21. Parnas, D.L. and D.M. Weiss. 1985. "Active Design Reviews: Principles and Practices." NRL Report 8927, Naval Research Laboratory, November 18. Accessed 2023-12-25.
22. Parsons, R.J. 2005. "Enterprise Architects Join the Team." IEEE Software, pp. 16-17, September/October. Accessed 2023-12-20.
23. Perry, D.E., and A.L. Wolf. 1992. "Foundations for the study of software architecture." ACM SIGSOFT Software Engineering Notes, vol. 17, no. 4, pp. 40-52. Accessed 2023-12-20.
24. Prakash, V. 2021. "Web Application Architecture." Geek Culture, on Medium, September 13. Accessed 2023-12-25.
25. Pureur, P., and K. Bittner. 2022. "Software Architecture: It Might Not Be What You Think It Is." InfoQ, April 15. Accessed 2023-12-20.
26. Pureur, P., K. Bittner, and T. Betts. 2023. "12 Software Architecture Pitfalls and How to Avoid Them." InfoQ, December 13. Accessed 2023-12-19.
27. Richards, M. 2023. "Developer to Architect: Resources." DeveloperToArchitect. Accessed 2023-12-20.
28. Riggins, J. 2021. "Do You Have the Empathy to Make the Move to Architect?" The New Stack, August 5. Accessed 2023-12-20.
29. SEI. 2021. "Software Architecture." Software Engineering, Institute, Carnegie Mellon University, May 12. Accessed 2023-12-20.
30. Savidis, A. and C. Savaki. 2022. "Software Architecture Mining from Source Code with Dependency Graph Clustering and Visualization." In: Proceedings of the 17th International Joint Conference on Computer Vision, Imaging and Computer Graphics Theory and Applications (VISIGRAPP 2022) - Volume 3: IVAPP, pp. 179-186. doi: 10.5220/0010896800003124. Accessed 2023-12-20.
31. Sharma, A., M. Kumar, and S. Agarwal. 2015. "A Complete Survey on Software Architectural Styles and Patterns." Procedia Computer Science, Elsevier, vol. 70, pp. 16-28. Accessed 2023-12-20.
32. Solms, F. 2012. "What is software architecture?" SAICSIT '12: Proceedings of the South African Institute for Computer Scientists and Information Technologists Conference, pp. 363-373, October. doi: 10.1145/2389836.2389879. Accessed 2023-12-20.
33. Taylor, R.N. 2018. "Only the Architecture You Need." In: Gruhn, V. and R. Striemer (eds), The Essence of Software Engineering, Springer, Cham. doi: 10.1007/978-3-319-73897-0_10. Accessed 2023-12-20.
34. Taylor, R., W. Tracz, and L. Coglianese. 1995. "Software development using domain-specific software architectures." ACM SIGSOFT Softw. Eng. Notes, vol. 20, no. 5, pp. 27-38. Accessed 2023-12-20.
35. Thoughtworks. 2023. "Evolutionary architecture." Thoughtworks. Accessed 2023-12-20.
36. Wikipedia. 2023. "Software architecture." Wikipedia, December 15. Accessed 2023-12-20.
37. Wikipedia. 2023a. "IEEE 1471." Wikipedia, December 22. Accessed 2023-12-23.
38. Wikipedia. 2023b. "ISO/IEC 42010." Wikipedia, December 18. Accessed 2023-12-23.

Further Reading

1. Fowler, M. 2003. "Who Needs an Architect?" IEEE Software, pp. 2-4, July/August. Accessed 2023-12-20.
2. Taylor, R.N. 2018. "Only the Architecture You Need." In: Gruhn, V. and R. Striemer (eds), The Essence of Software Engineering, Springer, Cham. doi: 10.1007/978-3-319-73897-0_10. Accessed 2023-12-20.
3. Sharma, A., M. Kumar, and S. Agarwal. 2015. "A Complete Survey on Software Architectural Styles and Patterns." Procedia Computer Science, Elsevier, vol. 70, pp. 16-28. Accessed 2023-12-20.
4. Buschmann, F., R. Meunier, H. Rohnert, P. Sornmerlad, and M. Sta. 1996. "Pattern-Oriented Software Architecture: A System of Patterns." Vol. 1. John'Wiley & Sons Ltd. Accessed 2023-12-20.

Article Stats

Author-wise Stats for Article Edits

Author

No. of Edits

No. of Chats

DevCoins

arvindpdmn

2

0

1534

DevCoins due to articles, chats, their likes and article hits are included.

Cite As