How the Oracle acquisition of ATG effects retailers

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

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

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.

PR: wait... I: wait... L: wait... LD: wait... I: wait... wait... Rank: wait... Traffic: wait... Price: wait... C: wait...

The Offshore Myth

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

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

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?

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.