Characteristics of SaaS Applications

The evolution of Cloud Computing has paved way to enterprises look at subscribing for SaaS applications as against licensing an application for exclusive use. The primary benefit being the cost savings due to centralization. As more and more enterprises are looking for Cloud and SaaS model for its application needs, the product companies are exploring options to enhance their existing products so that they can be offered on SaaS model. It is important to understand the key characteristics of the SaaS applications before planning for the conversion.

While the application should be accessible over the web is an important characteristic, the following other characteristics are also important to look at:

1. Multi-tenancy

Typically all applications support multiple users. But a SaaS application should support multiple users of different organizations. Which means there should be a mechanism to identify and appropriately differentiate the users of a specific organization. That is the application should support multiple tenants. The tenants would also be interested to have their data be isolated and not to be mixed up with that of other tenants. At the least, the SaaS application should have the ability to uniquely identify each and every data record against a tenant.

2. Subscription and billing mechanism

Organizations are embracing SaaS applications on the premise that they will be paying far less based on one or more parameters, which measure the usage by the specific tenant. For instance, SaaS application may be priced based on number of users or based on subscription and use of specific modules / features. Some times, the pricing may be even complex, where it could be based on the transaction volume or a combination of one or more such measures. So, the application should be capable of tracking and logging such parameters and that the billing could be automated.

3. Scalability

A typical web application is hosted on a separate instance owned and exclusively used by a specific tenant. Whereas in case of SaaS application, the provider owns the hosted instance, which is used by all the tenants. Though the provider has the option to host a separate instance for each tenant, the economy of scale would at its best when a single instance is offered for multiple tenants. Depending on the application's features and the wide reach amongst the potential customers, the customer base could grow so fast and the application should be scalable both horizontally and vertically to support the unexpected growth in volume.


4. Manageability

The tenants should have the ability to manage their part of the application including managing the users, roles, permissions, etc. As the subscription base grows, it would be ideal to leave the application management to the tenants themselves. This requires the application to have necessary features / functions for use by the tenants.

5. Self service sign-up

While self service sign-up is not a key characteristic, it is a highly desirable to have this feature when the customer base is expected to grow too fast. Similarly, on boarding a customer may involve data migration from a different application used by the tenants before. The SaaS application should expose appropriate interfaces / APIs to facilitate the migration. It would also be a desirable to expose APIs to facilitate export / back up of data by tenants themselves.

6. Tenant specific customization

Typically, product companies undertake to customize an application to meet the specific needs of the customers by enhancing the application. But this would not work in case of SaaS application, as all the tenants would typically be using the same version of the application. That means, the application should be highly customizable, so that it satisfies the specific needs of all the tenants. In a large scale SaaS application this is achieved by providing the ability to extend the application by defining and deploying specific screens and scripts by the tenants themselves.

That is not all. There are other characteristics too and some of them could be key depending on the nature and demands of the industry and the providers. Please feel free to share your thoughts.

Here are some useful reference links that deal with the SaaS application challenges and characteristics.

• SaaS: an Enterprise perspective
• Challenges in converting existing web applications to a multi-tenant solution

Future of Personal Computer

With the evolution of smart phones and tablets, the survival of Personal Computer could be under threat. Let us examine, if there is a possible thing that PC alone can do.

Thick Client Applications: We have started seeing the increasing number of applications moving to the cloud and one just need a browser and may be an appropriate pug-in to run a cloud application. Even heavy weight applications like ERP suites and Business Intelligence Suites are now being offered over the cloud. In few years from now, I don't think there will be any compelling need to use a thick client application.

User Convenience:  Yes, a bigger monitor and a regular keyboard with a mouse will really be convenient to work on a PC. But do we need a PC just to have a bigger display and the key board? Not really, some of today's smart phones are dockable on to a device, which facilitates connecting to a bigger display and keyboard.

Higher Computing Power: When the applications are served out of Cloud, much of the processing happens elsewhere on some server(s) located over the cloud, and not much power is required on the client device. That is not the end, in few years from now, the smart phones / tablets will equally sport a high end processor with even multiple cores.

Extreme Gaming: Most of the popular games today are online games. Gamers also prefer online games which connects buddies from all over the globe to join and play together. More so, because the gaming service providers gain more in the form of Ad revenues in case of online games than Thick client games. Above all, there are special purpose gaming consoles in the market for extreme gaming.

Enterprise Computing: While it could be ideal to go with enterprise owned secured and locked down personal computers to access and process enterprise information, but that does not mean that they have to be PCs. Even now most enterprises are encouraging their employees to work from home on a Laptop, there by saving so much of energy costs at the physical location and at the same time commuting time for the employee. The evolving tablets could easily replace the Laptops.

Research firm Gartner slashed its growth forecast for the global PC market this year to 3.8 percent from 9.3 percent citing boom in media tablets.

You name one thing, we can think of how tomorrow's personal gadgets could address that. Would like to here from you on this trend.

Tap to Click feature of Touch pad on Laptops

Long time ago, when I was seriously preparing a process document on my Laptop and I kept typing in the text as it was flowing from my mind, not looking at the screen. When I looked up to see how it is coming up, surprised that the sentences were scrambled here and there. Then I started observing as to what is happening while typing in and found that the typing position suddenly changes to a an unexpected location, and your key strokes produce characters at an unwanted location! For a while I thought this could be a virus or malware problem or may be a problem with Microsoft Word.

But it did not took much time for me to figure out that this is the 'tap to click' feature of the touch pad. As you keep typing in, your thumb or such other finger taps on the touch pad surface and as a result, the typing position shifts to the position where the mouse cursor was at that time. From then on I have it included in my Laptop build document to have the tap feature disabled. May be this feature is useful for some, but for me it is a hindrance. Similar issues with the pointing stick, which is positioned amidst the keys and if you have it enabled, the chances of you taping on it is even more. Share your experiences with this feature.

Microsoft and Toyota partner on smart-grid tech | Microsoft - CNET News

Microsoft and Toyota partner on smart-grid tech | Microsoft - CNET News

Interesting to note that cars of next decade will be one's smart terminals and would allow the drivers and / or passengers to interface with various devices at home or office and transact. This means, travelling is not a waste of time, one can be at work while driving!

Even cars and the humans can be embedded with devices and technology that will authenticate the driver / passengers based on one or more of various personal traits, before allowing to drive the car. We have seen some such capabilities in science fiction movies, which can be a reality in the coming decades. The possibilities are endless!

High Performance Workforce

For a sustained success of an IT services organization, it is important to have a high performance workforce backing the leaders. A quick peek into various resources on what is high performance workforce, found that the following are the three fundamental building blocks to setup a High Performance Workforce:

1. Accountability for Right Results, which requires the employees to have the ability to focus on the right priorities and in turn achieve the right results at right time.

2. Earn Trust, which requires continuous mentoring and recognition of people whom the organization depend on, so that they feel valued, confident and ready to give their best.

3. Talent Development, a continuous skill assessment and development program, with which, the workforce is always on the edge of the needed skills and is ready to tap the opportunities that comes through its way.

High Volume Transaction Processing

Came across a presentation on payment processing by Voca at InfoQ. Just felt that the key design principles used by voca may be of interest to those generally deal with the problems of high volume transaction processing. These principles are:

1. Minimize movement of data: Movement of data across physical and logical layers could result in heavy network traffic and also necessitates a complex transaction and exception management over multiple layers. The idea is to whenever a set of transactions need to be processed for certain validation or transformation, do it within the database instead of moving such set of data to other layers and then bringing it back to the database.

2. Task parallelization: This an area which most of us might have not considered. Using the Work Manager / worker architectural pattern, the tasks can be executed by multiple nodes, which could be separate physical nodes with the ability to add more nodes when demanded.

3. Physically partition data: When the all in one database hits its scalability limits, the option is to partition the database. It would be ideal to envision the possible physical partitioning of the data and implement it right from the beginning.

4. Optimized reads and writes of volatile data: This is one principle, which most of us adhere to by having necessary indexes, managing the fetch sizes, etc.

5. Minimize contention: Contention is certainly an avoidable thing as this will cause the workers wait for release of the resources or data and directly impacting performance. One option is not to wait for the release of resources and instead, look for an alternate source of data / resources. Of course this will require a thought through design of multiple synchronized instances providing the data / resource.

6. Asynchronous decoupling: Usage of a middleware like message queue can certainly help in this area and there by improving the response for the consuming applications.

7. Keep Complex business logic outside database: Considering the limited scalability options of the database, it would be ideal to minimize the work load for the database by shifting it to other tiers where possible.

8. Caching frequently accessed data: There is no point in traversing through multiple physical and logical layers to fetch the same data multiple times. Caching such data in appropriate layers will certainly will leave the network and other resources for other useful tasks.

The referenced presentation is available on InfoQ website at http://www.infoq.com/presentations/qcon-voca-architecture-spring

Scalability

When we talk about the scalability for a web application, it is quite common for us to think of load balanced web farms. This obviously will require the application session state be managed using one of the OutProc options. Depending the utilization of the session state data and the implementation approach, the state server (be it state service or SQL server) may soon hit the scalability / performance limits and become a bottleneck.

This prompted me to think about possible scalability and availability solutions for the State Server. It is again possible to have a load balanced farm of servers to serve the session state requests. But, this requires the state information is replicated across all such servers, so that the information will always be available in across all the load balanced state servers. Obviously this is additional overhead. There are third party tools(like scalenet) to have the session and cache information replicated across multiple servers.

As I was looking for an alternative solution, just came across this Best Practices article on state management published by Microsoft. This article suggests a simple approach of session partitioning using the PartitionResolver Interface and determining the partitioned server using a key derived from the session id.

If any of you have implemented this or any other approach, do post it here.

Framework Vs Library

I was trying to understand the difference between Framework and a Library and came across an article by Martin Fowler on Inversion of Control. What I understand from that article is that the Inversion of Control is what makes a Framework different from a Library. I have in the past been involved in the development of reusable components, but wondered if they can be called as Frameworks, but the answer seem to be No, as in those cases, I have not inverted the control over to the Framework. So, those packages were just libraries and do not qualify to be called as Frameworks. What is the significant differentiator then? Based on my reading of various articles, I think the following are the key differentiators:

1. You call the a library method, whereas, a Framework calls your code.
2. A Library provides an API for your use, whereas a Framework provides an API to which your application should conform.
3. A Library is something contained within the application; i.e, if a library is not suitable, we can always substitute with a different library. But a Framework is a container for the application, having said that if the framework ends up not meeting the need, one need to throw away the entire application.

I also enjoyed reading the discussion on Why I hate Frameworks.

Good discussion on Enterprise Architect

Came across an interesting discussion on the role of Enterprise Architect in the Linkedin.com groups. and my take on this is as below:

Though EA is all about engineering the enterprise, which is primarily the business side of the architecture, it emerged and evolved with IT in the last decade or may be since little earlier than that. The EA role is like a swiss army knife, to craft the enterprise IT needs including infrastructure, hardware and software.

In the Software Development perspective, it will be Solution Architect or Technical Architect and the parameters will vary by project. Solution Architect's role is confined within the project's / product's constraints and SA is expected to determine the most appropriate technical solution for the given business problem / requirement confined within the customer's enterprise IT infrastructure / needs.

This will require the Architect to have high degree of understanding of the business domain of the enterprise and in addition should be highly knowledgeable in diversified Technologies, so as to choose the best solution. The SA / EA should also be a continuous learner and shall keep abreast of the technology happenings and keep an eye on the future. This will also require the Architect to be good enough in adopting the technology to suit the business needs.

Update - July 27, 2012:
This blog post has been created couple of years ago. I recently happened to participate in the Enteprise & IT Architecture Global excellence Awards 2012 and was amazed with the participation from various industries and from all over the world. The list of participants are listed in their website and the winners would also be published there soon. It was interesting to note that government and public sector organizations also are practicing EA within their organization and are reaping the benefits.

While that is showing a positive trend, there are still many enterprises who are finding it difficult to leverage the EA to their strategic business advantage. Nick Malik in his recent blog post titled as Will Enterprise Architecture Ever “Cross the Chasm?” expresses the same view,

"Unfortunately, while EA has been successful in some target markets in the Early Majority (like Telecom and Federal), the lack of consistency in the approach, terminology, and even value proposition of EA across industries poses an obstacle for increasing EA adoption. In other words, the success of EA in one or two areas is failing to help EA gain a foothold among other industries. Could it be because they don’t use the same words to describe success?"

He continues to summarize that the EA profession is plagued by the following three problems:

1. Enterprise Architecture is poorly defined by a wide array of discordant opinions, overlapping and industry-specific frameworks.
2. Enterprise Architecture is hobbled by an inability to build momentum among Early Majority companies on the adoption curve.
3. Enterprise Architecture has responded by focusing on the wrong set of problems: describing short-term-quick-win initiatives using methods and tools designed to produce long-term value.