Cross posted from my blog at the SAP Community Network.

I’m one of the few people in the cloud marketing team at SAP who’s been involved in supporting nearly all categories of SAP’s cloud offerings in the last couple of years: from virtualization and public cloud support to the software service offerings to our platform service offerings. These different offerings can help you migrate your on premise SAP software into cloud environments, deliver configured software as a service via the web, and develop and deliver custom software in the cloud. Which you might choose boils down to whether you want to retrofit what you have, take new capabilities via the Web, or need to build your own solution. I’ve commented on these as components of a cloud program extensively in my blog series “Turning Cloudy Chaos into an IT Strategy – Part I.” Part II, and Part III. For an excellent discussion of IT as a Service, see SAP Mentor Sina Moatamed’s blog “The Era of Demand Supply IT Begins”.

If Wine Making Were Like IT

If you read my recent Blog It Forward blog, you’ll know that I’m an amateur wine maker. I’m also a user of Wine making as a Service (WMaaS) offerings. Ok, that sounds really geeky, but I do find an analogy in how I engage in my hobby and how customers use the various cloud services I’m in charge of marketing at SAP – we marketing people think in analogies all the time.

When I first started wine making I did it in house. In the analogy, this would be the equivalent to writing my own software and deploying it to servers I manage in a server room. I literally implemented my own winery in my garage with hardware I purchased and leased – fermented the grapes in a primary fermenter, pressed them, racked the wine into 5 gallon glass storage containers, and let them bulk age in storage in my garage until it was time to bottle some number of months later.

My former garage winery – table is the winery lab, to the right are 5 gallon glass jars of chardonnay and petite syrah in bulk aging. [Source – © Greg Chase, under creative commons license, use w/ attribution]

The goals you or your business are trying to achieve should dictate whether it makes sense to hire a service, do a job yourself, or architect some hybrid combination of the two. If my goal was to have great wine at a great price, then Wine as a Service would have made a lot more efficient sense. In fact, I do have a couple of subscriptions to wineries that send wine to my house. No, in this case, my goal was to learn the craft, as much as I could, and have the pride of wine that I made that I could share with friends. Back to our analogy: if getting access to a standard, configurable transactional system is your company’s goal, then a SaaS solution that meets your requirements should do just fine. If you have unique needs, or a business goal for creating a competitive advantage, then you may need to bring your service in house, or architect a series of finer-grained services into a solution.

Virtual Wineries and Virtual Data Centers

Now in the case of running my winery, availability of my labor and appropriate facilities (environmental stability, access to water and sewer) are the limiting factors. As a side note, even though I had initially started with my own winery on premise, I still used some Wine Making as a Service offerings. In this case, I used Peter Brehm who helped me source grapes and crush them. His service specializes in creating smaller lots out of large purchases. If creating a unique advantage in my wine making was a goal, then one potential area of innovation would be to seek exclusive sources of grapes that other winemakers could not obtain.

Now as requirements shift, so might the services you choose. In my second year of wine making, I started attending SAP TechEd in the fall, which unfortunately falls squarely in harvest season. That year I had to add another Wine Making as a Service of Peter Brehm’s which is to freeze small lots of grape must if you are not available to pick up at harvest. This essentially allowed me to postpone fermentation a week or two after harvest. It had some impacts, but I can’t be sure whether it affected the final quality of the wine vintage that year.

The following year, I moved to a new place, which lacked appropriate space for wine making. Now here’s where it get’s interesting. How do I continue to do wine making when I can’t have a winery on premise? Recently I found a local winery that provides custom wine maker services. I can engage them to do some or all of the wine making chores such as the twice daily punch downs of cap of grape skins that forms during fermentation, and the significant amount of cleaning of equipment and storage tanks that makes up most of the labor. In addition, I gain access to high end hardware and expertise that I normally could only afford if I was a commercial wine maker (or willing to spend even more money).

Wine making as part of the Bacchus Wine Making Club at Dominico Winery. Dominico Winery’s wine maker, Dominick Chirichillo, is the person on the far right of the wine press. [Source: © Greg Chase, under Creative Commons License, use with attribution]

Here comes the analogy again – in a sense, this winery is a lot like a wine making platform as a service, allowing me to focus on the parts of the product that let me achieve my unique goal. From an IT perspective, a Platform as a Service provider handles much of the operational chores of managing software stacks for development environments and cloud-based customer deployment, allowing software developers to focus on creating and deploying their software to customers. Such a service level makes sense if you have integration or application-level features in mind that can provide your company a competitive advantage, or, if you work for a software company to develop a software service with your unique features.

There are cases, however, when you want even finer grained control, when the unique differentiation you are trying to achieve lies in deeper usage of technology. As I had mentioned earlier in wine making, this differentiation can occur in the sourcing of grapes. This can also occur later in the wine making process in terms of decisions such as deciding whether to filter or fine the wine, age with oak, or blend it with other wines. In the case of the Bacchus Wine Making Club, if I wanted to have much more control over the source of grapes, or which wines I blend with, it’s likely I would have to negotiate a different arrangement, such as operating as a virtual winery. In the extreme case, I literally would use their space and some or all of their equipment, and could produce wine for sale under my own label (future retirement job maybe?). As an example of a similar case, see NPR Market Place’s recent podcast about nano breweries.

How Fine-Grained Do You Need Your Cloud Services To Be?

There are similar cases in software cloud services. Two come to mind. First is the case of retrofitting on premise systems such as SAP ERP with cloud technology. One reason to choose more of a do-it-yourself approach to retrofit your ERP system instead of moving to a SaaS solution is that you’ve already invested a lot to customize the system to meet your unique requirements. This can make sense if you foresee the system having many years of useful life if you increase operating efficiency and agility of system changes by putting your system onto cloud technology.

A second case is in when you want to take advantage of fine grained optimizations of a technology such as the ability of a software application to radically speed up real time queries on large databases through stored procedures in SAP HANA. Running such a system on premise or in your private cloud will give you this degree of control.

If you are looking for the efficiency and agility of a cloud offering, then SAP HANA One running within a public cloud such as Amazon Web Services might be a good fit. A public cloud instance of SAP HANA One gives you freedom to leverage all the capabilities of SAP HANA including the database accessible via JDBC and ODBC, and development with SAP HANA Studio. SAP HANA One runs on an AWS EC2 cluster computer 8XL instance with 16 cores (32 logical cores) in an elastic, metered basis. Since it is your own system, as opposed to a shared service such as you might find in SAP NetWeaver Cloud’s HANA-based persistence service, you have complete freedom to manage it and tweak it as you see fit. Of course it also means that you are responsible for administering and maintaining the software.

The choice depends on your use case and business model. Some use cases we are seeing today for SAP HANA One on AWS include:

The SAP HANA One service is brand new, and is currently running SAP HANA SPS4. Enhanced management capabilities, improved customer experiences, and new capabilities of SAP HANA SPS5 itself will be brought online in an agile fashion. Expect the use case list to expand significantly as the utility of the platform improves.

Try out SAP HANA One on AWS in a test drive yourself. Take advantage of a $25 AWS credit available for a limited time to do your own development work. Share your own use case ideas with the SAP HANA Community.