My feedback after reading Ralph's response:

I work for a very large software project mostly developed in Smalltalk.
We have over 5000 classes, with 12.6% of the system code purely
architectural-framework based (as opposed to application-framework
based).  Now this statistic may not seem out of the order, until you dig
in and see what is happening with the code base.  A good portion of the
architectural framework is unused.  A good portion of what should be an
architectural framework is reimplemented time and time again in the
applications, as the core framework does not provide the right set of
services.

I agree with Ralph's comments, particularly the notion that we can't
just go out and create architectural frameworks from scratch.  That is
what my project attempted to do.  Our architectural framework is huge,
slow, complex, difficult to understand, largely undocumented, and
practically impossible to evolve.  You simply don't know what to build
until you have some applications to tell you what to build.  You also
don't know how to build it until you try and iterate on it a few times.

I have seen this pattern two places now, and it goes like this:

The people designing the framework thought they could create the
framework first, then engineer the application on top of it (you know,
sell that reuse thing to management).  They were dead wrong.  The
framework was orginally planned to cost $10 million.  They spent that,
then tried to build applications on top of it.  Next, they found that
the framework did not provide the right set of services.  They were out
of money for framework so they made the applications build architectural
framework-type services that were not reusable across the various
application areas.  Next, they found that each application area built
different services which did not work the same across applications, so
they had to go beg for more money to redesign the framework and add
those services.  They, of course, could not spend the time to remove the
services that were not used, so those stayed.  And, the applications
that built their proprietary frameworks could not spend the time to use
the new standard system framework services, so those stayed as well.
The framework cost over $25 million and is still a huge source of
maintenance today.

When frameworks are concerned, I think we have three key interrelated
concepts to develop in a parallel, prototypical, iterative, and
incremental fashion.  They are:
     Architectural Frameworks
     Application Frameworks
     Applications

Yes, this approach is going to require refactoring all over the place.
It is going to be difficult and frustrating.  But the code quality is
going to be unparalleled in the industry.

To develop large-scale object software any other way extremely costly
and egotistical.

One developer's opinion who is very interested in your work!
     Todd (Todd_Lauinger@bigfoot.com)