5 things you need to migrate web analytics on-premises to SAAS

Remember the IBM announcement back in April to sunset NetInsight? The truth is on-premises web analytics is a dying art. The only other well-known vendor that provides on-premises solutions is WebTrends. It is destined to suffer a slow death – there have not been any new releases for the last few years and customers are encouraged to move to the SAAS version. So, the next best thing is to prepare and plan for inevitable – migration to SAAS.

1. Assess Web Analytics vendors. Sunsetting the on-premises solution presents a good opportunity to reassess the web analytics landscape instead of blindly sticking with the same vendor and moving your data from on-premises to SAAS.
2. Documentation. Documentation. Documentation. I said it three times and I meant it. No one likes to create it. I get it – it’s a boring, monotonous task to write every variable, every processing rule, every customization. However, switching your web analytics tool without documentation is like going into battle and forgetting your ammunition. You need to ensure you have documented the following:
   • A List of Key Custom Built Reports and Layouts. This is your foundation for stakeholder expectation management and therefore the golden key to your sanity during migration. This task can become a project on its own since going through such an exercise will confirm what reports and metrics are critical and important for the business and which ones you can delete because no one is using them anyway.
   • Current Tool Configuration rules. This is a big one and can cost you dearly. I had many urgent calls from clients desperately trying to understand why their data tanked 20 – 30% when they switched to a new tool or data collection method. In 99.9% of all cases the answer was due to configuration such as page view definition, filtering, visitor tracking methods, etc. The configuration topic certainly warrants a separate post, so check back in a while.
   • Site/Metric Matrix. List all custom collected metrics per site, including metric definition, collection method and syntax. This exercise should be completed hand-in-hand with report documentation to ensure every single custom metric is documented. This is your bible. Keep it on your nightstand and refer to it often. If you need a sample template, come back in a few weeks – I will be posting further on this subject.
3. A Project Manager and a Project Plan. Web Analytics migration is like surgery – you need to make sure that your patient (aka reporting) will not die during the surgery (migration). You may get away without a plan if you a dealing with a simple site and basic data collection (wart removal), but if you a dealing with multiple sites, channels, applications and vendors (open heart surgery), a solid plan is required for successful execution.
4. Assessment against Current Reporting Capabilities. Migration from on-premises to a SAAS solution (or one vendor to another) almost always results in loss and/or gain of features. E.g., SAAS solution is likely to have greater social and mobile tracking capabilities but you may need to make some data collection tradeoffs in order to adhere to your company’s data collection policies, especially if you are in the healthcare or financial industry. Create a loss/gain matrix and use it to manage change. No one likes to give up things that they already have. Over communicate any changes to stakeholders in advance, quantify impact of such changes on business and help to define mitigation plan, if necessary.
5. Assess Current Roles, Responsibilities and Processes. Switching from on-premises to SAAS will impact current roles and processes, e.g., there will be no need to maintain servers.   Process-wise, you will not be able to re-analyze collected data, which will have an impact on new report deployment as well as the ability to apply new reporting requests to historical data. Don’t wait for a bear to get you – review current roles and processes, outline necessary adjustments and manage change before the migration occurs.

Feel free to comment or add to my list!

The Cloud Has No Clothes!

Everybody remembers the classic fairy tale where an emperor and his people are conned in to believing he was attired in a fantastically beautiful set of clothes, when in fact he was in the buff.  No one was willing to admit they did not have the refined taste and intelligence to see the spectacular cloth and splendid robes. It took the strength of innocence in a child to point out the truth. I am about as far from an innocent child as one can get, but it appears to me the cloud is parading about naked.

Every vendor has a cloud offering, every pundit “agrees” the cloud is the future, investors value every cloud company with a premium, every data center operator is “born again” as a cloud player. Every CIO has a cloud initiative and budget line. Really, I have seen this movie plot before, and it does not end well, especially for the Emperor (and the con-men vendors too).

We have worked internally on projects as well as externally with clients to implement aspects of the “cloud”. Results have been mixed and in the process gathered some hard won experience which I will condense here (while protecting both the clothed and the naked).

First, Software as a Service (SaaS) will work if adopted with minimal software modification and maximum adoption of it’s native business process. It is very cost effective if it precludes investment in internal IT infrastructure and personnel, not bad if it slows the growth of same. Outsourcing well-defined rote functions to the SaaS route works well (such as Email).  Adopting SaaS for new non-strategic functions tends to be successful where there are few users and a high degree of specialization. Data backup into the cloud is an excellent example regarding highly specialized solutions that take advantage of economies of scale provided in hardware.

SaaS fails in terms of cost or functionality when it is subject to customization and extension. Service costs tend to swamp the effort from initial modification through long-term maintenance (humans=$$$$). Costs will especially spiral when you combine many users and many customizations.  Remember the “Keep It Simple, Stupid” (KISS) principle saves money and points to success.

Buying virtual machines in the cloud works well if the configuration is simple; few software products, few users, straightforward integration. Development and early deployment is particularly attractive, as is usage by start-up companies and software proofs, tests, and trials. Again, the KISS principle reigns supreme. Remember hardware continues to drop in price and increase in capacity.  Package software costs are stable. Understand the billing algorithms of the key “clouds”. Each has its cost advantages and drawbacks, and they change rapidly under increasing competition and hype. Always benchmark medium to long-term cloud virtual machines against native hardware virtual machine implementations, the results may surprise you (I have been surprised over and over).

The Emperor’s story is an old one and so is the cloud concept in principle; remember its first turn on the karmic wheel of optimizing the highest cost component was time-sharing. This strategy optimized the high cost of proprietary hardware/software (remember IBM and the Seven Dwarfs, but I digress into another fairy tale). As minicomputers (Digital, Data General, Wang) dropped the price of hardware through competition with IBM, software packages became the gating factor. Workstations continued the trend by another factor of 10 reduction in cost of hardware and package software (human service costs are rising).  Wintel and the Internet have driven the marginal cost of raw computing to almost zero compared to the service component. As hardware has followed Moore’s law and software package economies of scale moved to millions of copies, the human costs have skyrocketed in both relational and absolute terms.

If we can keep history as our lens and focus on our cost pressure points, we can maintain our child-like innocence and see others prancing naked while we keep our kilts and heads about us.

Is Custom Development Dead?

Is Custom Development dead? After the last two years of custom development’s nuclear winter, (following 2008s Financial Armageddon), one would think the the Grim Reaper did his best in the blast. I really hope not, designing and building strategic systems make the more mudane aspects of software engineering worth enduring the mind-numbing syntactical pain of creation. Nothing like the smell of napalming the competition with a totally new way of doing business in the morning (my view of “Apocalypse Now” with a business bent). Maybe, just maybe, I hope rumors of Custom Development’s death are greatly exaggerated.

Did Custom Development die of natural causes, maybe pulled off of life support by risk-hating Executive Management as a perverse form of parental control after the financial snafu (Custom Development moves from PG-13 to XXX)?  Off-the-Shelf software products and the ever increasing cost of continuing maintenance really hurt Custom Development as a viable systems choice, but is that enough to put it down? Cloud and “nouveau Cloud” technologies (read SaaS, SalesForce.com) may have provided the coup de grace.  I seriously doubt it, every time I look into the Cloud I get serious PTSD flashbacks to the 70s and 80s IBM Mainframe World Domination (OMG there is a 3270 in the corner!!).  At least there was alot less hype and easier choices back then (Nobody got fired picking IBM!).

It is possible Custom Development died offshore (simple Mickey Finn, bag over the head, Shanghaied and Held for Ransom!)?  While Business Processes and System Maintenance have done reasonably well offshore (Castor Oil of the Corporate world, let Mikey take it!), strategic custom development has had less success.  Quality innovation that can transform a corporation really requires a local team steeped both in the host company and surrounding culture.  Plus, Custom Development tends to have a high infant mortality rate so it is best attempted in short phases supported by an Agile Methodology, definitely not in Offshore’s financial model wheelhouse.  So I don’t think Offshore is implicated.

There is the theory that evolution has spoken and Product-based Solutions have succeeded Custom Development, just as mammals succeeded dinosaurs.  Product companies would like you to believe that, but does that seem plausable (Land of the Lost, Jurassic Park where are you?)?  While Product-based solutions have advantages in success rates and cost, they by their nature lack the true freedom that drives raw creativity and innovation.  Custom Development is that wellspring.

The only thing we have to fear, is fear itself!  Adversity to risk is curbing animal spirits, creativity, and innovation, ….for now.  Custom Development is not dead and will return from its vacation with Puff in the Cave by the Sea when Jackie Paper locks-and-loads and we begin some serious innovation and transformation with strategic custom software systems (BTW thats when the Jobs return too!).

Best Practice: Cloud Computing

Red sky at morning, sailor take warning.

Here’s a forecast: clouds are rolling in. Architecting for cloud computing will, very soon, become a conscious best practice.

There are lots of handy objections to Cloud Computing: Regulatory compliance, geographic containment requirements, taxes, liability, vendor lock-ins and lack of standards. Many are brushing off cloud technologies as a result, and maybe rightly so… for about another minute, anyway.

Last year, I was involved in a client’s effort to re-provision an application from an in-house infrastructure to a SaaS vendor. All told, the effort was risky and enormous. The administration of it took a year. It took a team of talented engineers from several different companies over six months to implement the transfer. When it was done, everyone breathed a sigh of relief.

The amazing part was that it wasn’t about changing applications. It was just changing who hosted the application. Simply put, no one had the fore-sight to architect for a transition of this nature, and so the ROI was heavily diluted.

Market fluctuations, re-focused specialization, business units changing hands, economic right-sizing, disaster recovery; there are many reasons agile infrastructures can be useful. Cloud computing technology is evolving quickly and has the very real potential to offer agility at a dramatically lower cost, if you’re prepared to leverage it. You don’t have to go in to the cloud to see what you might gain from it. The important part is preparing for it so you can use it when it makes sense for you. And, you could even go green at the same time.

I won’t try to predict what your organization has to gain by architecting around cloud technology. It’s more about what your organization is at risk of losing if you don’t.

Cloud Computing Trends: Thinking Ahead (Part 1)

The aim of this three part series is to gain insight into the capabilities of cloud computing, some of the major vendors involved, and assessment of their offerings.  This series will help you assess whether cloud computing makes sense for your organization today and how it can help or hurt you. The first part focuses on defining cloud computing and its various flavors, the second part focuses on offerings from some of the major players, and the third part talks about how it can be used today and possible future directions.

Today cloud computing and its sub-categories do not have precise definitions. Different groups and companies define them in different and overlapping ways. While it is hard to find a single useful definition of the term “cloud computing” it is somewhat easier to dissect some of its better known sub-categories such as:

• SaaS (software as a service)
• PaaS (platform as a service)
• IaaS (infrastructure as a service)
• HaaS (hardware as a service)

Among these categories SaaS is the most well known, since it has been around for a while, and enjoys a well established reputation as a solid way of providing enterprise quality business software and services. Well known examples include: SalesForce.com, Google Apps, SAP, etc. HaaS is the older term used to describe IaaS and is typically considered synonymous with IaaS.  Compared to SaaS, PaaS and IaaS are relatively new, less understood, and less used today. In this series we will mostly focus on PaaS on IaaS as the up and coming forms of cloud computing for the enterprise.

The aim of IaaS is to abstract away the hardware (network, servers, etc.) and allow applications to run virtual instances of servers without ever touching a piece of hardware. PaaS takes the abstraction further eliminates the need to worry about the operating system and other foundational software. If the aim of virtualization is to make a single large computer appear as multiple small dedicated computers, one of the aims of PaaS is to make multiple computers appear as one and make it simple to scale from a single server to many. PaaS aims to abstract away the complexity of the platform and allow your application to automatically scale as the load grows without worrying about adding more servers, disks, or bandwidth. PaaS presents significant benefits for companies that are poised for aggressive organic growth or growth by acquisition.

Cloud Computing: Abstraction Layers

So which category/abstraction level (IaaS, Paas, SaaS) of the cloud is right for you? The answer to this question depends on many factors such as: what kind of applications your organization runs on (proprietary vs. commodity), the development stage of these applications (legacy vs. newly developed), time and cost of deployment (immediate/low, long/high), scalability requirements (low vs. high), and vendor lock-in (low vs. high). PaaS is highly suited for applications that inherently have seasonal or highly variable demand and thus require high degree of scalability.  However, PaaS may require a major rewrite or redesign of the application to fit the vendor’s framework and as a result it may cost more and cause vendor lock-in. IaaS is great if your application’s scalability needs are predictable and can be fully satisfied with a single instance. SaaS has been a tried and true way of getting access to software and services that follow industry standards. If you are looking for a good CRM, HR management, or leads management system, etc. your best bet is to go with a SaaS vendor. The relative strengths and weaknesses of these categories are summarized in the following table.

	App Type Prop. vs. Commodity	Scalability	Vendor Lock-in	Development Stage	Time & Cost (of deployment)
IaaS	Proprietary	Low	Low	Late/Legacy	Low
PaaS	Proprietary	High	High	Early	High
SaaS	Commodity	High	High	NA	Low

Cloud Computing: Category Comparison

Taking the Plunge into SaaS

Under pressure to reduce IT budgets, many businesses will make their first attempts at implementing Software as a Service (SaaS) in 2009. While there are real savings to be gained by phasing SaaS into the enterprise architecture, careful planning can help steer around some of the common difficulties.

1. Start with a realistic assessment of your application portfolio to determine where your best SaaS conversion options lie. Customizations are a complicating factor when moving to the SaaS model. It can be done, but manage expectations within the business aggressively to let them know that the SaaS solution will be implemented as close to out-of-the-box as possible.  Your first attempts at moving to SaaS might be best steered towards the applications with fewer points of integration, as these will complicate the implementation (see point #3, below).

2. When doing your initial scan for SaaS solutions, make sure you have second sources lined up for each application, and thoroughly vet out the differences in their offerings from the application functionality, service offering, and cost perspectives.

3. Model your integration points rigorously. Identify all possible interface failure points and document exactly who is responsible for identifying and fixing these failures. Include the failure scenarios in your SaaS migration test plan.

4. Service level agreements are key to making the relationship work. Even some of the oldest SaaS offerings, such as Salesforce.com, have outages from time to time that leave users high and dry. Every service component needs several service level agreements explicitly defined in the contract. These include:

• Application uptime as well as maximum length of downtime per outage episode
• Time to resolve trouble tickets by email and by phone
• Required advance notification for scheduled maintenance outages

5. Pre-sale due diligence is not enough. The Satyam scandal has taught us that. Use every means available to stay ahead of news on all your SaaS partners, including monitoring twitter, technorati, Google alerts, and traditional media for hints that they might be experiencing customer satisfaction or business issues that could impact the quality and longevity of their service.