3/27
Another problem is what we usually call industry standards. A long
time ago, the process of coming up with a standard was basically the
following: try a couple of alternatives; see which one is best; set up a
committee that defines the standard, based on the experiences made
before, the standard is usually close to the solution that worked best.
Today, this is different. Standards are often defined by a group of
(future) vendors. Either they already have tools, and the standard must
accommodate for all the solutions of all the tools of all the vendors in
the group, or, there is no practical previous experience and the standard
is defined “from scratch”. As a consequence of this approach, standards
are often not usable (because there was no previous experience), or
overly complicated (because it must satisfy all the vendors…). Thus, if
you use standards for too many aspects of your system, your system will
be complicated!
All these things together prevent people from thinking about the really
relevant aspects of an architecture. In my opinion, these include
architectural patterns, logical structures (architectural metamodels),
programming models for developers, testability, and the ability to
realize key QoS concerns.
The following pages sketch something that I consider a reasonable
approach to software architecture. It also paves the way to automating
many aspects of the software development, a key ingredient to model-
driven software development [SV05] and Product Line Engineering.
Of course I am not the only one seeing this problem in current software
architecture. There are good architectural resources you should
definitely read, such as [POSA1, 2 and 3] as well as [JB00], [VSW02]
and [VKZ04].
Patterns Overview
The approach is structured into three phases.
Elaboration: In the first phase, the elaboration, you define a
TECHNOLOGY-INDEPENDENT ARCHITECTURE. Based on it, you define a
nice and workable
PROGRAMMING MODEL for the developers that work
with the architecture. In order to let developers run their stuff locally, a
MOCK PLATFORM is essential. Finally in this phase, you define one or
more
TECHNOLOGY MAPPINGS which project the TECHNOLOGY-
INDEPENDENT ARCHITECTURE to a particular platform that provides the
required/desired QoS features. A
VERTICAL PROTOTYPE verifies that the
system performs as desired – here is where you run the first load tests
and optimize for performance – and that developers can work efficiently
with the
PROGRAMMING MODEL.
Iteration: The second phase iterates over the steps in the first phase.
While I generally recommend an agile approach, I want to outline
