{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

arch_paradox_solution - subbu.org about | archives |...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
subbu.org about | archives | twitter | Search Results subbu.org about | archives | twitter | Architecture Paradox without comments Introduction A 1996 technical report [1] from the Software Engineering Institute , in its introduction points out that software architecture is still a relatively immature area from both research and practice perspectives. The same holds true in 1999 after maturity and emergence of several generic as well as domain-specific architectures. Today, the area is largely immature not because of lack of research, but lack of its practice. But why is it difficult to practice software architecture? In commercial software industry, where products and applications are required to be built over very short time-frames with tight budgets, the term "architecture," though widely used, is rarely practiced as a concept or as an integral part of software building. Ironically, it is this specific industry segment that requires more emphasis on software architecture for at least two reasons: budgetary constraints, and shorter time to deployment. Both these factors demand protection of investments in information technology. Protection of investments requires protection of software architecture against changing requirements. In a nutshell, this is the focus of this article. While architecture is generally perceived to be crucial for any software development exercise, in practice, architectures are rarely part of software development life-cycles, when so, rarely complete, and when complete, rarely protected and adhered to. This is one of the reasons why changes to software are expensive. Despite this, architectures are sought by concerned parties in almost all software development projects. The purpose of this article is to discuss "Architecture Paradox" and bring out the conflicting forces that influence the architecture over the life-time of software products and applications. A sequel to this paper also presents some of the author’s early ideas on how to defy this paradox and develop long-lasting and evolutionary self-supporting architectures. What is Software Architecture?
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
This article does not attempt to define or redefine architecture as applicable to software. The focus of this article is, instead, on the purpose and role of architecture during the software life cycle and beyond, to identify the factors that affect the architecture, and to finally discuss how to address the conflict between these factors. Readers interested in what software architecture is, should refer to [1] and [2] . For the purpose of the present discussion, the following definition and explanation (both from [1] ) are relevant. Architecture: Structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}