The building blocks of a robust software architecture
Architecture is a term that is popularly used in the construction world and it’s a means of ensuring that there are no failures in structural engineering and construction management, which is one of the reasons why software engineering has also adopted the practice of architecting software systems. In this context, software architectures have proven to be extremely useful in the design and implementation of software systems. Besides technical tasks, software architectures can assist stakeholders in driving project management tasks such as the assignment of human resources to the implementation of different modules of a complex system.
Despite the wide use of architectures in software engineering, there is no widely accepted definition yet. Nevertheless, most software engineers agree that it is a tool for capturing and preserving the designers’ perspectives about the structure and behavior of a software system. In practice, software architectures are used in order to streamline the complexity of sophisticated software systems, through modularizing them and defining the interfaces and interactions between the different modules. Typically, a software architecture comprises of the following attributes:
Another way to view an architecture is as an abstraction of a system, which excludes low-level implementation details (e.g., internal elements). This abstraction conveys the structure of the software system, which can be used to drive several software engineering activities such as implementation (e.g., dividing tasks based on the modules of a system’s architecture) and deployment (e.g., deploying the various elements of the systems independently).
An architecture influences the system design, yet it is much different from the detailed design of a system. In particular, the design of a system architecture deals with decisions that have systemic impact on the software product (e.g., they impact their overall scalability and resilience), while the detailed design of the system deals with decisions that have local impact (e.g., which algorithm will be used to implement a functional unit of the system). For instance, a detailed design describes which software elements will be invoked when a user presses a button in a software application, as well as how they will interact with each other. On the other hand, a system architecture design should describe what will happen in cases where several millions of users will press this button at the same time. It should indicate how the system will be able to handle so many users in a scalable and resilient fashion. Overall, architecture design decisions concern system-wide decisions, while narrowly-scoped decisions are not likely to be architectural.
In most cases, software architecture design activities lie between the requirements and design phases of the software engineering lifecycle. Specifically, architecture design activities include the selection of architecture elements, the specification of the interactions between them, the specification of constraints about the operation of the elements and their interactions, and more. The resulting architecture should satisfy the system’s requirements while serving as a basis for the activities of the design phase. Likewise, the design phase deals with the modularization of the system and the detailed specification of the interfaces between the design elements. The resulting design should be aligned with the architecture while satisfying the requirements as well. Finally, the system coding and implementation phase should produce data types and algorithms that satisfy the design, the requirements, and the architecture at the same time. Hence, the development of a software architecture impacts all phases of the software engineering lifecycle. Note also that all software engineering methodologies (including both waterfall and agile methodologies) include tasks where a software architecture is developed to drive design and implementation activities.
An architecture is in general too complicated to be depicted based on a single view. Hence, software architectures tend to have many structures or views i.e. a software architecture is documented on the basis of multiple views. Different views might be relevant for different stakeholders and their roles in the system development process.
There are several approaches to view-based software architecture description and documentation. As a prominent example, the 4+1 View Model uses 4 complementary views to describe an architecture, while validating them against a set of reference scenarios about the operation of the target software system. In particular, the views of the 4+1 model, include:
Other models comprise analogous views. For example, the Views & Beyond Model of the Software Engineering Institute (SEI) presents an architecture based on three major view types, namely:
Overall, proper software architecture design is a key ingredient to the successful development and delivery of a complex software system. This is what makes the role of a system architect one of the most important in a software team. Software system architects need to have a broader understanding of the system, including knowledge of network, hosting and performance aspects, besides a very good understanding of software solutions. At the same time, software engineers should be proficient in understanding and interpreting the UML diagrams that reflect the various views of a system’s architecture. This knowledge will help the teams complete the development tasks faster and would ensure that there is compatibility among the various modules developed by the different teams.
Six Ingredients of Data Management Intelligence
Top Strategic Priorities for CIOs in 2021
Positioning Your IT for Success in 2021
Customer Centric Processes: From CRM to Customer Data Platforms
Robotic Process Automation: A Driver for Cost-Efficient Enterprises Processes
Seven Ways COVID19 has Changed the CIO Role
AIOps: Empowering Automated and Intelligent Cloud Operations
Shaping the Future of Enterprise Content Management with Artificial Intelligence
An Introduction to Continuous Integration and Workflows
Cloud Leaks: The basics you need to know
We're here to help!
No obligation quotes in 48 hours. Teams setup within 2 weeks.
If you are a Service Provider looking to register, please fill out this Information Request and someone will get in touch.
Outsource with Confidence to high quality Service Providers.
If you are a Service Provider looking to register, please fill out
this Information Request and someone will get in
Enter your email id and we'll send a link to reset your password to the address
we have for your account.
The IT Exchange service provider network is exclusive and by-invite. There is
no cost to get on-board;
if you are competent in your areas of focus, then you are welcome. As a part of this exclusive