Monthly Archives: June 2014

SaaS Represents the Commoditization of Business Function

North Bridge in partnership with GigaOm Research released their 2014 Future of Cloud Computing – 4th Annual Survey Results. As you examine the 124 slides, one thing is obvious that the greatest growth in cloud computing is coming from Software-as-a-Service (SaaS). Market research like this is very important because it provides tangible proof for our anecdotal hypotheses. That said, the report does not extrapolate what is the most interesting facet of SaaS hyper growth—59% in three years—the model for commoditization of business function is market validated.

Like all things that get commoditized, differentiation or uniqueness that keeps economic value high becomes less important than the common, undifferentiated features driving costs down. The interesting thing is that lower costs is a side-effect of commoditization as commoditization can only occur when businesses identify that they can achieve the same goals with the commodity item as they can with the unique one. Hence, businesses are speaking with their dollars and telling the market, we’ve figured out how we can operate our businesses equally well using this less complex, highly-configurable SaaS version as we can your expensive, monolithic, high-overhead, licensed version of this business function.

Maybe you’ve all figured this out already and I’m late to the game, but it’s definitely an “A-ha” moment for me. It’s easy, as demonstrated by the aforementioned report, to get caught up in the fact that cloud computing is having a disruptive impact on both the buy- and sell-side of the IT marketplace. However, for many, there is a belief that the costs, complexity, and delivery capabilities of internal IT have been the drivers for SaaS massive and rapid growth.

However, based on recent conversations with IT executives, I’ve come to the realization that businesses are willing to pay the high costs associated with enterprise applications if they deliver value. Thus, in order for SaaS to be growing at the pace it’s growing and seeing the increasing number of enterprise deployments, businesses have to be able to achieve an overall subset of functionality in an equivalent manner. Hence, the SaaS effect we’re seeing in the market has more to do with SaaS vendors hitting the sweet spot regarding commodity business functions and less to do with businesses’ frustrations with their own internal IT or agility alone. Moreover, this should be a clear message to startup SaaS companies, if you do not properly commoditize the right business function or enough of it, chances are your SaaS application will not see the success of those like Salesforce.com, Workday and others.

It’s A Multi-Vendor Cloud World

Experts say that cloud computing is disruptive and then continue on to discuss how the cloud quickly enables innovation while competition between cloud service providers drive costs down. Both of these scenarios are accurate, but the disruption from cloud has additional shockwaves that only now beginning to be felt. Hardware and software vendors are starting to show signs of wear on their revenue streams due to cloud. Eventually, that wave will begin to impact the ecosystems that includes Value-Added Resellers and professional services firms that implement the products for those vendors. Sometime between these two points another wave of disruption will begin to take hold; the move to multi-vendor solutions.

Multi-vendor solutions have been in place for some time, but typically as an additive effect versus subtractive. For example, a large enterprise will contract with both AT&T and Verizon for telecommunications services to ensure that there’s always one operational path available for transmission of data. The thing that makes the multi-vendor cloud different is the tearing down of the functional barriers of the single in-house managed enterprise applications from a single vendor into a combination of Software-as-a-Service (SaaS) and custom applications running on different cloud service provider’s platforms.

None of this is news, of course, it is the focus of many discussions around the emergence of SaaS. The element that is news here is that this effect is now starting to impact the channel partners for the large enterprise applications’ vendors. The IT professional services firms that grew up around deploying solutions like Oracle E-Business Suite, SAP, Peoplesoft, JD Edwards, etc. continued to see a consistent flow of work regardless that this new cloud platform was emerging around them. Many of these firms may even have been aware of what was occurring, but stymied to do anything about it due to the speed at which solutions have been taking hold.

Competing in the cloud market is significantly more difficult. It’s not enough to have one or two competencies in order to provide a solution. Now professional services firms need to have competency in three or four SaaS platforms, data management and integration. Businesses want to use Workday for Human Resources related activities, Salesforce.com for customer facing activities and Netsuite for financial accounting. Rapidly waning is the appetite of businesses to sustain a one and a half to two year development effort to deliver a consolidated platform. Moreover, recently promoted executive managers have some element of information systems training as part of their education making it difficult to convince them that they need a lot of custom business processes to operate their business. Indeed, they have learned that complexity has a high cost to maintain, operate and audit.

Further complicating this change, the vendors themselves are realizing that they need to transform or die. Hence, many of them are attempting to shift as quickly as possible to provide specialized SaaS applications. As much as they realize the devastating results of doing so, this means that the big enterprise application vendors will eventually begin to cannibalize their own channel. Ultimately, same type of work that used to be required to deploy a multi-module enterprise application is just not required on the SaaS alternatives. Thus, professional services that thrived and were successful being a prized channel partner had better start buddying up to emerging SaaS vendors and learning about IaaS and PaaS if they intend to survive.

The long-term implications of cloud disruption on this aspect of the business are astounding and there has been little discussion in the media or by analysts. Not only does cloud have the capability to reshape enterprise IT, it will have terraforming effects on the entire IT vendor solution ecosystem.

Excuse Me Ms. Shannon-Solomon, But DevOps Is Great For Enterprises

On May 13th, Rachel Shannon-Solomon wrote an opinion piece in the Wall Street Journal’s CIO Journal section entitled “DevOps Is Great for Startups, but for Enterprises It Won’t Work-Yet.” In this piece, Ms. Shannon-Solomon implies that DevOps—a loosely-defined IT initiative oriented toward creating higher quality and more resilient systems—currently faces too many hurdles to see broad-spectrum adoption. Unfortunately, this assertion is incorrect and based on some rudimentary mistakes individuals make about what defines DevOps and what is required to be successful with DevOps adoption.

First, I will address Ms. Shannon-Solomon’s premise and then propose alternative thinking from other industries that will work well for enterprises. Ms. Shannon-Solomon’s initial point that silod-structures and organizational change are necessary to institute DevOps is an area of debate and contention among many leading the DevOps charge. There is an entire school of DevOps influencers that do not believe silos are the enemy and, indeed, serve a purpose in large IT organizations for ensuring focus and a level of specialization needed to ensure that the prime operational mission—keeping the systems available and secure—is met. The issue Ms. Shannon-Solomon uncovered relates to organizations that have been indoctrinated into the school of thought that DevOps requires cultural change. One of her later points in the piece explicitly states that the hurdle many DevOps tools vendors are running into is related to attempts to sell this cultural revolution.

This entire line of thinking is spurred by the perspective that DevOps fosters greater collaboration between various facets of IT that need to work more closely to ensure successful completion of the tasks. Moreover, the cultural change is not revolutionary, but evolutionary, with regard to instituting accountability for the availability and security of the corporate assets across all of IT. The outcome being reduced finger-pointing, reduced outages and faster recovery times in cases where outages do occur (and they will).

Ms. Shannon-Solomon’s points around build vs. buy illustrates another common misunderstanding regarding DevOps, which is that tools are an essential element of adoption. It is true that a key element of DevOps is automation as it provides consistency and reduces configuration drift—the issue where application and infrastructure configuration changes are instituted with loose control leading, a leading cause of outages—and increases productivity through the reduction of time spent on repetitive tasks. However, there are a bevy of tools already deployed in enterprise environments that can be used to drive an end-to-end design-build-test-stage-deploy-operate process. Indeed, I, and other DevOps throught-leaders, have indicated caution with regard to tools adoption around DevOps as it can lead to new IT silos and a significant increase in code and scripts that require their own architecture and maintenance lifecycles.

Finally, with regard to her point about return on investment, Ms. Shannon-Solomon addresses, anecdotally, one aspect of the DevOps process focused on engineering and development. Specifically, she addresses a lack of ROI with regard to agile development projects, when it’s important to examine and measure impact on all facets of application delivery including those that touch security, network operations, data center operations and help desk, as would be expected of an effective enterprise DevOps strategy. However, the real value to any business in successfully adopting DevOps is the increase in focus on depleting backlog and supporting innovation that is currently lost to just keeping the lights on. As with cloud computing, the greatest value proposition to the business is increased agility.

Where I agree with Ms. Shannon-Solomon is that the same tactics used to institute DevOps in a startup will not work in an enterprise setting. These are very different environments with extremely different goals and requirements. She is correct in her assessment of enterprise as resistant to change and stymied by organizational structure. However, requiring a “rip-n-replace” approach has never been popular in enterprise settings and tearing down the silos to gain efficiencies or achieve IT modernization are simply utopian follies.

Interestingly, an answer to this problem domain can be found in military strategy. Armies are simply a group of individualized regiments each with a specific responsibility toward an overarching mission. Within each regiment, the commanding officers institute rules and procedures based on military guidelines and the specific situation on the ground. Each regiment carries out its assignment based on a specific timeline as part of a bigger plan that leads to completion of a whole mission. In this scenario, DevOps comprises the military guidelines plus the individual commander’s input.

The real hurdle that lies in front of enterprises is the lack of well-understood missions as defined by the executive office. Often when speaking with IT management I will ask, what are the top 3 initiatives of the CIO and CEO for this year and next. Quite often, the answer to this question is unknown or unclear. In some cases, they just haven’t been clearly laid out by the CEO, in other cases, the information does not get disseminated beyond a certain point of management. In lieu of of mission directives, the regiments will aimlessly execute the last known set of tasks. To those who have experience in enterprise IT organizations, this can easily be translated into, “because it’s the way we’ve always done it!,” which is a curse of death for adoption of well-intentioned DevOps initiatives.

Ms. Shannon-Solomon’s perspective is greatly skewed by her association with those attempting to sell DevOps; those is attempt to implement change through the introduction of new tools and cultural revolution. This approach is akin to Woodstock. It produced great music, raised awareness of what was happening in Vietnam, but did little to dramatically change the lives of the majority of individuals living in the United States. Impact on the scale of the enterprise occurs through accountability, incentive, and management directives. The cultural change is one of constant improvement. DevOps initiatives approached with this as a goal and following something akin to the regiment model can achieve great strides in delivering on the larger mission and obtaining the known benefits of agility.