Building Frameworks For Internal Use

Suppose you have a number of products, or a number of applications, that share some common functional needs. It seems obviously reasonable to create a separate team to build those functions in common. Often these grow to become known as a framework, and the product or application teams are expected to use it.

It’s a seductive concept, but don’t do it. Why not? I can think of several reasons.

The first is that good frameworks aren’t built before being used. Instead, they’re extracted from successful products or applications. For anything of size, there are bound to be subtleties that you won’t get right until you try it for real. If you’re building a framework first, you’re delaying that first real trial. If the team using the framework is different from the one building it (as things are usually arranged) there’s significant delay for improvements needed by actual use. And that assumes the application team knows that the framework could and would be modified to accommodate them. Most often, they’ll just live with the problems.

Another reason is that your framework will never justify its cost as an internal product. When frameworks are built for sale, they have a large customer base depending on them, or they go off the market. Internal frameworks do not have that large customer base, and can never pay back enough to cover the inefficiencies of working that way. Instead, you’ll have taken the best and brightest of your developers for a framework that can’t turn a profit, starving your actual product of talent.

If you want to build an internal framework, build it from actual use. Put those best and brightest developers on the front lines of customer need, where they can do the most good. Distribute them among your application teams. Have them talk with each other, determining the common needs, and extract the framework as they go. They can act as Component Stewards, guiding the framework development and also guiding the use of it. They can then be in a position to know when the application should adjust to the framework, or the framework should accommodate the application.

One Reply to “Building Frameworks For Internal Use”

  1. Good article. Moreover, in the majority of cases an extracted framework should be immediately open sourced and disconnected from the commercial entity from which it came to give it the best possible chance to evolve, which is as an independent project drawing on the talents of the entire community. This is one aspect which most companies fail to realise.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.