Customization in Saas using Plug and Play Architecture

There exists a lot of design patterns, architectures and design concepts that can be applied to technical aspects of implementing a product. For eg., we have MVC architecture that isolates the view, controller and model of the application. We have a factory pattern that defines how to create objects and so on. Yet, these all limit themselves to the technical aspects of the product, while there exists no definite pre-defined architecture or patterns to design and build “business functions”. The Plug and Play architecture I want to describe in this article is a “Functional architecture”, that defines a pattern to design the business functionality to get the most out of it.

Modular architecture is a design technique where functionality of a program is separated into independent, interchangeable modules, such that each module contains everything necessary to execute one aspect of the desired functionality. Typically, in modular architecture, separation is done based on technical aspects. For eg., a module is created for database interaction, another is created for logging and so on. The advantage of a modular architecture is that you can easily replace or add components without affecting the rest of the application. The modules clearly define the interfaces that are used to interact with the module and these are tied at compile time to other modules.

What if we could extend this architecture to “business functionality” rather than just limiting it to technical aspects of a product. We already design “Business functionality” in a modular manner. But, we do not consciously look at it as modules with clear-cut interfaces for inputs and outputs.

Defining the Plug and Play architecture

The Plug and Play architecture extends the techniques of modular architecture to business functions. For eg., a module can be created to encompass all functions related to Order, while another can be created to encompass all functions related to Quote. I will call these independent modules implementing business functions as Flows.

An application, in this architecture, is a “collection of flows working together”. The same advantage of modular architecture applies here, i.e., you can replace, add or remove flows without affecting the rest of the application. An added advantage to extending modules to business functions, is that the flows can be combined in different paths to get different business functionality.

Further, extending this definition to be able to add, remove or replace modules at “runtime” rather than tying them together at compile time gives us the flexibility to customize the application at runtime without “in-built flags and if clauses”. The beauty of this extension of the architecture is that “it gives us the flexibility to create a set of loosely coupled flows that can be bound together at runtime as opposed to coding one tightly integrated application that is rigid and not malleable”.

To further see how this architecture works, let us consider a set of loosely coupled flows coded as per the diagram:

pnp-architecture

There are 5 flows coded and deployed. Each flow exposes an output and accepts a set of inputs.

For eg., the “Product Listing” flow encapsulates the following business functions

  • Create products manually by admin
  • Import products by admin
  • Provide services to view, search and list products
  • Expose an output, “Product” data that can be linked to other flows

Another eg., is the Cart Flow. This encapsulates the following business functions

  • Create a new cart
  • Add Items to the cart
  • Check out the cart
  • Expose an output, “Cart” data that can be linked to other flows
  • Accept an input, “Cart Item” that can be linked to the output from other flows

We can connect the output “Product” data from “Product Listing” flow to the “Cart Item” input of the cart flow. This is not tightly coupled at compile time and is left as an open gate or an input for the cart flow. At runtime the gate is closed or left open as required by the customer.

From the diagram we see that we have 5 gates that can be closed. Leading us to create different applications at runtime by closing the correct gates. For eg., we can just enable “Product Listing” for a customer which provides just the basic features of product listing. Gates 4 and 6 can be closed to create an application with the features

  • Create, list products
  • Add products to a cart
  • Send an enquiry for the products added to the cart

In another variation instead of gates 4 and 6, gate 7 can be closed. The application now has the features

  • Create, list products
  • Send an enquiry for single products

By plugging the “inputs” of flows with different “outputs” from other flows, varied applications can be created. This is called a plug and play architecture. SMART is implemented in this architecture to give a highly flexible container to build Saas products.

Need for plug and play architecture

When a product is exposed as a multi-tenanted Saas product, it cannot be created with “One size fits all” tenet. To break this tenet we need a flexible, customizable runtime environment where features can be varied based on a customer need without affecting other customers serviced by the same application. The plug and play architecture provides this flexibility to the Saas.
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


4 − = three



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close