What is a software architecture and how to represent it?

Question

I've searched a lot for a clear explanation for a software architecture but each time I got more confused, so What a software architecture really is and is there a standard way to represent it or it's something generic that describes some software components?

Answer 1

There are many definitions for what a software architecture is. The Software Engineering Institute has a collection of definitions of software architecture that includes bibliographic definitions taken from papers and articles in the SEI database, published definitions taken from various books and other writings, classical definitions from more prominent or influential works, modern definitions from more recent works, and community-contributed definitions.

There's no right definition, but I tend to favor ones that mention decisions. I feel that the definition from the Rational Unified Process best captures what I consider to be architecture:

An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition.

Based on this definition of architecture, you would need to represent any important decisions and their rationale, the structural elements and interfaces to those structural elements, and how the structural elements are composed together to create larger systems.

I would consider an important decision to be one that is costly (in terms of time, effort, or monetary cost) to change. An example could mean choosing a given programming language, targeting a specific environment (hardware environment, operating system, special-purpose devices), data transmission and storage methods. You can record these decisions using any number of textual or graphical tools, ranging from a wiki to formal meeting minutes and the use of decision matrices.

The structural elements can be captured using any number of representations. SysML and UML are common. BMPN can be useful to represent business processes. Object-Process Methodology can be used during the system design phase to capture the objects and actions that make up the system. If you have a data-heavy system, Entity-Relationship Modeling is also useful I favor using a standard and well-documented modeling language because (ideally) it's one less thing to have to communicate to people using it - anyone who is not familiar should be able to get a significant amount of information on how to understand the modeling notation from existing sources. Although it's written for UML, Martin Fowler's UML Modes can also apply to these other formal modeling languages - your models may range in fidelity from sketches to blueprints and may be started before development and completed after the fact to show appropriate information to the intended target audience.

If you want to know more, I've found that Software Architecture in Practice and Documenting Software Architectures: Views and Beyond are great resources to understand the process of creating, maintaining, and documenting the architecture of software systems.

Answer 2

Architecture means the "big boxes" that compose your application and how these interact with each other to make the application work. Because these "boxes" are specific to each project there is no universally accepted definition of software architecture that applies to all projects (what's good software architecture for one project might be a disaster for another) and so there is no standard way to represent it either.

Martin Fowler has a short presentation in which he talks about what software architecture is, in terms of common characteristics: "Making Architecture Matter" (youtube link here).

Some highlights from the talk:

• software architecture is what's important;
• it's the decisions you need to make early on;
• architecture is about internal quality that you can't trade off for cost (or you will end up loosing on the long run because a bad architecture makes it difficult to add new features that make your product competitive);
• it's the decisions that are hard to change;

Answer 3

what is software architecture ?

Software architecture is the higher level structure of a system, i.e. the way chosen to decompose software into its building blocks and to hold the pieces together.

Here a nice quote from Martin Fowler's book "Patterns of enterprise application architecture":

Architecture is a term that lots of people try to define, with little agreement. There are two common elements: one is the highest level breakdown of a system into its parts; the other, decision that are hard to change.

Example of architectures

At the highest level, the architecture is often represented with its layers and the boundaries withe the outside world. Example:

• Martin's clean architecture
• Cockburn's hexagonal architecture
• Fowler's presentation-domain-data source layers
• and lots of other layering approach

How to represent the architecture ?

Like architecture of buildings which has different facets (e.g. volumetric representation of the building in its environment; overall view of the building's façade; blueprint of each floor, etc...), software architecture also handles different views on the same system.

Ti help out, there is UML. At the highest level:

• the system in its environment is represented with a high-level use case: this shows the boundaries, the main functions, and the relation with external actors (humans or other systems)
• the building blocks can be represented with a component diagram
• a deployment diagram can give the overview of how the components can be distributed in the software's environment
• composite structure diagrams, to show the internal structure of a component.

As the levels get more an more detailed, you'll gradually leave the field of architecture to end up in design, using class diagrams, sequence diagrams, activity diagrams, and communication diagrams.

Answer 4

Architecture is the part of a system that is impossible to change without starting over from scratch.

In other words, those parts that are really expensive to change.

This means one system's design can be another system's architecture and vice versa.

For example, if you believe in 3-tier and put all the stuff that matters in the business layer, regarding you database as just a dump container of rows and columns that should be easily replacable, the RDBMS will not be part of your architecture.

On the other hand, if you consider the data as the core part of your system, with the applications just being dumb little tools that may ask for result sets once they are authenticated and authorized, your RDBMS is likely to become your architecture and your silly little totally replacable Java or whatever client components will not be.