Ralph Johnson's Comments on Architectural Frameworks Posting

Lines proceeded by ">" are from the original posting. 

>  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).

I don't know if that is THE key step.  One prior step is figuring
out the architectural framework.  This is not easy.  Once you have
one, you build applications with it and figure out the methods for
developing applications on it.  In my opinion, each architecture is
likely to have its own method.  Before we can make a science of
these architectures, we have to study of bunch of them.

>  * 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 ).

Yes, it is necessary.  The process for defining a reusable
architecture is different from that for defining a single application.
A key part is that it results from the defining a set of applications.
So, first you develop a bunch of applications, then you are able to
make an architecture that makes it a lot easier to create new
applications.

>  * 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.

Sure, but this doesn't say much.  First you have to have a set of
frameworks to choose from.  Each of them has to be described.  You
have to able to understand it well enough that you can tell what
generic scenarios it supports.  In fact, most of the time you are
lucky if there is ONE to choose from.  I wish that our problem
were having to figure out which one to use.

>  * 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.

Yes, I've seen it.  "Tailored" is an understatement.  Each
framework has its own method.  While there are generic things
you can say about these methods, the most interesting things
are domain specific.

>  * 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.

This has been one of the goals of my work on refactoring.
How do you change the application when a framework evolves?

>  *  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.

Yes, you need version control on your metadata.
-Ralph