Question No. 1
1) What makes a “GOOD” software architecture” [Marks 8] 2) Are architectures influenced by background and experience of software architects? Explain. [Marks 8]
First and foremost, the architect is a technical leader, which means that, as well as having technical skills, the architect exhibits leadership qualities. Leadership can be characterized in terms of both
position in the organization and also in terms of the qualities that the
In terms of position in the organization, the architect is the technical lead on the project and should have the authority to make technical decisions. The project manager, on the other hand, is more
concerned with managing the project plan in terms of resources,
schedule, and cost. Using the film industry as an analogy, the project
manager is the producer (making sure things get done), whereas the
architect is the director (making sure things get done correctly). As a
result of their positions, the architect and project manager represent
the public persona of the project and, as a team, are the main contact
points as far as people outside the project are concerned. The
architect, in particular, should be an advocate of the investment made
in creating an architecture and the value it brings to the organization.
The architect is also involved in organizing the team around the architecture and should actively contribute to planning activities as a result, since dependencies in the architecture translate to the
sequencing of tasks and therefore the skills required at particular
points in time. On a related note, since the success of the architect is
closely linked to the quality of the team, participation in
interviewing new team members is also highly appropriate.
In terms of the qualities that the architect exhibits, leadership can also be characterized in terms of interactions with other team members. Specifically, the architect should lead by example and show confidence
in setting direction. Successful architects are people-oriented, and
every architect takes time to act as a mentor and coach to the members
of their team. This benefits the team members requiring help, as well as
the project and, ultimately, the organization itself, since one of its
most valuable assets (the organization's people) becomes better skilled.
Also, the architect must be focused on the delivery of tangible results and must act as the driving force for the project from a technical perspective. An architect must be able to make decisions
(often under pressure), and make sure that those decisions are
communicated, understood, and, ultimately, implemented.
There is a difference between a role and a person. One person may fulfill many roles (for example, Mary is a developer and a tester), and a role may be fulfilled by many people (for example, Mary and John
fulfill the role of tester). Given that the role of architect requires a
very broad set of skills, it is often the case that the architect role
is fulfilled by more than one person. This allows the skills to be
spread across a number of individuals, each bringing his or her own
experiences to the role. In particular, the skills required to
understand both the business domain and also various aspects of
technology are often best spread across a number of individuals. The
resulting team does, however, need to be "balanced." Throughout this
article, the term "architect" refers to the role, which may be fulfilled
by either an individual or a team.
[A team is] a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.2
If the architect role is to be fulfilled by a team, then it is important to have one individual who is considered the lead architect, who is responsible for owning the vision and can act as a single point
of coordination across the architecture team. Without this point of
coordination, there is a danger that members of the architecture team
will not produce a cohesive architecture or that decisions won't get
For teams that are new to the concept of architecture, it has been suggested that, in order to achieve this common purpose, goals, and approach, the team create and publish a charter for the architecture
Good architects know their strengths and weaknesses. Irrespective of whether or not the architect role is fulfilled by a team, it is often the case that an architect is supported by a number of "trusted
advisors." Such architects acknowledge where they are weak and
compensate for these weaknesses by either obtaining the necessary skills
or working with other people to fill the gaps in their knowledge. The
best architectures are usually created by a team, rather than an
individual, simply because there is a greater breadth and depth of
knowledge when more than one person is involved.
One pitfall with the concept of an architecture team is that it is sometimes perceived by others in the organization as an "ivory tower," whose output is intellectual rather than useful. This misconception can
be minimized from the outset by 1) ensuring that all stakeholders are
actively consulted, 2) continually communicating the architecture and
its value, and 3) being conscious of the organizational politics at
The architect should have an appreciation of the software development process, since this process ensures that all of the members of the team work in a coordinated manner. A good process defines the roles
involved, the activities undertaken, the work products created, and the
handoff points between the different roles. Since the architect is
involved on a daily basis with many of the team members, it is important
for the architect to understand their roles and responsibilities.
Day-to-day, the development team will often look to the architect to
tell them what to do and often how to do it. There is therefore a clear
overlap between the role of the architect and the role of the project
As well as having a grasp of software development, it is also highly desirable (some would say necessary) for the architect to have an understanding of the business domain.
[A domain is] an area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. 4
Such knowledge will allow the architect to better understand and contribute to the requirements of the system and be in a position to ensure that "likely" requirements -- i.e., requirements that, based on
the architect's domain knowledge, will probably have to be considered --
are captured. Also, it is often the case that a particular domain is
associated with a particular set of architectural patterns that can be
applied. Knowing this mapping can also greatly assist the architect.
Therefore, a good architect will have a balance of software development knowledge and business domain knowledge. When architects understand software development but not the business domain, a solution
may be developed that does not fit the problem, but merely reflects what
the architect is comfortable or familiar with.
Another reason the architect needs familiarity with the business domain is that the architect needs to anticipate likely changes to the architecture. Given that the architecture is heavily influenced by the
environment in which it will be deployed, having an appreciation of the
business domain will allow the architect to make better-informed
decisions about the likely areas of change, and the areas of stability,
from an architectural perspective. For example, if the architect is
aware that new regulatory standards may need to be adhered to at some
point in the future, then this should be accommodated in the
architecture should such standards be mandated during the life of the
Certain aspects of architecting clearly require a knowledge of technology; an architect therefore must maintain a certain level of technology skills. However, architects do not need to be technology
experts. This relates to the idea in Part 1 of this article series --
that an architecture focuses on significant elements. Correspondingly,
the architect need only be concerned with the significant elements of a
technology and not the detail. Since technology changes fairly
frequently, it is essential that the architect keep abreast of these
Although architecting is not confined to design, design is clearly an important aspect of architecting. The architect should therefore have good design skills since the architecture embodies key design decisions.
Such decisions could represent key structural design decisions, the
selection of particular patterns, the specification of guidelines, and
so on. In order to ensure the architectural integrity of the system,
these elements are typically applied "across the board" and can have far
reaching effects in terms of the success of the system. Such elements
therefore need to be identified by someone with appropriate design
The developers on the project represent one of the most important groups that the architect must interact with. After all, it is their work products that ultimately deliver the working executable software.
The communication between the architect and the developers can only be
effective if the architect is appreciative of the work of developers.
Therefore, architects should have a certain level of programming skills,
even if they do not necessarily write code.
Most successful architects have, at some stage, been hard-core programmers, where typically they have learned certain aspects of their trade. Even as technologies evolve and new programming languages are
introduced, good architects can abstract the concepts in any programming
language and then apply this knowledge to learning a new programming
language to the depth required. Without this knowledge, the architect
will be unable to make decisions with respect to the architecturally
significant elements of the implementation, such as the organization of
the implementation and the adoption of programming standards, and a
communication barrier will emerge between the architect and the
Of all of the "soft skills" associated with the architect, communication is the most important. There are a number of dimensions to effective communication, and the architect needs to be proficient in
all of them. Specifically, the architect should have effective language
skills, including speaking, writing, and presentation abilities. Also,
the communication is two-way. The architect should be a good listener
and observer, as well as a good talker.
Being able to communicate effectively is a skill that is fundamental to the success of a project for many reasons. Clearly, communication with stakeholders is particularly important in order to understand their
needs and also to communicate the architecture in a way that secures
(and maintains) agreement with all stakeholders. Communication with the
project team is particularly important, since the architect is not
simply responsible for conveying information to the team, but also for
motivating them. Specifically, the architect is responsible for
communicating (and reinforcing the communication of) the vision for the
system, so that the vision becomes shared and not something that is only
understood and believed in by the architect.
An architect who is unable to make decisions in an environment where much is unknown, where there is insufficient time to explore all alternatives, and where there is pressure to deliver is unlikely to
succeed. Such an environment is to be expected, and successful
architects acknowledge the situation, rather than try to change it.
Thus, the architect needs to be "thick-skinned" since they may need to
correct their decisions and backtrack at times during a project. As
Philippe Kruchten puts it, "The life of a software architect is a long
and rapid succession of suboptimal design decisions taken partly in the
An inability to make decisions will slowly undermine the project. The project team will lose confidence in the architect, and the project manager will be concerned because those waiting on the architecture
cannot make the required progress. Here's the greatest danger: If the
architect does not make and document decisions about the architecture,
then team members will start to make their own, possibly incorrect,
Successful architects are not geeks only concerned with technology. They are also politically astute and are conscious of where the power in an organization resides. This knowledge is used to ensure that the
right people are communicated with and that support for the project is
aired in the right circles. To ignore organizational politics is, quite
simply, naïve. The reality is that there are many forces at work in
organizations that lie beyond the project team delivering the system,
and these need to be accounted for.
Given the many dimensions of architecting, the architect interacts with many stakeholders. Some of these interactions require negotiation skills. For example, a particular focus for the architect is to minimize
risk as early as possible in the project, since this has a direct
correspondence to the time it takes to stabilize the architecture. Since
risks are associated with requirements, one way to remove them is to
remove or diminish the requirement with which the risk is associated.
Hence the need to "push back" on such requirements so that a
mutually-agreeable position -- between stakeholders and architect -- can
be reached. This requires that the architect be an effective
negotiator, able to articulate the consequences of different tradeoffs.
This article has focused on defining the characteristics of a software architect. The remaining articles in this series will focus on the characteristics of the process of architecting
and the benefits of treating architecture as a fundamental IT asset.
This article describes the role of the software architect from the perspective of the ideal nature of a successful architect. My exploration touches the octopus/chameleon/parrot/bull-nature that is the
heart and soul of the architect. We need to recognize, as software architects
ourselves, that what we do is aimed at changing the lives of many different groups
Architecture is user experience
Architecture is negotiating and bargaining
Architecture is technology
Architecture is form
Architecture is communication
Architecture is artful
Architecture is agile
Architecture is the creation of a better world
About the author
Let’s start from the top: What the user of any piece of software sees, feels and experiences when touching the application. The user is there to do a job that needs to get done. Using
well-designed, easy-to-use software is enjoyable and simplifies the user’s
life. The opposite experience, to paraphrase a Star Wars character, leads to
frustration, frustration leads to pain, and pain leads to suffering.
The user wants to efficiently and preferably enjoyably use the software. A software architect spends his life realizing this need! The GUI – the attractive and highly usable interface
between application and software that makes using the application so worthwhile
– depends heavily on the architecture. This is absolutely critical. Whatever
capabilities the architecture has underneath it will impact the GUI. The
opposite is especially true: if you have great UX people but a lousy architect,
you’re in trouble. I recently heard that Kent Beck, the creator of Extreme
Programming methodology, said, “you can’t hide a bad architecture with a good
GUI,” and I believe this to be absolutely true. There are many things you need
to know if you want to create a great user experience. One of the architect’s
best friends is the UX expert/interaction designer, but the more the architect
understands these needs, the better.
In the comparison made in Architecture as Metaphor, 1999, the written account of a workshop held at OT ´99, the goal was “to investigate how the software community perceives the similarities
and differences between software architects and building architects.” One of
the most interesting findings was that it is perceived that we software
architects are less accountable for our results than are building architects.
This is likely due to the fact that many of our results are less visible to the
naked eye than the results of building a physical structure. It’s sad that this
is the case, because I believe that we would get much better use of our
creations if we cared more about the end product of our efforts. Perhaps this
will make us more accountable? All the better!
Somewhere in every project there is a client. This is where the project usually starts. In order to focus on the client, let’s say that it’s just one person. To bring the client in on this we
must move slightly back in time to before the user was trying to get something
done. In our scenario, we must move to the inception of the application:
Someone realized that there was a need for some system. Someone had an idea.
Whoever that person was, they likely had a vision of the kind of software they
needed. This is both a blessing and a curse in software projects. In many
projects, I have at times felt it would be nice if there were no clients. Since
this is never the case, it’s good that I love a challenge. It is very inspiring
for an architect to capture the client’s vision and process it. The curse part
becomes obvious when you realize that the client simply does not understand the
needs of the end user for whom the software is being built. More often than
not, the client is not even an end user.
This goes back to the user, I realize, but the two are closely related. If the client is not the end user, an architect must get in touch with the intended end user. The architect can try to imagine the
software requirements of the end user, but obviously this is quite difficult.
Sadly, this is how many user interfaces are created. Many UIs are created by
technicians, who I think we can all agree make very poor UI experts. The
architect must be in contact with real end users, either in person or through
the proxy of a requirements gathering function.
Two things need to be said here. First, there are several other project roles, including the business analyst function, that can handle much of the work of requirements gathering. Of course, this
depends on the size of your project and the lay of the land within your
organization. The architect might not have to be personally involved in
requirements gathering, but good and sound architecture must be based on the
real needs of the end users of the system. No matter how the requirements are
gathered, the architect always needs to digest what the end user truly needs.
Second, with regard to client requirements or end user requirements or both, there is a problem with requirements that needs to be bridged. End users don’t understand technology and developers don’t
understand people! The not understanding technology part is often true for
clients, too. Some clients understand technology to some extent, but most of
them do not, and they certainly do not want to be bothered by highly technical
While most clients and end users want to stay far away from technology, it could be argued that the architect should stay one layer above the core technical decisions of the system development
process. This is only partly true. The architect must transform requirements
into something that will be developed, using hard-core techie stuff, by a team
of skilled developers. Thus, the architect needs to have at least a bird’s-eye
view of the technology that will make up the solution. I’ll get back to this
topic later in this paper. For now, let’s stay focused on the user.
How do we get from perceived user requirements to real requirements? This is no small feat. Naturally, the architect needs to understand the capabilities of the underlying technical
systems. While most technical issues can be solved one way or another, the
problem is the small matter of making correct architectural decisions. Equipped
with an understanding of what technology is potentially in play, the architect
must begin mapping available technology to the perceived requirements and start
investigating where there might be a mismatch between perception and reality.
The architect will, during this work, suggest changes to the perceived set of
requirements. This can be done either to correct mistakes made by those who set
the requirements, or it can be done to suggest changes to the design due to
technological capabilities that are not envisioned by the client or even dimly
fathomed by the end users.
Have you ever met a client with a 100% accurate view of what needs to be built, and an equally insightful view of the real needs of end users? There is no such client! If there were, that person
would be the architect. Heaven forbid the client who has architectural
ambitions! In this dreaded case, you would not be asked to fill this role. In
either case, there is usually quite a bit of negotiation among those who claim
a requirement or request a feature and the architect who is bringing technical
knowledge to the table.
In the end, a client envisions some software system or product and a set of end users, and has a list of needs to be fulfilled. The architect is instrumental in realizing this set of requests and
needs. And so my initial claim holds true: An architect changes people’s lives.
As Spider-Man says, “With great power comes great responsibility.” The architect
must really care about the client and the end users, and what these people
need, in order to realize the best and most efficient software system. The
architect must be an investigator who inspects and adapts, but even more
importantly, the architect must be a caring individual.
In discussing project requirements, we have naturally come to the issue of what is possible to build. Some of us feel that almost anything is possible in technology. I’m sure that’s what they said 40
years ago, too! It is critical, however, that a software architect be a good
technician. Of course, this is always a balancing act, since there is always
going to be much more technology to be skilled in than there is time to acquire
during a lifetime. No architect can be an expert in all areas of technology. In
fact, I will argue that the better the technician, the less skill a person
likely has in interpersonal communications. I will not delve into this question
too deeply here because it is not essential to this article. Of course, there
are some really good architects who are also really good technicians.
Now that we have separated the architect from the implementation-level details, let’s reverse the perspective. If an architect does not take part in the actual implementation of the project, we
run the risk of having all of the architect’s beautiful visions making a poor
match with the technology being used. It is crucial for the success of project
implementation that the architect take time to compare implementation details
against the vision. Organizational Patterns of Agile Software Development
[Coplien & Harrison, 2005], a great book on agile software development,
states a pattern for this phenomenon: “Beyond advising and communicating with
Developers, Architects should also participate in implementation.” This is not
the same as saying that the architect should do a lot of coding, but it
certainly helps if the architect gains a full understanding of the art of
putting the pieces together. An architect who does some coding will gain
valuable insights, and this in turn will aid in fitting requirements to
Or is it the other way around? Fit the technology to the requirements? A great way of doing this effectively is to pair up the architect with an experienced developer. This should be done from
time to time to get a feel for the experience of coding the architect’s design.
An additional benefit of this pattern is that developers perceive a buy-in from
the architect. Also, there is an improvement in the overall soundness of the
fit between framework-level concerns and the application being built. The
supporting framework will do just that – support the application better – when
the fit with the application is as frictionless as possible. This is more
easily achieved if the architect also implements code, because then the
architect knows what it is like to use the design.
One final note is that the architect is labeled the keeper of the flame, meaning that the architect owns the principles of the project. The architect is a role model for the entire development organization.
This is not a small burden.
Let me now turn to the issue of specialization. True mastery comes from excellence in one or a few areas, combined with a good understanding of many related fields. It is the
architect’s job to know a little about a lot of relevant technologies. The
architect must successfully map the complex requirements from the client and
the end users onto a set of technologies suitable for the design challenges at
hand. The artifacts coming in from the user side might be a set of drawings, user
stories, or something of that sort. These will be transformed into language
that must be meaningful to a completely different set of people, namely
developers. This must be done to enable developers to work as efficiently and
joyfully on the development of the system as humanly possible. Did I say
joyfully? Did I say humanly? Yes. A happy developer is a productive developer!
And what makes developers really happy? I’ll tell you: Working with great
technology, creating great applications out of a set of well-laid plans. If the
architect listens only to the needs of the end users and not to the developers,
the developers will be unhappy and unmotivated. The architect must make the
developers excited about the requirements. This is absolutely paramount to the
success of the project. The two sets of people, end users (and clients) and
developers, really and truly do not understand each other. To ensure success,
the architect must understand and satisfy both groups. This work is never
complete, and spans the entire project.
It is tempting to label the architect a spineless coward, bending to every whim of clients, end users and developers. This is far from true! After all, it is the architect who, in the end, will
drive development forward by bridging the gap between the users and the
developers. It is the architect who holds the Rosetta Stone for translating
among groups with very different needs. As noted earlier, the architect must
inform the client and the end users of the technological possibilities and
limitations, set realistic expectations, modify expectations, and even create
new expectations. This is scary business and not for the faint of heart.
This means that the architect is both a technician and a humanist, and wields the power of translation from geek to speech, and back again. Simultaneously!
It is important to explore what architecture is all about. It is easy to think that the goal of creating architecture is to build an intricate yet adequate diagram of objects and
classes with relations among each other. It is tempting to think that the
completeness of the architecture is somehow measured in terms of how the
architectural artifacts of the system look. But this is the naive view of architecture,
and it is merely a confusion of structure over form. Structure is classes and
code patterns and so on. However, to presume that this is the
architecture could not be further from the truth. Architecture is about form:
If you do not know the form of a system before you begin building it, you are
in over your head. Many Object Oriented (OO) practitioners tend to confuse the
one with the other, because it is the structure of a system that we can look
at, and teach and learn about, the relations among objects and framework
components and such. This is what is tangible.
This in no way implies that structure is unimportant. It just tells us that often when we speak about structure we are actually referring to form. Structure is a critical part of what we do as
architects. What layering model of the system do we need? How do the layers
define? What code patterns should we use? What techniques are appropriate in
the application? To be fair, are these not exactly the questions one would ask
oneself while figuring out the structure of a software system? Your previous
experiences constructing other software with similar needs would guide you to
use techniques that have worked for you before, or perhaps new techniques that
you have recently learned but not have yet used. In recent years we have seen
the introduction of new concepts into our trade, including object factories,
dependency injection and modularity. Not long ago this arcane knowledge was
known only to the mythical pattern experts. Yet now these are just tricks of
the trade, if you will.
The real purpose of an architect is that of a craftsman and artist, as the building architect Christopher Alexander writes in The Mary Rose Museum: “Our experience as contractors, engineers and
architects during the last 15 years has proved one thing over and over again:
The things placed on drawings are inevitably – always – wrong in many
particulars. Drawings serve as an important rough sketch of something that will
be built, but must be executed with constant attention to room shape, light,
wall and ceiling detail, openings – above all to the feelings which arise in
each place, in the construction, as it is taking shape. These feelings are too
complicated to predict and cannot be predicted. When a building is built from
plans that are conceived on the drawing board and then simply built, the result
is sterile at best – silly most of the time – and sometimes unthinkably bad.
This is something familiar in virtually all large buildings that have been
built since 1950. It is inevitable, given the process of construction used to
build them. And it is inevitable that this process must lead to unsatisfactory
results.” [Christopher Alexander, Gary Black and Miyoko Tsutsui, 1995] An
architect who builds a house does not and cannot predict the location of each
wire and pipe, because they must fit through the stones, bricks or studs in the
walls. That, in turn, can change the location of sinks. You don't know these
things until the last minute.
While it is true that the architect has many masters, it is equally true that the architect must work very much like Cardinal Richelieu, the Red Eminence, and with a firm hand guide developers to realize a
beautiful vision. The architect must be a stickler for detail and an enforcer
of high standards, while always having the guts to make critical changes to a
design when necessary. An architect has to have guts paired with a good sense
of the form of what is to be built.
According to an article by Alstair Cockburn [The end of software engineering and the start of economic-cooperative gaming, 2004], “At its core, software development is people inventing and
communicating, solving a problem that they do not fully understand, which keeps
changing underneath them, creating a solution that they do not fully
understand, which also keeps changing underneath them, and expressing their
thoughts in artificial and limited languages that they do not fully understand
and that also keep changing underneath them, to an interpreter that is
unforgiving of error, where every choice has economic consequences, and
resources are limited. Software development is a resource-limited,
goal-directed, cooperative game, whose moves consist of invention and
Cockburn deliberately does not indicate which people are solving, creating and expressing, or “gaming” if you will. The way I see it, the architect is at the very heart of this activity. In other
words, the architect is a gambler and an explorer.
If you are an architect, you must have a vision for the system, and the series of discussions that lead to the architectural structure of the solution, as being created throughout the life
of the project. Creating software architecture is not a process we may plan
ahead of time, as with building architecture. We may employ our skills and
experiences to guide the process with some accuracy. The effectiveness of
quickly finding proven solutions from similar situations in the past, or of
actually feeling in your gut what the right solution can be, is based in
experience. From these cooperative gaming activities, the architecture is the
living artifact. It stems from the commitment to a project over the life of the
development, and it is carried through by means of different forms of
In another article [The declaration of interdependence for modern management, 2004], Cockburn writes that we should “Focus on the value that is being created and watch the flow of increase
in value. Each person or work station contributes a value, and there is a flow
involved. In software development, the flow is often around decisions: someone
makes a visioning decision, a requirements decision, an architecture / UI /
domain model / testing / configuration management decision, and those decisions
affect other people in a patterns. That I call the ‘flow’.” This means that
software engineering is not really an engineering practice at all! In an
engineering practice, you can copy a previous construction and re-create it
over and over again. In creating software, it has been found from 40 years of
collective experience that you cannot copy another team’s efforts and re-create
their exact results. The act of developing software does not work that way!
Building software is creative at heart – artistic! Software architecture, being
an essential part of this process, is therefore artistic, and it is the glue
that holds the artifacts of an artistic process together.
The architect can never sit behind closed doors and expect to succeed. The architect must be out there every day, communicating with stakeholders, in order to perform the job function with
excellence. Wait, isn’t this the project manager that I am writing about now?
No. The day-to-day tasks of the person who is doing the architecture quite
often cross over into the realm of the manager. Also, I am a firm believer that
each person on any team has to do everything possible to further the project.
If that means the lines between roles become fuzzy, then so be it. The exact
line is hard to define and is based on the needs of the organization. There are
powerful and classical organizational patterns at work here that govern the
needs of each organization. It is all but impossible for a good architect, one
who is inclined toward interpersonal communication, not to care about the needs
of his organization when they are so closely related to the architectural
endeavor. Sometimes the architect and the project manager are one and the same
person, which means of course that the architect does officially have
managerial tasks. Even when the manager is not the architect, the architect
still cares about the state of the organization and works continuously to
improve the quality of work in the organization by enabling the team(s) to work
at full efficiency. The architect constructs the architecture of the solution
in a manner that enables developers to use their tools effectively. The
architect enforces high standards and makes sure that work on the project is as
enjoyable, straightforward and efficient as possible. Thus, it is impossible to
be an architect without also at times being a talented psychologist. You have
to feel how the winds blow in an organization, especially if the winds are not
just gentle breezes. It is a fundamental mistake not to listen to the
organization when creating architecture.
What is it we want to communicate through software architecture? We want to convey a beautiful vision! What we build is something that users and observers of the system will likely spend some time with.
Doesn’t this mean it has to be beautiful as well as useful?
Many great architects came before us, including the Athenian Mnesikles who created the Periclean gateway to the Athenian Acropolis, and also the unknown designer of the Roman Coliseum. They
did not have computers, as we do today, but they did understand beauty and
Wait a minute! We were discussing software architecture, not building architecture! Please humor me; there is a strong connection between the two.
Christopher Alexander wrote in The Timeless Way of Building that “There is one timeless way of building. It is a thousand years old, and the same today as it has ever been. The great traditional
buildings of the past, the villages and tents and temples in which man feels at
home, have always been made by people who were very close to the center of this
way. It is not possible to make great buildings, or great towns, beautiful
places, places where you feel yourself, places where you feel alive, except by
following this way. And, as you will see, this way will lead anyone who looks
for it to buildings which are themselves as ancient in their form, as the trees
and hills, and as our faces are.” [Alexander, 1979]
Alexander hands this task to those who today work with computers. In a presentation he gave at OOPSLA, The Origins of Pattern Theory the Future of the Theory, And The Generation Of A Living
World, Alexander stated that he had, “. . . . an extraordinary vision of
the future, in which computers play a fundamental role in making the world – and
above all the built structure of the world – alive, humane, ecologically
profound, and with a deep living structure . . . . I hope that all of you, as
members of a great profession of the future, will decide to help me, and to
help yourselves, by taking part in this enormous world-wide effort. I do think
you are capable of it. And I do not think any other professional body has quite
the ability, or the natural opportunity for influence, to do this job as it
must be done.” [Alexander, 1996]
Alexander’s vision was all about the beauty and truth of the world, and he passed his vision of a living, breathing and beautiful world to us, the people who work with computers. Those who guide this
process are the architects.
There is one very important quality of the art that is architecture, and that is the ability to see the solution ahead of time, to feel it or envision it, if you will, in all its glory and in quite
rich detail. Some would mark this down to experience, but there’s more to it.
This is about having the skill of foresight. Before the design begins, the
architect needs to take a step back in his mind and see the design in full
function before him. This is done before any cardboard mock-ups or prototypes
are built, and the process should be revisited at every major change point
during the life of the project. The architect has to become the user and see
himself using the system. The end user is not the final focus of the
construction; the end user has a goal in mind when using the system, and the
fulfillment of this goal is the real reason for which this system will be
built. The better the architect is at seeing this beforehand, the better
he or she will be at understanding what needs to be put into motion to
accomplish it, and thus what the design needs to be.
Am I not now redefining the role of the architect? The software architect today typically is not involved in many of the activities I describe here. Rather, the architect
is concerned with doing the delivery. A more proper name for many architects
today is chief building contractor. I understand many people see it this way
because our discipline was defined from a foundation in engineering. I feel we
have to change this view of the architect! The
architect has a good imagination and is good at painting mental pictures. This
skill may be taught, but aptitude for this activity is critical. Experience builds
it, too. When we have this mental picture in our heads, it is time to begin the
actual design process, which does not end until the project ends.
Discussing the concept of agile software development seems to be inevitable in this paper. What do I mean by the statement architecture is agile? Well, with all due respect, would you
like to be involved in a non-agile software development project? I did not
think so! We strive to be agile in our development processes; all of our
architectural structure is supposed to be agile to the nth degree, with
modularity and factories all over. How can an occurrence as central to any
development project as its architecture be anything less? Does it matter
whether agile architecture or agile practices came first? Of course, agility in
structure is associated to some degree with size of organization. Does our
organization require distributed development, or are we a small core team
producing our product? Do we adapt our core functionality to key customers?
These are technical questions, of course. Okay, so what about changing business
needs? Responding to competitor evolution? Agility is present in business and
practical development both, yet I see so many solutions that are a Gordian
knot, where if you lift one little class at the edge of the code base, all of
the other classes and parts of the software automatically get pulled up, too. I
also see many solutions that are such a complete pain to work with that you
almost immediately give up! All this effort for nothing! What a waste. The
exact definition of what makes architecture agile I will leave for another
Let’s instead examine the concept of whether architecture is agile from another perspective, and slant it back toward the architect that we are discussing here. I am a certified Scrum Master who
really likes the openness and agility of that process. Scrum as such does not
define an architect’s role. The process does not define many roles at all – it
is agile in this respect. A Scrum team is free to figure out who does what, as
long as the members agree that this is the most productive way to reach the
sprint goal. Consequently, if there is a team member who enjoys architectural
tasks and has useful experience in resolving the tasks quickly and
expeditiously, and if the team agrees it is a good way of moving the sprint
forward, then the team may turn to that person for resolving architectural
tasks. In Scrum, as I said, the architect’s role is not defined as such, and if
no architect is appointed by the team, who does the architecture? Usually it is
the team that makes decisions regarding the design and architecture of a
solution. And in cases of scaling, several Scrum teams make decisions about the
overall architecture that may span several Scrum teams. The last part is often
performed in a congregation known as a Scrum of Scrums meeting. When the
architect as a role is not present in a Scrum project, it means that the
architectural tasks are completed in collaboration within the team and through
discussion among the participants and among the teams in the Scrum of Scrums.
So the architect now is not an actual person but rather an entity created
inside the project. Perhaps describing the architect as some non-physical entity
seems strange, but if we briefly and for argument’s sake imagine such an
entity, what is its core nature? It is communication!
The architect must be able to adjust the architecture to respond to changing needs, and must retrofit a solution that is applicable for multiple settings. The architecture had better suit distributed
development! I don’t see it as too much architecture if you take reasonable
measures based on knowledge passed at the beginning of a project. Some things
you just have to know you will need as part of your solution. Architecture that
is agile does not mean it is necessarily lean or piecemeal; it means being
subject to continuous change, and flowing around changes in a fluid manner. The
solution can flow, but only if the architect can flow.
Some of the responsibilities mentioned above are sometimes not handled solely by the architect. Instead, they may be handled by a project manager, an interaction
designer or a business analyst. That’s all good and
well if you have those roles in your project. Any large project would. What I
am trying to say is that you, as the architect, must continuously communicate
with all of these functions (and certainly several more) to get to the form of
your project. Some things you just have to know about your domain in order to
be a good architect. One good thing to know is who your friends are in the
The architect has been described in this article as a person with a range of positive qualities. Is this the ode to the architect? No, that is not my goal. Is there really a living individual that
can live up to all of these expectations? I believe there are people like this.
In fact, I know a few really good candidates. It is not always easy to live up
to being a positive, sharing, honest and caring person. Most of us only manage
to be as good as we want to be. I don’t intend it to be a requirement that the
architect always live up to all of the qualities described in this article. You
can be a really good architect even if you don’t have a generous serving of
some of the personality traits described here. What you must realize, however,
is that, as an architect, you are the role model every day for many different
people. You are the main line of communication that bridges the gap between
user and technology. You are the keeper of the flame in your development
department because the design you create will inspire good use of proven
practices. As an architect, you have to get into the minds and lives of many
people and get emotional about what they need. There is not a more communicative
or social role than that of the architect! The architect must be part architect,
part listener, part organizer, part psychologist, part visionary, part humanitarian,
part friend, part leader, part stickler for detail, and always willing to make a
critical change in the design while not being a pushover.
Everything that I’ve written above has to matter to you as an architect! You can’t be a great architect if you don’t honestly and truly care.----------------------------------------------------------------------------------------------------------------------