What Is Software Architecture?

The process of software architecture takes customers' requirements, analyses them, and produces a design for a piece of software that will meet their needs. Successful software designs must balance the inevitable trade-offs that arise due to conflicting requirements; comply with the design tenets and good practice techniques that have evolved over time; and complement modern hardware, networking, and management systems. Strong Software architecture involves considerable experience of both theoretical and practical topics, as well as the vision that is necessary to translate what may seem like vague business scenarios and requirements into solid and practical working designs.

Software architecture involves defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of that software.

Modern software rarely stands alone. At minimum it will, in most cases, interact with a data source such as a corporate database that exposes the information with which the users of the software work. Typically modern software must also interact with other services and network functions to perform authentication, obtain and publish information, and to offer an integrated user experience. Without an appropriate architecture, software may be difficult or even impossible to deploy, operate, maintain, and integrate successfully with other systems; and will fail to meet user requirements.

Software architecture can be thought of as a mapping between what a piece of software must achieve and the details of the implementation as code. Getting the architecture right will ensure the optimum match between requirements and outcomes. Well-architected software will carry out the specified tasks within the parameters of the original requirements, and do so in a way that maximizes performance, security, reliability, and many other factors.

At the highest level, the architectural design should expose the structure of the system but hide the implementation details; realize all of the use cases and scenarios; try to address the requirements of all of the stakeholders; and satisfy as far as possible all of the functional and quality requirements.

Why Is Software Architecture Important?

The requirements for modern software are increasingly complex as users expect more from their applications. Simple stand-alone desktop applications are not longer good enough in most business and commercial scenarios. In our connected world, application must interact with other applications and services, and run in a range of environments such as the cloud and on portable devices. The monolithic designs common in the past have been replaced by componentized service-oriented software that uses frameworks, operating systems, runtime hosts, and networks to implement features that were unheard of even a few years ago.

This complexity affects not only the design, but also the deployment, maintenance, and administration of the software. The total cost of ownership (TCO) of software is now predominantly made up of post deployment costs. A well architected application will minimize TCO by reducing the cost and time required to deploy the application, keep it running, update it to meet changing requirements, and fix problems. It will also simplify user support and administration.

Software must also meet several vital criteria in order to be successful. It must provide security so that the application and its data are protected against both malicious attacks and accidental errors. It must be robust and reliable so that failures and the associated costs are minimized. It must perform within the required parameters to meet the customer's needs, such as a maximum response time or a specific workload capacity. It must be maintainable in order to minimize administration and support costs, and extensible enough to allow for the inevitable changes and upgrades that will be required over time.

All of these factors involve some trade-offs. For example, implementing the most secure mechanisms through complex encryption will affect performance. Implementing wide-range configuration and upgrade options can make deployment and administration more complicated. In addition, the more complex the design, the more it will cost to implement. A good architecture will aim to balance these factors to produce the optimum result for the specific scenario.

What Does a Software Architect Do?

Software architecture starts with a set of requirements. These may be expressed in a form of diagrams, process flowcharts, models, or documented lists of operational tasks that the software must perform. Typically the customer or partner will also express less precise requirements, such as the look and feel or the way that certain user interfaces should work for common tasks. The requirements must also include information about the existing software, systems, hardware, and networks that the new software will interface with; and other factors such as the deployment and maintenance plan and, of course, the budget available for the project.

The software architect must consider the needs of the customer. However, the general term "customer" typically comprises three conflicting area of responsibility: the business requirements, the user's requirements, and the systems requirements. The business requirements usually define a range of factors such as the business processes, the performance factors (such as security, reliability, and throughput), and the budget and cost constraints. The user requirements include the interface design, operational capabilities, and ease of use of the software. The system requirements include the hardware, networking, and runtime environment capabilities and constraints. Figure 1 shows how these different requirements can vary so that the architect must work to achieve a design that fits into the overlapping area.

Figure 1 - The conflicting requirements of a typical customer

Software architects each have their own approach to collecting and analyzing requirements, and to defining the architecture. However, the questions they commonly need to answer include "how will the users work with the application?"; "how will the application be deployed into production and managed?"; "what are the quality attribute requirements for the application, such as security, performance, concurrency, internationalization, and configuration?"; "how can the application be designed to be flexible and maintainable over time?"; and "what are the architectural trends that might impact the application now or after it has been deployed?"

This last question is both interesting and important. Good software design not only meets the customers' requirements now, but will continue to do so into the foreseeable future. This affects the decisions the architect must make about the hardware, components, frameworks, runtime platforms, management software systems, and many other features built into the software or with which the software must integrate.

Like most tasks in the world of software design and development, designing the architecture is both an upfront and an iterative process. Many initial tasks such as requirements analysis, technical research, and the identification of objectives typically take place at the start of the process. The next step is to identify the key scenarios for the design. These are the primary requirements the software must meet, and the constraints within which it must operate. From this information, the architect can generate an overview of the application. This overview encompasses high-level details such as the type of application (web, phone, desktop, or cloud), the deployment architecture (typically a layered design with components communicating over hardware and network boundaries), the appropriate architecture styles to follow (such as n-tier, client-server, or service-oriented), and the implementation technologies that best suit the scenario.

From there the architect can start to generate candidate designs that satisfy the high-level and the most important requirements identified earlier. This design is then reviewed and tested against the key scenarios, often in conjunction with feedback from the customer and trial or test versions, to ensure that it provides the optimum solution. This is unlikely during the first iteration, but as the cycle is repeated the design will converge on the requirements and key scenarios. Figure 2 shows this iterative approach.

Figure 2 - An iterative architectural design process

As the design becomes more granular and the individual tasks and components are identified, the architect can further refine and add detail at each stage. For example, having identified the architectural style and deployment approach, the architect can make decisions about communication between layers and components. This may involve choosing a protocol based on present and future requirements, and taking into account previews of new technology and capabilities defined in upcoming standards.

The final product of an architects' work is usually a set of schematics, models, and documents that define the application from several perspectives so that, when combined, they provide developers, test teams, administrators, and management with all of the information required to implement the design. This information will describe the structure and layout of the component parts and application layers; the way that cross-cutting concerns such as logging and validation are handled; the testing and deployment plan; and documentation to assist developers, administrators, and support staff.

The final design must also specify the quality attributes that the application must meet. These are the result of considered decisions and tradeoffs made by the architect in consultation with the customer. They include definitions of the security requirements and the security implementation plan, the required scalability and performance when deployed on the target platform, the ways that maintainability and extensibility are implemented, and the features that enable interoperability with other systems.

What Skills Does a Software Architect Need?

It's evident that a software architect requires a wide range of both soft and hard skills. During the requirements analysis and review stages, the architect must work with the customer, consult with partners and other team members, and act as a go-between for managers, users, and system administrators. Excelling at these soft skills can produce a better initial plan and a more accurate set of requirements, saving time and effort later on.

A software architect must also have the hard skills required to understand how modern software systems, frameworks, and hardware support the requirements; how networking and operating system factors may affect the design decisions; and how the trends and changes in these areas will have an impact on the design. After initial requirements analysis, a software architect must also apply hard skills around design patterns, communication and messaging standards, code capabilities, security concerns, and performance constraints. All of these require an intimate knowledge of the technologies that will be used to implement the final software.

Of course, software architecture also requires vision. Being able to see how systems will fit together and interoperate, how they will be partitioned and deployed, and how they interact with users can often only be determined once the architect can see the overall solution in their mind. This requires an organized approach and a great deal of attention to detail to collate and understand all of the requirements and constraints, and to gradually morph these in a fluent and comprehensive technical design. However, it also requires flair and imagination to be able to visualize the end result and then work methodically work towards the ideal solution.