Modeling Business Transactions – 1 (For SaaS Pricing)

Raji SankarJanuary 21st, 2014Last Updated: January 20th, 2014

3 77 4 minutes read

In the blog “Transforming a server application to cloud application“, I have talked about the changes required in business functions to transform an application to a cloud application. In this series I want to bring out the changes required in architecture to implement these use cases.

Need for Re-architecting for pricing

Starting with the pricing use cases, pricing can be done in a number of ways. Some samples are:

per business transaction
based on the end states of the different business transactions
by usage pattern (number of active users using specific the business transaction)
blocks of users, blocks of business transactions and so on.

For eg., in the petstore blueprint, “Buy Pets” can be considered as a business transaction that involves the following steps:

Search and add pets to a shopping cart
Check out the shopping cart
register and login into the system
Create an order
Pay for the order

In the SaaS model, this business transaction can be priced in different ways. For eg., a lower price can be offered for “carts created but not paid for”, while “carts that result in payment” can be priced higher. This allows the SaaS customer (i.e., a petstore owner) to easily track their ROI. It also allows pricing based on complexity of business transaction backed by business reasons for higher or lower pricing. For eg., the business transaction that involves “payment for an order” costs more due to integration into a payment gateway.

To be able to price in this way, the system should recognize business transactions, states of the business transactions, users using the business transactions and so on. Moreover, it should also be recognized that SaaS pricing is untested, with no data available on how or what is the best pricing model. Pricing has to be experimental and product should be architected to easily collect data to help analyse the margins.

Standard architectures such as MVC, are oriented towards technical implementation and modularity of code. Business transaction exists as just an abstract notion that is distributed across the code. For eg., in the petstore application, the “Buy Pets” business transaction is modeled as components “Shopping Cart”, “Customer”, “Inventory” and these are tied together using controllers as shown below:

Here, the business transaction can only be understood by tracking the code in the controllers, events, EJBs and other code. In this implementation all the elements of the business transaction are present, but they are hidden under the obfuscation of code and cannot be used to easily enable business transaction pricing. Custom reports has to be generated based on the understanding of the code. But these reports do not bring out the complexity involved in executing the business transaction, for eg., knowing how many requests were made before an order was paid for.

An independent slap on module cannot be implemented alongside existing systems that can adapt and generalize pricing modules. The pricing module implementation has to be coded into the system specific to different business transactions. This makes it cumbersome, to experiment with pricing model to decide an optimal pricing. What is required is an architecture where any business transaction can be modeled in a generic way. This model needs to have necessary elements to be able to provide the SaaS use cases for standard requirements.

Defining a business transaction and re-architecting

We can define a business transaction as a set of business events occurring on one or more business data that transitions the state of the current or related business data. The state of business data is a set of attributes associated with the business data.

For eg., in the “Buy Pets” business transaction, we can identify 4 major business data involved (Pet or product, Shopping cart, Order and Payment). All functionality can be organized as business events that occur on this set of business data. For eg., Search Pets, Create Cart, Add or remove pets from cart, checkout cart, pay for order are business events that occur on product, shopping cart and order objects. These objects already exist in any MVC architecture implementation but just not organized this way. Hence, we should be able to reorganize the code of the petstore implementation as below with a few additions i.e., storing the events also into the database:

Advantages of defining business transaction

Once we have redefined our architecture in this way we find a number of advantages to it. The primary advantage is that we have forced business transactions to be modeled with certain recognizable objects in the system i,e., business events, business data and states of business data.

Tracing the events in a chronological order starting from a start state business data (here shopping cart) to an end state of a business data (here payment) gives us a recognizable generic business transaction represented in the system and the database.

This allows us to implement generic modules against business transactions required for SaaS use cases. For eg., we can count the number of events that occurred, number of business data that did not complete, number of business data that completed that whole transaction, the time taken for a business transaction to complete and so on. This information collected helps us provide slap on modules for pricing, invoicing, billing etc that can be changed globally without affecting single transactions.

SMART builds on this concept of business transaction definition to provide a container that provides generic modules for pricing, billing and invoicing out of the box.

Reference: Modeling Business Transactions – 1 (For SaaS Pricing) from our JCG partner Raji Sankar at the Reflections blog.