Software Architecture #3. Final

Software architecture design is one of the software architecture life-cycle activities. As in any software project life cycle, this activity is concerned with the translation of requirements into a design into an implementation. Specifically, the architect need to worry about the following issues:

• Architectural requirements. Among all requirements, a few will have a particular importance with respect to the software architecture. These architecturally significant requirements include not only most important functionality of the system and the constraints that need to be taken into account, but also - and most importantly quality attributes such as high performance, high availability, ease of evolution, and iron-clad security. These requirements, along with a clear design purpose and other architectural concerns that may never be written down or may be invisible to external stakeholders and components over another.
• Architectural design. Design is translation, from the world of need(requirements) to the world of solutions, in terms of structures composed of code, framework, and components. A good design is one that satisfies the drivers.
• Architectural documentation. Some level of preliminary documentation (or sketches) of the structures should be created as part of architectural design. This activity, however, refers to the creation of a more format document from these sketches. If the project is small and has a precedent, then architecture documentation may be minimal. In contrast, if the project is large, if distributed teams are collaborating, or if significant technical challenges exist, then architectural documentation will repay the effort invested in this activity. While documentation is often avoided and derided by programmers, it is a standard, non-negotiable deliverable in almost every other engineering discipline. If your system is big enough and if it is mission critical, it should be documented. In other engineering disciplines, a "blueprint" - some of sort of documented design - is an absolutely essential step in moving toward implementation and the commitment of resources
• Architectural evaluation. As with documentation, if your project is non-trivial, then you owe it to yourself and to your stakeholders to evaluate it - that is, to ensure that the decisions made are appropriate to address the critical requirements. Would you deliver code without testing? Of course, not. Similarly, why would you commit enormous resources to fleshing out an architecture if you had not first "tested" the design? You might want to do this when first creating the system or when putting it through a major refactoring. Typically evaluation is done informally and internally, but for try important projects it is advisable to have formal evaluation done by an external team
• Architectural implementation/conformance checking. Finally, you need to implement the architecture that you have created. As an architect, you may need to tweak the design as the system grows and requirements evolve. This is normal. In addition to this tweaking, your major responsibility during implementation is to ensure conformance of the code to the design. If developers are not faithfully implementing the architecture, the may be undermining the qualities that you have designed in. Again, consider what is done in other fields of engineering. When a concrete foundation for a new building is poured, the building that rests on top of that foundation is not constructed until the foundation has first been tested, typically vi a core sample, to ensure that it is wrong enough, dense enough, sufficiently impermeable to water and gases, and so forth. Without conformance checking, we have no way of ensuring the quality of what is being subsequently constructed.

The role of architect

An archives is much more that "just" a designer". This role may be played one or more individuals, has a long list of duties, skills and knowledge that must be satisfied if it to be successful. These prerequisites include the following:

• Leadership: mentoring, team-building, establishing a vision, coach
• Communication: both technical and nontechnical, encouraging collaboration
• Negotiation: dealing with internal and external stakeholders and there conflicting needs and expectations
• Technical skills: life-cycle skills, expertise with technologies, continuous learning, coding
• Project skills: budgeting, personnel, schedule management, risk management
• Analytical skill: architectural analysis, general analysis mindset for project management and measurement

Why is architectural design so important? There is a very high cost to a project of not making certain decisions, or not making them early enough. Without doing some architectural thinking and some early design work, you cannot confidently predict project cost, schedule, and quality. Without architecture, the benefits that the system is supposed to bring will be far harder to realise. If you do not make some key architectural decisions early and put if you allow architecture to degrade, you will be unable to maintain spring velocity, because you cannot easily respond to change requests. Such decisions may include:

• Selection of tools
• Structuring development environment
• Supporting releases
• DevOps

Architectural concerns

Architectural concerns encompass additional aspects that need to be considered as part of architectural design but that are not expressed as rational requirements. There are several different types of concerns.

• General concerns. These are "broad" issues that one deals with in creating the architecture, such as establishing on overall system structure, the allocation of functionality to modules, the allocation of modules to team, organization of code base, startup and shutdown, and supporting delivery, deployment and updates.
• Specific concerns. These are more detailed system-internal issues such as exception management, dependency management, configuration, logging, authentication, authorisation, caching and so forth that are common across large numbers of applications. Some specific concerns are addressed in reference architectures, but other will be unique to your system. Specific concerns also result from previous design decisions. For example, you may need to address session management if you previously decided to use a reference architecture for the development of web applications.
• Internal requirements. These requirement are usually not specified explicitly in traditional requirement documents, such as customers usually seldom express them. Internal requirements may address aspects that facilitate development, deployment, operation, or maintenance of the system. They are sometimes called "derived requirements"
• Issues. These result from analysis activities, such as design review, so they may not be present initially. For instance, an architectural evaluation may uncover a risk that requires some changes to be performed in current design.

Some of the decisions surrounding architectural concerns might be trivial or obvious. For example, your deployment structure might be a single processor for an embedded system, or a single cell phone for an app. Your reference architecture might be constrained by company policy. Your authentication and authorisation policies might be dictated by your enterprise architecture and realised in a shared framework. In other cases, however, the decisions required to satisfy particular concerns may be less obvious - for example, in exception management or input validation or structuring code base.
From their past experience, wise architects are usually aware of the concerns that are associated with a particular type of system and the need to make design decisions to address them. Inexperienced architects are usually less aware of such concerns; because these concerns tend to be tacit rather than explicit, the may not consider them as part of the design process, which often results in problem later or.
Architectural concerns frequently result in the introduction of new quality attribute scenarios. The concerns of "supporting logging", for example, is too vague and need to be made more specific.

The selection of externally developed components, which is a key aspect of the design process, can be a challenge task because of their extensive number. Here are few criteria you should cosied when selection externally developed components:

• Problem that it addresses. Is is something specific, such as framework for object oriented to relation mapping or something more generic, such as platform.
• Cost. What is the cost of the license, and if it is free, what is cost of support and education?
• Type of license. Does it have a license that is compatible with the project goals?
• Support. Is it well supported? Is there extensive documentation about the technology? Is there an extensive usr or developer community that you can turn for advice?
• Learning curve. How hard is to learn this technology. Have others in your organization already mastered it? Are these courses available?
• Maturity. Is it a technology that has just papered on the market, which may be exciting but still relatively unstable or unsupported?
• Popularity. Is it a relatively widespread technology? Are these positive testimonial or adoption by mature organisations? Will it be easy to hire people who have deep knowledge of it? Is there an active developer community or user group?
• Compatibility and ease of integration. Is it compatible with other technologies used in the project? Can it be integrated easily in project? Support for critical quality attributes. Does it limit attributes such as performance? Is it secure and robust?
• Size. Will the use of the technology have negative impact of the size of the application under development

In their paper "A General Model of Software Architecture Design Derived from Five Industrial Approaches", Holfmeister and her colleagues compared five industrial software architecture design methods and extracted from their commonalities a generic software architecture design approach.
The derived general model consist of three main activities that are present in all five models reviewed:

• Architectural analysis. In this activity, requirements (called concerns) and system context are used as inputs to determine set of architecturally significant requirements(ASR).
• Architectural synthesis. This activity is described as being the core of architecture design. It proposes architecture solution to a set of ASRs, moving from the problem to the solution space. The results of this activity are candidate architectural solutions, which are partial or complete architecture designs an include information about the rationale.
• Architectural evaluation. This activity ensures that the architectural decisions are the right ones. Candidate architectural solutions are measured agains ASRs. Several evaluations of different architectural solutions are expected, but the eventual result its the validated architecture.

Analysis is the process of breaking a complex entity into its constituent parts as a means of understanding it . The opposite of analysis is synthesis. Analysis and design are therefore inerwined actives. During the design process, the activity of analysis can refer to several aspects

• Studying the inputs to the design process to understand the problem whose solution you are about to design.
• Studying the alternative design concepts that you identified to solve a design problem so as to select the most appropriate one. In this situations, analysis forces you to provide concrete evidence for you choices.
• Ensuring the decisions made during the design process (or an iteration) are appropriate.