I Started a New Blog

I started another new blog. The Health Care IT Synthesis Project (http://healthtechsynthesis.wordpress.com/).

I swear this blog is not just about SaaS, but…

When I started this blog, my intention was NOT to cover only SaaS, but it has been top of mind lately.  I promise to work on some new topics, but I’d like to share a an ealier response I posted to an article by Peter Pearce. 

I think the whole SaaS movement sheds a lot of light on WHY we (in technology) do what we do, and should help drive better business systems and decisions in the future.

My main question for you is… how do your customers overcome the urge to customize to fit their business and or processes (when configuration alone won’t cut it)? And under SaaS have you seen different answers than you had under traditional COTS and ERP packages?

From my perspective, the canned answer (for any COTS, SaaS or not) should be… “we streamline our processes” and/or “we adapt to the best practices implemented by package”, but… I have yet to see a customer that followed through on that entirely (sometimes it seemed like for good reason).

On the surface, it seems logical NOT to customize, but at least some of the time the business asserts that its model or process is a true competitive advantage.

To try and answer my own question:

1: I assume those are just areas better suited to customized or “build” solutions, but those same enterprises probably have plenty of “industry standard” processes that would be great candidates to use packages or SaaS.

2: I think one of the beauties of SaaS is the growing selection of “reusable parts” that can be “composed” into very unique solutions for a business that should “feel custom” if nothing else….

That seems like a nice business to be in as a technology consultant come to think of it 😉

Is SaaS a disruptive innovation?

Software as a Service (or SaaS) is relatively new on the scene and rapidly gaining traction in the market.  I think it is safe to say that it is an innovation in the technology industry, but is it a disruptive or sustaining innovation?  In Clayton M. Christenson’s Innovator’s Solution, he draws a distinction between the two.  In a nutshell you can think of a disruptive innovation as having the power to displace more established competitors, and the potential for great profits, and a sustaining innovation as having the power to help an established firm maintain its current trajectory but not necessarily improve it.

The Innovator’s Solution uses a few litmus tests to tell whether the innovation is truly disruptive, namely:

·         Does the innovation make it easier for those who were previously non-consumers of a product or service to enter the market?

·         Is it price-competitive with established firms and can pick off less demanding customers at the lower end of the market?

If you read Gartner’s 2009 predictions about SaaS, a “Disruptive” diagnosis jumps off the page for at least the “low end”.  The first generations of SaaS applications are provided by smaller vendors, and they tend to be less complex in terms of the functionality they currently offer.  Gartner’s analysis shows two other telltale signs of a disruptive innovation:

1.       The established enterprise software firms (Oracle, SAP, Microsoft, etc) are economically incented to NOT offer a SaaS model to their customers at this time

2.       The “disruptive” entrants will be moving up market and  offering more substantial functionality (they actually predict functional equivalence by 2013)

Gartner does predict that by 2013, 7 of the top 10 SaaS offerings will be made by the established enterprise software players, but that still leaves 7 of the 10 slots for less established firms. 

The potential Long Tail market for SaaS should improve its disruptive potential.   

First, we have probably only scratched the surface in terms of the breadth of the typical enterprise application portfolio that has a SaaS offering.  Currently Customer Relationship Management (CRM), Human Resources, and Collaboration applications are SaaS strongholds, but there is room for growth into other enterprise applications such as finance and Enterprise Resource Planning (ERP).  There is also a huge set of industry specific or other niche solutions yet to be offered.   

Second, have the current set of SaaS vendors / solutions really reached low enough in to the “low end” of the enterprise software market?  How well have they done at creating an offering that they can earn new customers that have not previously used enterprise software?  I have personally heard anecdotes about companies who are customers of a CRM SaaS offering, yet maintain “prospects” in spreadsheets and other home grown systems until they become paying customers because the cost per “contact” is still too high for them.

In order to get a clearer vision for how “disruptive” or successful SaaS based solutions will become, there are some key questions left to answer that likely don’t have a single straightforward answer:

·         How easy is it to migrate from one proprietary SaaS based solution to another, or to an on-premise system?

o   To win over some of the most conservative enterprises, they will need assurances that they can get their data out of the system and are not locked in. 

o   This seems like a key feature that SaaS vendors should be competing over unless data standards already exist or are developed.

·         What kind of an innovation is SaaS for system integrators? 

o   On the surface, it seems like a good opportunity for sustaining innovation, but is it?

o   How well will the SaaS vendors partner with integrators as they grow?  Will there be an economic incentive for them to do so?

·         What are the financial accounting implications of investing in SaaS? 

o   I.e. How are the costs/capital expenses amortized for a pay as you go SaaS versus traditional enterprise software investments? Would this incent or dis-incent a company from using SaaS?

In summary, it is my opinion that the SaaS movement in general is clearly a disruptive one.  Some established players will eventually start to offer SaaS based solutions, but the economic temptation to fight this off in the short term will cost them.  Time will tell whether the new comers can continue to move up the value chain in the enterprise software market, and whether the incumbents have learned how to cope based on the history lessons that are out there from other markets that have already been changed by disruptive innovations.

Is SaaS the “Killer App” for Business Driven Development?

I was reading a blog post on Software as a Service (SaaS) by a colleague (Peter Pearce) the other day, and it struck me that there are profound positive impacts of this movement that are not yet being discussed in the Enterprise IT community.

The first thought that came to mind was that SaaS may be the “Killer App” that really forces the IT world into a Business Driven Development model once and for all. 

On the surface, there is the obvious advantage of a business not needing to understand the inner workings of the systems they are implementing, and the promised agility for the business are great.  But when I take a closer look at one of the SaaS vendors mentioned in Peter’s article (Work Day), I see a great new era for the IT Business Analyst and Solution Architect.

The reason I mention WorkDay is its emphasis on Object Oriented technology.  I know everyone wants to jump in to Service Orientation, but Object Orientation is an important stepping stone along the way in my opinion.  One of the main advantages of WorkDay is that its internal architecture has been started from scratch as an Object Oriented one.  While object oriented systems are not new by any means, most of the existing object oriented systems (client server, web based, or otherwise) rely on Relational databases like Oracle, MySql, MS SQL Server, etc. 

A lot of necessary, but complex and not exactly business oriented coding is required to translate between the Object oriented application and the Relational database.  Yes, it might save some coding work if we had an Object Oriented Database as well, but that is not the biggest benefit in my opinion.

The biggest benefit I see is to the analysis process, and the ability to focus on business processes and structures (that object orientation describes in a more logical way) as opposed to considering relational concepts such as data normalization, query performance, etc.  I have been in more than one JAD session where we “couldn’t” do X or Y because it broke a rigid relational data model, or worse yet, the technical team did not know what the implications of changing that model would be.

To prepare yourself for this wave, if you are an IT professional, but did not “grow up” as a Java, or C++ (and now C#) programmer (and I think this is pretty common these days), and you expect to be working with any Service Oriented systems going forward, I recommend getting up to speed on the basic concepts of Object Orientation first. 

The first book I’d recommend is The Object-Oriented Thought Process.  I like this one because the reason I am recommending you learn object orientation is to get you thinking about problems in terms of objects and interactions between them. 

The second is a more in depth “field manual”, The Object Primer by Scott Ambler (who happens to be big in the Agile community too in case you are also adopting or interested in Agile practices.  This one covers a lot of ground on how to apply Object Orientation, and how Object Orientation applies to other common activities in most SDLCs (software development lifecycles).

If you want to be effective at Business Driven Development, I think it is also important to educate your business customers in Object Oriented concepts as well if you will be doing serious requirements analysis or explaining the conceptual solution architecture to them.  For this, I personally have created some short slide presentations that borrow from the ideas in the two books above, as well as my own experience, but am not shy about resorting to a quick whiteboard session either. 

This is a balancing act, your customers don’t need to know everything about object orientation, but they should be able to understand the artifacts left behind by your analysis and have a rough understanding about the basic structure and complexity of a given solution.  This will help everyone to set more realistic expectations, and understand opportunities for future enhancements.