Benefits and Drawbacks of SaaS

Benefits

For the Consumer	For the Provider:
No client/server software installation or maintenance - that's right, no more 800-page planning and implementation guides.	Aggregate operating environment - as a provider, you own your domain.  No longer are you sending technicians to fix or customize your software because it doesn't fit into a customer's highly-specialized (or horribly outdated) infrastructure.  You have complete control to optimize an infrastructure to your SaaS application's specific requirements.  This is synergy at its best, and leads to financial savings as well as less headaches.
Shorter deployment time - potentially minutes as opposed to a phased implementation that could take months.	Predictable Revenue Stream - the subscription model associated with SaaS means that your customers will pay you on a recurring schedule.  If you make this cycle flexible enough, you can get a real handle on forecasting revenues.  The payment may be tied to your product (think cell phone plans) where everybody pays according to the same term, or tied to your individual subscribers where some may pay monthly, some yearly, and some quarterly.
Global availability - sure the technology exists to make on-premise software available outside of the premises, but we're talking about functionality that is available from anywhere on the internet natively	Predictable Growth - Same as above, but here we're talking about sheer volume of subscribership.  The fact that users hit your site to access the application means that with the right tools you can monitor their usage pretty closely - something that's not so easy with all your customers running the application on premise.
Service Level Agreement (SLA) adherence - reported bugs can be fixed minus any rollout overhead.  Sure the provider actually has to fix the issue, but assuming they've deployed a moderately efficient SaaS application the rollout of a patch or fix should happen in the blink of an eye.	Focus On Smaller Upgrades Instead of Monster Patch Rollouts - and while you're at it, don't worry about rollout logistics across all of your customer sites either.  Your development teams can focus on fixing core application functionality, tackling bugs and enhancing features in smaller incremental rollouts because it's just easier to do so.
Constant, Smaller, Upgrades - when you use a SaaS application, it is in the best interest of the provider to keep you happy and they can do so by constantly improving the application experience.  With SaaS this can come in the form of consistent miniscule changes that add up over time instead of monster patch and upgrades that cost you time and money to implement.	Sales Becomes Customer Relationship Management - When you are selling a subscribable service, the game of gaining subscribership becomes one of balancing user retention vs. attrition more than a game of landing the 'big deals'.  Sure, it's important to have a team out there pounding the pavement to sell your application - i.e. getting subscribers in the door - but the real thrust of the new sales and marketing in SaaS is customer relationship management.  The equation becomes quite simple - keep retention rates higher than attrition rates and focus on bringing in new customers.
Ease Your Internal IT Pains - This is a big one. Most of the last several points here highlight that SaaS offloads a great deal of IT pains incurred by software consumers in the traditional client/server model.  This leaves IT personnel to focus on improving the day-to-day technical operations of your company instead of being called upon to troubleshoot 3rd party software or maintain aging infrastructure.
Redistribute IT Budget - by outsourcing software functionality to a provider, the enterprise realizes a cost savings in infrastructure requirements and IT personnel knowledge requirements.  This allows the enterprise to focus on core competencies.  It also means that the cost savings from using SaaS applications can be flat out saved, or reallocated to boost productivity through other services

 

Drawbacks

For the Consumer:	For the Provider:
No direct control of the data - One of the biggest hurdles to get over is the control of the data. Specifically, what happens when things go wrong? I'm sure every company trying to sell you a product will tell you that things can't go wrong and that they will be there to support you for years to come. It is important that you ask the difficult questions: How safe is my data? Will I be able to download it? Will it be disposed of properly and safely? Can it be sold? Can anyone else host the application and my data? Will the application source be opened so that hosting can happen in house or by another provider? Stories of companies going belly up are not uncommon, and not only for SaaS companies but for traditional software companies as well.	Focus on customer satisfaction - This is one of those bad things that it's good to have and makes great companies but we have to mention it anyways. SaaS providers need to focus on customer satisfaction month in and month out or they will lose their customers. They need to earn their customer's business every month or they can simply leave. Contrary to on-premise deployments which are very costly and time consuming, if your customer is unhappy with the service he can up and leave at any time with very minimal cost. Some might argue that you can negotiate longer term contracts, make it hard to take their data and all other kind of shenanigans but if you ask me, it is bad practice and if you are not the best, then you better have one damn good reason why they should stick with you other than a binding contract.
Internet connection required - I don't know of many businesses that run without an internet connection these days. Nonetheless, it could affect your operations if you need to access an application and the internet connection is down.  A good set of companies are trying to solve this problem by allowing their applications to continue to work in a disconnected fashion for a period of time but at some point you will need to sync back up to the server. If this is a big concern for you make sure that your provider can address this need.	Harder development process - There are many different approaches to writing SaaS applications and they are outside the scope of this article but the bottom line is that there is a whole new set of things that you need to worry about when writing a SaaS application that you otherwise wouldn't need if it were a traditional on-premise deployment. Things like tenant isolation, provisioning and scalability to mention a few could be a hard thing to tackle where you wouldn't even have to think about if you were writing an on-premise application.
Dependence on an outsider to run your business - In a big way, you are trusting an outsider to help you run your business, and if they are not keeping their end of the bargain it can really affect you. To keep it in perspective, these people are out there to stay in business and they do this for a living so arguably 95 out of 100 times they can do it a lot better than you could in house. This does not mean that you shouldn't be aware of the implications so make sure you ask the tough questions.	Compensation issues - One of the early problems for SaaS providers is how to maintain operations when there is only very little money coming in. Unlike traditional on-premise deployments where one deal could bring you $60,000 upfront and carry you for a couple of months while you close more deals, SaaS deals are MUCH smaller so initially it will be a lot harder to maintain operations unless you are properly funded so you can survive until enough money is coming in .
Security awareness - Another big hurdle is security. This concern is the umbrella that is home to the concerns above, as the common thread among them all is that they make you consider how "secure" you feel with SaaS. You are trusting your really valuable data to someone else. This can be a painful reality to accept but most security breaches occur because of disgruntled internal employees that end up selling or releasing the data when they are fired or when they quit, having your data managed and stored by an expert of the application is not a bad idea as long as they take it as seriously as you would.	Success can be a problem - You've heard many times that being too successful is a great problem to have but in the case of SaaS it can literally bring you to your knees if you are not prepared. This goes back to my second point of SaaS being harder to develop. Things can grow out of control if the application is not architected properly and addresses scalability issues and your service can become unusable over time if it does not scale properly with the addition of new tenants. Make sure you don't leave the hard decisions for later because you will run into a wall down the road.

This blog entry is a tabulated version of SaaS' Benefits and Drawbacks

VS 2008 (Orcas) Project creation failure....

Visual Studio 2008 (ORCAS) "Project Creation Failed"

This is due to some assembly redirects that are added to the devenv.exe.config file by installing the GAX (Guidance Automation Extensions).

Here is the fix, and it's an easy one:

1) Navigate to: C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE in Windows Explorer

2) Load devenv.exe.config in your favorite text editor.

3) Find this string: "Microsoft.VisualStudio.TemplateWizardInterface"

4) Comment out the element so it looks like this:

<dependentAssembly>
<!--assemblyIdentity name="Microsoft.VisualStudio.TemplateWizardInterface" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /-->
<bindingRedirect oldVersion="0.0.0.0-8.9.9.9" newVersion="9.0.0.0" />
</dependentAssembly>

5) Restart Visual Studio 2008. All fixed!

Thanks Pete

Smart Clients.

What are smart clients?
Smart clients are the applications provide the benefits of a rich client model with thin client manageability, they also provide much more flexibility than the traditional rich client applications.

Smart clients are those that :-
1. Utilizes Local Resources
A smart client application always has code artifacts on the client that enable local resources to be utilized. What do we mean by local resources? We mean everything from hardware to software resources. A smart client may take advantage of the local CPU or GPU, local memory or disk, or any local devices connected to the client, such as a telephone, bar-code/RFID reader, and so on. But it may also take advantage of local software, such as Microsoft Office applications, or any installed line-of-business (LOB) applications that interact with it.

2. Stay connected
Smart client applications are never standalone and always form part of a larger distributed solution. This could mean that the application interacts with a number of Web services that provide access to data or an LOB application. Very often, the application has access to specific services that help maintain the application and provide deployment and update services.

3. Are offline capable
Because they are running on the local machine, one of the key benefits that smart client applications offer is that they can be made to work even when the user is not connected. For applications running in occasional or intermittent connectivity situations, such as those used by traveling workers or even those running on laptops, tablets, PDA's, and so on, where connectivity cannot be guaranteed at all times, being able to work while disconnected is essential. Even when the client is connected, the smart client application can improve performance and usability by caching data and managing the connection in an intelligent way.

4. Intelligently Install and Update
Smart client applications manage their deployment and update in a much more intelligent way than traditional rich client applications. The .NET framework enables application artifacts to be deployed using a variety of techniques, including simple file copy or download over HTTP. Applications can be updated while running and can be deployed on demand by clicking on a URL. The Microsoft® .NET Framework provides a powerful security mechanism that guarantees the integrity of the application and its related assemblies. Assemblies can be given limited permissions in order to restrict their functionality in semi-trusted scenarios.

5. Client Device Flexibility
The .NET Framework together with the .NET Compact Framework provides a common platform upon which smart client applications can be built. Often, there will be multiple versions of the smart client application, each targeting a specific device type and taking advantage of the devices unique features and providing functionality appropriate to its usage.

Why is a smart client required?
The complexity of applications is increasing, and with it the expectations of the user. The thin client model is no longer able to provide the required levels of functionality, performance, flexibility, and integration. Users are now demanding fast and responsive applications to perform their daily work in a flexible and efficient manner.

Laptops have proven to be indispensable for a number of information worker uses. Industry analysts are predicting that the majority of information workers will be operating on non-desktop machines within the next few years. The advent of Windows CE, XP Embedded and Pocket PC PDAs and Phones has brought the possibility of an unlimited number of form factors, including ruggedized models, to meet the needs of a broader range mobile workers.
While just reusing older applications on these new devices may be expedient, it often does not foster timesaving or cost-saving improvements, nor does it allow for business innovation. By utilizing the greatly increased computing power contained within these new devices, Smart clients can assist the mobile worker to get more work done in less time.

Feature of smart client
· Rich Components
· Dashboard Functionality
· Rapid Application Development
· Smart Application Delivery and Management
· Standards Based Application Development Environment
· Online / Offline Applications Access
· XML / Web Services Consumption
· Enterprise Security
· Extensibility

Reference:-http://blogs.msdn.com/dphill/articles/66300.aspx

MVCs in RIA

The birth of MVC

MVC was conceived in 1978 as the design solution to a particular problem by Trygve Reenskaug during his visit to XEROX Parc. The top level goal was to support the user's mental model of the relevant information space and to enable the user to inspect and edit this information. Originally MVC was designed to handle the complexity of stateful GUI with rich controls.The ideal MVC solution is intended to support the user to visualize and manipulate the domain information directly. This model is useful the user need to see the same model simultaneously in different context.

Then came the Browsers.

With the advent of the browsers which were stateless, the complexity of MVC could not be handled. So the programming community proposed that the MVC be moved to the server, which became Model 2. Model 2 manages parts of web application like navigation, calls to back end services to perform business functionality, data validation and many others.

Enter RIA.

RIA applications are the web applications that run on the browser with rich functionality of traditional desktop application.RIAs are either 'Zero' or 'Low' 'Foot print applications', meaning they do not require any software installation or require a small plug-in to the browser. They are cross browser and cross platform applications.

MVCs in RIA.

MVC comes as a second nature to RIA, here is how that it employs MVC.

RIA primarily uses XML data structure to store the data of different kinds, it could be the actual data that user is interacting with, the data the RIA app maintains to remain in sync the service tier, and the data about the user as session data.

The client side browser brokers several calls to service layers. As response to its calls, it receives commands as to when and which application need to be rendered with what data. So here browsers does control the data and commands between the client and service (or and) back end.

DHTML/HTML is made use by the browser in case of "Zero-footprint" apps to render the data, where as "Low-footprint" apps like Flex and Silverlight render the browser with their own mechanism.

The advantages of having MVC at the client end are:-

1)Just-in-time delivery of application from server to the client.

2)Helps in optimizing the calls to the server, by allowing the client to access only required portions.

3)Client side validation gives the user a responsive experience.

SOA as in Service Oriented Architechture

In the next few posts I will post few articles,excerpts from various sources reflecting my understandings on SOA.


While doing a reality check on SOA,I really found"6 burning questions on SOA" which was published on JavaWorld by Jon Brodkin. very useful

Here are the excerpts.

1. Is anyone saving (or making money) using SOA?

Ashok Kumar of Avis Budget Group says he is. Avis began using SOA about two years ago in portions of the company to open new channels with travel partners. “They can now do direct business with us without having to go through a middleman. So it’s saved them a couple bucks, saved us a couple of bucks,” says Kumar, who is based in New Jersey and is director of services architecture information technology. “The cost of bringing on new partners is down to nothing now because of SOA.”
Avis Budget can now bring on a new partner in a day instead of a month, he says, because with SOA it is just a matter of configuring a service rather than making large application changes. “When we started that the cost of bringing on a new partner was anywhere from $40,000 to $50,000, now it’s down to $3,000 or $4,000,” he says.


Traditional approaches to building software assume you start from scratch and develop something designed to solve a specific problem, Hurwitz notes. SOA allows businesses to be flexible and seamlessly react to major changes. A business might not see much benefit from SOA for months after deployment, but if it is suddenly involved in an acquisition “there’s a major change in their ability to cope with that change and react and then provide the software,” Hurwitz says.


2. Why is it so hard to find employees with SOA expertise?


The task of finding SOA experts is complicated by the fact that people in the IT world simply don’t agree on what SOA means, Mengerink says.
“You get one person coming in and saying ‘that means it’s a Microsoft service interface.’ Another guy comes in and says ‘no it’s an Apple widget.’ Well, which one is right? If you’re hiring and you say ‘I want an engineer, you could get anything,’” he says.

The best approach is to train your own people, Mengerink argues, because the concepts and technology that underlie SOA aren’t that complicated. Of course, this is easier if you happen to be implementing SOA at a large organization such as PayPal. “If you take a really large company, they’re sort of defining what SOA is,” Mengerink says. “Somebody who has the resources is the one who’s going to say to the world what it is.”
SOA requires a different mind-set than traditional approaches to building an IT infrastructure, Kumar says. Many people can program in Java and understand how to make a single Web service, but putting it all together in a services-oriented architecture is difficult, he notes. “A lot of people have a hard time making that leap, and that’s why we tend to go to outside service providers,” he says. “Even then, I think good talent is just hard to find.”


3. Has Microsoft gotten a clue about SOA?
“I’d say in fairness, Microsoft is getting a clue about SOA,” Fulton says. “Right now, their SOA strategy per se is a little mysterious; it’s a little harder to tease out. I think they have recognized it’s a significant force in the market.”


“Microsoft’s current story on ESB isn’t ‘hey, here’s out ESB product,’ but ‘you [the customer] can build an ESB … and you can use these products to do it.' They even talked about having accelerator packs that make it easier to build them on top of things like BizTalk.” Fulton says.
That would be Microsoft’s BizTalk Server, a business process management server that has tools to design, develop, deploy and manage a company’s business processes. Hurwitz describes the integration technologies in BizTalk as Microsoft’s “alternative’” to an enterprise service bus.

4. How does SOA affect network performance and management?

For all its benefits, you can bet SOA will saddle your network with increased requirements and complicate network management and operations, consultant David Jacobs writes in a paper for IT professionals.
Since each application in a SOA is composed of many individual software components, a failure anywhere in the network can bring down an application, he notes. Your own performance in monitoring the network and immediately responding to problems is thus even more important after an SOA is deployed
Data rates and the time required for each interchange between components are a factor in transaction rate -- but only one factor. Management software must be able to detect problems at the application level and then be able to drill down to find the root of the problem.

5. Do security requirements change when an IT department uses SOA?

IT executives thought security was a peripheral concern when SOA efforts began. Now it’s become one of the most pressing issues they must address.

Identity management is one of the key challenges IT managers have to address with SOA.
“When you have a SOA environment, the same business service may be used in 10 different ways,” Hurwitz says. “You have to make sure you have a security structure in place that says who’s allowed to access what in what circumstances. … It becomes more complicated. The risks in some ways get higher because you’re reusing a lot of services and you have to make sure you have the right level of security on top of that.”

6. What are SOA’s dark sides?

Security is clearly posing a challenge to at least some IT executives deploying SOA, but it’s not the only dark side you’ll find when building a service-oriented architecture. One of the “dark underbellies” of SOA, according to Fulton, is the challenge of providing a unified view of data and access to data across multiple business services.
Reusing old software for new business processes is great, but it exposes an Achilles heel of most enterprises: their customer data has evolved over time.
Offering an example, Fulton notes that five years ago, cable companies thought of a customer as a person who lives in an apartment or house where they receive a bill. “Today, you probably [say] a customer is someone who receives a bill for multiple premises, potentially. That’s a small change, but the old applications can’t do that. … So all building blocks of services can be manipulated to do things quickly, you have to figure out how to unify the data. People are still struggling with that.”