Tennis Balls and Architecture???

What is a tennis ball’s major component?

… Air

If you cut a tennis ball in half the entire core is air.

What does this have to do with a Technology Solution Architecture?

Lets take a look at how the construction of a tennis ball can help us solve a problem in business.

The Tennis Ball Architecture Model

It is expensive to build a Business Solution from scratch.

A “Home Grown” solution may sound good as it gives full control of the feature set to the Company but the reality is:

… The Decision to Create a Custom Solution

…… Is Probably Reinventing the Wheel

The Tennis Ball Model creates a structure that allows
a Company to gain benefits of “Off the Shelf”
products without the constraints of their concept
of your Company’s Business Requirements

It is possible to build a customized business solution that provides the Feature Set that your Customer’s require while leveraging the power of Third Party Products.

The design is based on a Tennis Ball:

1. A Tennis Ball is all Air in its Core

2. There is an Inner Ring that Holds the Tennis Ball’s Skin

3. The Tennis Ball’s Surface is the Skin

The Enterprise Services Bus (ESB)

The Tennis Ball model is a variation of the Enterprise Service Bus architecture.

It is a simple way of explaining the somewhat complication ESB concept.

The major difference in this model is that the requirements that a company has for the complete feature set is created and deployed as a 3rd party application.

The In-House Developed Feature Sets

… Are Treated Like as a 3rd Party Application API

This model allows the company to create an abstraction for the remaining features not available in current Technology offerings.

When a new 3rd party application API become available it can be added to the Application collections and replace the in-house  “Home Grown Feature Providers“.

The Tennis Ball ESB

The “Core” holds the Third Party Applications that offers robust Application Program Interfaces (API) that are the engines that drive the Customer Features.

The “Inner Ring” holds the Application Feature Interface Layer that acts as “Adapter Design Patterns” which creates an “Anti-corruption Abstraction Layer” between the Application’s APIs and the solution’s Client-facing Feature Set.

This creates a loosely coupled relationship between the current Application API solution and the Business Solution’s delivered feature set.

The “Surface Skin” maps the Application Feature API Interfaces to the Customer Feature Layer. This layer defines the functionality offerings for the Client-facing Application.

Here are the benefits of this architecture

1. Feature Set functionality is developed and maintained by Alliance Partners: The API Providers are responsible for bug fixes, updates and feature enhancements to meet market requirements

2. The Feature Set is Scalable and Extensible: The API is loosely coupled to the Solution and can be swapped out with a minimum of refactoring

3. The Feature Set is Atemporal: The loosely coupled architecture allows for complete swap out of an Application API with changes encapsulated within the Interface abstraction. As better solutions appear on the market to solve new problems an Application can be augmented  or replaced at a lower cost

4. Feature Set Can be Enhanced: New features can be added by simply adding a new API Application and create the Anti-corruption Abstraction Layer

The features that are required to complete the super set of functionality, developed by the in-house development team, creates an API set that interfaces with the Application feature set.

This is implemented in the same fashion as any 3rd party application’s API.

This allows for replacement of the features when they can be leveraged by a new Application solution’s APT set with a minimum touch to the code base and a reduction in regressive testing requirements.

This Model offers the Best of Both Worlds:
Leveraged Applications and Customization
control over your Business Solution

In Conclusion

When a Business Vertical has a robust offering of “Off the Shelf” products but none of them are really a good fit this architectural model may be the right choice.

The Tennis Ball Model offers a scalable, extensible and flexible model over time that can adapt to a changing business climate with the lowest Cost of Ownership compared to a “Home Grown” solution.

Be Open to Thinking Outside the Box
A New Paradigm of Thought
Could Leap Frog Your Market Share

Wisdom Pearl # 137 – The Primary Technical Imperative

The Primary Technical Imperative in Software Development

… Is to Manage Software Complexity

…… Always be able to Justify Your Designs Complexity