Preface
Many
excellent
books have been written on software architecture.
These books, which, among other things, define, classify, and
describe software architectures, define notations for representing
and communicating architectural choices, and provide guidance on
making good architectural decisions, have
enduring
value.
Unfortunately, while these books may help you build a successful
architecture,
they fall short of the goal of helping
you create a
winning solution.
To create a winning
solution, you need to move beyond subsystems and interfaces, beyond
architectural patterns such as Front Controller or Pipes and
Filters, and beyond creating third-normal-form relational
databases. You need to move beyond software architecture and move
toward understanding and embracing the business issues that must be
resolved in order to create a winning solution.
An example of one such business issue concerns technical
support. It is inevitable that some of your customers are going to
have a problem with your software. The choices you've made long ago
in such areas as log file design, how the system is integrated with
other systems, how the system is configured, or how the system is
upgraded will determine how well you can solve their problems.
Beyond Software Architecture
helps you move beyond
software architecture and toward creating winning solutions by
discussing a wide range of business issues and their
interrelationship with architectural choices.
This book
presents
a unique perspective that is motivated and
informed by my experiences in creating single-
user
programs costing
less than $50; software systems used in academic research;
utilities to diagnose and fix problems associated with internally
developed systems; and distributed, enterprise-class platforms
costing millions of dollars. Along the way, I've
played
a variety
of roles. I've been an individual
contributor
, a direct manager,
and a senior member of the corporate executive staff. At various
times I've either worked in or led engineering, product marketing
and management, quality assurance, technical
publications
, and
first- and second-line support organizations. I've managed
teams
and projects across multiple cities and continents.
The common thread tying all of this software together is that it
was created to provide value to some person. Research software, for
example, serves the needs of the researchers who are trying to
understand some phenomena. Enterprise application software, dealing
with everything from customers to supply-chain management, is
designed to serve the needs of a
well-defined
set of users and the
businesses that license it in a sustainably profitable manner.
Similar comments apply to every other kind of software, from
games
to personal contact managers, inventory management systems to
graphic design tools.
The issues identified and discussed in this book affect every
kind of software. Their presentation and discussion occur most
often in the context of enterprise application software, where I
have spent most of my professional career. While they have no
universally
accepted definition, enterprise applications typically
meet one or more of the following characteristics:
-
They are designed to support the needs of a business, at either
a departmental or larger organizational unit.
-
They are relatively expensive to build or license
($50,000$5,000,000 and up).
-
They have complex deployment and operational requirements.
-
They can be operated independently, but the needs of the
business are often best
served
when they are integrated with other
enterprise applications.
Even if you're not creating an enterprise application, you will
find this book useful. Creating sustainable software
solutionsmeeting customer needs over a long period of time through
multiple releasesis a challenging, enjoyable, and
rewarding
endeavor,
certainly
not limited to the domain of enterprise
applications!
Although I will often refer to software architecture and discuss
technical matters, my discussions won't focus on such things as the
best ways to diagram or document your architecture or the deeper
design principles associated with creating robust, distributed
Web-based component systems. As I said earlier, there are plenty of
books that address these topicsin fact, almost
too
many, with the unfortunate side-effect that many people become so
focused on technical details that they lose sight of the business
value they're trying to provide.
Instead of
concentrating
on purely technical choices,
Beyond Software Architecture
helps you create and
sustain truly winning solutions by focusing on the practical,
nuts-and-bolts choices that must be made by the development team in
a wide variety of areas. I have found that focusing on practical
matters, such as how you should identify a release or integrate
branding elements into your solution,
reduces
the often artificial
barriers that can exist between developers and the business and
marketing people with whom they work.
These barriers prevent both groups from creating winning
solutions. I cringe when
engineers
take only a
techno
logy
view without due consideration of
business
issues, or when marketing people make
"get-me-this-feature" demands without due consideration of their
underlying technical
ramifications
. When either side takes a
position without due consideration of its impact, the
likelihood
of
creating and
sustaining
a winning solution
drops
dramatically.
What is
especially
troubling is that these arguments seem to be
made in support of the idea that technical issues can somehow be
separated from business issues, or that business issues can somehow
be separated from technical issues. At best this is simply wrong;
at worst it can be a recipe for disaster. Developers are routinely
asked to endure the hardships of design extremes, such as a
low-memory
footprint, in order to reduce total system cost. Entire
companies are started to
compete
in existing markets because
investors are convinced that one or more technological
breakthroughs will provide the competitive advantage necessary for
success. Not surprisingly, investors are even more
eager
to invest
when the technological breakthrough is accompanied by a similar
breakthrough
in the business model being
offered
to customers.
Managing the interrelationship between technology and business
will be a recurring theme throughout this book. Handle only the
former and you might have an interesting technology or, perhaps, an
elegant system,but one that ultimately withers because no one is
using it. Handle only the latter and you'll have a paper solution
that excites lots of people and may even get you fundingbut one
that doesn't deliver any sustainable value. Handle both and you'll
have a winning solution. While creating new technologies or elegant
systems can be fun, and designing sophisticated new software
applications or business models can be exciting, both pale in
comparison to the deep satisfaction that comes from creating
winning solutions and sustaining them.
|