Guest View: The rise of the software-enabled business

By Jerry Smith

June 1, 2008 —

Marc Benioff, CEO of Salesforce.com, got it only partly right when he proclaimed the “end of software.” There is no question that software as a service is having a huge impact on the traditional software company. Yes, the old construct of license sales is being challenged; companies are seeing the value in maintenance contracts, and the upgrade and implementation costs are skyrocketing. In general, costs are rising and value is declining—two unfavorable trends for any business.

Indeed, there is a movement afoot in the industry, but it’s not simply a change in the way that companies procure software. The bigger trend is the increasing overlap between “software” and other products and services. Companies that you’d never think were in the software business are in it in a big way. News Corp.’s acquisition of YouTube is a prime example. And half the companies in the world are more worried about competing with Google than with their traditional competitors.

So it’s not the end; it’s the pervasiveness of software in just about every business that is the trend. Software is becoming more important than ever in delivering all manner of products and services. In short, it’s the rise of the software-enabled business (SWEB).

So, what exactly is a SWEB? It’s a new term for companies that don’t sell software in the traditional manner that an ISV does, but it still remains core to generating revenue from products and services. The software may be monetized by charging per transaction (Amazon, eBay BestBuy), through a subscription fee (Salesforce.com), via an advertising supported model (Google) or as a simple enabler of the business (e.g., a mobile banking platform) where revenues are not directly tied to usage. Rather, those revenues are part of enhancing the service delivery or improving customer acquisition/retention strategies (Charles Schwab, Bank of America, E-Trade).

Now you may put some of those companies into the SaaS category. But, as I heard recently, that may be the worst acronym that the software industry ever created, because it keeps everyone thinking about software only. The truth is that software may no longer be a market, but just a delivery mechanism. SWEB may be no better as an acronym, but it applies to a broader set of businesses. Many companies now believe they compete with Google, and they may not now nor ever have considered themselves a software company. But if they don’t start operating more like one, it could be their downfall.

SWEB solutions are composed of three core components: commercial-grade products, operations and continuity of operations (COOP). In addition to creating and maintaining effective products, software-enabled businesses need efficient operations to realize the value of the development investment. These companies are looking to efficiently operate the software they build, essentially “eating their own dog food.” It is not enough for the development team to produce a product with good-enough features along with acceptable performance, scalability and reliability. The product also must work within the defined business parameters of the company, designed for operability. This is a huge difference between developing software for an ISV and doing it for a SWEB.

But it is in the continuity of operations that real differences emerge between independent software vendors and software-enabled businesses. COOP is concerned with making sure essential business functions are performed in the face of catastrophic events. This function is actually dual: Prevent disruptions and respond to disruptive events when they occur.

On a COOP team, terms like “recovery time objective” and “recover point objective” are commonplace. But COOP involves more than just cobbling together pieces of a disaster-recovery solution. It affects the very fabric of how the product is created. Capabilities like disk-to-disk-to-disk replication and synchronous/asynchronous replications are enablers used to mitigate the disruptive impact of a disaster. From a product development perspective, it is therefore not enough to design around features or technical concepts, such as software-oriented architecture. One needs also to design for COOP and to implement the design.

The SWEB business is also different from an execution point of view. In traditional ISV operations, development operates incrementally to get the product right, while SWEB needs to execute so the product is never wrong. In today’s market, it is acceptable to release products that are both incomplete and with known types of bugs (none critical). The industry has developed a whole maintenance and sustenance program around the firm knowledge that we will need to fix the product after it has been released and improve it over time. However, when the revenue of your company flows directly through the operational product you built, this traditional point of view can be devastating.

So the SWEB is a pretty unusual, but nevertheless emerging, market. It not only needs to have the capabilities to produce great products on time and within budget, but also the additional capacity that enables the same organization to effectively use those products without fear of disruption. For most ISVs, this could mean more than 2.5 to 5 times the revenue for every dollar generated through traditional software sales. Something to think about, don’t you think?

Jerry Smith is CTO of Symphony Services, which offers outsourced software engineering services.

Related Search Term(s): SOA & SaaS

Share this link: http://www.sdtimes.com/link/32168

SOA Software releases project-planning suite for SOA transition Portfolio Manager provides a framework for SOA planning, helping developers prioritize services, understand dependencies, and plan architecture and governance processes, the company says. The product is marketed as being essential for creating road maps for transitioning to SOA.

SOA Watch: Best of times for SOA architects Even though economic times are tough right now, organizations are increasingly looking for SOA architects. Businesses looking to hire SOA architects should look for certain traits so that they pick someone actually proficient in the technology.

SOA Watch: Calculating the cost of SOA Figuring the cost of implementing a SOA can be a bit complex, but when you break it down into its components, you can come up with a reasonable figure. Remember to factor in an estimated ROI when you're trying to sell the business on adopting a SOA.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST