Tennis Balls and Architecture???
What is a tennis ball’s major component?
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:
A Tennis Ball is all Air in its Core
There is an Inner Ring that Holds the Tennis Ball’s Skin
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
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
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
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
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
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
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services