In continuation to my earlier blog on benchmarking the maturity of a SaaS solution where I talked about 4 segments through which one can find the maturity of a SaaS solution. In this blog I am going to talk about assessing the architecture segment.

Design

Is your application well layered?

Incorrect layering is a common problem for legacy systems. To avoid major rework some people tend to continue with the existing architecture, which might not be layered properly. This could become a major show stopper when the SaaS application starts experiencing performance issues.

Do you have service oriented architecture between the layers?

Integration is the top concern next to Security when it comes to adoption of SaaS applications. Service Oriented SaaS Architecture enables your SaaS application to integrate with a diversified set of external applications thereby significantly reducing the integration effort. If your team is spending more time on integration then this is the area to watch out.

Do you have a loosely coupled architecture between the modules?

Again this is one of the basic design principles for building applications. A loosely coupled architecture helps you minimize the impact created to other modules when you modify a given module. Given the amount of requests you may get in a SaaS model it’s very likely that you will be touching one module or the other, and when you do that you better be sure the rest of the system is not impacted.

Do you have a mechanism in your framework to ensure your developers follow the architecture norms?

Design and Development are 2 different things for a reason. I have seen many cases where the architect would have sweated out to put together a great framework that can make the developers life easy. But then the developers would have simply ignored it and written the code exactly in the way it’s not supposed to the written. Training and monitoring are the only way to address this situation.

Can your solution be deployed in any cloud (public, private, on-premise)?

Cloud has been more of an English Weather so far – it’s been changing pretty rapid every minute. While cloud vendors provide a whole lot of services to make their infrastructure services more attractive, it is only wise to use them after careful consideration of your business priorities. For ex: Hybrid support is a common strategy that ISVs take to handle both SaaS model business as well as On-premise business (for large customers). In this case if are dependencies with the hosting provider then it becomes difficult for on-premise installations, so you may end up with more than one version of your application.

Maintainability

Do you have a good instrumentation mechanism?

Maintainability is something that is most often overlooked during the development stage. As everyone is under pressure to hit the dates and take the product live, sometimes maintainability takes a back seat. A good instrumentation can help you save significant amount of effort and money. Why don’t you check out if your SaaS product has the following – Security Audit, Event Audit, Notification Audit, Workflow Audit, Data Change Audit…

Do you capture SaaS Product Analytics information?

Just like instrumentation product analytics is another overlooked area. As a SaaS provider it’s extremely critical to know the real-time health of the product. By integrating product analytics you will be able to find every single information about the usage of your product at finger tips. For example: if a customer calls and complains about the system being slow, then you should be able to first figure out the overall performance of your SaaS application, and then filter it by the customer experiencing the slowness. This will give insights if this something all customers are going through on just that customer who has reported. Next you should be able to look at all the hits that were processed for this customer. Hits should give you details around the page size, response size any potential errors that happened. This way in few seconds you will be able to find out the root cause of the problem, which in some cases might just be a internet slow down at the customer end J – but the key is you were able to address this issue in seconds and not hours of diagnosis.

Scalability

Can you scale your web and application layer (without engineering efforts) to handle increasing loads?

SaaS is a volume game. The more customers you have the more profitable you can be. Therefore, it’s mandatory to think through the load that is expected to come to your system in the next few years. The greatest thing about cloud is the flexibility it offers to ramp up and down the hardware resources as per the need, but for that the SaaS application should have been designed for scalability in the first place.

Is your database layer scalable to handle data growth?

Scaling at the web and application layer is much easier compared to database layer. In case of web and application layer a simple load balancing will solve the problem, but you cannot do the same at the database layer. There are specific concepts like data sharding available today to help you out scale at database layers.

You can also read through this interesting blog that talks about SaaS Architecture past and present. In my next blog we will look at assessing the Security segment of a SaaS Application.

In the meantime, if you are interested to know more details about the benchmarking exercise you can download the following free tool offered by TechCello.

SMART Calculator – SaaS Maturity Assessment and Reporting Tool (SMART) helps you identify the maturity of your SaaS solution that you already have or plan to build. There are several ways to deliver a product in SaaS model, but how stable and sustainable is your solution? Given the very fact that SaaS is a volume game, scalability is the key for a successful SaaS business. SMART will help you find how scalable and matured is your product.

Click here to download the SMART calculator.

In case of any queries please feel free to contact me at [email protected]