I touched a bit on some of this in my last blog post, intended to
stimulate a discussion on what is architecturally significant. There
are many things that someone could critique about a solution's
architecture, and what is significant is very dependent on the
organization's larger goals. As Rob suggests, if on time delivery is
top priority, that frequently has long term implications. Here's my
blog:
http://www.biske.com/blog/?p=777
-tb
Todd Biske
http://www.biske.com/blog/
Sent from my iPhone
On Apr 26, 2010, at 1:09 PM, reamon943 <[email protected]> wrote:
I was reading a review of a new book that just came out covering the
architectural aspects of buildings in and around where I live. One
of the comments from the author was about how the architecture of
one of the newer movie theater complexes was considered "throwaway
architecture" (or disposable architecture) but still was a
significant aspect of the community.
This got me to thinking about throwaway architecture and how/if it
might apply to business, enterprise, application, etc. architectures
that are influenced or guided by SO principles.
Candidate aspects for discussion:
* When to consider throwaway aspects. This as contrasted with what
I'd call "Roman" architecture--aspects that are expected to last a
long time.
* How this might tie in with anti-principles or "non-principles."
Steve Jones explored these in his blog at http://service-architecture.blogspot.com
. Non-principles are items that the architecture explicitly states
that it is not addressing. How might this factor in with throwaway
architecture?
* "Quick and dirty" projects (time and cost considered above all
else) often become the "long and painful"--systems that are used
well beyond their intended life. How might an architecture address
these sort of projects, perhaps isolating them in some way.
* From a letter to the editor discussing the state of construction
in Houston: "Are we better off in a city with a lot of expensive
"built-to-last" structures that are renovated for new uses? Or with
cheaper structures that just get torn down and replaced every so
often?...Does it make sense to invest in a structure that will last
50, 100, or more years and then try to continuously re-adapt it as
needed?" Applying these questions to business and/or enterprise
architecture might yield some interesting and useful answers. Jones
touches on this as well in his "Is IT evolution a bad thing?" blog
post.
I hope this is an interesting topic that generates some good open-
ended discussion.
-Rob
