Image courtesy of timetrax23

Reuse in the Enterprise

Wheelsmiths United

You need to build some functionality for your website. Your team has identified that the solution can be generalized and reused by many other websites across the organization. Let's skip the reinventing the wheel discussion. The decisions were made and things are moving forward. It's going to be built so it's only a matter of how successfully the idea is implemented and maintained. Let's look at a few options based on familiar models that can help form a plan for success.

Use before reuse

So your website needs analytics. Unfortunately you work in a high security industry so Google Analytics is out. There is also no money in the budget for the expensive third party COTS (commercial off the shelf) options on the market. Some of the analytics are incredibly tied to how your business works but there are aspects that can be generalized. Being a good programmer you identify the redundancies and want to build the general solution so others can benefit from your work. If we are going to re-invent the wheel let's only re-invent it once right?

Before we get too far down the path to building the "perfect solution" let's step back and remember one thing - right now we don't fully know what we need. We haven't built and launched this functionality so we are missing all sorts of valuable info. The allure of generalizing it now is difficult to ignore but let's do it anyway.

Instead of extracting this functionality from our website let's keep it local. This will let us iterate faster and keep our dependencies down. Having fewer dependencies means we can be less responsible when it comes to interface changes and we can follow new design directions as the concepts evolve. At this point your discipline and your ability to think globally and act locally is important. It is all too easy to hack something in that will work in your specific context instead of thinking about how to modularize or componentize the design. Clean interfaces and cohesive APIs can help to build the general solution in the middle of your specific context.

This is great for the first few releases as you work through issues that only use in production can bring. Now that you have shown the concepts work, validated your assumptions, and are happy with the results let's look at some options for reuse so others can benefit.

Reuse Option 1 - SAAS Model

The first model that may come to mind is the software as a service model (SAAS). This model provides a clear boundary between the provider and consumer systems. It also looks familiar to the team as they probably already integrate with third-party solutions so they are capable of integrating this first-party-twice-removed solution.

To make this succeed you need to think about having:

a team and team lead with time and money allocated to drive future development so everyone's needs are met without sacrificing the overall framework.
the ability to get feedback and integrate it into the framework.
the ability to encapsulate the implementation to improve adaptability and secure the ability to change in the future.
a clear versioning strategy so you can evolve the framework without worrying about backward compatibility.

Some common issues you can run into with this model:

you now have another product needing funds, resources, and time. without business support from the top you will struggle to get features added reliably.
a new product that only serves internal teams is an expensive product. if it is not core to how the business operates it is always seen as a lower priority.
it's easy to fail if there is no defined boundary. developers coming and going to the SAAS team can leave the code in shambles as they patch on new features without long term vision.

Reuse Option 2 - Self Hosted Model

This model is a more traditional software release model and works great with opensource projects. You can still have a team of core contributers who are responsible for the development of the framework but the production system support is distributed across all the teams that use it. This allows teams to experiment in their own projects without impacting all users of the framework which creates less fear of risk and failure. This can lead to big leaps as the framework evolves due to increased confidence in each team using it since the risk of failure is small and the reward is great.

To make this succeed you need to think about having:

strong teams that learn opensource practices for forking/contributing.
good communication to keep the vision of the framework strong while adding new features.
good documentation and a simple deployment model to let teams start their own instances with little ramp up time.

Some common issues you can run into with this model:

the cost and training as each team has to support their own version of the framework. this reduces some of the economies of scale that we get in the SAAS model.
without a strong core team of contributors the code can quickly devolve due to the tragedy of the commons.

Reuse Option 3 - Hybrid Model

This is really just running the SAAS model and the Self Hosted model as the same time. You have a core team building the "product" version that is hosted and supported. Then you have a method of distribution that let's other teams spin up their own version like the Self Hosted model. This offers the best of both solutions if you have the cash and a strong team to support it.

Comparison

	SAAS Model	Self Hosted Model	Hybrid Model
Resources, cost, and management	centralized	distributed	centralized or distributed
Business culture	traditional hierarchical and command and control	distributed self-managed teams	advanced self-managed teams
Types of solutions	takes you down the path of building frameworks and systems	lends itself more to libraries and components	the SAAS influence pushes it more towards frameworks and systems

Pros and Cons

	Pros	Cons
SAAS	The clear boundary between provider and consumer helps to build out the API for everyone as feature requests need to be exposed publicly. Economies of scale makes supporting and deploying simpler.	Can be seen as "us versus them" approach. Time lag between requesting a feature and it's implementation by framework team can cause schedule pressure. Framework team can lose sight of day to day usage if they are dedicated to framework and are not dogfooding.
Self Hosted	There are more opportunities to tightly couple the feature providing simpler and tighter integration	Without a hard boundary between your application and the framework you can get into trouble being tightly dependent on the framework. Any modifications that your team makes may not make it back upstream to the main product if there is a time crunch. This can lead to one-off framework versions and all the increased support costs that entails. Without a hard boundary between your application and the framework you run the risk of your application logic becoming part of the framework.
Hybrid	Provides the most options depending on the team's needs and skill level.	Most complex model. It can be difficult to get one model or the other right so it's an order of magnitude harder to get both right.

Which Is The Best?

At the end of the day any one of them are a good choice in the right context. It's important to be aware of the environment and supporting ecosystem in place when picking one option over the other. Oddly enough they all share some of the same flaws in that poor leadership can be their downfall.

Either way good luck and remember not to generalize too early. An amazingly built wheel still fails if your business needed skis!