System Architecture – Detailed Explanation

Software architecture is a set of principles that define the way software is designed and developed.
Architecture defines the structure of the software system and how it is organized. It also describes the
relationships between components, levels of abstraction, and other aspects of the software system.

Architecture can be used to define the goals of a project, or it can be used to guide the design and
development of a new system. Software architecture is a set of principles that define the way
software is designed and developed.

 The fundamental organization of a system, embodied in its components, their relationships to each other and to
the environment, and the principles governing its design and evolution. [5]
 A representation of a system, including a mapping of functionality onto hardware and software components, a
mapping of the software architecture onto the hardware architecture, and human interaction with these
components.[6]

*A description of the design and contents of a computer system. If documented, it may include information such
as a detailed inventory of current hardware, software and networking capabilities; a description of long-range
plans and priorities for future purchases, and a plan for upgrading and/or replacing dated equipment and
software.

Introduction

The architecture of a system reflects how the system is used and how it interacts with other systems
and the outside world. It describes the interconnection of all the system’s components and the data
link between them. The architecture of a system reflects the way it is thought about in terms of its
structure, functions, and relationships.

In architecture, the term “system” usually refers to the architecture of the software itself, rather than
the physical structure of the buildings or machinery. The architecture of a system reflects the way it is
used and therefore changes as the system is used.
Therefore, the system is always described in terms of its parts and their operations. In the same way,
data is always described in terms of the elements which compose it and the operations which make it
useful to an end user. Now that we know the system and its parts, let’s dig into the data.

What is a System Architecture Diagram?

The system architecture diagram is an abstract depiction of the system’s component architecture. It
provides a succinct description of the system’s component architecture in order to assist in
component-component relationships and system functioning.

The system architecture diagram is a visual representation of the system architecture. It shows the
connections between the various components of the system and indicates what functions each
component performs. The general system representation shows the major functions of the system
and the relationships between the various system components.

Now, development teams must be divided into different regions to ensure that all the systems are
developed on the client side by one team and that the backend is developed by another team, and
the database is developed by the last team.

The team will work with a common system architecture diagram, and they will be able to use it as a
reference when designing their new system. A common architecture diagram for a new system
provides a good starting point for the team to work from. It provides a common language for
communicating system design, as well as a way to track the status of the system.

Benefits of Using System Architecture

The following are benefits associated with system architecture.

 The system architecture diagram is a visual representation of the software architecture. It

depicts the system architecture, including its context, components, relationships, and
dependencies. The key to a good system architecture is to clearly communicate its
requirements to your stakeholders and developers and to have a well-defined system
architecture from the beginning. A well-defined system architecture enables you to focus on
 the development of the software, and avoid long-term problems with integration and
operational issues.
 Customer satisfaction provides the key to great architecture. If you do not hear the customers’
voices in your decision-making, you will not know what direction to take. It does not matter how
great the architect is if the customers do not buy the product. The same applies to your
software architecture. It does not matter how good the developer is if the end-user does not
feel comfortable with the software. In order to know what to build and how to build it, you need
to know what the customer values and how to keep them happy.
 The diagram shows the customer value that a supplier’s product or service adds to the
customer’s business. It also shows the value of the supplier’s market position to potential
customers. As a supplier’s value increases, so does the diagram’s importance. For a high-
value supplier, the diagram is often expanded to show the customer value the supplier’s
solution adds to the customer’s business.
 It is essential that you make it a point to keep your system architecture diagrams up to date.
The system architecture diagram shows the current state of the system and the dependencies
between the modules. Outdated or incorrect diagrams can cause a lot of trouble. The
regulatory bodies need to see an up-to-date system architecture to make sure that the system
complies with their standards. When the regulatory bodies’ standards become complacent,
your reputation decreases in their eyes and they can fine you up to billions of dollars. When
the regulatory bodies’ standards are out of date, they can negatively impact your company’s
reputation.

System Architecture Diagram Examples

It is critical to become familiar with the system architecture in order to appreciate its implications. In
this section, we will discuss the system architecture in more detail.

1. System Test Architecture Diagram

The software is also checked using the data provided by the operational layers, which includes
information about how the software is used by users. This data is collected using metrics and
measurements that are connected to the data, such as the number of failed test cases, time to fail
test cases, and average time to failure. The system also tests the code against the data that is
provided by the business users, including how the software is used by the business users and how
the system is used by partners and customers of the business. This data is gathered using the usage
data that is connected to the data, such as the number of requests for the software, the number of
times the software was used, and the amount of data used for each request. The system is also
connected to the data that is provided by the users, such as how the software is used by end users,
what problems the users have, and what actions the users take to improve the software. Combining
information about how many questions were asked, how many answers were given, and how many
recommendations were given, this data can help improve the system.
2. Content Assignment System Architecture Diagram

The database structure also includes the process of receiving assignments and assigning them to
students or learners. This process may be implemented as a workflow or a set of procedures. In
either case, the process of receiving an assignment and assigning it to a student or learner is known
as assignment tracking. This process is implemented as a workflow and thus the architecture is
referred to as a workflow-based architecture.
3. E-Learning System Business Architecture Diagram

The learning process then consists of the following activities: collection of data, analysis of data,
presentation of learning material, evaluation of learning material, and closing of the learning process.
The presented system architecture diagram is intended for the E-learning System Business
Architecture. The system architecture is a representation of the business or customer requirements.
The diagram illustrates all of the components that make the system function. As outlined in the
overview, the architecture illustrates how the system functions in general. The system, as a
hypothetical user, first registers himself via The presented system architecture diagram is intended for
the E-learning System Business Architecture. The system architecture is a representation of the
business or customer requirements. The diagram illustrates all of the components that make the
system function. As outlined in the overview, the architecture illustrates how the system functions in
general. The system, as a hypothetical user, first registers himself via the client application and this
information is saved in the database. The student may now gain access to the material in the
learning. The learning process then consists of the following activities: collection of data, analysis of
data, presentation of learning material, evaluation of learning material, and closing of the learning
process.
Conclusion

The design of an application involves many factors, including the software architecture. An application
architecture describes the structure of the software, including its components, data models, and
programming models. It also describes how the application is built and maintained, including how it is
tested and maintained. The architecture of an application can be divided into three main categories:
The first category is the software architecture. This describes the structure of the software, including
its components, data models, and programming models. It also describes how the application is built
and maintained, including how it is tested and maintained. The second category is the software
development model. This describes how the application is built and maintained, including how it is
tested and maintained. The third category is the maintenance model. This describes how the
application is maintained, including how it is tested and maintained. The application architecture
should be designed to meet the needs of both current and future users. It should be flexible enough
to accommodate changes in technology and user needs while providing a solid foundation for future
growth.
SYSTEM ARCHITECTURE

 A representation of a system, including a mapping of functionality onto hardware and software

components, a mapping of the software architecture onto the hardware architecture, and human
interaction with these components.[6]

software component is a software package, a web service, a web resource, or a module that
encapsulates a set of related functions (or data).
All system processes are placed into separate components so that all of the data and functions inside
each component are semantically related (just as with the contents of classes). Because of this
principle, it is often said that components are modular and cohesive.
With regard to system-wide co-ordination, components communicate with each other via interfaces.
When a component offers services to the rest of the system, it adopts a provided interface that
specifies the services that other components can utilize, and how they can do so. This interface can
be seen as a signature of the component - the client does not need to know about the inner workings
of the component (implementation) in order to make use of it. This principle results in components
referred to as encapsulated. The UML illustrations within this article represent provided interfaces by
a lollipop-symbol attached to the outer edge of the component.
However, when a component needs to use another component in order to function, it adopts
a used interface that specifies the services that it needs. In the UML illustrations in this article, used
interfaces are represented by an open socket symbol attached to the outer edge of the component.

A used.
Software components often take the form of objects (not classes) or collections of objects
(from object-oriented programming), in some binary or textual form, adhering to some interface
description language (IDL) so that the component may exist autonomously from other components in
a computer. In other words, a component acts without changing its source code. Although the
behavior of the component's source code may change based on the application's extensibility,
provided by its writer.
When a component is to be accessed or shared across execution contexts or network links,
techniques such as serialization or marshalling are often employed to deliver the component to its
destination.
Reusability is an important characteristic of a high-quality software component. Programmers should
design and implement software components in such a way that many different programs can reuse
them. Furthermore, component-based usability testing should be considered when software
components directly interact with users.
It takes significant effort and awareness to write a software component that is effectively reusable.
The component needs to be:

 fully documented
 thoroughly tested
o robust - with comprehensive input-validity checking
o able to pass back appropriate error messages or return codes
designed with an awareness that it will be put to unforeseen uses

Software architecture Software architecture is the set of structures

needed to reason about a software system and the discipline of creating such
structures and systems. Each structure comprises software elements, relations among
them, and properties of both elements and relations.
The architecture of a software system is a metaphor, analogous to the architecture of a
building.[3] It functions as the blueprints for the system and the development project,
which project management can later use to extrapolate the tasks necessary to be
executed by the teams and people involved.
Software architecture is about making fundamental structural choices that are costly to
change once implemented. Software architecture choices include specific structural
options from possibilities in the design of the software.
For example, the systems that controlled the Space Shuttle launch vehicle had the
requirement of being very fast and very reliable. Therefore, an appropriate real-time
computing language would need to be chosen. Additionally, to satisfy the need for
reliability the choice could be made to have multiple redundant and independently
produced copies of the program, and to run these copies on independent hardware
while cross-checking results.
Documenting software architecture facilitates communication between stakeholders,
captures early decisions about the high-level design, and allows reuse of design
components between projects.

Hardware architecture
, hardware architecture refers to the identification of a system's physical
components and their interrelationships. This description, often called a hardware
design model, allows hardware designers to understand how their components fit into
a system architecture and provides to software component designers important
information needed for software development and integration. Clear definition of a
hardware architecture allows the various traditional engineering disciplines (e.g.,
electrical and mechanical engineering) to work more effectively together to develop
and manufacture new machines, devices and components.
Hardware architecture is the representation of an engineered (or to be engineered)
electronic or electromechanical hardware system, and the process and discipline for
effectively implementing the design(s) for such a system. It is generally part of a larger
integrated system encompassing information, software, and device prototyping.

 Several types of systems architectures

 Hardware architecture
 Software architecture
 Enterprise architecture
 Collaborative systems architectures(such as the Internet, intelligent transportation
systems, and joint air defense systems)
 Manufacturing systems architectures
 Strategic systems architecture

List of Principles

Principle: underlying and long enduring fundamentals that are always (or almost always) valid.

For each pricinple, a short description is provided, along with longer normative and
descriptive explanations, and hopefully an example. If the principle is inspired by a
person, a thing, or a quote, that attribution should be given and/or explained.

There is no one perfect way to phrase a principle: wording is significant, but the spirit
of the principle is more important.

What Is Good Architecture?

1. A good architecture is one that meets the needs of the stakeholders (especially the users)
to their satisfaction, does not violate established principles of system architecture, and
takes into account the relevant ilities by allowing for maintenance, evolution, further
development, embedding, etc. as the customer requires.
2. Really good architectures are also elegant (intellectually clean of unnecessary
complexities or 'exceptions'), can direct a builder to cost-effective structures that can be
completed within a reasonable time frame, conceptually pleasing to all stakeholders
(especially the user), and provide some special advantage (such as a competitive
advantage) or utility to the customer.

Robust Functionality Drives Essential Complexity

 1. Essential complexity is that which is essential to deliver functionality before gratuitous
complexity slips in.
2. Functionality drives complexity in any given concept.
3. But “Functionality” is often defined as a surrogate for a much broader set of functions for
which the product will actually be used.
4. Therefore, it is the (often implicit) robust functionality which drives essential complexity.

Every System Consists of Subsystems

1. Every system consists of subsystems.
2. Alternatively, every system can be viewed as a part of another system, up to the whole
universe.
3. The interfaces between subsystems are a place of key leverage for the architect.
4. Therefore, the architect should spend a significant chunk of his/her efforts on designing
and clearly specifying these interfaces.

All Design Processes Should Involve Iteration

1. All design processes can and should involve iteration.
2. Many systems are too complex, and many architects are not competent enough, to do a
perfect job on the first pass.
3. Many data points only become available later in the architecture or design process.
4. Therefore, every architecture design process should involve iteration: the process should
be designed to be conducted over and over again until a satisfactory solution is reached.

Local versus Global Optimality

1. The optimal architecture or design for a given subsystem may result in sub-optimal
global functionality of the bigger system.
2. Therefore, the architect must be cognizant of the global system when optimizing and
designing subsystems.

Omnipresent Risk

1. Every system has risks associated with it.

 2. Risks can rarely be completely eliminated, but they can be noted and accommodated in
the architecture.
3. A well-designed architecture is robust to these risks, can continue to function if they
materialize.

The Customer is the Judge of Quality

1. An architecture that satisfies the architect but not the customer is useless.
2. The customer should be involved in the process as much as possible, giving frequent and
honest feedback on all aspects of the system architecture.
3. While the architect may attempt to educate the customer to their mutual benefit, in cases
of difference of opinion it is the customer's opinion that matters.

Holistic Thinking
1. The architect should strive to think holistically about the system, its components, its
usage contexts, and other relevant systems.
2. Holistic thinking is important in coming up with the best possible architecture.
3. If the architect does not think holistically, he or she may miss important factors that
should influence the system architecture.

Modularity
1. One of the architect's roles is to ensure the best modularization of the system architecture,
so as to allow for all the benefits of modularity: easier testing, easier accommodation of
new requirements at the component level, and easier accommodation of new components
at the system level.

KISS (Keep It Simple, Stupid)

1. The architect should strive to adhere to the KISS principle, "keep it simple, stupid." # The
system architecture should be as simple as possible without conflicting with other design
principles.
2. Architectures that are more complex than necessary will result in sub-optimal systems.
3. This principle is also known as Occam's Razor.
4. And much more documentation exists, e.g.
i. Filip Hanik's

Identity
 1. Everything that exists have a specific set of characteristics or identity that describe what
it is.
2. A system's identity is based on the identities of its constituent parts and how they interact
together. In other words, an entity is more than the sum of its parts.
3. Because system features are parts of a system identity, system designers need to
understand the decompositions and the inner interactions of these parts in a system.

Conceptual Brilliance Doesn't Blind the Laws of Physics

1. A system architecture may be elegant, but the architect must not become so enamored
with his or her work so as to lose track of the basic governing laws of the usage context
in which the system operates.
2. Most of the time, the laws of physics must be obeyed: perhaps if the system is to be
operated in a complete vacuum in outer space, some may be relaxed, but not all ;)
3. Therefore, the architect and other stakeholders must not be blinded by the beauty (in their
eyes) of their creation, and always review features with a pragrmatic and detail-oriented
eye as well.
4. The inspiration for this principle comes from the 1996 Woodruff Distinguished Lecture,
delivered by Norman R. Augustine, at the time the Chairman and Chief Executive Officer
of Lockheed Martin Corporation.

Develop a common language for your team

1. Not only is the job of the architect to drive ambiguity out of the system by defining the
boundaries of the system, to creating the concept of the system, by allocating
functionality and defining interfaces and abstractions, but the architect need to be able to
communicate these goals completely and clearly in the deliverables. Moreover, a
common language is needed for continuous communication among team members
throughout the developmental process. It is the architect’s job to define the language of
the system.
2. The architect must not allow ambiguity to creep back into the system through difficulties
in communication. The architect must create a basic method of communication, so that
all team members can communicate clearly and accurately.
3. On any given project, an architect has the responsibility of getting everyone on the same
page so that they can speak about their system in common terms. One example from
industry is the use of UML in many projects. UML provides a common language for
teams to communicate about designs.

Garbage In, Garbage Out

 1. The quality of a system architecture depends largely on the inputs provided to the
architect.
2. The architect is partially responsible for ensuring high-fidelity inputs. For example, the
architect should identify sources for user needs appropriately, and obtain user needs from
them, rather than through other indirect or secondary sources.
3. If low-fidelity, noisy, inaccurate, or otherwise low-quality upstream data is provided to
the architect, the system will suffer with a sub-optimal architecture.
4. Communications, cross-checking, and other data gathering and verification approaches
can and should be used to ascertain the quality of data being used to design the system
architecture.
5. Inspired by the corresponding computer science principle.

Between the Idea and Reality Falls a Shadow

1. The ability of state an idea simply does not neccessarily or frequently lead to simplicity
in execution of said idea.
2. The architecture concept or design may seem simple or logically flow on paper, but often
times in reality the challenges of cultures, technology interfaces and other real world
issues prove more problematic than anticipated.
3. The difference between espoused ideas and the action of people often do not align. This
is exemplified when individuals brief plans and everything sounds great but the
environment in which the plan will be executed is not considered in the planning process.
This generally results in significant problems and plan changes. An example of this is the
difficulty of successfully implementing the business principle of buying cheaply and
selling dearly to amass great fortune.

Must Do To Learn
1. No class or homework is sufficient for one to become a good system architect.
2. A well-designed course, such as MIT's ESD.34 System Architecture offering, teaches the
important concepts, provides examples, and most of all, attempts to instill in the student a
way of thinking appropriately about systems and system architecture.
3. However, such courses are no substitute for real experience. The only way to become a
good system architect is to serve in this role on multiple projects, preferably (at least
initially) working under the guidance of more experience architects.
4. Prescriptive version: to be a good system architect, one must have been properly educated
and had experience in the system architect role on at least one significant real-life projct.
5. Descriptive version: a good system architect is one who is both educated and experienced
in the role.
6. Inspired by the ancient Chinese proverb: ""I hear and I forget, I see and I remember, I do
and I understand."
Systemic Uncertainty
1. Decisions are almost always based on uncertain information and almost always depend
on future things happening, future technologies, future values...
2. Accordingly, these decisions are best made using appropriately weighted systemic
uncertainty measures.
3. Inspired by Thomas Speller, an MIT PhD student as of 2005, during a discussion for
MIT's ESD.34 System Architecture course.

Standardized Process Improvement

1. A process should be standardized before it's improved, for maximum effect. If a process
is not standardized the benefit from improvement will be reduced.
2. Inspired by Thomas Speller, an MIT PhD student as of 2005, during a discussion for
MIT's ESD.34 System Architecture course.

Early Defect Elimination

1. Defects should be identified and eliminated as early as possible in the product
development process.
2. The later you are in the process, the more expensive and/or difficult it is to fix defects
appropriately.
3. Inspired by Thomas Speller, an MIT PhD student as of 2005, during a discussion for
MIT's ESD.34 System Architecture course.

Value is Identified Outside

1. Most often, customers judge the value of a product, system, or service by looking at its
external interfaces and their function and form. They frequently treat the product/system
as a black box for their use and for their value.
2. The architect should keep this mind, and maximize the perceived value of the system by
focusing on its external interfaces, external form, and externally-delivered function. Of
course, the architect must also keep the internal modules and sub-systems in mind.
3. Inspired by the common proverb "Don't judge a book by its cover" which unfortunately
many people do -- that's why the proverb is a proverb ;)