Software architecture facts for kids

Kids Encyclopedia Facts

Imagine you're building a huge LEGO castle. You wouldn't just start sticking bricks together, right? You'd probably look at a blueprint or plan first. Software architecture is a lot like that blueprint, but for computer programs! It's the plan that shows how all the different parts of a big computer system fit together and work with each other.

This plan helps people understand how a program is built, how its parts connect, and what each part does. It's super important because it helps teams build the program step by step, making sure everything works well together.

When creating software architecture, there are two main ideas to remember:

Everything involves a trade-off. This means choosing one good thing often means giving up another.
Understanding why something is built is more important than just how it's built.

Software architects use special ways to plan and draw out these systems. They think about how different parts of a program should talk to each other. If parts communicate at the same time, they become very connected and need to share similar features.

Having good software architecture helps everyone involved in building a program understand the big picture. It also helps teams reuse parts of the design in new projects, saving time and effort.

Software architectures can be grouped into two main types:

Monolithic: Like one big block of LEGOs, where all parts are tightly connected.
Distributed: Like many smaller LEGO sets that can work together, even if they are far apart.

Over time, software systems can become very complex. Software architects use special tools to make sure the architecture stays organized and works correctly as the program grows.

Software architecture activities show how a program is planned and built.

What Does Software Architecture Cover?
Software Architecture Styles vs. Patterns
- What Are Software Architecture Patterns?
- What Are Software Architecture Styles?
Common Mistakes in Software Architecture
Key Features of Software Architecture
Why Is Software Architecture Important?
History of Software Architecture
How Software Architecture Is Made
Strategies for Designing Software Architecture
Important Software Architecture Topics
Related Fields
See also

What Does Software Architecture Cover?

People have different ideas about what software architecture includes, but here are some common ones:

The Big Picture of a System

Software architecture often looks at the overall structure of a computer system. This means seeing it as a collection of different parts that work together, along with the ways these parts connect and interact.

Focusing on Important Decisions

Software architects need to focus on decisions that have a big impact on the system and the people who use it. These are the choices that are hard to change later on.

Understanding the System's Environment

It's important to understand how a system fits into its surroundings. This includes how it will be used and what other systems it might interact with.

Decisions That Are Hard to Change

Since the architecture is planned at the very beginning, architects focus on decisions that need to be right from the start. If something is easy to change later, it might not be considered an architectural decision.

A Set of Design Choices

Software architecture isn't just about drawings or models. It also includes the reasons behind the choices made and why certain structures were picked. This helps everyone understand the thinking behind the design.

There isn't a clear line between software architecture, detailed design, and figuring out what a program needs to do. They all work together, like steps in a chain, from big ideas to small details.

Software Architecture Styles vs. Patterns

When building software, architects often use common ways to solve problems. These are like recipes or blueprints that have worked well before.

What Are Software Architecture Patterns?

A Software Architecture Pattern is a proven solution for a common problem that happens at the system level. It helps decide how parts of a system interact and what qualities the system should have (like being fast or secure). These patterns are like bigger, more general solutions compared to smaller "design patterns" that solve problems within a single part of a program. An example is the Circuit Breaker pattern, which helps a system recover when one part fails.

What Are Software Architecture Styles?

A Software Architecture Style is a high-level way of organizing a whole system. It defines how different parts are arranged, how they communicate, and what rules they follow. These styles are the broadest way to think about how a system is put together. Examples include:

Layered Architecture: Like a cake with different layers for different jobs.
Microservices: Many small, independent programs working together.
Event-Driven Architecture: Programs that react to events happening, like a notification popping up.

Common Mistakes in Software Architecture

Sometimes, architects can make choices that lead to problems. These are called "anti-patterns."

Delaying Decisions: An architect might be afraid to make a choice, fearing it's the wrong one. To avoid this, they work closely with the development team and make decisions at the "last responsible moment." This means waiting until they have enough information, but not waiting so long that it slows down the team.
Forgotten Decisions: Sometimes, important architectural decisions are not written down or are misunderstood. This can lead to the same discussions happening over and over. To fix this, architects write down their decisions, including why they made them, in a special record (like on a wiki page). This way, everyone knows the latest and most accurate information.

Key Features of Software Architecture

Software architecture has several important features:

Many Different People Involved

Software systems need to work for many different people, like business owners, users, and people who operate the system. All these people have their own ideas and needs for the system. A big part of designing the architecture is making sure everyone's needs are met. This means architecture involves many different skills and viewpoints.

Keeping Things Separate

To make complex systems easier to manage, architects separate different concerns. For example, they might have different drawings or descriptions (called "architectural views") that show how the system looks from different angles, addressing different people's needs.

Focused on Quality

While older ways of designing software focused on what the system would do, today's architects know that the architecture is more about how well the system performs. This includes things like:

Fault-tolerance: How well it handles problems.
Reliability: How consistently it works.
Security: How safe it is from attacks.
Usability: How easy it is to use.
Maintainability: How easy it is to fix or update.

These are often called "quality attributes" or "non-functional requirements."

Using Common Solutions

Just like building architects use standard ways to build houses (like different roof styles), software architects use standard ways to solve common problems. These are called architectural styles, tactics, or patterns.

Keeping the Main Idea Clear

A good software architecture has a clear, overall vision of what the system should do and how it should do it. The architect acts like the "keeper of the vision," making sure that any new parts added to the system fit with the original plan.

How Teams Affect Design

There's a famous idea called Conway's Law that says the way a team is organized often shows up in the design of the software they create. If a team has separate groups that don't talk much, the software they build might also have separate parts that don't communicate well.

Why Is Software Architecture Important?

Software architecture helps us understand a complex system in a simpler way. This has many benefits:

Testing Before Building: It allows us to check if a future program will meet everyone's needs *before* it's actually built. This saves a lot of money and reduces risks.
Reusing Parts: You can reuse parts of a software architecture, or even whole designs, in different projects. This saves design costs and avoids repeating mistakes.
Making Early Decisions: Getting the big, important decisions right early on helps prevent projects from going over budget or schedule.
Better Communication: It helps everyone involved talk about the system. People can understand the effects of their ideas and design choices before the system is built, when it's still easy to make changes.
Managing Risks: Good software architecture helps reduce risks and the chance of a project failing.
Saving Money: It helps manage costs in big computer projects.

History of Software Architecture

The idea of comparing software design to building architecture started in the late 1960s. However, the term "software architecture" didn't become widely used until the 1990s.

Computer science has always faced challenges with making things too complicated. Early on, developers solved these problems by choosing the right ways to store data and by breaking down problems into smaller parts. Even though the term "software architecture" is somewhat new, the basic ideas have been used by pioneers in software engineering since the mid-1980s.

Important scientists like Edsger Dijkstra and David Parnas in the late 1960s and early 1970s stressed that the structure of a software system is very important. In the 1990s, there was a big effort to define and organize the main parts of this field, focusing on architectural styles (patterns), ways to describe architecture, and how to document it.

Research groups have played a big role in developing software architecture as a field. Mary Shaw and David Garlan from Carnegie Mellon University wrote an important book in 1996 that helped spread ideas like software components (parts), connectors (how parts link), and styles.

Standards have also been created to help guide software architecture. For example, a standard called ISO/IEC/IEEE 42010:2011 helps people describe software architectures clearly. This standard now includes not just software and hardware, but also people, processes, and other parts of a complete system.

How Software Architecture Is Made

Making architectural decisions involves gathering information, explaining why a decision was made, writing it down, and sharing it with the right people.

A software architect's job is to match the qualities a system needs (like being fast or secure) with what the business wants. For example:

If customers need to be very happy, the system needs to be available, handle problems well, be secure, easy to test, and perform quickly.
If a company plans to combine with other companies, the system needs to be easy to expand, grow, adapt, and work with other systems.
If there's not much money or time, the system needs to be simple and possible to build.
If the product needs to be ready quickly, it needs to be easy to maintain, test, and put into use.

There are four main activities in designing software architecture. These activities are repeated and happen at different stages as a program is first built and then updated over time.

Architectural Analysis

This is about understanding the environment where the new system will work and figuring out what the system needs to do. This information can come from many different people and includes:

What the system will do (its functions).
How well the system will perform, like how reliable, secure, or fast it needs to be.
How easy it will be to maintain or transfer the system.
Business needs and other things that might change over time, like laws or new technologies.

The result of this analysis is a list of important requirements that will affect the software's architecture.

Architectural Design

This is the process of actually creating the architecture. Based on the important requirements and any evaluations, the design is created and improved.

Architecture Evaluation

This step checks how well the current design meets the requirements. An evaluation can happen at any point: when an architect is thinking about a decision, after part of the design is done, after the final design, or even after the system is built. There are special techniques to help with these evaluations.

Architecture Evolution

This is about keeping an existing software architecture updated and changing it to meet new needs or environments. Since the architecture is the basic structure of a system, changing it means changing that core structure. This involves adding new features and keeping existing ones working.

Architecture also needs supporting activities that happen throughout the main process. These include managing knowledge, making decisions, and documenting everything.

Supporting Activities for Architecture

These activities help a software architect with analysis, design, evaluation, and evolution. For example, an architect needs to gather information, make choices, and write things down during the analysis phase.

Managing Knowledge and Communication: This means finding and sharing information that is important for designing software architecture. Architects work with many people, getting ideas and requirements from them. This activity is about finding, sharing, and keeping this knowledge. It includes looking for design patterns, trying out ideas, asking experienced people, and writing down experiences on a wiki page.
Making Design Choices: This is about thinking through and deciding on design choices. It involves understanding the situation, figuring out the problems, finding possible solutions, and weighing the pros and cons before making a decision. This happens at different levels of detail. For example, an architect might think about how a requirement affects quality, what problems a design might cause, and which solutions are best.
Documentation: This is about writing down the design created during the software architecture process. The system design is often described using different "views" that show the code structure, how the system acts when it runs, and how it's placed on hardware. This includes writing specifications, recording design models, and explaining why decisions were made.

Strategies for Designing Software Architecture

Software architecture often deals with things that are not certain. The size of different parts of a program can really affect how well the system works. Experts Neal Ford and Mark Richards suggest a step-by-step approach to figure out the right size for these parts. This method involves constantly improving the design as teams learn more about how the system behaves and what it needs.

This approach usually involves a cycle with several steps:

First, a general plan for dividing the system into parts is made. This plan often focuses on technical aspects or different areas of the business. Rules are set for the smallest useful piece of the program. These early decisions can be changed later if needed.
Next, the first parts of the system are identified based on the plan.
Then, the requirements are assigned to these parts.
The jobs and responsibilities of each part are checked to make sure they are clear and don't overlap too much.
Important qualities like how well the system can grow or handle problems are checked.
Finally, the parts might be reorganized based on feedback from the development teams.

This cycle is a general guide and can be changed to fit different types of projects.

Important Software Architecture Topics

Software Architecture and Agile Development

Some people worry that planning too much architecture at the beginning (called "big design up front") can slow down agile software development, which focuses on being flexible and quick. However, many methods have been developed to balance early planning with flexibility. For example, the agile method DSDM includes a "Foundations" phase where just enough architecture is planned to get started.

Software Architecture Erosion

Software architecture erosion happens when the way a software system is actually built slowly drifts away from the original plan over time. This problem was first pointed out in 1992.

This "erosion" can happen at any stage of building software and can affect how fast new features can be added and how much it costs to maintain the system. It happens for reasons like:

Violating the Architecture: People make changes that don't follow the original architectural rules.
Technical Debt: Quick fixes are made that aren't ideal, creating problems that need to be fixed later.
Lost Knowledge: People forget or don't understand the original design decisions.

A famous example is the Mozilla Web browser. Its code became very hard to maintain because of constant changes and growing architecture erosion. Netscape spent two years rebuilding it, showing how important it is to manage architecture actively to avoid costly delays.

Architecture erosion can make software perform worse, greatly increase costs, and lower the quality of the software. Many tools and methods have been created to find this erosion early, such as checking if the code matches the architecture and analyzing the code automatically.

To deal with erosion, there are two main types of actions:

Preventative measures: These include making sure architectural rules are followed, regularly checking code, and using automated tests.
Remedial measures: These involve fixing the code, redesigning parts, and updating documentation.

Software Architecture Recovery

Software architecture recovery is about figuring out a software system's architecture from the information available, like its code and any existing documents. This is often needed when the original documentation is old or missing, or when the actual system has changed a lot from the planned architecture (due to architecture erosion). Methods exist to recover software architecture by analyzing the program's code.

Related Fields

Design

Architecture is a type of design, but not all design is architectural. The architect decides what is "architectural design" (big picture) and what is "detailed design" (smaller details). There are no strict rules for this, but generally, architectural decisions are those that are hard to change later and affect the whole system.

Requirements Engineering

Requirements engineering and software architecture work together. Requirements engineering focuses on "what" the system needs to do (the problem), while software architecture focuses on "how" to build it (the solution). Requirements engineering involves finding, discussing, writing down, checking, and managing what the system needs. Both fields are about understanding what people need and want from the system.

There's a lot of overlap between these two fields. Often, the needs of the system become clearer as the architecture starts to take shape. Also, how the system is designed can lead to new requirements.

Other Types of 'Architecture'

The word "architecture" is used in many different fields related to computers and systems.

Computer architecture: This focuses on the internal parts of a computer system, like the CPU (the brain), the bus (the communication lines), and the memory.

Serverless architecture: This is a way of building cloud-based programs where you don't have to manage servers yourself. Instead, a cloud provider handles them. This means businesses can run their code without worrying about physical servers. It uses small, specific functions that run only when needed, which can save money because you only pay for what you use.

Systems architecture: This term was first used for systems that have both hardware and software. It focuses on making sure the software and hardware work together correctly. More broadly, it can apply to the architecture of any complex system, whether it's technical, social, or a mix of both.

Enterprise architecture: The goal of enterprise architecture is to turn a business's vision and plans into effective systems for the whole company. It often looks at different layers of a business, like the business itself, the applications it uses, and the technology it relies on. It helps make sure these layers work together, usually starting from the top (business goals) down to the technology.