Architecture
An architecture is a blueprint that can be applied repeatedly and consistently within a system or across many systems.
The blueprint can take many forms:
- A set of specific standards that must be adhered to.
- A set of agreed design principles that must be followed.
- A set of recommended best practices.
- A partially completed design that can be extended as necessary.
Architectures may exist in many spheres of interest:
Application Architecture
A blueprint concerning the partitioning and
allocation of responsibilities within a software system. For example, the
principle that presentation details should be kept separate from business logic
is part of a blueprint for an application architecture.
Data Architecture
A blueprint concerning the data of interest in the
business domain. For example, the standard that defines mnemonics for currencies
is part of a blueprint for a data architecture.
Functional Architecture
A blueprint concerning the allocation of business
functions to software systems or modules. For example, the principle that all
customer information and processing should be allocated to “System X” is part of
a blueprint for a functional architecture.
Messaging Architecture
A blueprint concerning the exchange of information
between systems using messages. For example, a Java framework that supports the
creation and transmission of messages in a standard form is part of a blueprint for
a messaging architecture.
Process Architecture
A blueprint concerning the structure, organisation
and dynamics of a software development project. For example, the best practice of
managing project risk by developing iteratively is part of a blueprint for a
process architecture.
Technical Architecture
A blueprint concerning the use of technology and
tools. For example, a standard that limits the choice of database technology to DB2
or Oracle is part of a blueprint for a technical architecture.