Information Technology Reference
In-Depth Information
Engineering perspective
Deployment perspective
Logical perspective
Figure 5.3
Architectural perspectives.
has been involved in the requirements gathering process) to ascer-
tain their criticality. Customers are often open to making compro-
mises in their needs if they understand technology constraints, or
the resulting financial implications.
2.
. Architects
can decide on certain network and deployment topologies, or
choose third-party components that they think are appropriate to
the needs of the customer. They are, however, aware of the
constraints each of these choices will impose on the system and
its evolution.
The result of architectural choices made by the architect
Architecture Perspectives
Most approaches to creating a software architecture are somewhat similar,
yet some tend to be more comprehensive than others. Architects have a
tendency to be exhaustive in their creations, and even delve into design-
(and occasionally even coding-) level details. We do not encourage this
practice. Using SEE principles, we believe that there are three perspectives
that should be treated as
musts
to create a architectural description of the
system.
Logical Perspective
It is important that the architect dons the “systems thinker” hat at this
stage. Use this to describe the architecturally significant building blocks
— software and hardware components (or subsystems) — that together
constitute the system. It would be nice to show usage scenarios, and use-
cases and logical classes/structures for these components, but it is not
necessary, especially at the onset of creating the document. It is imperative
