What is Software Architecture and Why Do We Need It?
Like any other complex structure, software must be built on a solid foundation. Failing to consider key scenarios, failing to design for common problems, or failing to appreciate the long term consequences of key decisions can put your application at risk. With no architecture in place, the code grew like ivy on a moisty garden shed, resulting in poor maintainability and low productivity in adding new features to the software.
Software Architecture is a technical blueprint explaining how the system will be structured into subsystems (modules) while optimizing common quality attributes such as performance, security, and manageability.
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is:
Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.
In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common recurring themes when explaining architecture. He identifies these themes as:
The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system’s lifetime; and, in the end, architecture boils down to whatever the important stuff is.
In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman define architecture as follows:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.
The goal of architecture is to identify the requirements that affect the structure of the application. Good architecture reduces the business risks associated with building a technical solution. A good design is sufficiently flexible to be able to handle the natural drift that will occur over time in hardware and software technology, as well as in user scenarios and requirements.
Software Architecture offers some rather relevant benefits, which include:
- Higher productivity. It is easier to add new features to existing software, since the structure is already in place, and the location for every new piece of code is known beforehand.
- Better code maintainability. It is easier to maintain existing software, as the structure of the code is visible and known, so it’s easier to find bugs and anomalies.
- Higher adaptability. New technical features, such a different front ends, or adding a business rule engine are easier to achieve, as your software architecture creates a clear separation of concerns.
- Hype agnostic. Last but not least, it will allow you to see hypes and fads in the industry – or which there are a lot – in the light of your current structure, and to fit these hypes and fads in if so required.
Software Architecture Patterns & Styles
Client/Server Architecture
Client/Server is a software architecture model consisting of two parts, client systems and server systems, both communicating over a computer network or on the same computer. A client-server application is a distributed system made up of both client and server software. Client server application provides a better way to share the workload. The client process always initiates a connection to the server, while the server process always waits for requests from any client. Client-server architectures are sometimes called two-tier architectures.
Component-Based Architecture
Component-based architecture focuses on the decomposition of the design into individual functional or logical components that represent well-defined communication interfaces containing methods, events, and properties. It provides a higher level of abstraction and divides the problem into sub-problems, each associated with component partitions.
The primary objective of component-based architecture is to ensure component reusability. A component encapsulates functionality and behaviors of a software element into a reusable and self-deployable binary unit.
An example of two components expressed in UML 2.0. The checkout component, responsible for facilitating the customer’s order, requires the card processing component to charge the customer’s credit/debit card (functionality that the latter provides).
Domain Driven Design
Domain-Driven Design, or DDD, is an approach for building high-quality software that meets core business objectives. It emphasizes collaboration among domain experts, developers, UX designers and other disciplines to create a domain model that reflects the needs of the business. This involves agreeing on common terminology (a.k.a. the Ubiquitous Language), identifying business entities, their behavior and relationships and organizing them in a way that lends itself to a clean and modular implementation.
Patterns in strategic domain-driven design and the relationships between them
Layered Architecture
Layered architecture focuses on the grouping of related functionality within an application into distinct layers that are stacked vertically on top of each other. Functionality within each layer is related by a common role or responsibility. Communication between layers is explicit and loosely coupled. Layering your application appropriately helps to support a strong separation of concerns that, in turn, supports flexibility and maintainability.
Message Bus Architecture
Message bus architecture describes the principle of using a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other. It is a style for designing applications where interaction between applications is accomplished by passing messages (usually asynchronously) over a common bus. The most common implementations of message bus architecture use either a messaging router or a Publish/Subscribe pattern, and are often implemented using a messaging system such as Message Queuing.
N-Tier / 3-Tier Architecture
N-tier / 3-tier architecture describe the separation of functionality into segments in much the same way as the layered style, but with each segment being a tier that can be located on a physically separate computer. They evolved through the component-oriented approach, generally using platform specific methods for communication instead of a message-based approach.
Object-Oriented Architecture
Object-oriented architecture is a design paradigm based on the division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object. An object-oriented design views a system as a series of cooperating objects, instead of a set of routines or procedural instructions. Objects are discrete, independent, and loosely coupled; they communicate through interfaces, by calling methods or accessing properties in other objects, and by sending and receiving messages.
Service-Oriented Architecture (SOA)
Service-oriented architecture (SOA) is an approach used to create an architecture based upon the use of services. Services (such as RESTful Web services) carry out some small function, such as producing data, validating a customer, or providing simple analytical services.
One of the keys to SOA architecture is that interactions occur with loosely coupled services that operate independently. SOA architecture allows for service reuse, making it unnecessary to start from scratch when upgrades and other modifications are needed.
Onion Architecture
The *Onion Architecture* is a software architecture proposed by Jeffrey Palermo. It is similar to the *Hexagonal Architecture* (Ports and Adapters) proposed by Alistair Cockburn.
The fundamental motivation of the approach is to avoid layer-to-layer dependencies usually associated with the N-tier architecture approach. This is achieved by placing all infrastructure, including databases, outside the problem domain.
Applying this principle to the n-tier layered architecture means inverting the flow of dependency to make the business logic layers independent of interfaces and infrastructure.
This principle leads to a model where the business logic is in the centre of the architecture, with additional layers placed around it in concentric rings, like an onion.
In Summary
This is first in a series of articles that are targeted to cover a wide range of topics related to the Software Architecture.
We’ll be posting more articles in the series soon, so stay tuned. You can freely subscribe to this blog for weekly updates on new articles.
References
CodeProject
I am an Entrepreneur, co-founder of Luce & Morker, a tech enthusiast, car lover, movie buff and foodie. I write posts for our company blog which are mostly about providing helpful tips, advice, and insights related to web design, web development, web technologies etc.
I love reading articles and I like to keep myself updated with latest tech and business related news.
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
