Software Architecture
3 views
Skip to first unread message
dark...@gmail.com
May 26, 2009, 10:35:40 AM5/26/09
to freesky
Essential Software Architecture
Ian Gorton
Foreword
Architects learn on the job, bring years of experience in design and
technology to business problems they tackle.
Preface
Application servers, component technologies and messaging
infrastructures are the basic building blocks that are import to an IT
architect.
Definition of Software Architecture
a. Architecture Defines Structure
An architecture must be designed to meet the specific requirements and
constrains of the application it is intended for.
In partitioning an application, the architect assigns responsibilities
to each constituent component. These responsibilities define the tasks
a component can be relied upon to perform within the application. In
this manner, each component plays a specific role in the application,
and the overall component ensemble that comprise the architecture
collaborates to provide the required functionality.
Responsibility-driven Design can be used effectively to help define
the key components in an architecture.
A key structural issue for nearly all applications is minimizing
dependencies between components, creating a loosely coupled
architecture from a set of highly cohesive components.
b. Architecture Specifies Component Communication
A body of work known collectively as architectural patterns or styles
has cataloged a number of successfully used structures that facilitate
certain kinds of component communication. There patterns are
essentially reusable architectural blueprints that describe the
structure and interaction between collections of participating
components.
Large systems tend to use multiple patterns, combined in ways that
satisfy the architecture requirement. When a architecture is based
around patterns, it also becomes easy for team members to understand a
design.
c. Architecture Addresses Non-functional Requirements
Rather than define what the application does, they are concerned with
how the application provides the required functionality.
There are three distinct areas of non-functional requirements:
Technical constraints
Business constraints
Quality constraints
An application architecture must therefore explicitly address these
aspects of the design.
d. Architecture is an Abstraction
One of the most powerful mechanisms for describing an architecture is
hierarchical decomposition. Different levels of description in the
hierarchy tend to be of interest to different developers in project.
In reality, any architectural description must employ abstraction in
order to be understandable by the team members and project
stakeholders.
e. Architecture View
Views and Beyond approach recommends capturing an architecture model
using three different views:
Module: This is a structural view of the architecture, comprising the
code modules such as classes, packages and subsystems in the design.
It also captures module decomposition, inheritance, associations and
aggregations.
Component and Connector: This view describes the behavioral aspects of
the architecture. Components are typically objects, threads or
processes, and the connectors describe how the components interact.
Common connectors are sockets, middleware like CORBA or shared memory.
Allocation: This view shows the processes in the architecture are
mapped to hardware, and how they communicate using networks and/or
databases.
What Does a Architect Do?
a. Liaison
Architects play many liaison roles. They liaise between the customers
or clients of the application and the technical team, often in
conjunction with the business and requirement analysts. They liaise
between the various engineering teams on a project, as the
architecture is central to each of these. They liaise with management,
justifying designs, decisions and costs. Much of the time, this
liaison takes the form of simply translating and explaining different
terminology between different stakeholders.
b. Software Engineering
Excellent design skills are what get a software engineer to the
position of architect. They are an essential pre-requisite for the
roles. More broadly though, architects must promote good software
engineering practices. Their designs must be adequately documented and
communicated and their plans must be explicit and justified.
c. Technology Knowledge
Architects have a deep understanding of the technology domains that
are relevant to the types of applications they work on. They are
influential in evaluating and choosing third party components and
technologies. They tract technology development, and understand how
new standards, features and products might be usefully exploited in
their projects. Just as importantly, good architects know what they
don't know.
d. Risk Management
Good architects tend to be cautious. They are constantly enumerating
and evaluating the risks associated with the design and technology
choices they make. They document and manage these risks in conjunction
with project sponsors and management.
Architectures and Technologies
Architects must make design decisions early in a project lifecycle.
Judicious prototyping of key architectural components can help
increase confidence in a design approach, but sometimes it's still
hard to be certain of the success of a particular design choice in a
given application context.
Competition between product vendors drives innovation, better feature
sets and implementations, and lower prices, but it also places a
burden on the architect to select a product that has quality
attributes that satisfy the application requirement. Different COTS
technology implementation have different sets of strengths and
weaknesses and costs, and consequently will be better suited to some
types of application than others.
The difficulty for architects is in understanding these strengths and
weaknesses early in the development cycle for a project, and choosing
an appropriate reification of the architectural patterns they need.
Summary
"The life of a software architect is a long (and sometimes painful)
succession of sub-optimal decisions made partly in the dark". -
Philippe Krutchen
※※※※※※
五百年谪在红尘 略成游戏 三千里击于沧海 便是逍遥 >>>>>>飞天玄鹤留<<<<<<
本帖地址：http://club.xilu.com/darkcran/msgview-826955-50525.html[复制地址]
上一主题：第一财经周刊：当当卓越争分夺秒 下一主题：背包:材料+纤维度+纺织方法
[楼主] [2楼] 作者:darkcran 发表时间: 2008/11/02 22:21
[加为好友][发送消息][个人空间]
回复 修改 来源 删除
Is Design Dead?
http://www.martinfowler.com/articles/designDead.html
Growing an Architecture
==============================
What do we mean by a software architecture? To me the term
architecture conveys a notion of the core elements of the system, the
pieces that are difficult to change. A foundation on which the rest
must be built.
What role does an architecture play when you are using evolutionary
design? Again XPs critics state that XP ignores architecture, that
XP's route is to go to code fast and trust that refactoring that will
solve all design issues. Interestingly they are right, and that may
well be weakness. Certainly the most aggressive XPers - Kent Beck, Ron
Jeffries, and Bob Martin - are putting more and more energy into
avoiding any up front architectural design. Don't put in a database
until you really know you'll need it. Work with files first and
refactor the database in during a later iteration.
I'm known for being a cowardly XPer, and as such I have to disagree. I
think there is a role for a broad starting point architecture. Such
things as stating early on how to layer the application, how you'll
interact with the database (if you need one), what approach to use to
handle the web server.
Essentially I think many of these areas are patterns that we've
learned over the years. As your knowledge of patterns grows, you
should have a reasonable first take at how to use them. However the
key difference is that these early architectural decisions aren't
expected to be set in stone, or rather the team knows that they may
err in their early decisions, and should have the courage to fix them.
Others have told the story of one project that, close to deployment,
decided it didn't need EJB anymore and removed it from their system.
It was a sizeable refactoring, it was done late, but the enabling
practices made it not just possible, but worthwhile.
How would this have worked the other way round. If you decided not to
use EJB, would it be harder to add it later? Should you thus never
start with EJB until you have tried things without and found it
lacking? That's a question that involves many factors. Certainly
working without a complex component increases simplicity and makes
things go faster. However sometimes it's easier to rip out something
like that than it is to put it in.
So my advice is to begin by assessing what the likely architecture is.
If you see a large amount of data with multiple users, go ahead and
use a database from day 1. If you see complex business logic, put in a
domain model. However in deference to the gods of YAGNI, when in doubt
err on the side of simplicity. Also be ready to simplify your
architecture as soon as you see that part of the architecture isn't
adding anything.
Do you wanna be an Architect when you grow up?
==================================================
For much of the last decade, the term "software architect" has become
popular. It's a term that is difficult personally for me to use. My
wife is a structural engineer. The relationship between engineers and
architects is ... interesting. My favorite was "architects are good
for the three B's: bulbs, bushes, birds". The notion is that
architects come up with all these pretty drawings, but it's the
engineers who have to ensure that they actually can stand up. As a
result I've avoided the term software architect, after all if my own
wife can't treat me with professional respect what chance do I stand
with anyone else?
In software, the term architect means many things. (In software any
term means many things.) In general, however it conveys a certain
gravitas, as in "I'm not just a mere programmer - I'm an architect".
This may translate into "I'm an architect now - I'm too important to
do any programming". The question then becomes one of whether
separating yourself from the mundane programming effort is something
you should do when you want to exercise technical leadership.
This question generates an enormous amount of emotion. I've seen
people get very angry at the thought that they don't have a role any
more as architects. "There is no place in XP for experienced
architects" is often the cry I hear.
Much as in the role of design itself, I don't think it's the case that
XP does not value experience or good design skills. Indeed many of the
proponents of XP - Kent Beck, Bob Martin, and of course Ward
Cunningham - are those from whom I have learned much about what design
is about. However it does mean that their role changes from what a lot
of people see as a role of technical leadership.
As an example, I'll cite one of our technical leaders at ThoughtWorks:
Dave Rice. Dave has been through a few life-cycles and has assumed the
unofficial mantle of technical lead on a fifty person project. His
role as leader means spending a lot of time with all the programmers.
He'll work with a programmer when they need help, he looks around to
see who needs help. A significant sign is where he sits. As a long
term ThoughtWorker, he could pretty well have any office he liked. He
shared one for a while with Cara, the release manager. However in the
last few months he moved out into the open bays where the programmers
work (using the open "war room" style that XP favors.) This is
important to him because this way he sees what's going on, and is
available to lend a hand wherever it's needed.
Those who know XP will realize that I'm describing the explicit XP
role of Coach. Indeed one of the several games with words that XP
makes is that it calls the leading technical figure the "Coach". The
meaning is clear: in XP technical leadership is shown by teaching the
programmers and helping them make decisions. It's one that requires
good people skills as well as good technical skills. Jack Bolles at XP
2000 commented that there is little room now for the lone master.
Collaboration and teaching are keys to success.
At a conference dinner, Dave and I talked with a vocal opponent of XP.
As we discussed what we did, the similarities in our approach were
quite marked. We all liked adaptive, iterative development. Testing
was important. So we were puzzled at the vehemence of his opposition.
Then came his statement, along the lines of "the last thing I want is
my programmers refactoring and monkeying around with the design". Now
all was clear. The conceptual gulf was further explicated by Dave
saying to me afterwards "if he doesn't trust his programmers why does
he hire them?". In XP the most important thing the experienced
developer can do is pass on as many skills as he can to the more
junior developers. Instead of an architect who makes all the important
decisions, you have a coach that teaches developers to make important
decisions. As Ward Cunningham pointed out, by that he amplifies his
skills, and adds more to a project than any lone hero can.
※※※※※※
五百年谪在红尘 略成游戏 三千里击于沧海 便是逍遥 >>>>>>飞天玄鹤留<<<<<<
[楼主] [3楼] 作者:darkcran 发表时间: 2008/11/02 22:35
[加为好友][发送消息][个人空间]
回复 修改 来源 删除
http://space.itpub.net/81/viewspace-232358
The role of the Software Architect
by Fabrice Marguerie (http://weblogs.asp.net/fmarguerie)
The Software Architect function is not well defined, and we have to
admit that it is difficult to give a precise definition of the term.
This article tries to determine the identity of these strange
characters by presenting the tasks they are assigned and the required
qualities to fulfill them.
Some time ago, I was asked to give my definition of therole of a
software architect in a small team, and state what the required
qualities to satisfy this function are, in my opinion. This article
presents the answer I gave at that time. I hope it will help you to
better understand the role and duties of an architect.
Architect or ArchitectS ?
The term "Software Architect" is somewhat vague. The definitions we
can give depend on the context. This article concentrates on
architects working with a small to medium team, on multiple projects,
but not so many. In these conditions, the software architect also acts
as atechnical experton one or multiple platforms.
During the DotNetGuru Symposium 2003, Sami Jaber presented two kinds
of architects:
* functional architects, who optimize business processes, and have a
very good knowledge about analysis methods;
* technical architects, who design long-term, reliable and adaptive
technical architectures, and constitute a technical gateway between
the project manager and the developers.
We can come across other kinds of architects. You can refer to the
resources presented at the bottom of this page to learn more. We will
focus here on technical architects, and not on functional architects.
Here is the role of atechnical architect, according to Sami:
* Anticipate on technological evolutions
* Build durable architectures
o Independence with regard to API/framework providers
* Promote genericity and abstraction
* Bridge between developers, project managers, and business experts
* Technological evangelization, sharp sense of communication
* Ensure the technical directions and choices
* Often mixed culture (.NET/J2EE/opensource)
* First a role instead of a job
Tasks and required skills
I won’t give here a definition of the wordarchitectin the sense I use
it. I will instead introduce some aspects of the role of a technical
software architect, as well as the required qualities to perform. such
a function. As previously stated, I here address mostly the context of
small and medium-sized businesses or small development departments. In
these cases, the role is often close to the role of a technical
expert.
We could summarize the functions of an architect within a few words.
Those could include: proposal work, advisory work, design,
realization, validation, presentations, reports, management,
transmitting as clearly as possible the results of a continuous
technological survey, guarantee the technical quality of developments…
But there is much more than that. The work carried out by an architect
is satisfying only if he has understood that his mission goes beyond
simple expertise and knowledge application.
An architect is often an ex-developer who has accumulated such
experience as to reach a good level in expertise. This experience must
cover ideally a variety of platforms and products, and knowledge about
the lifecycle of an application, or even of an information system.
The role of an architect is unique compared to the job of developers
or project managers, because it requires long-term involvement,
transverse to projects and teams. This gets even truer for long-
lasting collaborations, compared to classic consulting missions.
It is a key role in a team. The architect must work hand in hand with
the whole of the team to federate the energies of all the team
members.
It is obvious that the benefits of having an architect highly rely on
his involvement and integration with the project teams. It is thanks
to permanent interchanges with the developers and the project managers
that the architect will be able to communicate his knowledge, but also
make the best out of the work of the team and the individuals. The
architect must also be listening to the needs. Due to all this, there
are big relational requirements in this function. Communication skills
are required.
Diplomacy and pedagogy skills are also required to be able to explain
architectures, debate about them and have them adopted.
An architect must be able to step back and take a higher-level look,
which is often difficult for developers and projects managers because
they are often too focused on a specific project and so on immediate
needs. This means raising from the application level to the
information system level. This also means that the architect has to
perform. a continuous technological survey; one that goes further than
the context a specific project.
The architect has to submit proposals on the directions for
developments, with a long-term vision of the information system’s
architecture and of application integration problems, while keeping in
mind the priorities. It is thus better to favor a pragmatic approach,
by opposition to an idealistic one. Theory must remain guidance for
the long term and not an obstacle for developments, which are often
constrained in terms of delays.
However, even if I maintain that an architect has to step back from
his work and the teams’ work, I hardly conceive an architect who would
remain far from the implementation shop (the code, the project).
Indeed, an architect can have to write lines of code (at least to
create prototypes or mock-ups), but also has to get his hands dirty
with code to validate the quality of what is produced or resolve a
particularly technically difficult situation. Often are the pretty UML
diagrams or the architecture papers to be left aside to look under the
hood how things work (or don’t) in an application. This mainly means
that an architect must be able to quickly read and analyze code.
An architect doesn’t take part to a project only at its beginning, but
during the whole project’s lifecycle to ensure a right implementation
of the design and architecture. He also has to keep listening to new
requirements to adapt solutions if needed. Therefore, the involvement
of an architect can span the lifetime of an application to give new
directions, and ensure that the evolutions don’t weaken the whole
construction.
Often, architects will initiate in-house frameworks, which represent a
big part of the capitalization work of a company. In this case, the
architect becomes responsible for the framework’s directions and works
on the evolution to come.
A framework also facilitates the adoption of a technological platform.
such as .NET or J2EE. This is another task where an architect can help
if he is expert in a given environment.
Let’s repeat thatarchitectis more a role than a job. Having experience
is not all, it also requires qualities and before all a state of mind.
Architect or developer?
To finish on a lighter note, a question that gets often asked is: "how
to differenciate a software architect from a developer?"Michael Platt
wrote: "Architects are a lot slower in getting a solution, especially
if the problem is simple!". Probably we could add that "Architects are
much likely to come up with complex and costly solutions, especially
if the problem is simple!".
Addendum
When I first published this article, a couple of persons came up with
interesting links:
* Who needs an architect?- Martin Fowler
* Do you wanna be an Architect when you grow up?- Martin Fowler
Who is Fabrice Marguerie?
Fabrice Marguerie is a .NET architect and a Microsoft MVP. Fabrice
works as a consultant on design and implementation missions. He writes
a weblog in English:http://weblogs.asp.net/fmarguerieand administrates
the web site:http://sharptoolbox.com
Ian Gorton
Foreword
Architects learn on the job, bring years of experience in design and
technology to business problems they tackle.
Preface
Application servers, component technologies and messaging
infrastructures are the basic building blocks that are import to an IT
architect.
Definition of Software Architecture
a. Architecture Defines Structure
An architecture must be designed to meet the specific requirements and
constrains of the application it is intended for.
In partitioning an application, the architect assigns responsibilities
to each constituent component. These responsibilities define the tasks
a component can be relied upon to perform within the application. In
this manner, each component plays a specific role in the application,
and the overall component ensemble that comprise the architecture
collaborates to provide the required functionality.
Responsibility-driven Design can be used effectively to help define
the key components in an architecture.
A key structural issue for nearly all applications is minimizing
dependencies between components, creating a loosely coupled
architecture from a set of highly cohesive components.
b. Architecture Specifies Component Communication
A body of work known collectively as architectural patterns or styles
has cataloged a number of successfully used structures that facilitate
certain kinds of component communication. There patterns are
essentially reusable architectural blueprints that describe the
structure and interaction between collections of participating
components.
Large systems tend to use multiple patterns, combined in ways that
satisfy the architecture requirement. When a architecture is based
around patterns, it also becomes easy for team members to understand a
design.
c. Architecture Addresses Non-functional Requirements
Rather than define what the application does, they are concerned with
how the application provides the required functionality.
There are three distinct areas of non-functional requirements:
Technical constraints
Business constraints
Quality constraints
An application architecture must therefore explicitly address these
aspects of the design.
d. Architecture is an Abstraction
One of the most powerful mechanisms for describing an architecture is
hierarchical decomposition. Different levels of description in the
hierarchy tend to be of interest to different developers in project.
In reality, any architectural description must employ abstraction in
order to be understandable by the team members and project
stakeholders.
e. Architecture View
Views and Beyond approach recommends capturing an architecture model
using three different views:
Module: This is a structural view of the architecture, comprising the
code modules such as classes, packages and subsystems in the design.
It also captures module decomposition, inheritance, associations and
aggregations.
Component and Connector: This view describes the behavioral aspects of
the architecture. Components are typically objects, threads or
processes, and the connectors describe how the components interact.
Common connectors are sockets, middleware like CORBA or shared memory.
Allocation: This view shows the processes in the architecture are
mapped to hardware, and how they communicate using networks and/or
databases.
What Does a Architect Do?
a. Liaison
Architects play many liaison roles. They liaise between the customers
or clients of the application and the technical team, often in
conjunction with the business and requirement analysts. They liaise
between the various engineering teams on a project, as the
architecture is central to each of these. They liaise with management,
justifying designs, decisions and costs. Much of the time, this
liaison takes the form of simply translating and explaining different
terminology between different stakeholders.
b. Software Engineering
Excellent design skills are what get a software engineer to the
position of architect. They are an essential pre-requisite for the
roles. More broadly though, architects must promote good software
engineering practices. Their designs must be adequately documented and
communicated and their plans must be explicit and justified.
c. Technology Knowledge
Architects have a deep understanding of the technology domains that
are relevant to the types of applications they work on. They are
influential in evaluating and choosing third party components and
technologies. They tract technology development, and understand how
new standards, features and products might be usefully exploited in
their projects. Just as importantly, good architects know what they
don't know.
d. Risk Management
Good architects tend to be cautious. They are constantly enumerating
and evaluating the risks associated with the design and technology
choices they make. They document and manage these risks in conjunction
with project sponsors and management.
Architectures and Technologies
Architects must make design decisions early in a project lifecycle.
Judicious prototyping of key architectural components can help
increase confidence in a design approach, but sometimes it's still
hard to be certain of the success of a particular design choice in a
given application context.
Competition between product vendors drives innovation, better feature
sets and implementations, and lower prices, but it also places a
burden on the architect to select a product that has quality
attributes that satisfy the application requirement. Different COTS
technology implementation have different sets of strengths and
weaknesses and costs, and consequently will be better suited to some
types of application than others.
The difficulty for architects is in understanding these strengths and
weaknesses early in the development cycle for a project, and choosing
an appropriate reification of the architectural patterns they need.
Summary
"The life of a software architect is a long (and sometimes painful)
succession of sub-optimal decisions made partly in the dark". -
Philippe Krutchen
※※※※※※
五百年谪在红尘 略成游戏 三千里击于沧海 便是逍遥 >>>>>>飞天玄鹤留<<<<<<
本帖地址：http://club.xilu.com/darkcran/msgview-826955-50525.html[复制地址]
上一主题：第一财经周刊：当当卓越争分夺秒 下一主题：背包:材料+纤维度+纺织方法
[楼主] [2楼] 作者:darkcran 发表时间: 2008/11/02 22:21
[加为好友][发送消息][个人空间]
回复 修改 来源 删除
Is Design Dead?
http://www.martinfowler.com/articles/designDead.html
Growing an Architecture
==============================
What do we mean by a software architecture? To me the term
architecture conveys a notion of the core elements of the system, the
pieces that are difficult to change. A foundation on which the rest
must be built.
What role does an architecture play when you are using evolutionary
design? Again XPs critics state that XP ignores architecture, that
XP's route is to go to code fast and trust that refactoring that will
solve all design issues. Interestingly they are right, and that may
well be weakness. Certainly the most aggressive XPers - Kent Beck, Ron
Jeffries, and Bob Martin - are putting more and more energy into
avoiding any up front architectural design. Don't put in a database
until you really know you'll need it. Work with files first and
refactor the database in during a later iteration.
I'm known for being a cowardly XPer, and as such I have to disagree. I
think there is a role for a broad starting point architecture. Such
things as stating early on how to layer the application, how you'll
interact with the database (if you need one), what approach to use to
handle the web server.
Essentially I think many of these areas are patterns that we've
learned over the years. As your knowledge of patterns grows, you
should have a reasonable first take at how to use them. However the
key difference is that these early architectural decisions aren't
expected to be set in stone, or rather the team knows that they may
err in their early decisions, and should have the courage to fix them.
Others have told the story of one project that, close to deployment,
decided it didn't need EJB anymore and removed it from their system.
It was a sizeable refactoring, it was done late, but the enabling
practices made it not just possible, but worthwhile.
How would this have worked the other way round. If you decided not to
use EJB, would it be harder to add it later? Should you thus never
start with EJB until you have tried things without and found it
lacking? That's a question that involves many factors. Certainly
working without a complex component increases simplicity and makes
things go faster. However sometimes it's easier to rip out something
like that than it is to put it in.
So my advice is to begin by assessing what the likely architecture is.
If you see a large amount of data with multiple users, go ahead and
use a database from day 1. If you see complex business logic, put in a
domain model. However in deference to the gods of YAGNI, when in doubt
err on the side of simplicity. Also be ready to simplify your
architecture as soon as you see that part of the architecture isn't
adding anything.
Do you wanna be an Architect when you grow up?
==================================================
For much of the last decade, the term "software architect" has become
popular. It's a term that is difficult personally for me to use. My
wife is a structural engineer. The relationship between engineers and
architects is ... interesting. My favorite was "architects are good
for the three B's: bulbs, bushes, birds". The notion is that
architects come up with all these pretty drawings, but it's the
engineers who have to ensure that they actually can stand up. As a
result I've avoided the term software architect, after all if my own
wife can't treat me with professional respect what chance do I stand
with anyone else?
In software, the term architect means many things. (In software any
term means many things.) In general, however it conveys a certain
gravitas, as in "I'm not just a mere programmer - I'm an architect".
This may translate into "I'm an architect now - I'm too important to
do any programming". The question then becomes one of whether
separating yourself from the mundane programming effort is something
you should do when you want to exercise technical leadership.
This question generates an enormous amount of emotion. I've seen
people get very angry at the thought that they don't have a role any
more as architects. "There is no place in XP for experienced
architects" is often the cry I hear.
Much as in the role of design itself, I don't think it's the case that
XP does not value experience or good design skills. Indeed many of the
proponents of XP - Kent Beck, Bob Martin, and of course Ward
Cunningham - are those from whom I have learned much about what design
is about. However it does mean that their role changes from what a lot
of people see as a role of technical leadership.
As an example, I'll cite one of our technical leaders at ThoughtWorks:
Dave Rice. Dave has been through a few life-cycles and has assumed the
unofficial mantle of technical lead on a fifty person project. His
role as leader means spending a lot of time with all the programmers.
He'll work with a programmer when they need help, he looks around to
see who needs help. A significant sign is where he sits. As a long
term ThoughtWorker, he could pretty well have any office he liked. He
shared one for a while with Cara, the release manager. However in the
last few months he moved out into the open bays where the programmers
work (using the open "war room" style that XP favors.) This is
important to him because this way he sees what's going on, and is
available to lend a hand wherever it's needed.
Those who know XP will realize that I'm describing the explicit XP
role of Coach. Indeed one of the several games with words that XP
makes is that it calls the leading technical figure the "Coach". The
meaning is clear: in XP technical leadership is shown by teaching the
programmers and helping them make decisions. It's one that requires
good people skills as well as good technical skills. Jack Bolles at XP
2000 commented that there is little room now for the lone master.
Collaboration and teaching are keys to success.
At a conference dinner, Dave and I talked with a vocal opponent of XP.
As we discussed what we did, the similarities in our approach were
quite marked. We all liked adaptive, iterative development. Testing
was important. So we were puzzled at the vehemence of his opposition.
Then came his statement, along the lines of "the last thing I want is
my programmers refactoring and monkeying around with the design". Now
all was clear. The conceptual gulf was further explicated by Dave
saying to me afterwards "if he doesn't trust his programmers why does
he hire them?". In XP the most important thing the experienced
developer can do is pass on as many skills as he can to the more
junior developers. Instead of an architect who makes all the important
decisions, you have a coach that teaches developers to make important
decisions. As Ward Cunningham pointed out, by that he amplifies his
skills, and adds more to a project than any lone hero can.
※※※※※※
五百年谪在红尘 略成游戏 三千里击于沧海 便是逍遥 >>>>>>飞天玄鹤留<<<<<<
[楼主] [3楼] 作者:darkcran 发表时间: 2008/11/02 22:35
[加为好友][发送消息][个人空间]
回复 修改 来源 删除
http://space.itpub.net/81/viewspace-232358
The role of the Software Architect
by Fabrice Marguerie (http://weblogs.asp.net/fmarguerie)
The Software Architect function is not well defined, and we have to
admit that it is difficult to give a precise definition of the term.
This article tries to determine the identity of these strange
characters by presenting the tasks they are assigned and the required
qualities to fulfill them.
Some time ago, I was asked to give my definition of therole of a
software architect in a small team, and state what the required
qualities to satisfy this function are, in my opinion. This article
presents the answer I gave at that time. I hope it will help you to
better understand the role and duties of an architect.
Architect or ArchitectS ?
The term "Software Architect" is somewhat vague. The definitions we
can give depend on the context. This article concentrates on
architects working with a small to medium team, on multiple projects,
but not so many. In these conditions, the software architect also acts
as atechnical experton one or multiple platforms.
During the DotNetGuru Symposium 2003, Sami Jaber presented two kinds
of architects:
* functional architects, who optimize business processes, and have a
very good knowledge about analysis methods;
* technical architects, who design long-term, reliable and adaptive
technical architectures, and constitute a technical gateway between
the project manager and the developers.
We can come across other kinds of architects. You can refer to the
resources presented at the bottom of this page to learn more. We will
focus here on technical architects, and not on functional architects.
Here is the role of atechnical architect, according to Sami:
* Anticipate on technological evolutions
* Build durable architectures
o Independence with regard to API/framework providers
* Promote genericity and abstraction
* Bridge between developers, project managers, and business experts
* Technological evangelization, sharp sense of communication
* Ensure the technical directions and choices
* Often mixed culture (.NET/J2EE/opensource)
* First a role instead of a job
Tasks and required skills
I won’t give here a definition of the wordarchitectin the sense I use
it. I will instead introduce some aspects of the role of a technical
software architect, as well as the required qualities to perform. such
a function. As previously stated, I here address mostly the context of
small and medium-sized businesses or small development departments. In
these cases, the role is often close to the role of a technical
expert.
We could summarize the functions of an architect within a few words.
Those could include: proposal work, advisory work, design,
realization, validation, presentations, reports, management,
transmitting as clearly as possible the results of a continuous
technological survey, guarantee the technical quality of developments…
But there is much more than that. The work carried out by an architect
is satisfying only if he has understood that his mission goes beyond
simple expertise and knowledge application.
An architect is often an ex-developer who has accumulated such
experience as to reach a good level in expertise. This experience must
cover ideally a variety of platforms and products, and knowledge about
the lifecycle of an application, or even of an information system.
The role of an architect is unique compared to the job of developers
or project managers, because it requires long-term involvement,
transverse to projects and teams. This gets even truer for long-
lasting collaborations, compared to classic consulting missions.
It is a key role in a team. The architect must work hand in hand with
the whole of the team to federate the energies of all the team
members.
It is obvious that the benefits of having an architect highly rely on
his involvement and integration with the project teams. It is thanks
to permanent interchanges with the developers and the project managers
that the architect will be able to communicate his knowledge, but also
make the best out of the work of the team and the individuals. The
architect must also be listening to the needs. Due to all this, there
are big relational requirements in this function. Communication skills
are required.
Diplomacy and pedagogy skills are also required to be able to explain
architectures, debate about them and have them adopted.
An architect must be able to step back and take a higher-level look,
which is often difficult for developers and projects managers because
they are often too focused on a specific project and so on immediate
needs. This means raising from the application level to the
information system level. This also means that the architect has to
perform. a continuous technological survey; one that goes further than
the context a specific project.
The architect has to submit proposals on the directions for
developments, with a long-term vision of the information system’s
architecture and of application integration problems, while keeping in
mind the priorities. It is thus better to favor a pragmatic approach,
by opposition to an idealistic one. Theory must remain guidance for
the long term and not an obstacle for developments, which are often
constrained in terms of delays.
However, even if I maintain that an architect has to step back from
his work and the teams’ work, I hardly conceive an architect who would
remain far from the implementation shop (the code, the project).
Indeed, an architect can have to write lines of code (at least to
create prototypes or mock-ups), but also has to get his hands dirty
with code to validate the quality of what is produced or resolve a
particularly technically difficult situation. Often are the pretty UML
diagrams or the architecture papers to be left aside to look under the
hood how things work (or don’t) in an application. This mainly means
that an architect must be able to quickly read and analyze code.
An architect doesn’t take part to a project only at its beginning, but
during the whole project’s lifecycle to ensure a right implementation
of the design and architecture. He also has to keep listening to new
requirements to adapt solutions if needed. Therefore, the involvement
of an architect can span the lifetime of an application to give new
directions, and ensure that the evolutions don’t weaken the whole
construction.
Often, architects will initiate in-house frameworks, which represent a
big part of the capitalization work of a company. In this case, the
architect becomes responsible for the framework’s directions and works
on the evolution to come.
A framework also facilitates the adoption of a technological platform.
such as .NET or J2EE. This is another task where an architect can help
if he is expert in a given environment.
Let’s repeat thatarchitectis more a role than a job. Having experience
is not all, it also requires qualities and before all a state of mind.
Architect or developer?
To finish on a lighter note, a question that gets often asked is: "how
to differenciate a software architect from a developer?"Michael Platt
wrote: "Architects are a lot slower in getting a solution, especially
if the problem is simple!". Probably we could add that "Architects are
much likely to come up with complex and costly solutions, especially
if the problem is simple!".
Addendum
When I first published this article, a couple of persons came up with
interesting links:
* Who needs an architect?- Martin Fowler
* Do you wanna be an Architect when you grow up?- Martin Fowler
Who is Fabrice Marguerie?
Fabrice Marguerie is a .NET architect and a Microsoft MVP. Fabrice
works as a consultant on design and implementation missions. He writes
a weblog in English:http://weblogs.asp.net/fmarguerieand administrates
the web site:http://sharptoolbox.com
Reply all
Reply to author
Forward
0 new messages