today, a RUP teacher tell me that architecture is layering. is he right?

Jim Standley wrote:
See a few dozen defeinitions here:
Martin Fowler has a good one: "Design decisions that are hard to reverse."
, "architecture" is just the "big" end of the "design"
spectrum, with no distinction between designing and architecting.

Jim Standley <jimstandley (AT) adelphia (DOT) netwrites:

It's a little strong to say that Folwer puts that forth as a definition
here: He
comes closer to adopting something Ralph Johnson posted to a discussion:
It's the important stuff.

i did not well understand the last few paragraphs. what's Fowler's point about
regarding architecture as irreversible part of a system? he said people can
make irreversible part as non-irreversible and this effort adds complexity. so
should or not we as a programmer try to eliminate the irreversibilities in a
system?

I really like "the big end of the design spectrum" but I don't know just
where the line is when things are not "big enough" to be architecture. A
system has an architecture; a component might have an internal
architecture; how small can we go?

I also agree the activities "architecting" and "designing" are a lot the
same. I'd hesitate say a system with no "hard to reverse" bits has no
architecture. It probably has some beautifully designed (architected?)
abstractions.

"The important stuff" of course leads to the question, to whom? It's
interesting to see just how many people come to our team and ask for an
"architecture overview" and how different their needs and expectations are.

Phlip wrote:
>Jim Standley wrote:
>
>
See a few dozen defeinitions here:

>
>
>Martin Fowler has a good one: "Design decisions that are hard to reverse"
>
>, "architecture" is just the "big" end of the "design"
>spectrum, with no distinction between designing and architecting.
>
>
>
To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links
>
>
>

>
>
>
>

Architecture is a poorly defined term: there is no
formal difference between it and design.

The people who took the job title from the building
trade didn't realize that it corresponded to what we
call UI designers or usability design. The actual
building design is done by a structural engineer.
It's a term that's looking for a meaning.

That's what Martin Fowler is doing; he's looking
for some meaning to give it that's different from
design, and has the importance that people tend
to give the job title of Architect.

John Roth

Message
From: "Steven Woody" <narkewoody.at.gmail.com (AT) yahoogroups (DOT) at.jhrothjr.com>
To: "extremeprogramming (AT) yahoogroups (DOT) com"
<@yahoogroups.at.jhrothjr.com>
Sent: Tuesday, September 13, 2005 7:39 AM
Subject: Re: [XP] What is exactly definition of Architecture

Jim Standley <jimstandley (AT) adelphia (DOT) netwrites:

It's a little strong to say that Folwer puts that forth as a definition
here: He
comes closer to adopting something Ralph Johnson posted to a discussion:
It's the important stuff.

i did not well understand the last few paragraphs. what's Fowler's point
about
regarding architecture as irreversible part of a system? he said people can
make irreversible part as non-irreversible and this effort adds complexity.
so
should or not we as a programmer try to eliminate the irreversibilities in a
system?

I really like "the big end of the design spectrum" but I don't know just
where the line is when things are not "big enough" to be architecture. A
system has an architecture; a component might have an internal
architecture; how small can we go?

I also agree the activities "architecting" and "designing" are a lot the
same. I'd hesitate say a system with no "hard to reverse" bits has no
architecture. It probably has some beautifully designed (architected?)
abstractions.

"The important stuff" of course leads to the question, to whom? It's
interesting to see just how many people come to our team and ask for an
"architecture overview" and how different their needs and expectations
are.

Phlip wrote:
>Jim Standley wrote:
>>
>>
See a few dozen defeinitions here:

>>
>>
>Martin Fowler has a good one: "Design decisions that are hard to
>reverse."
>>
>, "architecture" is just the "big" end of the "design"
>spectrum, with no distinction between designing and architecting.
>>
>
>
To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links
>
>
>
>
>
>
>
>

Jim Standley <jimstandley (AT) adelphia (DOT) netwrites:

It gets a bit circular here: "Making something easy to change makes the
overall system a little more complex, and making everything easy to
change makes the entire system very complex. Complexity is what makes
software hard to change."

yes, it is the circular statement which make confusion. i dont know what i
should follow.

Making something easy to change makes it hard to change. I'm glad we're
clear on that. :-)

I'm optimistic that fanatical attention to dependencies by skilled folks
can make good abstractions emerge to help reduce the number of things
that are hard to change. I've observed, however, that without the right
skills and priorities, lots of things become hard to change.

Steven Woody wrote:
>
>
>i did not well understand the last few paragraphs. what's Fowler's point about
>regarding architecture as irreversible part of a system? he said people can
>make irreversible part as non-irreversible and this effort adds complexity. so
>should or not we as a programmer try to eliminate the irreversibilities in a
>system?
>
>
>
To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links
>
>
>

>
>
>

Mon, Sep 12, 2005 at 12:35:04PM -0400, Jim Standley wrote:
It's a little strong to say that Folwer puts that forth as a definition
here: He
comes closer to adopting something Ralph Johnson posted to a discussion:
It's the important stuff.

I really like "the big end of the design spectrum" but I don't know just
where the line is when things are not "big enough" to be architecture.
[]

I'm pretty sure I agree with the above, since it reminds me a lot
of something I've posted here in the past. I think I like the
phrasing "the big end of the design spectrum" better; succinct,
simple.

I also agree the activities "architecting" and "designing" are a lot the
same. []
"The important stuff" of course leads to the question, to whom? []

I'm going to stick with the answer I posted previously, which is
"to whoever's asking" :-). Architecture is, IMH, the design aspects
as seen from one level up from whatever is your main context; the view
that usefully hides enough detail to let you think about the strategic
implications of what you're doing, while at the same time remaining
relevant to what you're doing:
- To a particular development team, architecture is how the big pieces
of the programming puzzle fit together.
- To the system group, architecture may include the hardware as well
as the major application environments running on it (databases,
messages queues, app servers, etc).
- To a CT, architecture may include long-term investments in
technology infrastructure (including the human and organizational
infrastructure).

And so forth. Sometimes there's a sweet spot, a particular
neighborhood of contexts where you seem to to spend a lot of time, and
of course there's overlap.

My definition: Architecture is the set of design choices that
most affect the quality attributes of the system.
Dale