So you want to become
a software architect? Or perhaps you are already a software
architect, and you want to expand your knowledge of
the discipline? This is a book about achieving and maintaining
success in your software career. It is also a book about
an important new software discipline and technology,
software architecture. This is not a book about getting
rich in the software business; our advice helps you
to achieve professional fulfillment. Although the monetary
rewards of this career are substantial, often, what
motivates many people in software architecture is being
a continuous technical contributor throughout their
career. In other words, most software architects want
to do technically interesting work, no matter how successful
and experienced they become. So the goal of this book
is to help you achieve career success as a software
architect and then maintain your success.
In this book, we
cover both heavyweight and lightweight approaches to
software architecture. The role of Software Architect
has many varied aspects, an architect is: part politician,
part technologist, part author, part evangelist, part
mentor, part psychologist, and wears many more hats.
At the epitome of the software profession, the Software
Architect must understand the viewpoints and techniques
of many players in the IT business. We describe the
discipline and process of writing specifications, what
most people would consider the bulk of software architecture,
but we also cover those human aspects of the practice
which are most challenging to architects, both new and
1.0 Advice for Software Architects
"Success is easy; maintaining success
is difficult." - J.B.
If you have a focus
for your career, gaining the knowledge you need to advance
can be relatively easy. For software professionals,
simply doing more to build your expertise is all that
is needed in most corporate environments. For example,
we often ask software people what books they have read.
In the west, most professionals are familiar with design
patterns (See Section 1.3). And many have purchased
the book by Erich Gamma and co-authors that established
the field of design patterns. [Gamma 95] Some have even
read it. However, it always surprises us how few people
have read anything further on this important topic.
For software architect
books, the situation is even worse. Possibly because
there are fewer popular books. But more likely because
people are not really focused on software architecture
as a career goal. In this book series, we are eliminating
the first obstacle to establishing a software architecture
profession, by publishing a common body of knowledge
about software architecture theory and practice. However,
making this information available does not automatically
change people's reading habits.
So, if the average
software professional only reads about 1 book per year,
just think what you could do in comparison. If you read
3 books on design patterns, you would have access to
more knowledge than the vast majority of developers
on that important topic. In our own professional development,
we try even harder. At least a book each month, and
if possible, a book every week. Some books take longer
than a week. For example, the 1000 page book on the
Catalysis Method. [D'Souza 98]. In our opinion, it contains
breakthroughs on component-oriented thinking, but so
few people are likely to read it thoroughly (except
software architects), that it becomes a valuable intellectual
tool for making you (the reader) a thought leader, as
the entire industry moves through the difficult transition
to component-based development.
social systems, it's the perceptions, not the fact,
that count." [Rechtin 97]
Getting ahead on
book reading is a clearcut way to differentiate yourself
from the software masses. Converting your book learning
to real-world success is also straightforward. You can
apply your knowledge on your current projects. You can
covert your knowledge into briefings and tutorials that
put you in visible leadership and teaching roles. You
can share you knowledge at conferences and professional
groups. And you can write. The key transition that leads
to success starts with sharing your knowledge one to
one (e.g. inefficiently), and proceeding to knowledge
sharing with many at a time. In our own careers, when
we began to share knowledge in one to many situations,
the appearance of success came with it. Since, for most
people, appearance is reality, success is easy to attain.
The much more difficult challenge is maintaining success,
once you've achieved it.
The software architecture career path is a difficult
one for many reasons. While becoming a competent software
architect can be difficult; maintaining your skills
is usually even harder. Here are some of the key reasons
why the architecture career is difficult:
- Nascent Body of Knowledge
- Confusion and Gurus
- Professional Jealousy
- The Management Trap
- The Software Crisis
We discuss each of
these in the following subsections.
Body of Knowledge
First of all, the body of software architecture knowledge
is not well established. Software architecture is a
relatively new field of computer science. There is not
much software architecture taught in schools. Academics
have not yet sorted out many fundamentals. In fact,
there is still much discussion and disagreement on the
However, many practicing
software architects believe that sufficient knowledge
does exist. The pratice of software architecture is
much more mature than many will admit. Hopefully, you
will gain this understanding too, after reading further.
In the absence of
widespread agreement about software architecture theory,
you have to be your own expert. To be a software architect,
you have to acquire your own set of knowledge and strong
set of beliefs about how to do software right. No one
book or software method will give you everything that
you need to be an effective software architect.
become political problems." [Rechtin 97]
There are many published software approaches, which
claim to provide the benefits of software architecture,
but can't deliver on their promises, in most instances.
In fact, the software industry has created many technology
fads and trends, which are based on incomplete principles.
When these approaches are applied in practice, software
projects fail. And guess what? The overwhelming majority
of corporate development projects do fail, by being
cancelled or overspending for under-delivery.
The software products
industry has not suffered based upon this almost universal
failure of corporate development. In contrast, it has
thrived. These failures are characteristic of a vast
corporate software market, populated with companies
that are struggling to deliver their internal software.
New products and software development ideas are constantly
being produced, in a never-ending attempt to meet the
needs of the struggling software masses.
As a software architect,
you have to be an evangelist and leader for your software
team. You need to sort out what works and what does
not work from the myriad of conflicting software approaches
and products. This is not easy because there is a tremendous
onslaught of marketing information generated by vendors
and industry experts that tend to contradict your architectural
messages. It is your fate to have your architectural
decisions frequently contradicted and obsolesced by
the commercial software industry. One of your key skills
as a architect, is to make sound decisions that can
survive the ravages of time and commercial innovation.
The more successful that you become, the more some people
will resent your success. Many software professionals
are genuinely nice people. But there are many people
in our profession who have large egos. We all have egos
that can be abrasive, but whether you intend to compete
on the basis of ego or not, professional competition
can create serious problems in software organizations
and in your career, unless you are careful.
Challenge the process
and solution, for surely someone else will." [Rechtin
As a software architect,
professional jealousy is a factor that you will have
to watch for vigilantly. You must learn to conduct yourself
with a certain degree of humility, and be prepared to
defend yourself when necessary. Learn to never take
any comment personally; it's always a mistake. Consider
that someone you just met who appears to be acting quite
rudely, might be acting in their usual manner, in the
eyes of people who already know them and disregard their
As you become more successful in your software career,
it's more likely than not, that you will be joining
the ranks of management, since most companies organize
around a single management ladder. If you are good at
what you do, it is natural for management to want you
to mentor and supervise other people doing it too. The
company can try to get the productivity of several good
performers based upon your experience.
As your administrative
responsibilities increase, your time to perform technical
work can decrease dramatically. Because there is less
time on technical tasks and less time for maintaining
your technical skills, you can lose your technical edge.
If you chose a software career because you enjoyed technical
work, you can lose one of your most important motivations
for your work.
Being a software
architect is quite different than being a manager. A
software architect is a direct technical contributor,
whereas a manager contributes indirectly by coordinating
the actions of other people. Together, managers and
architects make highly effective leadership teams. In
our experience, combining the two roles can work only
As you advance as a manager, eventually a superior will
tell you to stop touching the keyboard. (i.e. programming).
LESSON END A software architect can avoid becoming a
manager if they establish a personal professional policy.
If you don't want management duties, you must learn
how to say so. For many of us, one of the most difficult
transitions is learning how to say 'No". For example,
you have to avoid lateral promotions that lead to management
and administrative roles.
In some organizations
you will become trapped in a management role, because
the company does not have a technical ladder. At a certain
level of seniority (typical of software architects),
you may be surprised, one day, to find yourself assigned
responsibilities on the management organization chart.
One this is decided, it is very hard to reverse. The
best approach is to declare your expectations (e.g.
for technical assignments) when you first take the job.
And repeat your policy often.
An increasing number of software professionals are claiming
the title: software architect. In our opinion, very
few of these people know what software architecture
is, beyond an informal understanding.
Have you ever been
involved in a discussion of the question: "What is architecture?"
The term "architecture" is one of the most abused words
in software technology. Below, we describe one of the
common mis-uses of architecture; then, we answer the
question "What is architecture?" with a conceptual standard
that is in widespread use today (see Section 1.2).
Too often, architectures are used as sales tools rather
than technical blueprints. In a typical scenario, a
fast-talking technical manager (the "architect") presents
a few high-level viewgraphs to convince you of the greatness
of his product or system. This is a presentation of
a marketing architecture. Most marketing architectures
are directed externally at customers and not at software
are fine for advertising the features of commercial
products, but they only provide limited technical information
for developers. The problem with marketing architectures
is that they are decoupled from the development process.
The so-called architect is a manager who delegates most
technical details to individual developers. Unless the
architect manages the computational model (including
subsystem interfaces), the architecture is unlikely
to deliver any real technical benefits. Architectural
benefits that are easily compromised include: system
adaptability (for new business needs) and system extensibility
(for exploitation of new technologies).
Even though there
are many competing definitions of software architecture,
experts emphasize the importance of architecture, especially
for component-based applications. As component reuse
and software complexity increase, architecture is growing
dramatically in importance. In the following sections,
we discuss several architecture-centered approaches,
which support business change, technology innovation,
and design reuse. Reuse of architectural designs benefits
component reuse, because design reuse is often much
more effective than software reuse alone.
High quality, flexible software is one goal of architecture-centered
development. In recent years, popular development approaches
assumed that bad software is better. In other words,
getting software delivered quickly, is better than delivering
quality software which supports change and reuse. Well-known
process models and vendor regimes are founded on the
bad is better principle.
approaches accommodate reuse and change more effectively
than bad is better approaches, because there is a planned
system organization, specifically designed for these
purposes, i.e. the system architecture. In our opinion,
the practice of software architecture is essential for
component-based development. Bad is better was the thesis;
software architecture is the antithesis.
Of course, we do
not want to lose the inherent benefit of bad is better,
i.e. rapid delivery. Architecture-centered approaches
utilize several techniques including pragmatism, architecture
planning, and architecture reuse, which jointly support
increased productivity, reduced risk, and rapid time-to-market.
Many of us have serious misconceptions about the capabilities
of current software approaches. Based upon surveys of
corporate software projects in the United States, the
realities of software development are as follows. [Brown
98] About one third of all software projects are cancelled.
Average projects expend twice as much budget and schedule
as initially planned. After delivery, the majority of
systems are considered unsuccessful because they have
far fewer capabilities than expected. Modifying and
extending systems are the most expensive cost drivers
and very likely to create new defects. Overall, the
outcome of virtually all application software projects
are stovepipe systems, brittle software architectures
that under-perform on requirements.
The software crisis
in corporate development became apparent decades ago,
when procedural software technologies were popular.
Subsequent, object-oriented approaches (such as the
Object Modeling Technique) have been equally unsuccessful
for corporate developers. These outcomes have been repeatedly
confirmed by research. [Brown 98]
Three key factors
are exacerbating the software crisis:
- requirements change,
- commercial innovation, and
- distributed computing.
A significant part of the problem
is rising user expectations. User requirements for systems
have increased much faster than corporate developers'
capability to deliver. Requirements changes are more
frequent as businesses maneuver for competitive advantage
with strategic corporate software.
Another confounding factor is the
destabilizing force of accelerating technology innovation,
both in commercial software and hardware platforms.
Corporate developers have difficulty finding compatible
configurations of software products, and are forced
to upgrade configurations frequently as new products
are released. Software maintenance due to technology
upgrades is a significant corporate cost driver.
Distributed computing is an essential
feature of many new applications due to predominance
of the Internet and geographically diverse enterprises.
Traditionally, software designers assumed homogeneous
configurations, centralized systems, local communications,
and infrequent failures. Today's highly distributed
enterprises require heterogeneous hardware/software,
decentralized legacy configurations, and complex communications
infrastructure. The resulting computing environments
have frequent partial system failures. Distributed computing
reverses many key assumptions that are the basis for
procedural and object-oriented software development.
The software industry has established
object-orientation (OO) as the mainstream technology.
OO is the technology adopted by new corporate development
projects because OO is universally supported by software
tool vendors. Masses of legacy programmers are training
for object-oriented development (e.g. C++ and Java)
as corporations create new strategic systems. Unfortunately,
these developers and corporations are likely to become
the next generation of disillusioned participants in
the software crisis. However, the organizations that
survive and thrive with this technology, must use it
in sophisticated new ways, represented by componentware.