What is architecture?
The Rt Rev'd Dr Colin James III, KOTM
"GradyBooch" <e...@rational.com> posted with deletions:
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
>
> What is software architecture?
>
> My favorite definition is from Kent Beck, who defines it this way:
>
> "Software architecture is what software architects do."
>
> I've been surveying the literature, and as you might expect, there's a wide
> diversity of opinion.
>
> So, how do you define software architecture? Could you post/email me your
> definition?
>
> --
> Grads Booch
> Chief Scientist
> Rational Software Corporation
>
>
Software architecture is what Rational Software Corporation says it is, anyone
knows that.
Clearly Booch is not too busy as Chief Scientist, or lecturing, or traveling,
or writing books if he's posting idiotic trolls here.
On the upside, at least he found his Shift-key for a change, and is not typing
all in lower-case in the wee hours of the morning.
John Hawkins
Tim Ottinger wrote:
[snip]
> *** Task-wise ****
>
>
> I feel that there are physical architectures and logical architectures.
This is a good point. I had never thought of it this way.
As one of the dinosaur breed, I have always thought of architecture in
terms of defining the software components and the relationships between
them. In most systems I have worked on (combined Hardware/Software), the
architecture requires multiple descriptions just as building plans do.
The hardware system diagram represents one view and the software diagram
represents another, while the flow of control represents a third. The
term architecture refers to a combination of all of the views.
I do not include the design of the individual components as part of the
architecture.
While I belive in the OO approach, I still struggle with how to design a
system based on my architecture definition above.
Grady Booch
At the risk of starting a thread to which I'm sure there will be many
passionate responses, I'd like to pose a simple question:
What is software architecture?
My favorite definition is from Kent Beck, who defines it this way:
"Software architecture is what software architects do."
I've been surveying the literature, and as you might expect, there's a wide
diversity of opinion.
So, how do you define software architecture? Could you post/email me your
definition?
--
Grady Booch
Tim Ottinger
Grady Booch wrote:
>
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
I've a dispassionate response if that will help. And I didn't just
go and look it up in one of your books. :-)
*** Task-wise ****
To me, "architecture" is sort of like strategic design, and the rest
is tactical design. Architecture is a high level modeling activity.
I feel that there are physical architectures and logical architectures.
Physical architecture is determining how to split functionality across
machines and tasks (and sometimes threads, but these are more tactical).
It involves choosing hardware (if you're lucky, most aren't) and middle
ware (if you're lucky; most aren't), and databases (if you're lucky),
and
network technologies (if you're lucky) and the like. It may also
involve
consulting on the purchase of certain libraries of classes or functions.
Once physical architecture choices are made, they tend to "stick" more
due
to cost of change than anything else.
Another phase of the physical architecture is package design, and the
creation of libraries, DLLs, COM components, etc, to carry these
packages
-- at least at the strategic level. This is the physical part that may
(must?) evolve.
Logical architecture is different. It is about defining the operating
principles, highest level policies, and essential framework of an
application. It says how the UI will interact with the business
functionality and where dependencies will be allowed. It is "the overall
shape of the project". A lot of this is creating or selecting the idioms
(patterns?) that describe the "how to" for specific functions. The
logical
architecture is usually planned initially, but often must evolve as more
is learned about implementing the low-level designs.
*** "Phase Wise"
Architecture is what you do after you start exploring design space,
where
you look for threads that tie the "stovepipe" designs together in the
most cohesive way. It is somewhat parallel with detailed design, and the
overall goal is to build a system that supports the low-level design.
Is that useful, or at least interesting?
Nigel Tzeng
In article <63t9ma$r0a$1...@rational2.rational.com>,
Grady Booch <e...@rational.com> wrote:
>At the risk of starting a thread to which I'm sure there will be many
>passionate responses, I'd like to pose a simple question:
>
>
>My favorite definition is from Kent Beck, who defines it this way:
>
>"Software architecture is what software architects do."
I like this definition because it leads us down some interesting
paths.
If we follow the example of traditional architecture we could assume
that there are mechanical aspects to architecture...for the architect
these are the drawing, modeling and engineering skills that form the
foundation of their role. However, this isn't the most important
aspect of what they do. The architect seeks out elegant forms to
follow the function.
Likewise, the software architect has mechanical skills related to
software but the essence of their role is to seek out elegant designs
(conceptual models) to follow the requirements.
This doesn't specifically give a definition to software architecture
unless you want to define it as the structure/conceptual model/framework
of software but that seems as imprecise as saying architecture is the
"look" of a building.
The architecture is a synthesis of the way the building looks or the
software operates, the way it fits or interacts with the environment,
the way it fits and interacts with the resident or user and your
particular definition of how the "form" of a building/program differs
from the "function".
That still doesn't leave you with a very precise definition does it? :)
>Grady Booch
Nigel Tzeng
John D Salt
In article <63t9ma$r0a$1...@rational2.rational.com>,
Grady Booch <e...@rational.com> wrote:
>At the risk of starting a thread to which I'm sure there will be many
>passionate responses, I'd like to pose a simple question:
>
>What is software architecture?
At the risk of irritating everyone who hates "mu" answers (and, I
confess, to provoke some of those "passionate responses") I'd say
that "software architecture" is a mistaken metaphor.
We software folks often talk of "building", "constructing", or
(with a fine disregard for the language) "architecting" software
systems, which should be "industrial strength", and built on
"firm foundations", probably using "pre-fabricated" components.
In short, we see writing software as building. I don't think
it's a very good parallel with what goes on in s/w development.
If we think of information systems as living, evolving things, that
both cause and respond to changes in their environment, we might
do better with metaphors of "growing", rather than "building",
software.
Rather than "Software Architect", I'd like to see more appointments
made to the post of "Software Gardener".
All the best,
John.
[Who wonders if this reminds anyone else of Flann O'Brien's idea
of "tecticulture", growing buildings from seeds.]
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.
Richie Bielak
John D Salt wrote:
>
> In article <63t9ma$r0a$1...@rational2.rational.com>,
> Grady Booch <e...@rational.com> wrote:
> >At the risk of starting a thread to which I'm sure there will be many
> >passionate responses, I'd like to pose a simple question:
> >
> >What is software architecture?
> > [big snips]
>
> At the risk of irritating everyone who hates "mu" answers (and, I
> confess, to provoke some of those "passionate responses") I'd say
> that "software architecture" is a mistaken metaphor.
I have the same feelings about the analogy to "regular" architecture.
[...]
> Rather than "Software Architect", I'd like to see more appointments
> made to the post of "Software Gardener".
Rather than gardening why not consider similarities between designing
software and composing music? "Software Composer" feels right. After
all when you write music you specify precisely how certain sound
events occur in time. The same in software - a program executes in
time and the sequence of events is important. :-)
...richie
--
-> "It is a good day to code."
-> Mail: ric...@calfp.com
-> WWW: http://www.netlabs.net/hp/richieb
Ron Perrella
Grady Booch wrote:
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
>
> What is software architecture?
Software architecture is the art of selecting and combining software
patterns to meet system requirements and form software systems.
(I really tried hard to make a single sentence.)
Thus, software architecture is unrelated to object-oriented programming,
structured programming, and such because it deals with patterns. OO may
be used to implement the patterns but it is by no means necessary. For
example, the Client-Server pattern is hardly limited to object-oriented
designs. The patterns determine behavior, limitations, and such. For
example, if I describe a system architecture which is:
1. Is Client-server based
2. Has a relational database backend
3. Uses client and server side proxies.
4. has a name service.
5. etc.
you begin to get an idea of the "flavor" of a system. The more I add
patterns, the clearer the idea of how the system will look and behave.
In a way, a software architecture resembles building architecture in
having multiple views of a building. You may view a building from the
top, left-side, or right side. You may view software systems as a
multi-dimensional structure as well. As a result, I can view a system
as being Client-Server, in the "connectivity" dimension. However, I can
see it is also Event-driven, in the "thread-of-control" dimension. The
dimensions used depend on the nature of the system. Thus, there may not
be a canonical list of dimensions.
Does this make sense to anyone but me?
Ron Perrella
Scott Gibson
John D Salt wrote:
>
<SNIP of case for following statement>
> Rather than "Software Architect", I'd like to see more appointments
> made to the post of "Software Gardener".
Architect implies several things. Such as Solid foundations, 'Bigness'
etc.
Gardener implies someone who can work well with lots of small things.
There is also the implication that the Gardener can use manure and
create something really spectacular.
Shayne Flint
Grady Booch wrote:
>
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
>
> What is software architecture?
>
For users of the Shlaer/Mellor method the answer is simple. The method,
which is described at http://www.projtech.com, separates concerns into
'domains'. Typically you would have an 'Application Domain' containing
objects related to the application being developed, a 'User Interface
Domain' containing objects such as windows, buttons, icons etc., a
number of support domains (I/O etc.) and the 'Software Architecture
Domain' containing objects such as events, state machines, timers, etc.
Each domain is modelled using the Shlaer/Mellor method (information,
lifecycle and process models). Modelling of the application domain can
be considered "Analysis" (as the term is more widely used by the
industry), while modelling of most other domains (including the Software
Architecture Domain) can be considered "Design". (BTW - this answers
other often asked questions such as "What is Analysis?" and "What is
Design?" - they are easily separated using Shlaer/Mellor)
For my purposes, modelling of the "Software Architecture Domain" (and in
some cases other domains such as I/O) is the act of "Software
Architecture" and part of the overall design process. The result of this
work is a "Software Architecture" artefact. When modelling the "Software
Architecture Domain" you are developing, evaluating and selecting
appropriate implementations for objects in other domains. The concerns
of this work are nicely separated from other concerns rather than an
elaboration of them!
The problem with other methods is that they confuse the issues of
analysis and design into one set of models leading to questions such as
"What is analysis?", "What is design?" and "What is Software
Architecture?". These ARE separate issues and methods should treat them
as such. If they do, life is much simpler.
regards,
------------------------------------------------------------------
-- Shayne Flint, MIEAust, CPEng sha...@ainslie-software.com
-- Ainslie Software Pty Limited http://www.ainslie-software.com
--
-- ShapeDB, a database and form drawing add-on for Visio
------------------------------------------------------------------
George Seriakov
Hi!
On Thu, 6 Nov 1997 13:35:57 -0700, "Grady Booch" <e...@rational.com>
wrote:
>What is software architecture?
>So, how do you define software architecture? Could you post/email me your
>definition?
AFAIK "archi" means "main", "upper", "principal" in Greece.
"Tectos" means "linkage", "binding". Literally, architecture means
"binding in the top" or "main binding".
I.e. software architecture is upper level design, the set of
main design decisions which are not depending on other part of design.
>Grady Booch
---
George Seriakov (seri...@aha.ru)
Kimber
So event driven programming is sort of like punk rock? :-)
Richie Bielak <ric...@calfp.com> wrote in article
<34631ADF...@calfp.com>...
> John D Salt wrote:
> >
> > In article <63t9ma$r0a$1...@rational2.rational.com>,
> > Grady Booch <e...@rational.com> wrote:
> > >At the risk of starting a thread to which I'm sure there will be many
> > >passionate responses, I'd like to pose a simple question:
> > >
> > >What is software architecture?
> > > [big snips]
> >
> > At the risk of irritating everyone who hates "mu" answers (and, I
> > confess, to provoke some of those "passionate responses") I'd say
> > that "software architecture" is a mistaken metaphor.
>
> I have the same feelings about the analogy to "regular" architecture.
>
> [...]
>
> > Rather than "Software Architect", I'd like to see more appointments
> > made to the post of "Software Gardener".
>
Kyle
On Sat, 08 Nov 1997 15:58:28 GMT, seri...@aha.ru (George Seriakov)
wrote:
> AFAIK "archi" means "main", "upper", "principal" in Greece.
>"Tectos" means "linkage", "binding". Literally, architecture means
>"binding in the top" or "main binding".
>
> I.e. software architecture is upper level design, the set of
>main design decisions which are not depending on other part of design.
>
>>Grady Booch
>
>---
>George Seriakov (seri...@aha.ru)
Although I sympathize with Mr. James, I thougtht this etymology was
enlightening enough to expand upon. I would interpret it then, as
something (deliberately vauge) that provides *high-level coherency*
(in some aspect.) The "something" could be user interface guidelines,
a structured design, an object model, a function interface protocol,
etc. The "aspect" could be the cultural context it which the software
is used, the software practices in use by the developers, industry
conventions to which the software must conform, and so on. Considered
this way, it is easy to see why the term "software architecture" gets
applied to so many practices.
George Seriakov
Hi!
On Sun, 09 Nov 1997 19:23:50 GMT, ephe...@sky.net (Kyle) wrote:
>> I.e. software architecture is upper level design, the set of
>>main design decisions which are not depending on other part of design.
>Although I sympathize with Mr. James, I thougtht this etymology was
>enlightening enough to expand upon. I would interpret it then, as
>something (deliberately vauge) that provides *high-level coherency*
>(in some aspect.)
Anything during software development can be refered as
"decision". The key feature of the definition of software architecture
is dependence - dependence of the rest of project on architecture.
Thinking in expanded manner the software development project is
the "tree" (not a tree in mathematical sence) of depended decision. At
the top of this dependence the decisions are called "requirements". The
part of design decisions which are defining the rest of design (and
hence providing "coherency") is architecture .
>The "something" could be user interface guidelines,
>a structured design, an object model, a function interface protocol,
>etc.
These are decisions.
---
George Seriakov (seri...@aha.ru)
The Rt Rev'd Dr Colin James III, KOTM
"Kimber" <rbra...@san.rr.com> posted with deletions:
> So event driven programming is sort of like punk rock? :-)
No, it's as Richie Bielak of CALfp.com who is a consummate fool.
Michael Cox
Perrella <perr...@mindspring.com> wrote:
> Grady Booch wrote:
> > At the risk of starting a thread to which I'm sure there will be many
> > passionate responses, I'd like to pose a simple question:
> >
> > What is software architecture?
> Software architecture is the art of selecting and combining software
> patterns to meet system requirements and form software systems.
Yes! That's it! That's exactly what I do. Succinctly put.
<snip>
> In a way, a software architecture resembles building architecture in
> having multiple views of a building. You may view a building from the
> top, left-side, or right side. You may view software systems as a
> multi-dimensional structure as well. As a result, I can view a system
> as being Client-Server, in the "connectivity" dimension. However, I can
> see it is also Event-driven, in the "thread-of-control" dimension. The
> dimensions used depend on the nature of the system. Thus, there may not
> be a canonical list of dimensions.
The dimensions used depend on which facet of the whole
you are concentrating on at the time. Most of the systems
I have worked with have many dimensions. All of them must
be defined and described in order to "construct" them properly.
There most likely is a canonical list common to most systems.
The pattern community seem to be building one, even though
thay may not acknowledge it directly.
> Does this make sense to anyone but me?
Perfect sense.
> Ron Perrella
sha...@ainslie-software.com
Apologies if this message was posted twice - my ISP's news server may not
be operating correctly.
Grady Booch wrote:
>
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
>
> What is software architecture?
>
For users of the Shlaer/Mellor method the answer is simple. The method,
which is described at http://www.projtech.com, separates concerns into
'domains'. Typically you would have an 'Application Domain' containing
objects related to the application being developed, a 'User Interface
Domain' containing objects such as windows, buttons, icons etc., a
number of support domains (I/O etc.) and the 'Software Architecture
Domain' containing objects such as events, state machines, timers, etc.
Each domain is modeled using the Shlaer/Mellor method (information,
lifecycle and process models). Modeling of the application domain can
be considered "Analysis" (as the term is more widely used by the
industry), while modeling of most other domains (including the Software
Architecture Domain) can be considered "Design". (BTW - this answers
other often asked questions such as "What is Analysis?" and "What is
Design?" - they are easily separated using Shlaer/Mellor)
For my purposes, modeling of the "Software Architecture Domain" (and in
some cases other domains such as I/O) is the act of "Software
Architecture" and part of the overall design process. The result of this
work is a "Software Architecture" artefact. When modeling the "Software
Architecture Domain" you are developing, evaluating and selecting
appropriate implementations for objects in other domains. The concerns
of this work are nicely separated from other concerns rather than an
elaboration of them!
The problem with other methods is that they confuse the issues of
analysis and design into one set of models leading to questions such as
"What is analysis?", "What is design?" and "What is Software
Architecture?". These ARE separate issues and methods should treat them
as such. If they do, life is much simpler.
regards,
------------------------------------------------------------------
-- Shayne Flint, MIEAust, CPEng sha...@ainslie-software.com
-- Ainslie Software Pty Limited http://www.ainslie-software.com
--
-- ShapeDB, a database and form drawing add-on for Visio
------------------------------------------------------------------
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Glenn Schrader
Grady Booch wrote:
<snip>
> definition?
>
> Grady Booch
> Chief Scientist
> Rational Software Corporation
In my view, "Software Architecture" is a specialized sub-domain of
Systems
Engineering. Perhaps a better term would be "Software Systems
Engineering"?
I usually work on embedded real-time applications. In my experience a
"good"
software architecture is a component of a larger system architecture in
which reasoned tradeoffs are made between what will be done in software,
what will be done in hardware, etc. Even with off-the-shelf systems a
software architecture can be dependant upon the overall system
constraints.
These sorts of concerns seem to fall naturally into Systems Engineering.
There are three formal definitions for Systems Engineering at
http://www.mlode.com/~mcclinto/definitions.html
I especially like the IEEE definition although they all seem to be
acceptable generalizations of what I think should go into an
"architecture". By the way, I'm not a Systems Engineer. I just find
that this view works very well for me.
--
============================================================
| Glenn Schrader | Email gsc...@ll.mit.edu |
============================================================
Mike Brady
I would think it fair to first say "caveat emptor" before examining any
definition of software architecture. The burden of selecting one particular
definition would be well akin to my son Peter defining personality through
his view of "personable persons". I have to confess that the "pork chops'n
apple sauce" routine was quite amusing however. As misguided as Peter was,
he learned a valuable lesson in the end. As did I. Software architecture,
like personality, is dynamic. Attempting to formally define either term and
apply that definition in a structured context may not be practical or wise.
Mike Brady,
Speaking for myself, not Mr. Phillips.
For some great ideas on how to astro-turf your cubicle, e-mail me:)
Grady Booch <e...@rational.com> wrote in article
<63t9ma$r0a$1...@rational2.rational.com>...
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
>
> What is software architecture?
>
> My favorite definition is from Kent Beck, who defines it this way:
>
> "Software architecture is what software architects do."
>
> I've been surveying the literature, and as you might expect, there's a
wide
> diversity of opinion.
>
Brad Appleton
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
>
> What is software architecture?
I tend to think of software architectural design as fleshing out the
structure of the system. That is identifying what all the different
software components are (or objects or modules or whatever you want to
call them) at each level of abstraction, and identifying their
relationships to one another (colloborations, uses, dependencies,
etc.). The business of fleshing out the details of each components is
what I think of as "detailed design".
Some "software architecture" definitions that Im rather fond of are ...
**********
From an Aug'96 posting on comp.object by Robert Martin:
| In my view, the architecture of a software application is the
| structural portion of the application that is independent of the
| application and upon which the application is founded, and into which
| the partitions of the application are allocated.
|
| It is composed of the tools, class libraries and frameworks that are
| used. It is also composed of the high level reusable domain model.
| i.e. a set of high level abstract interfaces that describe the
| overall problem domain.
|
| A "good" architecture has the following properties IMHO.
|
| 1. It provides a significant amount of tools and framework to the
| application, and to many other similar applications in the same
| domain. A good architecture is reusable in plenty.
|
| 2. It captures the highest level policies of the application domain.
| That is, the design and code that implements the policies and
| algorithms that are invariant within the problem domain are captured
| in, and are part of, the architecture.
|
| 3. The bulk of the resuable parts of the architecture do not need to
| be modified. Indeed, they can be linked in from libraries and not
| recompiled. In the presence of DLLs, all the applications should use
| the same DLL, and when the architecture changes, a new DLL can be
| issued without recompiling all the applications.
|
| In my experience, good architectures have an initial design, but then
| evolve greatly beyond that design. I have learned that to try to
| design too much up front can lead to failure of the architecture. In
| order to be successful, architectural entities must apply equally to
| the different applications in the domain. Although it may seem
| possible to design such entities up front, before any applications
| have been written; I have found that it is far safer to build each
| element of the architecture and then test it with product intent
| code; especially from more than one application in the problem
| domain. That way you learn very quickly if the architectural elements
| are truly architectural, or just "real good ideas that didn't work
| out in the end".
**********
From the November 1995 issue of "IEEE Software" which is devoted
to Software Architecture. Some of the "definitions" of architecture in
that issue are:
++++++++++
... a system structure that consists of active modules, a mechanism
to allow interaction among these modules, and a set of rules that
govern the interaction.
-- Martin Boasson
Hollandse Signaalapparaten
++++++++++
There is currently no single, universally accepted definition of
software architecture, but typically a systems acrhitectural design
is concerned with describing its decomposition into computational
elements and their interactions.... Design tasks at this level
include organizing the system as a composition of components;
developing global control structures; selecting protocols for
communication, synchronization, and data access; assigning
functionality to design elements; physically distributing the
components; scaling the system and estimating performance; defining
expected evolutionary paths; and selecting among design alternatives.
-- David Garlan, Robert Allen, amd John Ockerbloom
Carnegie Mellon University
Garlan et. al. go on further to say that architectural design is
important for at least two reasons: it "makes a complex system
intellectually tractable by characterizing it at a high level of
abstraction"; and it lets designers "exploit recurring organizational
patterns".
++++++++++
Software architecture = {Elements, Forms, Rationale/Constraints}
-- Dewayne Perry and Alexander Wolf's formula as cited by
Phillipe Kruchten of Rational Software
++++++++++
Software architecture deals with abtraction, decomposition and
composition, and style and aesthetics. It also deals with the design
and implementation of software's high-level structures.
-- Phillipe Kruchten, Rational Software
Kruchten describes his 4+1 view model which characterizes a software
architecture using five concurrent views: logical, process, physical,
development, and scenarios. Kruchten and Booch are working on a new book
"Software Architecture and Iterative Design" which is currently due in
March of 1997 (Addison Wesley, ISBN: 0-8053-0596-3).
**********
David Garlan and Mary Shaw in "Software Architecture: Perspectives on an
Emerging Discipline" (Prentice-Hall, ISBN 0-13-182957-2) define software
architecture as:
Abstractly, software architecture involves the description of
elements from which systems are built, interactions among those
elements, patterns that guide their composition, and constraints on
these patterns.
++++++
... although architectural structures are abstract in relation to
details of the actual computations of the elements, those structures
provide a natural framework for understanding broader, system-level
concerns, such as global rates of flow, patterns of communication,
execution control structure, scalability, and intended paths of
system evolution. Thus, architectural descriptions serve as a
skeleton around which system properties can be fleshed out, and
thereby serve a vital role in exposing the ability of a system to
meet its gross system requirements.
++++++
In addition to specifying the structure and topology of the system,
the architecture shows the correspondence between the system
requirements and elements of the constructed system, thereby
providing some rationale for the design decisions.
**********
At the ICSE'97 conference there was a symposium on software reusability
(SSR'97) where one of the papers presented a 4+1model of software
architecture slightly different from Kruchten's model. They used the
following views: Domain (Problem Space), Component (H/W & S/W Elements,
Topology, Application), Interfaces (Protocols, Data Formats, Connectivity),
Platform (Computing H/W, O/S, Middleware), and the "+1" view of Context
(Scenarios, Simulations, Dynamics). The reference for the paper is:
"Software Architecture Characterization"
by Margaret (Maggie) J. Davis and Roger B. Williams
Proceedings of the 1997 Symposium on Software Reusability (SSR'97)
17-19 May 1997, Boston, MA (USA)
Edited by Medhi Harandi, ACM Press 1997
**********
There was a paper/presentation at OOPSLA'97 (sorry - the title escapes
me) that went into about a dozen different "views" of architecture that
either directly or indirectly influence the software. This included
things like process architecture and social architecture. If you really
want to know the reference - email me and Ill look it up at home.
**********
In "Guest editorial: Introduction to the Special Issue on software
architecture", IEEE Transactions on Software Engineering, 21(4), April
1995. David Garlan and DeWayne E. Perry define software
architecture as:
The structure of the components of a program/system, their
interrelationships, and principles and guidelines governing their
design and evolution over time. Like the architecture of a building,
it provides relationships among the components and constraints on
those.
**********
From "Issues in Software Architecture", Paul Dyson, OOPSLA '95, October
15-19th 1995, Austin, Texas:
A number of definitions for 'software architecture' have been
published but I would say that it is unnecessary and perhaps
impossible to provide a concrete answer to the question of what
software architecure actually is. This may seem like a problem, but
it is as impossible to define 'goodness', and yet still possible to
reach an agreement on what is good and what isn't - even on degrees
of 'goodness' such as "this is good, but that is better". However,
everone involved with architectural research agrees that architecture
is about structure rather than function. and my view of architecture,
at least for the purposes of these pages, is that it deals with the
structuring paradigms, styles and patterns that describe, or make up,
our software systems. In particular architectures can be overall
structures for systems. How it deals with those paradigms, styles and
patterns will change for different people at different times and in
different situations, but the important thing is that it not only
deals with how to structure and implement systems, but also why these
particular structures and implementations are better than other
possiblities.
**********
There are is also a great collection of software architecture definitions
at the SEIs software architecture site. Take a look at:
http://www.sei.cmu.edu/technology/architecture/definitions.html
I also have my own list of "favorite" links on this topic under
the "Software Engineering:Software Architecture" section of my
website (the URL is in my signature).
Summing up my own thoughts on the matter, I seem to recall someone
somewhere saying that "Software is [codified] knowledge!". (Does anyone
have a reference for that one?) If this is the case, and all the
elements from which we construct software were analagous to words and
characters in a language, then I would describe software architecture to
be the rules of "grammar" for the language that is softare.
Cheers!
--
Brad Appleton <bra...@enteract.com> | http://www.enteract.com/~bradapp/
"And miles to go before I sleep." | 3500+ WWW links on CS & Sw-Eng
Michael Wing
>My favorite definition is from Kent Beck, who defines it this way:
>"Software architecture is what software architects do."
I don't have any problem with this definition per se, but this cannot
be used for job definitions.
I recently worked in a company with 2 "architects" and about 10
"software engineers." The architects argued that they focus on
long-term issues while the software engineers merely grind out code.
There seems to be the subtle implication that architects make good
decisions and all of the important contributions, while software
engineers make bad decisions and write all of the bugs.
I find this distinction elitist and unfair. Many of our "software
engineers" had just as much experience and made equally valuable
contributions.
Until architecture is defined in such a way that architects know that
they can fail, and that software engineers are allowed to ignore
failed architectures, I don't want to work with any more "architects."
-- Michael Wing
Richie Bielak
Michael Wing wrote:
[...]
> I find this distinction elitist and unfair. Many of our "software
> engineers" had just as much experience and made equally valuable
> contributions.
>
> Until architecture is defined in such a way that architects know that
> they can fail, and that software engineers are allowed to ignore
> failed architectures, I don't want to work with any more "architects."
Ah!
"Those who can, code.
Those who can't code, architect."
Anonymous programmer
Jeffrey C. Dege
On Tue, 11 Nov 1997 20:00:06 GMT, Michael Wing <wi...@swcp.com> wrote:
>
>I recently worked in a company with 2 "architects" and about 10
>"software engineers." The architects argued that they focus on
>long-term issues while the software engineers merely grind out code.
>There seems to be the subtle implication that architects make good
>decisions and all of the important contributions, while software
>engineers make bad decisions and write all of the bugs.
>
>engineers" had just as much experience and made equally valuable
>contributions.
Jim Coplien has been working on identifying successful organization patterns,
See: http://www.bell-labs.com/user/cope/Patterns/Process/index.html
There are two patterns he discusses that might be relevent to your
situation: "Architect Controls Product" and "Architect Also Implements".
--
IF 2 + 2 .EQ. 5 THEN 5 = 4
Bill Bolton
On Tue, 11 Nov 1997 20:00:06 GMT, wi...@swcp.com (Michael Wing) wrote:
>Until architecture is defined in such a way that architects know that
>they can fail, and that software engineers are allowed to ignore
>failed architectures, I don't want to work with any more "architects."
Sounds fair to me.... as long as "architects" are also allowed to
ignore failed programs.
Unfortunately, "architects" often end up being the ones who have to
clean up the systems and business relationship problems caused by
failed programs.
Cheers,
Bill
Bill Bolton billb...@acslink.net.au
Sydney, Australia
Michael Wing
>>On Tue, 11 Nov 1997 20:00:06 GMT, wi...@swcp.com (Michael Wing) wrote:
>>Until architecture is defined in such a way that architects know that
>>they can fail, and that software engineers are allowed to ignore
>>failed architectures, I don't want to work with any more "architects."
>billb...@REMOVE-TO-EMAIL.acslink.net.au (Bill Bolton) wrote:
>Sounds fair to me.... as long as "architects" are also allowed to
>ignore failed programs.
>Unfortunately, "architects" often end up being the ones who have to
>clean up the systems and business relationship problems caused by
>failed programs.
In my experience, the architects move on to design the next cool
project, while the software engineers are left to clean up the mess. I
have yet to see architects held accountable for anything.
-- Michael Wing
m0nik3r
Scott Gibson wrote:
>
> John D Salt wrote:
> >
> <SNIP of case for following statement>
>
> > made to the post of "Software Gardener".
>
> etc.
>
> Gardener implies someone who can work well with lots of small things.
> There is also the implication that the Gardener can use manure and
> create something really spectacular.
Would this post be a case of that, cause I think I *DO* see something
growing there .... no wait, it was just mold!
John D Salt
In article <346A5EBB...@net1plus.com>,
m0nik3r <m0n...@net1plus.com> wrote:
>Scott Gibson wrote:
>> [snips]
>> There is also the implication that the Gardener can use manure and
>> create something really spectacular.
>
>Would this post be a case of that, cause I think I *DO* see something
>growing there .... no wait, it was just mold!
Please don't call that stuff "mould".
Senior management prefers the term "corporate culture". :-)
All the best,
John.
Bob Hutchison
wi...@swcp.com (Michael Wing) wrote:
I sympathise, but neither situation is very good, is it?
I kind of like the notion that, in the old days when architects built
cathedrals, they were personally responsible for placing the cap piece
on spires. This way, if the structure collapsed, it collapsed with the
architect. Until the cap piece is about to be set, the engineers have to
trust the architect not to design something that will fall apart in
construction. Then, the architect has to trust the engineers not to have
used shoddy construction techniques.
This separation of responsibilities and consequences may have something
to contribute to this thread.
Cheers,
Bob
---
Bob Hutchison, hu...@RedRock.com, (416) 760-0565
RedRock, Toronto, Canada
Teunis vanRee
Grady Booch wrote:
At the risk of starting a thread to which I'm sure there will be many
passionate responses, I'd like to pose a simple question:
What is software architecture?
Software architect: A person trained in the skill of software design.
Software architecture: The skill of software design...
Rafael J. Barros
> Grady Booch wrote:
>
> At the risk of starting a thread to which I'm sure there will be many
> passionate responses, I'd like to pose a simple question:
>
> What is software architecture?
The 1.1 chapter of the book Software Architecture by Mary Shaw and David
Garlan title is What is software architecture?... maybe this helps.
Bill Bolton
>At the risk of starting a thread to which I'm sure there will be many
>passionate responses, I'd like to pose a simple question:
>
>What is software architecture?
"Architecture: The technical blueprint for the corporate
resource that can be shared by many users and services. This
blue print is of how things fit together and so must concern
itself with standards. The opposite of architecture is to
select every element on a project by project basis."
Wendy Robson, "Strategic Management and Information Systems:
An Integrated Approach", Pittman Publishing, 1994
"An architecture is a framework for the disciplined
introduction of change. This is also a pretty good definition
of design. The difference between the two is that design, as
we commonly use the word, applies to a single product, while
architecture applies to a family of products."
Tom Demarco (but I've misplaced the citation details for it)