The “important” camp is typified by Workday.

Aside:  I love their ads joking about the whole SaaS, PaaS, IaaS chaos. Their line: “Your mother-in-law as a service.”

Anyway, their point is that having all customers on one version of the software allows development to focus on improvements and features for the next version, instead of support for various prior versions. In other words, customers do care and are sensitive to the internal resource demands that face their software application vendors.

Sounds good … except Ben Frankel of PegaSystems points out that it also forces all customers into a common upgrade cycle. Fine if the changes are minor. Not so fine if there are software interface changes or other things that require customer adaptation.

As a customer, I’d prefer to have two outstanding versions — the latest and one version prior.  The plan would be to transition customers from one to the other as part of the “support” policy, and fixing things only in the new one. Basically this would provide customers with some scheduling flexibility on the upgrade cycle.

I’ve written before about the advantages I see with SaaS for enterprise software.  Namely,  SaaS eliminates a lot of cross-platform QA, which doesn’t add any value at all. SaaS keeps the software engineers motivated to add the features customers really want. SaaS also eliminates some of the enterprise-feature-plugability stuff, e.g., “can your software work with my high-availability clustering system from vendor X?” Making something as intricate (especially to test) as HA pluggable…is a really bad idea. This is a related argument to the one Workday makes.

Back to multi-tenancy (MT) or not. Frankel points out that unless the reduced cost of multi-tenancy is directly passed through to the customer, why should customers care? His (correct) view is that MT is about saving money for the vendor. He also points out in other blog posts the importance of on-premise deployability. I’ve heard this same mantra from SAP, which touts “on premise, on demand, on device,” as in you can have whatever you want anywhere you want it.

I am not persuaded. This sounds appealing, but the realities and challenges in creating high-quality enterprise software make these visions very hard to achieve. Even the very large enterprise software vendors I’ve worked for have struggled to have enough people on development projects and QA to deliver high-quality and feature-rich software.  There’s an illusion that large enterprise software companies have massive test labs where every configuration a customer might have will have been tested. This is bunk. Nothing like that exists, and we frequently encountered customer scenarios where the customer’s configuration was breaking new ground, was scaling up in a dimension beyond what we had ever been able to test, and so forth. These QA overheads are very real.

So, at realistic business costs for software development, I believe SaaS will result in significantly higher product quality.

One more point on multi-tenancy. Customers do care about the viability of their vendors and competitiveness of features they are offered by them. Low-cost SaaS products have to be multi-tenant to be cheap. Otherwise the vendors won’t make any profit. Higher-cost SaaS products can be single tenant, or various hybrids.

At Oco, we’re a hybrid. We do multi-tenant infrastructure (configurations of analytical reports, users, logging, etc.) single-tenant data, meaning separate database instances for customer data. This is to support security audits. A customer DBA can audit the database security provisions we use. Given that we’re a Business Analytics company, and house large volumes of people’s data in our data warehouse(s), this seems like a good balance point. Our price point makes this viable, and customers definitely find it comforting.

Conclusion: there’s no one perfect answer on the MT issue. If MT is needed for a vendor to have a viable business model, then it *is* important to a customer. If the software is already an expensive and mature product, and you’re really just considering how to deploy it. Then MT is of much less concern.

I’d love to hear your thoughts on the topic.

informIT:  A Business Intelligence Roadmap: Project Planning

BeyeNetwork:  Roles and Responsibilities in Business Intelligence Teams, Part 2

While these articles take a more generic view of Business Intelligence and project management, I want to talk about a few tasks that aren’t mentioned as much. These are lessons learned from my experience working on a variety of different BI Implementations Before kicking off your next project, here are some tasks for your business team to consider (IT considerations will be in a future discussion):

Determine Critical Business Needs and Start With the End in Mind

A BI solution should address specific business needs. Attempting to report on everything is too broad of an approach will end in failure. It’s essential to define the key business issues you are trying to solve and the key corporate goals that your BI solution will support. By starting with the end solution in mind, the team can focus on delivering to that vision.

Figure Out What you are Looking at Today

I talk to customers all the time who claim there is a common view of the business across their organization. Then they get a bunch of people in a room together and realize that everyone is speaking a different language. Things that seem like they should be simple and standard across the business, even something as simple an organization’s definitions of the countries they serve, often turn into long conversations where each stakeholder has a different opinion. Take stock of your current reporting and poll some different users on key business dimensions and transactions. Determine the true level of standardization across the organization.

Allocate Appropriate Resources, Not Just in Name

It’s one thing to have people assigned to a project; it’s another to have them as active participants. The key participants in this type of project are often the same resources that are already overbooked on other initiatives. First, management needs to understand the resource, skill, and time requirements throughout the project and allocate the resources accordingly. Then, they need to make sure they clear the way for those resources to actively participate in the project. Without the right business user involvement, the project will be in jeopardy before it begins.

Determine Your Test Plan Before the Project Begins

One of the biggest issues with BI solution implementations is the ability to validate the solution data during the QA phase of the project. Often this data doesn’t exist elsewhere in the same form so there isn’t a good set of data to validate against. How can you know if your BI solution is correct if you don’t have the structure in place to prove it? It’s imperative that a plan is put in place to make sure the team is comparing “apples to apples” during the QA cycle. Without this, your project will be in danger of going through an endless cycle of trying to tie out two sets of numbers that were never meant to be the same.

By putting some effort into the tasks listed above prior to the start of your next BI Solution project, you will help put your team on the road to success.

Part 2 of this discussion will focus on the preparation tasks for the IT organization.  Please stay tuned, thanks.

Presentation after presentation by IT professionals took one of two angles:

1. We built a huge, super fast data warehouse and let me tell you how we did it; or
2. We built this home-grown system to do BI, let me tell you exactly how.

In the case of the big data warehouses, there were some very cool approaches with some real innovation.

In the case of the home grown systems…help! One VP of IT was proud that he built an operational data store from the ground up. Another was proud that he put a tremendous amount of business process in place, but lets users pull data down into spreadsheets and do what they like with it – strict process with loose data governance. Another said it all starts with the data: identify all the data, get it in a data warehouse, then figure out what to do with it.

Doesn’t the IT organization have more value-adding contributions to their company than simply building systems from scratch that are commercially available today?  Are these really examples of innovation in BI?

- How about CIOs talking about how they drove business benefits for their companies?
- How about VP, IT architecture talking about having business needs drive analytics that drive data that drives the solution?
- How about Directors of BI talking about how they leverage open source or SaaS to address a certain set of specific requirements from their user community?

Let’s hope we’re not hearing the same stories of “BI success” three years from now.

Is there any innovation around BI going on out there by IT organizations? Are they simply reluctant to talk about it? What do you think? What are your stories?

a) Privately held and therefore hard to gauge in terms of “how they are doing”, and

b) Are still too young in their evolution…meaning that even if they were growing at a healthy clip in the down economy (ie: double-digit growth), it is hard to tell if “they are doing well”.

Also, what metrics would one look at to assess growth for these firms?  What might be a meaningful metric to measure some of these firms may be far less meaningful for the others.

Measurements aside, here are some thoughts about why the SaaS Business Intelligence segment should be doing well:

• It’s faster to deploy vs. on-premise, therefore, can provide faster business benefit
• It offers a better economic model vs. on-premise….lower TCO
• Customers can “stretch” their existing budgets more (the SaaS model usually means little-to-no capital expenditure) and still get a solution
• An already over burdened IT staff can off load much of the low-value work associated with hardware provisioning, software provisioning, software configuration, database tuning, backups, etc. to the SaaS provider…therefore freeing them to focus on higher-value tasks to support the business
• Some SaaS Business Intelligence offerings are geared to specific functional areas and business problems and can therefore drive some tangible business benefit (ie: Inventory Cost Reduction, Increased Customer Retention, Lower Transportation Costs, Improve Gross Margins, etc.).

These points all make sense to me.  If you were to say to a CFO…”you can have a BI solution up and running in 8-10 weeks, with little-to-no upfront investment, minimal disruption to your IT staff, and it would be well aligned to your strategic business initiatives…” why wouldn’t he/she not want to give it a try?

Here are some reasons why many organizations are still not making the leap to SaaS BI:

• The SaaS model is disruptive to many of the traditional ways of procuring and deploying software….it’s different, therefore, it requires change and a lot of people don’t like change
• The “trusted advisors” of many organizations are not recommending SaaS solutions yet because they don’t fully understand the benefits and/or they have a vested interest in doing things the old way (meaning they make a lot of money from that)
• Control…the nature of SaaS is that if you are going to use a SaaS solution, a lot of things are no longer going to be in your control
• Trust…you need to take a leap of faith in your provider to trust that your data will be secure, your solution will be available/responsive and recoverable should there be a “disaster”
• Misplaced Fear…Many IT organizations are resistant to the SaaS model because they perceive it will impact job security.

But times are different now (didn’t General Motors just go bankrupt?) and doing things the old way may not always be working anymore.  Can we afford not to look at new and different ways of doing things?

COMMENTS (archived)

I don’t think anyone can afford not to look at new and different ways of doing things. SaaS is a good example. Although they’re not suitable for all organizations, they are for many and usually cost a fraction of large scale server/client solutions. Deployment is usually a child’s play, so IT resources can be spared for something else. That said, business intelligence software or SaaS is something that should not be cut in order to save money. Actually, BI software helps save money, among other things, when used wisely. A better solution could be to find a cheaper product, maybe, but getting rid of a BI solution isn’t quite a wise decision.

————————–

I believe Travis is spot on in his comments. Properly designed and deployed BI can provide organizations with enormous leverage and business benefits that far outweigh the costs. One big challenge is transitioning the discussion from a cost-basis to a value-basis. Yes I know this sounds a bit like “motherhood and apple pie” but this really is the dialogue that technology decision makers and leaders must engage in.

————————–
There needs to be some context set around the economics of any new innovative solution, like SaaS BI. Engaging in a total cost-of-ownership comparison of a build it yourself with traditional BI tools, versus say using a SaaS model, is interesting but only half of the story. Folks need to dig in with as much vigor to determine which solution will do a better job driving the value or “Return” in the ROI equation. There are differences and fundamental questions to be asked:

1. Which model allows more universal access to the solution by the community that counts — the internal business users (and perhaps even external supply-chain partners and custoemrs if appropriate) to help drive informed decision making?

2. Which approach does a better job leveraging functional best practices and domain expertise and who does a better job exposing these concepts into specific reports and analytics?

3. Which appoach is more of a business relevant solution solving a specific business challenge and driving specific initiatives?

Too often the question asked in traditioanl deployments with tarditional tools is “What does the tool do and what is it good at?. The common response is “That really depends what you want it to do.” I would sugegst this becomes a circular dialogue chewing up precious cycles and proloning already long production deployment times.

So Travis I agree folks need to be specific, ask the detailed business questions, and make certain that whatever approach is taken really solves the domain specific business challenge.

Borrowing from the dated, but still entertaining movie, Blazing Saddles: “We don’t need no stinking general reporting tools.”