ARCHITECTURAL-FRAMEWORK BASED SYSTEM DEVELOPMENT
                          by Bob Marcus

    There is a growing realization in the software engineering
 community that industrial application development should be based
 on reusable architectural frameworks. Most of the existing methodologies
 and modeling techniques have been focused on individual application
 development.

   Key Question:  How should industrial organizations model, deploy,
 customize and extend architectural frameworks to support application
 development?

   (Related references from CMU http://www.cs.cmu.edu/Groups/able/)

  Introduction:  The purpose of this message is to initiate a
  discussion on methodologies for system development using a two tier
  process.  On one tier, the underlying reusable architectural
  frameworks  for families of application systems are defined and
  made available. Some examples of application families include data
  warehousing, Web-based systems, and application package integration.
  The second tier will be the implementation of specific applications
  on top of these reusable foundations. The  use of this type of split
  process is an increasing trend in industry (e.g. an SAP installation
  followed by application customization) and is implicit in a "Common
  Systems" approach. The key new step necessary to make this strategy
  generally successful is the creation of  tailored methods for
  developing applications on top of architectural frameworks.(e.g.
  SAP's Implementation Management Guide).

  Definitions: An architectural framework is a reusable foundation
  for a set of  related application systems. This foundation can
  include multiple levels of architectures (e.g. infrastructure,
  domain-specific), APIs, services, components, supported
  scenarios, standard data models, templates, implemented skeletons
  and customization methods.

  Basic Assumptions for Industrial System Development:

  * Individual application projects should not be developing
  underlying architectures and frameworks. The demanding
  schedules and budgets of most application projects are not
  adequate to support robust generic infrastructure development.
  Even if it were possible, the result would be islands of
  technology that would  create future maintenance problems.

  * It is therefore necessary to have a separate process for
  defining the reusable architectural-framework foundation.
  This process should extend beyond the selection of an abstract
  architecture. In particular, generic usage scenarios for the
  architecture should be included. Standard components, products,
  data models and templates can also be mandated. In some cases,
  a skeleton application framework could be part of the reusable
  foundation(e.g. Workflow templates or Enterprise Java APIs ).

  * Guidelines for selecting architectural frameworks should be
  provided to application development projects. In many cases,
  it will be necessary for projects to choose from a set of  standard
  alternative architectures and components. There should be well-
  defined criteria to help make this choice. One possible method is
  to compare the application's required scenarios with the generic
  scenarios supported by the architectural framework and
  components.

  * Tailored system development methods and techniques for
  creating applications on top of  the architectural frameworks
  are necessary. It should be possible to create focused
  methodologies for customization, extension and interfacing with
  frameworks for specific application development. There should
  also be well-defined interfaces and methods for plugging
  components into frameworks.  This approach should be very
  valuable to projects and will encourage the reuse of the
  architectural frameworks.  The cost and time for application
  system development will be greatly reduced as the framework
  and the associated  methodology gets more robust.

  * Processes for modifying and evolving architectural
  frameworks and associated applications will also be required
  for long range maintenance.  As technology and business
  requirements change, it will be necessary to have a strategy
  available for evolving the architectural frameworks and
  components. In particular, modifications should not adversely
  affect existing applications that use the frameworks. This goal
  should also be considered when creating the framework and
  tailored application development methodology  in order to
  prevent future problems.

  *  A  repository will be necessary for storing architectural
  models and components.  As the number of architectural
  models and components increases, the issues of configuration
  management and information retrieval will become very
  important. This will be especially critical as architectures and
  components evolve. Maintaining links between new application
  projects deliverables and existing architectural  framework
  elements could also be very valuable.