We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: William McKnight Subscribe to this blog's RSS feed!

William McKnight

Hello and welcome to my blog!

I will periodically be sharing my thoughts and observations on information management here in the blog. I am passionate about the effective creation, management and distribution of information for the benefit of company goals, and I'm thrilled to be a part of my clients' growth plans and connect what the industry provides to those goals. I have played many roles, but the perspective I come from is benefit to the end client. I hope the entries can be of some modest benefit to that goal. Please share your thoughts and input to the topics.

About the author >

William is the president of McKnight Consulting Group, a firm focused on delivering business value and solving business challenges utilizing proven, streamlined approaches in data warehousing, master data management and business intelligence, all with a focus on data quality and scalable architectures. William functions as strategist, information architect and program manager for complex, high-volume, full life-cycle implementations worldwide. William is a Southwest Entrepreneur of the Year finalist, a frequent best-practices judge, has authored hundreds of articles and white papers, and given hundreds of international keynotes and public seminars. His team's implementations from both IT and consultant positions have won Best Practices awards. He is a former IT Vice President of a Fortune company, a former software engineer, and holds an MBA. William is author of the book 90 Days to Success in Consulting. Contact William at wmcknight@mcknightcg.com.

Editor's Note: More articles and resources are available in William's BeyeNETWORK Expert Channel. Be sure to visit today!

Other than the fact that by the time I get to the word "service", half of the time I say "solution" instead of service, what about the viability of SAAS?

First, to levelset, SAAS refers to those set of solutions that are 'housed' offsite at the location of the vendor who actually developed the application. If a vendor is hosting all or most of a company's software, well beyond those applications which the vendor built, that is really an outsourcing relationship and falls under different rules. These 2 approaches are seldom compatible since the cost of applications to an outsourcing relationship is usually additive and efficiences are gained from having more applications at the outsourcer.

Back to SAAS, the 3 hallmarks or selling points are (1) no IT involvement, (2) pay-as-you-go with little upfront cost and (3) the vendor takes all responsibility for infrastructure and upgrades - those invasive and non-value-added activities. The perception of SAAS is lower costs, speed to market and no IT. Interest is growing across a range of applications at my clients and much of SAAS is designed to fit within a departmental budget.

Here are some rules of thumb for the consideration of SAAS solutions, BI or otherwise:

1. Check the value proposition of the application.

Of course, this applies to any application, SAAS or otherwise. However, it's worth mentioning that there should be some bottom-line business benefit at some level to actually doing the application in the first place.

2. Ensure scalability

I'm not referring to the expansion of disk, etc. That's assumed to be taken care of by the vendor. I'm referring to the ability to expand the core functionality of the application beyond the provided functionality, which becomes less interesting after the first 60 days.

3. Don't sabotage IT plans

IT may actually have a way to provide the business the functionality it needs at a lower cost and in a manner that is congruent with the direction of the core infrastructure of the company. Notice I say the functionality that the business needs - not exactly the functionality of the vendor product.

On the other hand, if IT wants the business, it should be continually performing top-down analysis of the technical environment and demonstrating progress towards the ability to support the business requirements. If there's no plan, the business is not sabotaging the plan, now are they?

At the end of the day, the general situation that SAAS seems to make the most sense is in an SMB shop when the data sources are somewhat standard (i.e., popular) and the data is not overly sensitive in an SMB shop. I am quite optimistic that SAAS will make numerous inroads in the coming years.

Technorati tags: software as a service, SAAS

Posted May 21, 2008 8:18 AM
Permalink | 2 Comments |


William, as usual, good sensible advice clearly written. I was with you until the last paragraph. Couldn't disagree more. There is no foundation for your claim that SMB's data is more standard and less sensitive. SMB's are where you find all the 2nd and 3rd tier solutions, technologies and packages, lots of "vertical" AS400 apps (they'd be vertical if they had more than 3 installations).

I don't think data is really the problem. If the op data is messed up, it's a mess for IT as much as for a SaaS solution, maybe more so.


Hi Neil and thanks for commenting. I am really suggesting everyone considering SAAS utilizing the 3 rules of thumb, regardless of their shop size. These 3 ROT happen to come together, in my opinion, mostly in SMB shops.

Scalability of function is less of an issue because there are fewer users and more (relatively speaking) straightforward business objectives. And therefore the value proposition for the SAAS application can be assessed more readily, whereas Fortune-level requirements tend to need to include many more personnel and tend to roll out over longer periods of time. When it’s harder to nail down the requirements, it’s harder to know if a SAAS solution meets them. Also IT plans are less developed in SMB shops and SMBs seem to have less IT per business user than Fortune companies in my observation.

The 2 criteria I was listing where it made the most sense were logically “under” the SMB umbrella. In other words, SMBs (who fit the first 3 criteria) and also do not have extreme uniqueness or extreme sensitivity about their data is a fit for SAAS. Yes, as you point out, there are some 2nd and 3rd tier software solutions found there, but sometimes these software have as many deployments as 1st tier software. Their revenues just do not add up to 1st tier. However, this does not make them any less standard.

If a shop truly has unique data and applications, it will want to think twice about SAAS.

According to Forrester, “In 2007 SaaS adoption in the US SMB sector jumped a remarkable 58%.” While market adoption does not nearly always imply sensibilities, in this case, SMBs continue to flock to SAAS (relatively speaking, per-capita-wise) at least sometimes for some of the reasons I mentioned.

Messed-up data can be a problem for any kind of solution and maybe another time I will come at this from the angle of best practices, which would definitely include clean, accessible, well-managed data and not depending on the vendor to make that happen for you.

It’s like I always say to my clients: “get the data act together first.”

Leave a comment


Search this blog
Categories ›
Archives ›
Recent Entries ›