In this lesson, you will learn why software architecture is important from a technical perspective. System qualities will be largely determined by the architecture, and they are enabled by the design decisions at the architectural level. So let's take the example of a performance requirement. The system will be able to process 1,000 concurrent events per second. Now, to guarantee this quality, we need to reason about the concurrent behaviors, the communication properties, and the shared resources of the system. And this can happen before a single line of code is written. The software architecture allows you to estimate the number of modules needed to process a single event, evaluate the communication delays, and identify race conditions on shared resources. Now, similar architectural reasoning can be done for other system qualities. Architectural tactics, such as caching or parallel processing that support high throughput, are necessary to enable the system performance quality. But it can still be compromised by a bad implementation. So therefore, achieving quality attributes needs to be considered during every step of the software engineering process. The architectural model gives you a way to reason about them, but also to create clear guidelines for the design and the implementation. And it doesn't work the other way around. Poor architectures can not be fixed by implementation approaches. Throughput will not improve significantly by adding faster hardware, or if you have a structural bottleneck in your system. In the best case, you will increase the complexity and the cost of your system for just a marginal improvement. So software architecture models allow you to reason about future changes. And this is highly relevant for the many Internet of Things applications that have to deal with constant innovations in areas such as communication protocols, algorithms, and sensor technologies. Considering that more than 60% of the cost of software occurs after the initial release, we can certainly benefit from architectural models that provide the basis for the impact analysis of new requirements and anticipate the changes. So software architects can take into account future requirements and design future-proof architectures that are easier to change by implementing modifiability tactics. For example, for a location-based application the software architect can ask the following question, how can the architecture support the replacement of GPS by Galileo, the new European alternative. Architectural models also make it possible to predict the system qualities. So let's look again at the example of performance. The dynamic architectural views allow you to estimate the number of messages triggered by an event and to model their flow through the system. And this can already really give you a good indication of the feasibility of these performance requirements. As we said, performance is often not analyzed until it first comes into the lab. However, if you observe a performance problem that late, the cost of fixing it can be up to 20 times higher than in the case you were taking care of it during the architectural phase. And this is what is explained in this chart. It shows the relative cost of fixing a problem, taking into account the phase where it was introduced versus where it was fixed and detected. Now architects take dozens of decisions every day and need to understand the business impact of every single decision. System quality, cost, and schedule can never be specified independently. And the architect has to understand the trade-offs between them and make early design decisions to find a natural intersections between the technical and the economical drivers of the stakeholders. Typically, decisions which are taken by the architect are, well, will the system be operated on a local server or will it be offered as Saas software? Which existing middleware or operating system do you use? Do we need to design for certain modules to be reused or in the production line? Where will the data resides, will it be central or just distributed? How will the components communicate and what are the possible communication protocol? So as such, an architectural model can be considered as a number of early design decisions. Of course, the constructed software should conform to the design decisions that are captured in this architectural model. And each unit must be constructed within the boundaries of the architectural blueprints and behave or interact accordingly. So the software builder need to implement their individual components within a global set of constraints such as a total performance budget for a particular user scenario. An individual software engineer must be aware of the system level performance requirement and create every software unit with a dedicated unit level performance budget. The sum of the performance budgets of all software units necessary to support the functionality should not exceed the total budget for the scenario. Now, software reuse is often considered as the reuse of source codes, but reusing other architectural artifacts will potentially have a more economic impact. For instance, the automotive industry can gain competitive advantage by architecting software systems as product lines that can be reused across different types of vehicles. The parking assistant component for luxury car could also be used in trucks and buses. And sure, the requirements of both systems will be very similar. But they may run on other hardware platforms, connect to more specialized sensors, or use alternative driver interaction modes. It is the software architect who will identify those commonalities, separate them from the product specific parts, and model this in a very flexible architecture. So software architecture is the perfect place to design for reuse. But the architect always has to take into account the economics. The design of a reusable component does not come for free, because on average it costs 2.5 times more effort and time to create reusable components. So when the architect takes into account system qualities that supports reuse such as portability, interoperability, and modifiability during the architectural design phase, it will significantly reduce the development and the integration cost of those components in the next product. Not only will less work be needed to adapt or modify them, but reusable components have been tested before in the first project and lead to higher quality in general. So software architecture does not only enable the reuse of codes, but also the reuse of models, documentation, high-level design, and even test environments. So in summary, a software architecture model will allow the software architect to think about the enablement of system qualities, reason about change, and predict those system qualities. The software architecture model also supports early design decisions, defines implementation constraints, and enables reuse.
