Latest Activity In Study Groups

Join Your Study Groups

VU Past Papers, MCQs and More

We non-commercial site working hard since 2009 to facilitate learning Read More. We can't keep up without your support. Donate.


 

 

Helping Material 

Question No. 1


1) What makes a “GOOD” software architecture” [Marks 8] 2)Are architectures influenced by background and experience of softwarearchitects? Explain. [Marks 8]

Characteristics of a software architect

 

Thearchitect is a technical leader

First and foremost, the architect isa technical leader, which means that, as well as having technical skills, thearchitect exhibits leadership qualities. Leadership can be characterized interms of both
position in the organization and also in terms of the qualities that the
architect exhibits.

In terms of position in theorganization, the architect is the technical lead on the project and shouldhave the authority to make technical decisions. The project manager, on theother 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 inorganizing the team around the architecture and should actively contribute toplanning activities as a result, since dependencies in the architecturetranslate 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 thearchitect exhibits, leadership can also be characterized in terms ofinteractions with other team members. Specifically, the architect should leadby 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 focusedon the delivery of tangible results and must act as the driving force for theproject from a technical perspective. An architect must be able to makedecisions
(often under pressure), and make sure that those decisions are
communicated, understood, and, ultimately, implemented.

Thearchitect role may be fulfilled by a team

There is a difference between a roleand a person. One person may fulfill many roles (for example, Mary is adeveloper and a tester), and a role may be fulfilled by many people (forexample, 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 befulfilled
by either an individual or a team.

[A team is] a small number of people with complementaryskills who are committed to a common purpose, performance goals, and approachfor which they hold themselves mutually accountable.2

If the architect role is to befulfilled by a team, then it is important to have one individual who isconsidered the lead architect, who is responsible for owning the vision and canact 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
made.

For teams that are new to theconcept of architecture, it has been suggested that, in order to achieve thiscommon purpose, goals, and approach, the team create and publish a charter forthe architecture
team.3

Good architects know their strengthsand weaknesses. Irrespective of whether or not the architect role is fulfilledby 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 anarchitecture team is that it is sometimes perceived by others in theorganization as an "ivory tower," whose output is intellectual ratherthan 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
play.

Thearchitect understands the software development process

The architect should have anappreciation of the software development process, since this process ensuresthat all of the members of the team work in a coordinated manner. A goodprocess 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
manager.

Thearchitect has knowledge of the business domain

As well as having a grasp ofsoftware 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 characterizedby a set of concepts and terminology understood by practitioners in that area. 4

Such knowledge will allow thearchitect to better understand and contribute to the requirements of the systemand 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 willhave a balance of software development knowledge and business domain knowledge.When architects understand software development but not the business domain, asolution
may be developed that does not fit the problem, but merely reflects what
the architect is comfortable or familiar with.

Another reason the architect needsfamiliarity with the business domain is that the architect needs to anticipatelikely changes to the architecture. Given that the architecture is heavilyinfluenced 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
system.

Thearchitect has technology knowledge

Certain aspects of architectingclearly require a knowledge of technology; an architect therefore must maintaina certain level of technology skills. However, architects do not need to betechnology
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
changes.

Thearchitect has design skills

Although architecting is notconfined to design, design is clearly an important aspect of architecting. Thearchitect should therefore have good design skills since the architecture embodieskey 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 havefar
reaching effects in terms of the success of the system. Such elements
therefore need to be identified by someone with appropriate design
skills.

Thearchitect has programming skills

The developers on the projectrepresent one of the most important groups that the architect must interactwith. After all, it is their work products that ultimately deliver the workingexecutable 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, atsome stage, been hard-core programmers, where typically they have learnedcertain aspects of their trade. Even as technologies evolve and new programminglanguages 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
developers.

Thearchitect is a good communicator

Of all of the "softskills" associated with the architect, communication is the mostimportant. There are a number of dimensions to effective communication, and thearchitect 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 communicateeffectively is a skill that is fundamental to the success of a project for manyreasons. Clearly, communication with stakeholders is particularly important inorder 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.

Thearchitect makes decisions

An architect who is unable to makedecisions in an environment where much is unknown, where there is insufficienttime to explore all alternatives, and where there is pressure to deliver isunlikely 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 needto
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
dark."5

An inability to make decisions willslowly undermine the project. The project team will lose confidence in thearchitect, and the project manager will be concerned because those waiting onthe 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,
decisions.

Thearchitect is aware of organizational politics

Successful architects are not geeksonly concerned with technology. They are also politically astute and areconscious of where the power in an organization resides. This knowledge is usedto 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.

Thearchitect is a negotiator

Given the many dimensions ofarchitecting, the architect interacts with many stakeholders. Some of theseinteractions require negotiation skills. For example, a particular focus forthe 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.

Summary

This article has focused on definingthe characteristics of a software architect. The remaining articles in thisseries 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 ofthe software architect from the perspective of the ideal nature of a successfularchitect. My exploration touches the octopus/chameleon/parrot/bull-nature thatis 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 differentgroups
of people.

Tableof Contents

Architecture is userexperience
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

Architectureis user experience

Let’s start from the top: What theuser of any piece of software sees, feels and experiences when touching theapplication. 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 andpreferably enjoyably use the software. A software architect spends his liferealizing 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 Architectureas Metaphor, 1999, the written account of a workshop held at OT ´99, thegoal 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!

Architectureis negotiation and bargaining

Somewhere in every project there isa client. This is where the project usually starts. In order to focus on theclient, 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, Irealize, but the two are closely related. If the client is not the end user, anarchitect must get in touch with the intended end user. The architect can tryto 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 analystfunction, that can handle much of the work of requirements gathering. Ofcourse, 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 clientrequirements or end user requirements or both, there is a problem withrequirements that needs to be bridged. End users don’t understand technologyand 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
details.

While most clients and end userswant to stay far away from technology, it could be argued that the architectshould stay one layer above the core technical decisions of the systemdevelopment
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 userrequirements to real requirements? This is no small feat. Naturally, thearchitect 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 a100% accurate view of what needs to be built, and an equally insightful view ofthe real needs of end users? There is no such client! If there were, thatperson
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 somesoftware system or product and a set of end users, and has a list of needs tobe fulfilled. The architect is instrumental in realizing this set of requestsand
needs. And so my initial claim holds true: An architect changes people’s lives.
As Spider-Man says, “With great power comes great responsibility.” Thearchitect
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.

Architectureis technology

In discussing project requirements,we have naturally come to the issue of what is possible to build. Some of usfeel that almost anything is possible in technology. I’m sure that’s what theysaid 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 thearchitect 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
technology.

Or is it the other way around? Fitthe technology to the requirements? A great way of doing this effectively is topair 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 architectis labeled the keeper of the flame, meaning that the architect owns theprinciples of the project. The architect is a role model for the entiredevelopment organization.
This is not a small burden.

Let me now turn to the issue ofspecialization. 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 thearchitect a spineless coward, bending to every whim of clients, end users anddevelopers. This is far from true! After all, it is the architect who, in theend, 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 isboth a technician and a humanist, and wields the power of translation from geekto speech, and back again. Simultaneously!

Architectureis form

It is important to explore whatarchitecture is all about. It is easy to think that the goal of creatingarchitecture 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 ofarchitecture,
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 thatstructure is unimportant. It just tells us that often when we speak aboutstructure we are actually referring to form. Structure is a critical part ofwhat 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 isthat of a craftsman and artist, as the building architect Christopher Alexanderwrites 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 architecthas many masters, it is equally true that the architect must work very muchlike Cardinal Richelieu, the Red Eminence, and with a firm hand guidedevelopers 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.

Architectureis communication

According to an article by AlstairCockburn [The end of software engineering and the start ofeconomic-cooperative gaming, 2004], “At its core, software development ispeople 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
communication.”

Cockburn deliberately does notindicate which people are solving, creating and expressing, or “gaming” if youwill. The way I see it, the architect is at the very heart of this activity. Inother
words, the architect is a gambler and an explorer.

If you are an architect, you musthave a vision for the system, and the series of discussions that lead to thearchitectural 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
communication.

In another article [Thedeclaration of interdependence for modern management, 2004], Cockburnwrites that we should “Focus on the value that is being created and watch theflow 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 behindclosed 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.

Architectureis artful

What is it we want to communicatethrough software architecture? We want to convey a beautiful vision! What webuild is something that users and observers of the system will likely spendsome time with.
Doesn’t this mean it has to be beautiful as well as useful?

Many great architects came beforeus, including the Athenian Mnesikles who created the Periclean gateway to theAthenian 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
power.

Wait a minute! We were discussingsoftware architecture, not building architecture! Please humor me; there is astrong connection between the two.

Christopher Alexander wrote in TheTimeless Way of Building that “There is one timeless way of building. It isa thousand years old, and the same today as it has ever been. The greattraditional
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 thosewho today work with computers. In a presentation he gave at OOPSLA, The Originsof 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 thebeauty and truth of the world, and he passed his vision of a living, breathingand beautiful world to us, the people who work with computers. Those who guidethis
process are the architects.

There is one very important qualityof the art that is architecture, and that is the ability to see the solutionahead of time, to feel it or envision it, if you will, in all its glory and inquite
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 ofthe architect? The software architect today typically is not involved in manyof 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. Experiencebuilds
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.

Architectureis agile

Discussing the concept of agilesoftware development seems to be inevitable in this paper. What do I mean bythe statement architecture is agile? Well, with all due respect, wouldyou
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
article.

Let’s instead examine the concept ofwhether architecture is agile from another perspective, and slant it backtoward the architect that we are discussing here. I am a certified Scrum Masterwho
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-physicalentity
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 adjustthe architecture to respond to changing needs, and must retrofit a solutionthat is applicable for multiple settings. The architecture had better suitdistributed
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.

Architectureis the creation of a better world

Some of the responsibilitiesmentioned above are sometimes not handled solely by thearchitect. Instead, they may be handled by a project manager, aninteraction
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
organization.

The architect has been described inthis article as a person with a range of positive qualities. Is this the ode tothe architect? No, that is not my goal. Is there really a living individualthat
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 morecommunicative
or social role than that of the architect! The architect must be partarchitect,
part listener, part organizer, part psychologist, part visionary, parthumanitarian,
part friend, part leader, part stickler for detail, and always willing to makea
critical change in the design while not being a pushover.

Everything that I’ve written abovehas to matter to you as an architect! You can’t be a great architect if youdon’t honestly and truly care.


Views: 73

Replies to This Discussion

 

Software Engineering-1 (CS504)

Assignment # 3

  Totalmarks = 20

                                                                                      Deadline Date = 08-01-2011

Question No. 1

 

1)     What makes a“GOOD” software architecture”  [Marks 8]

ANS:

            The keyarchitectural virtues are

Utility: must deliver either business value ordeveloper productivity

Strength: reliable, secure and resilient to change

Beauty: easy to understand and communicate and cleandesign.

Emergingand evolutionary architecture is a core for asuccessful agile software system.

Effective architecture provides stable foundation andintegrity for the growing software system, enabling desired system qualitiesfor the business solutions. Ensures seamless and consistent integration welldefined interfaces and interaction between subsystems, external systems andoperational environment.  Supportsemerging abstractions, key system elements and frameworks for conceptualintegrity, efficiency and reuse.

 

 

 

2)     Arearchitectures influenced by background and experience of software architects?Explain. [Marks 8]

ANS:

            Yes the architecturesare influenced by the background and experience of the software architectsbecause of the qualities and the performances of the architects and encourageof work and to gaining the requirements. As architect is a technical leaderhe/she understands the development process he has also knowledge of businessdomain and the knowledge of the technology. He has the designing and theprogramming skills and he/she is a good communicator .the architect has awareof the organizational policies and he is a negotiator. Due to the abovementioned qualities of the architect the architectures are very deeply andtruly influenced by the background and the experiences of the softwarearchitects.

Architecture has some of the important issues as well likethe user experience, negotiation and bargaining, like a technology, form andthe communication, artful and agile, a creation of the better world. So it isclear that the architectures are rely influenced by background and experienceof the software architects.   

 

 

 

 

 

 

Question No. 2

 

“N-tier application architecture provides a modelfor developers to create a flexible and reusable application”, Comment (5 to 10lines). [Marks 4]

ANS:

N-tier architecture stems from the struggle o find a middleground between the fat-client and the thin-client architecture .in this casethe idea is to enhance the scalability and performances by distributing boththe data and the application using multiple server machines. This could involvethe different types of the servers such as application server, web server andDB server. Three-tier architecture which is explained below is a specializedform of the architecture.

N-tier architecture generalizes the concepts of 3-tierarchitectures. In the case the system architecture may have more than 3 layers.That's, in n-tier architecture, in order to increase performance, we maydistribute the application over different servers by putting differentsubsystems on different servers.

RSS

© 2021   Created by + M.Tariq Malik.   Powered by

Promote Us  |  Report an Issue  |  Privacy Policy  |  Terms of Service