Software Process Architecture Issues

While an architecture might appear to be just describing the structure and relationships among the components of a system and the system’s interfaces with its operational environment, architectures actually fulfill a number of purposes. For software process architectures these purposes include: describing the significant components, structure, internal and external relationships and interfaces; defining graceful evolution paths and reuse variations required; guiding component selection, adaptation, composition and binding; allowing smooth assembly of the components and ccinnecting them with the surrounding environment; and providing compatibility across multiple instances. An architecture must, of course, allow provision of the needed functionality and performance, but it should, where possible, facilitate their provision and use. Any architecture must also try to address particular qualities or properties important for its system - for example, a fault-tolerant structure might help address a requirement for high reliability. A software process architecture covers (is reusable across) some sub-domain of software projects. Since a reuse architecture aims at capturing the invariant plus providing for (at least) anticipated changes and variations, one must start by deciding what can treated as stable and what variety must be accommodated. Such decisions having strong impact on an architecture include the scope of variety that must be accommodated in methods, role definitions, and standards. While many organizations may simplify their concerns by severely limiting the variety in these areas, I have had to treat thein as having significant variety. 2. WHAT ARE THE MAIN COMPONENTS OF AN ARCHITECTURE