The common architectural views are

1. The functional view

2. The concurrency view
3. The code view
4. The development view
5. The physical view
The functional view
The functional view is an abstraction of system function and their relationships.
The component of the functional view are functions, key system abstractions,
and domain elements. The relationships between components are dependencies
and data flows.
The users of this view are domain engineers, product line engineers, and end
users. The stakeholders think about the view in terms of the functionality and
data flow the architecture will support.
One might create a database group, a transaction management group, user
interface group in response to identifying the functionality important for this
group.

The concurrency view

When a complex system is deployed it is typically packaged into a set of
processes or threads which are deployed on a computational resource. The
concurrency view is a necessary step for reasoning about what processes or
threads will be created and how will they communicate and share the resources.
The users of this view are people who worry about deploying the system and are
concerned with performance and availability of the system as well as integrators
and testers.

Code view
The code view is what the programmer sees. The components of this view are
classes, object, procedures, and functions and their abstractions/ composition
into things like subsystems, layers and modules. The relationships are again
what the programmer sees call and method invocation as well as containment
relation like is a sub module of.
The users of this view are programmers, designers and reusers. They use this
view to reason about modifiability, maintainability, portability and making
subsets of the system.
Development view
The development view is another view that the developer sees but it is distinct
from the code view. It is the view of the structure of the source code as a
repository that various users create, modify and manage. The components of
this view are files and directories. The main relationship between files and
directories are containment.
The users of this view are programmers, maintainers, configuration managers.
These stakeholders use this view to reason about maintaining, development and
testing the system for configuration management and versions.
This view provides a focus for the systems stakeholders when determining
division of labor, testing , integration and maintenance.

Physical view
The physical view of a system describes how a system is deployed in terms of
the hardware resources. For a single trivial system the system is installed on a
single machine. But for a large complex system there are a number of sensors,
actuators, storage devices, networks and computers.
The users of this view are hardware and software engineers who have to worry
about system delivery, installation and upgrades as well as performance,
availability, scalability and security.

Architecture as a manifestation of earliest design decisions

A software architecture is a coherent justified collection of systems earliest set
of design decisions. These decisions will affect what the system will become.
Firstly the design decisions will help you achieve the required systems quality
attributes. For example if your system has stringent performance requirements
then as an architect you need to pay attention to intercomponent communication
and component execution time. If there are modifiability/ maintenance
requirements then we need to pay attention to encapsulation requirements. If
security is a concern then there is need to pay attention to inter component
communication and data flows. Also there can be certain new elements
introduced such as security kernels and encrypt/decrypt functions. If reliability,
availability is important then architecture needs to provide redundant
components with warm or hot restart protocols. All these approaches are
achieving quality attributes are architecture in nature having to do with
decomposition of the system in parts and ways in which those parts
communicate and cooperate with each other to carry out their duties.
The architecture will affect the organization. There is always a strong
correspondence between architectural structure that define coherence grouping
of functionality and coherent group of concerns. The concurrency view may
suggest a need for separate teams that does the performance planning modeling
and tuning. Each of these teams might do their own analysis and require
specialized tools, training and knowledge. The code and development view also
dictate system structure in terms of module, subsystem and layers. The module,
subsystem and layers represent high internal cohesion and low data coupling.
The early design decision could also affect the choice of commercial
components which are used for implementation.
The generic architectural styles are
1. Independent Components, communicating processes
2. Data Flow, batch sequential pipe and filter
3. Data centric, repository, black board
4. Virtual machine interpreter, rule based
5. Call/return main program and subroutine, object oriented, layered.