Software as a Service Simplified

How the Oracle acquisition of ATG effects retailers

2010-11-02T13:06:00.000-07:00

It's an interesting play for both Oracle and ATG. The market for ecommerce software is extremely fragmented. The small, on-demand players like Big Commerce, Volusion and Shopify are making headway at the lowest ends of the market for two reasons. First, they are cheap and easy to use and second, they can continue to move upstream in both price and functionality without cannibalizing their own business model. From the top end, companies like ATG, GSI and Demandware have always had a lot of trouble moving downstream because once there is a sunk cost in the development, they have a hard time maintaining their prices for their higher end clients while pretty much giving the same functionality away to lower end clients.

Where we have specialized is in this intersection between Enterprise customers and really flexible mash-ups of lower cost technologies that can provide powerful capabilities to Enterprise customers but have to be created and positioned in a way that they become digestible by a larger Enterprise customer.

We are seeing many of our potential large customers considering Magento for their front end web application but then having to do a lot of thinking about how to integrate that successfully with their back-end SAP systems or other legacy ERP or fulfillment systems. In addition, many have made investments in development platforms like Drupal over the last few years for their flexible, CMS based web presences but aren't quite sure how that will work with their ecommerce driven sites and things like Ubercart just don't pass the smell test.

The merger between Oracle and ATG will have the immediate effect of driving that solution even farther upstream. It will become more comprehensive but less nimble. Companies already on the Enterprise Oracle infrastructure or running on ATG will definitely benefit if the have those kind of integration issues but everyone else will probably hesitate. That solution becomes more complex, not less and at least in the short term, certainly less flexible.

We still believe that for most enterprises, the mash-up is the way to go and have developed programs and methodologies that make sure the best of breed point solutions can be integrated in a way that fits into a long-term, Enterprise IT plan while at the same time, if flexible and iterative in the deployment and feedback processes.

I don't think that the competition needs to really worry about a significantly wider adoption for the mid or even high mid market of the combined Oracle/ATG solution but larger enterprises who are already customers of either one and want to either expand into ecommerce or integrate supply chain into their ecommerce solution stand the chance of benefitting greatly.

Magento

2010-10-14T09:04:00.000-07:00

SaaS Accelerator has created a new partnership with Magento where we are going to focus on recommending and using the Magento Enterprise platform for our storefront development. We have found that Magento provides an extremely flexible platform at the same time it provides some of the key functionality that our Enterprise customers demand.

We love the flexibility of the product catalog, the ability to have different store views and the out-of-the-box multi-language and multi-currency capability.

Given we have worked with many of the leading On-Demand and On-Premise systems, we feel we have a great perspective on this technology and Magento is best in breed in a lot of areas.

We are working with partners to make sure that the integration of Magento into back-end, drop ship, fulfillment and warehouse technologies to deliver a complete system. In addition, we are working with some of our demand generation partners to make sure that the stores are able to fully support SEO, SEM, affiliate and social media marketing campaigns.

Check back soon to hear more about this exciting new partnership.

Building on the Past

2009-11-03T05:40:00.000-08:00

A unique aspect of SaaS development that is difficult to get into people's minds during a sales process is the usefulness of building on top of a refined platform.

Most enterprise SaaS apps need customization. I was recently in a sales situation where I was competing against a ground up development shop. I assume they were very good at what they did.

When the prospective client asked me why he should go with a SaaS based mash-up rather than a ground up development I was in the embarrassing position of admitting that all software development is pretty bad out of the gate. That no matter what, you are going to start off in rev. 1 and 2 with lots of bugs that are either in the requirements or the implementation.

In my 25 years in the industry, I have seen little progress in this area. All software has bugs but new software has lots of bugs. That's why cobbling together different mature SaaS platforms makes a lot of sense.

Our strategy is to take one or more existing SaaS platforms or services and limit the customizations to our own SaaS servers that have the effect of bringing the platforms and services together in an integrated and unified end-user application.

Yes, this means we write new code and yes, it has bugs in it in rev 1 and 2. Most often these are requirement bugs. The client didn't know what they didn't know and need to make post launch revisions. To be fair, there are also implementation bugs. By doing everything we can to reduce the new lines of code created, we end up reducing these implementation bugs dramatically.

We build upon the past and still support an entirely SaaS model. That's why we think this will be the model of the future and I hope I will never have to do any ground up development again.

The Offshore Myth

2009-10-08T04:26:00.000-07:00

The argument about whether off-shore or near-shore programming works is one that is being fought in a 20th century paradigm. At SaaS Acclerator, we have moved away from caring where in the world a particular developer is and toward rewarding them for the excellence of their work and collaboration.

At SaaS, we currently have developers in India, Pakistan, Argentina and in the US in California and Arizona. Some are in intact teams. Some are individual contributors but none work in a central office.

I remember at one point I worked in a company where the CEO thought that if he didn't see the people working, they weren't. At SaaS, we only hire people who are so passionate about their work that we can't stop them from working, even if we wanted to.

This people policy mirrors our development methodology. If the code exists that we need in a robust SaaS platform anywhere in the world, we won't build the code. We search out best in breed technologies and leverage them for our clients.

At the same time, we hedge our bets with indirection layers and service level integrations that mean we can swap our almost any component of our solution without service interruption. This is also true of our developers. We have them write code, in such a way, that another qualified programmer can pick it up and run with it.

The key to our success here is the "master programmer" model. We hire both master programmers and entry level programmers but the master programmer, not the project manager, decides how a specific software development task is parceled to their group. Our entire goal here is to support the productivity of the master programmer since for whatever reason, they pump out 4-5x more code than their counterparts on the team.

So, in the end, we have a distributed people model that mirrors our distributed solution integration methodology. We have found that this dramatically reduces overall costs to everyone while maintaining the excellence of the work product. It's a global world and we want to position us and our clients squarely in the middle of the innovation revolution.

Near Shore and SaaS

2009-10-05T15:00:00.000-07:00

SaaS is about driving down the TCO of applications. There has always been this issue related to SaaS applications. How do you customize it as quickly and as inexpensively as possible?

In the long run, the innovations that are shared reduce the cost to each party but how do you reduce the cost of customizations? How do you speed them given the inherent tension that exists when the SaaS vendor wants slow, incremental change to the platform and customers want rapid evolution of their capabilities?

The answer lies in three areas: Sound SOA in the platform, a robust customization architecture that is supported by off platform services and servers and near-shore development to reduce development costs.

1. Sound SOA practices: SOA has a lot of meanings but the simplest explantion is that the platform is architected in such a way as to provide services to the outside world through defined interfaces. For instance, an ecommerce platform might have a "payment" service that it exposes so that it allows people to create their own services to different payment gateways. The platform never changes but clients can extend the platform. Without this, no SaaS platform will survive for very long.

2. Customization Architecture: Our clients are not willing to wait for their enhancements while a SaaS platform vendor decides whether or not to create a customization for them in the platform. At SaaS Accelerator, we rely on a software/hardware architecture that allows us to create applications and services, host them on our own servers and have them seamlessly interact with the SaaS platform. This allows for rapid deployment, unlimited customization and avoids the biggest pitfall of SaaS: non-sharable customizations adding so much complexity to the platform that the entire thing grinds to a halt.

3. Near shore development: Off shore development is find but near shore is always better. Time zones make a difference. Having real-time access to your team is important. Cultures make a difference. Groups that are more similar work together better. I can't tell you how many times cultural differences have hurt projects we have worked on. It is worth admitting that development will be eternal and reducing the costs of that part of the equation is as much an operational expenses as is the fee for the servers.

Through these three key concepts, mature organizations can leverage SaaS platforms, reduce their TCO and reduce their development expenses, thus driving even more efficiency from their IT systems. They have to be willing to throw out some bureaucracy but that's a small price to pay for this kind of cost savings.

On Demand and SaaS

2008-08-04T13:28:00.000-07:00

by Thomas Moewe
Managing Consultant

The concept of On Demand is often found surrounding the topic of SaaS. Recently I've found myself in several discussions regarding the two concepts, how they are similar and whether it is correct that they be tightly coupled.

I spent much of the last decade with IBM, who is responsible for much of today's vision behind the On Demand Enterprise. Similarly, IBM put much of the marketing muscle behind the concept of eBusiness in the 1990's. I've found that looking at the similarities between On Demand and eBusiness is a good way to understand how SaaS relates to On Demand.

SaaS is to On Demand as eCommerce was to eBusiness. That is, SaaS in itself does not deliver the On Demand Enterprise, just as eCommerce in itself did not deliver the vision behind eBusiness.

SaaS is an enabler of the On Demand Enterprise and a key step in the direction of realizing its' promise. As an organization embraces the concept of the On Demand Enterprise by investing in SaaS solutions, it is critical to take a holistic view of the enterprise to understand where SaaS fits and avoid building what we call SaaS stovepipes.

SaaS Accelerator's strategic consulting practice takes our clients through a 6-10 week process to look holistically at the enterprise from a business and technology perspective to create a multi-phased roadmap for realizing the On Demand Enterprise. By understanding the desired capabilities of the business and the underlying architecture to deliver the capabilities, the roadmap helps client to make better informed investments and avoid short-term technology decisions.

Are services part of SaaS?

2008-07-27T21:56:00.000-07:00

by Arthur Lawida

Managing Partner

Once you get past a simple SaaS application and into a broader SaaS Solution, it quickly becomes clear that software as a service is not enough. Often, people decide on SaaS Solutions because they do not have (or want) the in-house expertise to run all or part of their technology deployment. Just as often, they want to outsource all or part of their business operations as well.

This makes a great case for service companies like SaaS Accelerator getting involved to deliver needed services within the SaaS solutions they deliver.

As an example, one of the focus areas for our company is eCommerce. Ecommerce solutions delivered on a SaaS platform like Vcommerce often require several other applications to fit the requirements of an enterprise solution. Search, analytics and customer relationship management are all often required to be integrated into the platform to meet the client's business requirements.

From a services perspective there are several areas of engagement that should be considered to assist a client with a complete solution. Customer service, online marketing, product merchandising, merchant accounts, and supplier selection are all areas that we have seen client's need assistance.

The interesting question is where does the responsibility (and opportunity) for finding and recommending these services lie? Certainly, part of the responsibility lies with the SaaS vendor, especially if they are either early in their development efforts or fielding a Platform as a Service. In the end the business responsibility is with the client but we believe there is a significant opportunity for services companies in this space. Unlike the SaaS vendor, service companies have a core competency in the delivery of services and have the capability and opportunity to develop and deliver true services around each SaaS solution mash-up. If a services company focuses on delivering all of the services around a particular SaaS solution, the upside becomes a deep and integrated knowledge of that solution area leading to more value for the client.

Teamed with the client and the SaaS vendor, these services start to make a more compelling case enterprises to consider an enterprise SaaS solution because they can solve both their technology and business challenges in one package.

SaaS Knowledge Innovation

2008-07-11T23:39:00.000-07:00

by Arthur Lawida
Managing Partner

At first glance, companies usually consider SaaS solutions in order to reduce implementation and operational costs. The TCO of a SaaS solution should be less because the core operational costs are spread across all of the tenants.

While this alone is a very good reason to consider a SaaS solution, I think the best reason for a company to consider SaaS has more to do with leveraging the shared innovation that becomes inherent in the solution over time.

At one level, this innovation is in the technology. When tenants ask for enhancements to the core technology, all can benefit and share the costs. When a client asks for a core enhancement, the SaaS vendor must analyze the usefulness to the other tenants. Depending upon the result of this analysis, the cost to the client who requests the customization can range from the entire cost, if it is not likely to be a shared innovation, to completely free if the SaaS vendor feels the innovation will significantly enhance their core offering. In all cases, this ends up in a negotiation based upon functionality delivered, time to delivery and cost.

What is often overlooked by the market is the deep knowledge and wisdom that becomes collected at the SasS vendor across both vertical and horizontal markets served by their solution. This experience can be an extremely valuable asset to a new tenant, especially if they are entering a new business area or sales channel.

Whether it is an eCommerce solution or an HR solution, the SaaS vendor is likely to have seen practices develop over time that it can share with the new client in a way that does not violate the confidentiality of the other tenants. This kind of knowledge, gained from actual operating experience, means each new client doesn’t have to make the same mistakes everyone else made and over time will become a vital differentiator between SaaS vendors and premise based solutions. The key is that unlike traditional software companies, SaaS vendors must operate their client’s businesses and this provides a significantly faster feedback mechanism to drive further innovation into the shared platform.

Can SaaS even have a methodology?

2008-06-18T11:18:00.000-07:00

By Arthur Lawida, Managing Partner
SaaS Accelerator

A couple of weeks ago, I was reading several blogs about SaaS where they claimed that the move to SaaS was very similar to the move to client server technology in the 90’s. The claim was that you could not have a SaaS methodology. They said that having a SaaS methodology was comparable to having a “client server” or “mainframe” development methodology and just didn’t make sense without being tied to a particular application.

I think that misses a major point of cloud computing. SaaS means that “software” is fundamentally replaced by “service”. SaaS is not a software deployment model; it is a fundamental shift in the way we think about providing business solutions.

One of the key differentiators between mainframe and client server technologies, and today’s cloud technologies, is that control of the application has become increasingly difficult. In a cloud or SaaS model, an application is no longer highly centralized (mainframe) or tiered (client server). It has the capability to be fully distributed. Depending upon the requirements and the capabilities of the software vendor, these application parts can be customized, semi customized or not customized and each one can be premise based, on-demand or fully SaaS.

What this means is that in order for an enterprise to deploy a SaaS based application today that maximizes the potential of the cloud, even more rigorous planning must be applied up front. Some of this planning tracks with traditional development methodologies but some of it is new. Here are some thoughts on the “new” areas that we have designed into our methodology:

1. Security: When dealing with sensitive data, how do you insure that the cloud is secure? In ecommerce applications and medical applications there are security standards. If one of the software providers has the appropriate certifications, is that enough?

2. Requirements Analysis: Usually business requirements are prioritized on the basis of their value to the business. In a cloud model, another aspect must be analyzed. Customizing SaaS applications is not straightforward. Each requirement must be assessed in terms of its ability to be customized by the SaaS vendor providing that service.

3. Application partitioning: What parts go where in the cloud? What functions are business critical? Disaster planning takes on a whole new aspect when you have to worry about not just the technical infrastructure but the financial health of each participant of the SaaS application. If they go out of business, what are your recovery options?

4. Indirection layers: To support the above requirement, what data and application indirection layers need to be created by the enterprise so that a particular software service of the cloud can be easily replaced by another service if the original service becomes unavailable?

5. Quality Assurance: QA, especially integration and system testing, must take on the role of becoming knowledgeable and proficient in testing disparate software services.

6. Operations: How does the enterprise provide things like uptime guarantees, training, support and user documentation for an application spread among several service providers?

To summarize, I think there are a core set of issues that make a SaaS deployment methodology useful regardless of the application. Our methodology works to mitigate risk and increase the chances that the enterprise will be happy with the result.

SaaS is not just another software deployment architecture. It is much more like the move from structure programming to object oriented programming except at a meta-level. More to come on that point because I have found a lot of thinking has gone on around service oriented architectures at the single service level but I cannot find much that views entire applications as a services linked together to create a business solution.

SaaS Customizations: The 500 pound Needle in the Haystack

2008-06-04T09:39:00.000-07:00

By David Ebel, Principal Consultant
SaaS Accelerator

When embarking on Software as a Service implementation projects, few things are more underestimated than the solution customizations which will be required to make the final product suit the enterprise operation. In my experience the scoping of solution customizations is the most critical aspect of a SaaS project.

Solution customizations are the project aspects most likely to cause delays in launch and budget-exceeding costs. Moreover, many customizations are required for launch and can hold up the entire effort if they are not properly identified and scoped early on. Your best bet is to rely on your internal staff or a hired expert to assist in determining your SaaS customization needs prior to beginning the implementation of your project.

What commonly goes wrong?

Fundamentally, SaaS providers have made a bet that their solution will work for a broad spectrum of a specific market and that customizations will be brief and superficial. Unfortunately as the role of these applications becomes more core to enterprise organizations, the critical customizations required are much more than simple bullet points on a project plan template.

In many cases clients are trusting that the solution provider will come to understand their business and have the time and expertise to make the "out of the box" solution fit their business needs. This expectation can be costly to the client, since solution customizations are not commonly core to a SaaS company's business model.

To resolve this issue it is important that the client project leads:

Thoroughly review the “out of the box” functionality the SaaS solution contains
Identify gaps that will need to be met with vendor or client hosted customizations
Thoroughly describe the details of these requirements prior to project start

Once this is completed, the vendor can be held accountable to meeting the requirements outlined by the client, according to a mutually agreed upon time frame.

Taking the responsibility of determining solution gaps away from the vendor and giving it to an experienced independent client advocate is an excellent way to improve the project scoping process. Simply put, it stops the dependence on the SaaS vendor to provide critical project requirements in an area where they are reasonably not equipped to be the expert. After all, no one understands your business like you do.

The 500 pound needle in the haystack is not impossible to find or manage properly. It takes focus, experience, and decisive action to ensure that a SaaS project is scoped thoroughly and customizations are accurately identified early on. Once this often overlooked concern is addressed, the project can be brilliantly handled so that everyone will be celebrating the launch right on time and within budget.

Enterprise SaaS Solutions: A different animal

2008-06-02T15:10:00.000-07:00

By Arthur Lawida, Managing Partner
SaaS Accelerator

Enterprise SaaS Solutions are not the same as traditional SaaS applications. Initially, companies like salesforce.com delivered lightweight, single use applications in an on-demand model. These applications were barely customizable and extremely difficult to integrate with other enterprise level applications or within the enterprise information architecture.

SaaS applications have been moving upstream for the past couple of years into departmental and even enterprise wide solutions that are being customized to meet specific business requirements and fit within the enterprise architecture.

The traditional benefits of SaaS include:

Easier, faster and (hopefully) cheaper deployment.
More efficient and less costly management and operation.
Leveraging innovation investment across multiple enterprises.

The major downside is that since true SaaS Solutions exist in a multi-tenant (shared) environment, customizations are more difficult and the speed that those customizations can be delivered are often lengthened. Even if it is informal, negotiations must go on about every customization requested to see if it would be valuable to the other tenants and against all of the other customizations being delivered on the platform.

The tension between these competing desires (customization vs. SaaS benefits) is where every enterprise and SaaS vendor have their biggest deployment "discussions".

A specific methodology has to be employed that matches the enterprise requirements against the strengths and weaknesses of the SaaS application to find the optimal solution that leverages the benefits of the SaaS application and does not degrade the usefulness of the solution to the enterprise. After all, if the enterprise is talking to a SaaS vendor at all, they have probably already chosen it over a custom solution and know there will be tradeoffs. The key is getting the SaaS solution provide to understand the client's business and the client to understand the SaaS solution enough to reach the right compromises before deployment requirements are finalized.