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
