View from the Edge

3 Common Mistakes Made When Moving to SaaS

One of the questions that I get asked a lot is “What are the mistakes that others have made when moving to Software as a Service (SaaS)?”  I think that software vendors are always looking to learn from others mistakes – so they don’t make the same ones.  So, I thought I would highlight some of the common mistakes that I have seen by some of the vendors that I have spoken with over the past few years.

1) Thinking that SaaS is a replacement for the current offering
Many times when I first meet with a vendor, they are thinking about their SaaS offering in relationship to their existing product and their current target market.  The problem with this is that if you come in thinking that this new SaaS offering is just to replace your existing product offering – then that is called “cannibalization” and that is a bad thing.  What you want to do is develop a new adjunct or complementary service/offering for your existing customers – or even better - to develop a new offering for a completely new target market.  It may be based on your existing product/expertise – but you need to think of it as a new service offering to a new customer base and not just as a replacement to your current offering. The last thing you want to do is cannibalize your current product offering.
 
So, my advice is as follows: If you feel you have found an untapped market for your existing product capability – then go after this new market with a new service offering.  If you feel you only have access to your current target market/customers – then you need to develop a new service to be offered in addition to your existing on-premise product.

2) Targeting too broad of a market segment with the initial SaaS offering
The next thing that happens after many vendors decide to move to SaaS is that they try and take on the world all at once with the new offering.  Too many times when I first meet with a vendor and I ask who their target market is – they come back with an answer that almost includes everyone.  Now, I know that many times a product can solve many problems for many types of companies – but one thing to keep in mind when bringing a new product/service offering to market is to FOCUS.   What I mean by that is for your initial SaaS offering – think about starting small and targeted.  Maybe you can pick a subset of a broader market – or maybe you can limit your target by geography or by a particular set of business processes – whichever way you choose – the key is to start small – become successful and work out all the kinks. 

Once you have shown success – then it is time to open up the field a bit more and expand – but my advice would be to start small and target your offering at a set group of prospects and then once you have achieved success – expand into other areas.

3) Treating the SaaS customers the same as the current customers
Another mistake that I hear a lot about is around the level of service and customer support that is provided to a SaaS customer.  When I first meet with existing software vendors they always tell me that support is not a problem – because they have been doing software support for their customers for years and that is something they know a lot about.  Well – maybe they know a lot about product support – but servicing a SaaS customer is different.  Here is what I mean by that: in the SaaS model – it is all about service levels – that includes: product support, technical support, operational access and overall customer service experience.  I think that most software vendors are good at product and technical support – but it is in the areas of operational support and the overall customer experience that sometimes is forgotten or in many cases – just not thought about at all.

The customer experience will not only be critical to the renewing of the service – but it also counts in terms of how much the service is used as well as many times – how many additional services will be utilized/desired by the customer.  SaaS success is all about “stickiness” – and that means you need to get more customers using the system and you want them to think about going to you for additional services and not to another service provider.

So, my advice is to create a separate account management function to make sure that the needs of the SaaS customers are always being looked after.  You may also want to incent those account managers to continuously ask about how the service is going and provide them with additional service offerings.  Also, make sure from an operational perspective that service levels are constantly being met- if not exceeded – as it has been shown that a happy customer is much more likely to buy more and an unhappy customer is always ready to tell someone else how unsatisfied they were with a vendor.

A Strong and Stable OpenEdge Environment

In today’s “new economy” you have to make the best of everything you have.  This is even more critical when it comes to making your environment as strong and stable as you can.  Ensuring your environment is running optimally and not speeding towards the cliff is critical to your business doing the best it can.

This is especially important when you are working on Disaster Recovery plans.  Businesses are having a hard enough time making ends meet and staying in business without the additional challenge of losing data or a critical business system.

Disaster Recovery, from my perspective, is a timeline.  Along this timeline is developing your application, testing your application, deploying your application, and managing your application.  This timeline ties very nicely into the four phases defined for Emergency Management in the National Incident Management System (NIMS).  Although this information is for the Federal Emergency Management Agency (FEMA) in the United States, there are similar links for agencies in your region and country.

The four phases of emergency management are Mitigation, Preparedness, Response, and Recovery.  Although Emergency Management deals with man-made and natural disasters, the same concepts can also be applied to application management and Disaster Recovery Planning.

Mitigation is the process of eliminating and minimizing the effects of the disaster.  This is most critical in the development and deployment section of application management. 

Preparedness is the process of planning your DR plan and what the contingency is in the event of a disaster happening.  This is where a business impact analysis (BIA) determines what SHOULD be done to prepare for a disaster.

Response involves who is responsible for what in the event of a disaster striking.  In your business you should know who is going to make decisions, who is going to execute on those decisions, and who is going to DOCUMENT what is going on and what is being done.

Recovery involves returning the business to either partial or full capacity.  This may mean failing back to the production environment, like OpenEdge Replication can do.  It also involves getting your disaster recovery location up and running.  Whether this is utilizing Progress’ technology or something else, recovery requires that the business is running and doing the critical functions needed to stay in business.

It is important to understand that this process is a circular chain.  Disaster Recovery Planning is never done and is an iterative process.
 
Progress is committed to providing you with the tools to make your environment as efficient and safe as possible.  To this end, Progress will soon release OpenEdge Management 10.2A.  This release will include a new tool to help you remotely manage operations – OpenEdge Explorer (OEE). 

OpenEdge Explorer will provide an alternative to Progress Explorer as the configuration and management tool for the OpenEdge environment.  You will no longer have to install a Progress client to be able to graphically configure your OpenEdge environment.  You will also be able to monitor the current status of your systems from a browser anywhere on your intranet.

Additional free online training for Emergency Management and NIMS is available here.

This blog was an interrupt from my normal stream.  I would love to hear what you want to hear about and talk about from the Disaster Recovery world (or Emergency Management, Business Continuity, etc.).

In my next blog I will return to my normal process.

Until then, recovery from a disaster starts with the individual – are you ready?

Brian B

GUI presentation models - more than just look and feel

While working on a new ABL sample using OpenEdge GUI for .NET, I started thinking about the different presentation models that are available to an ABL programmer in 10.2A. While much of Microsoft geeks are focused on the cool new features of Vista, OpenEdge stays focused on real world business applications. Business applications need a productive, full-featured user interface whose purpose goes beyond catching the user’s attention. Since these applications must be functional above all else, the need for Vista’s multimedia effects (video, animation, graphics) might be nice but not critical. Business applications have a typical set of features that are often reused over and over again. These features include:

• Support Create, Read, Update, Delete (CRUD) capabilities – data entry and persistence
• Data managed in a grid or multiple entry fields

One of ABL’s core strengths has always been its ability to manage the backend data easily, with built-in and native data awareness and transactional support in the language. Now with OpenEdge GUI for .NET, you have even more choices available to select the right presentation model for your applications. In general business applications have many different screens to show to their users and often there is need to show more than one simultaneously. There usually is a central way of managing the various screens (a window manager), as well as some means of transitioning between them. It is crucial that users can easily navigate the application, and can use it in a flexible way that fits with their needs.

The presentation models to consider are:

• Single Document Interface (SDI)
• Multiple Document Interface (MDI)
• Tabbed Document Interface (TDI)
• IDE Style Interface (IDE)

Single Document Interface

SDI organizes graphical user interface applications into individual windows that the operating system's window manager handles separately. Each window contains its own menu or toolbar – there is no concept of a “parent” window. Applications which allow the editing of more than one document at a time, e.g. word processors give the user the impression that more than one instance of an application is open instead of a single application with multiple documents. Each window displays as an individual entry in the operating system's task bar or manager – which might group windows of the same application.

          Microsoft Word and Excel are examples of an SDI application.

Multiple Document Interface

MDI organizes graphical user interface applications into many windows that reside under a single parent as opposed to all windows being separate from each other like SDI. A single menu bar and/or toolbaris shared between all child windows, reducing clutter and increasing available screen space. In MDI a single instance of the application is shared and the child windows all float within the parent (container) window.

The disadvantage of MDI is that it is easy to “lose” a child window when many windows are open simultaneously. In order to view the list of windows open in MDI applications the user typically has to go to the menu bar, moving their focus out of the child window area.

Tabbed Document Interface

This is a specialization of the MDI model. Like MDI, TDI organizes graphical user interface applications into many windows that reside under a single parent window. Unlike the floating child windows of MDI, in TDI each “window” is displayed in its own tab. This makes it much easier to find open windows than traditional MDI. TDI windows must always be maximized inside their parent window, and as a result only one tab can be viewed at a time.

The disadvantage of TDI is with only a single window available at a time, comparing information or copy-and-pasting between two windows is more difficult. Additionally although tabs make it easier to find open child windows, if there are a large number of windows opened simultaneously there are many tabs for the user to search before finding the one they are looking for.

Firefox is an example of a TDI application.

IDE Style Interface

IDE Style Interface is another specialization of the MDI model. Like MDI, IDE organizes graphical user interface applications into many windows that reside under a single parent window. An IDE-style interface is a superset of the MDI model with features available to support the child windows that are not normally available in traditional MDI applications. These child-window features include:

• TDI model for child window
• Ability to view child windows simultaneously using splitter
• Separate window management for child windows - normally tree-based
• Additional, independent panels to support application – these often use a tabbed interface

Microsoft Visual Studio.NET and Eclipse are examples of IDE applications.

Microsoft Outlook

Microsoft Outlook, and its very popular user interface metaphor, is not true to any of these models. It is closest to an IDE application without tabs for the child windows. Or you could consider it an MDI application with child-window features.

When you plan to redesign your appIication's user interface, consider which of there models works best for your application and users. This is not a one size fits all solution but one that is customizable for your needs. With the new GUI for .NET you get access to Microsoft .NET Windows Forms, an extremely full-featured user interface solution. In Microsoft’s own words “With Windows Forms, you can create powerful Windows-based applications. You can harness the power of Windows Forms to display data, handle user input, and deploy your applications easily and with enhanced security.”