So next, you will learn how software architecture can improve software processes and contribute to business objectives. Can architecture models help us to better understand requirements, reduce costs or even improve or time to market. Well the beholders define the success of the software project, so the architect needs to take into accounts, who benefits, who pays and ultimately, even who losses. The software architecture provides a platform to communicate with the stakeholders from different domains. Each stakeholder with have his own priority and will be concerned about different characteristics of the system. For the customer, the cost is important. While a development manager needs to complete a project with a limited number of resources in a given time frame. And business people, they care about more features, time to market, and profit margins. So this often will lead to conflicting requirements and the software architect has to negotiate with all those stakeholders. To be successful, it needs a common vocabulary, and a blueprint. And this is exactly what the software architecture provides. Now the team structure of a software project often mirrors the architecture. And this makes the architecture level a good source for assigning work packages to individual Teams. Each Team has it's own area of expertise. Business domain, databases, user interfaces, real time operating systems, central control software and so on. For the structure elements from the architecture model. Identify the areas of expertise that are needed and drive the way the teams or built while the interfaces defend how they interacts and depend on each other. Now another side effect goes from the fact that once an architecture is baselines, it will become very difficult to change it. As the teams, we'll not easily resign staff or share module responsibilities with others. And this is especially relevant when working with large distributed teams and same contractors. And it's another good reason why sufficient time should be allocated to the architectural review of large systems. A related project management topic is the estimation of cost and schedules. Now the efforts and planning estimates for new projects is often based on feature sets and some historical data. Such tab down estimates are not always very accurate. But since the work breakdown is based on the module structure of the architecture that mirrors the team structure, a project manager cannot ask bottom-up estimations per architectural element from those teams. And for sure experienced teams can provide more accurate estimates based on the responsibilities and the quality attributes other volume. And their interaction with the rest of the system. So since architect also make some dependencies between the module explicit. Planning will even become more accurate, as this information can be used to schedule integration activities and monitor progress. So the architecture can also be used for building a skeletal system or prototype. This is a kind of executable architecture that contains the elements of the future softer architecture, such as communication middleware and database systems. And it is typically built before much of the system functionality is added or created. Now such an executable architecture, reduces product risks as it allows early validation. First versions of software components combined with hard coded steps can already be tested on this executable architecture. For example, to check a performance requirement. Smart City, internet of things applications are a good example of this practice. Because they are often designed as plug-in systems for intelligent applications like controlling street lights. At the start of the smart City project hard coded simulators replace the street lights. While later they will connect to the real devices, and in this way software architecture supports the incremental and iterative approach of agile development methods. Architectural views also provide a basis for buy versus build decisions. Interface descriptions define constraints on a module by specifying the controls. The communication protocols and the data. And combined with the behavior from the dynamic few, it gives the architect a technical specification for selecting implementation candidates. Now those software modules can be created from scratch. Or they can be composed of commercial off the shelf components, or even open-source software. And using those external elements that are compatible with your architecture has many benefits. Like time to market is reduced by saving development and testing time. Quality improves as external components have been proven to work in many other applications. And if the architecture is designed with this interchangeability as a quality requirement, it will also provide more flexibility to select the components that are available from the many sources. So finally one of the challenges of project management is the staffing ramp up how do I build my team. Project manager expect engineers to hit the ground running and be 100% productive from day one, ignoring the reality of learning curve, leads to product delays and cost overruns. And a well documented software architecture can be a very valuable tool for new product members and it is excellent training materials for new hires. It contains the first overview of the system and it explains the design decisions that have already been taken. So new hires can more easily identify their role and how they relate to other team members. This encourages communication and since poor communication is on the top three list of reasons why projects fail, you should care even more about software architecture. So as a conclusion, we can say that the software architecture also supports the business goals and the software processes of a software company. The software architecture provides a common language and is often the basis for the team structure. It also helps the team with more accurate project estimations. Prototypes and buy versus build decisions. And finally, architectural documentation will speed up the learning of new team members.
