Move, Adapt, or Die

Change is eternal in life, nature, business, and technology and you only have 3 options:  1) Adapt; 2) Move, or 3) Die.  I learned this truism in my 7th grade from my social studies class regarding animals response to ecological change, but the same is true for changes in our business environment.  The technology environment has forever been changed by CLOUD (IaaS, PaaS, and SaaS).  The software business and the systems integration (SI) will never be the same and is now presented with 3 simple options: 1) Adapt; 2) Move, or 3) Die.

As humans, especially business people, engineers, etc. who populate a lot of technology field, we believe we can overcome or stem the tide.  While this may work for short term or against small storms of change, it will not defeat real, substantial change any more than you can push back on walls of water from hurricanes.

IBM recognizes the power and importance of Cloud, even if it got off to slow start. Look at the emphasis. Less than 10% of IBM’s revenue is now from hardware. At the same time, everything from IBM is now on the cloud. IBM is even beating back its latest foe – Amazon Web Services (AWS). IBM Beats Amazon In 12-Month Cloud Revenue, $15.1 Billion To $14.5 Billion.

SAP has made a massive shift around SaaS and is adapting.  In 2013, Jon Reed, noted that even SAP executives would love to go on selling traditional on-premise perpetual licenses when he paraphrases the executive with ‘Hey, if we could continue to sell software to customers the way we’ve sold it to them for the last 40 years, we would. But they want new options.’  (more from Jon Reed’s Diginomica blog). Fast forward to 2016 and about 80% of SAP’s revenue is from 4 acquired SaaS products: SuccessFactors, Fieldglass, Concur, and Ariba. If SAP could figure out S/4 HANA cloud, they might even become a dominant SaaS ERP player.

Cloud and specifically SaaS to the software industry is a category 5 hurricane force of change driving a wall of water.  Remember when virtualization was only for non-proction. Now, most systems depend on virtualization.

Moving and adapting take time. So while almost everything will go cloud, it will take time. It will have to make IT and financial sense to move. The argument that some applications will not run well on the cloud will be a moot point when they are rewritten for the cloud.

The hurricane of cloud  in all forms is coming here. What are you doing to make sure your ready to move or adapt (and not die).


Please STOP using meaningless terms for cloud like Private, Public, and Hybrid

There are 2 dimensions that have meaning when discussing cloud solutions and the terms public, private, and hybrid contains too many overlaps and ambiguity.  Is a cloud private if it is hosted?  Is a cloud public because I access it over the internet and does that mean my corporate data center accessed via VPN is public?  Worse, the term Hybrid Cloud gets bounced around so many different ways that is no longer relevant at all.   I could have SAP ERP and SuccessFactors  or SAP ERP production in a corporate data center and the non-production SAP ERP systems on a IaaS cloud provider such as IBM’s SmartCloud IaaS  or it could mean I do some ERP functions on SAP ERP on premise and some using SAP Business-by-Design (BbyD) or on NetSuite ERP.   In the end, it only means  is I’m using more than one type of solution.

There are meaningful dimensions to describing cloud solutions.  The two (2) dimensions that matter are: 1) location, and 2) separation.

First is location.  Where is the solution residing?  Is it on my premise, site or facility that I own or at least consider part of my corporate network of locations.  Alternatively, is it away from the bulk of my IT assets such  that I need a WAN to access it.  For clients with highly distributed data centers this becomes a moot point since everything connects over the WAN; however, most clients have consolidated their corporate application and data centers into just a few locations.  IBM runs its corporate business in just a few data centers with SAP in just 2 of them globally.

Second is separation.  What separates the resources.  Are the solution resources separated by physical boundaries such as server, application, or database or is the solution separated by layers of software?

The trend is clearly towards SaaS where location is off premise and all the infrastructure and application components of the solution are software separated.  In a SaaS solution, it is clear you are using the SaaS providers data center of choice and not your own.  You also are accepting that the secured division of servers, network, and storage.  Even more importantly, you are accepting that your data in flight (within the application) and at rest is kept secured and separated from others including your competitor.  I have seen numerous cases where direct competitors use the same SaaS solution.  In fact, most SaaS providers count on competitors using their application to scale since you can’t build a SaaS business on single client.  Clearly, we do believe in software separation has come of age.

Software divided applications and infrastructure is becoming a the rule.  If you want to take the software divided and secured environment on premise, IBM calls it Software Defined Environment (SDE) ().  Another major player, VMware, calls it Software Defined Data Center (SDDC).  Regardless, each is an attempt to virtualize the infrastructure for more effective use of all assets.  This is good for both cost savings and for agility.  Deploying virtual infrastructure is far faster than physical.  Often clients think the value of the business case is in the cost savings, but ultimately it is found in the agility that translate into real application and business value.

So, next time someone comes to you with a hosted semi-private cloud infrastructure offering with hybrid capabilities, just ask them 2 questions.  Where is the solution residing?  What is separating the infrastructure and applications?  Concise answers will reveal a lot about the solution and you’ll have more time to do something beautiful like grow your hybrid tea roses and find PEACE.

More acceleration for your on-premise ERP program with SaaS

Rather than considering SaaS the enemy of on-premise ERP, consider how you can leverage its capabilities to consolidate, optimize, and simplify your on-premise ERP systems to achieve a better, faster, more agile result.  On-premise ERP  is not going away tomorrow, at least if you run it well and provide the required agility to the business and SaaS can help.  The key is providing the right services levels across the entire environment.

In my last blog, 2-tier ERP: A cure for the smaller markets in a global implementation, I discussed how you can use a SaaS based ERP implementation to eliminate some of complexity of the implementing simpler, smaller markets.  The focus was geographic or unit based.  Similar logic can be applied to functionality.  Some Line-of-Business (LOB) applications and/ Human Capital Management (HCM) / Human Resources (HR) functions can also be pulled into SaaS.  The result is even more acceleration of your overall program.

Most of my clients are either using or reviewing the use of SAP SuccessFactors, SAP Ariba, and SalesForce as SaaS based LOB’s.  These 3 SaaS solutions show up repetitively at many SAP clients.  I am well aware SAP has CRM and even a CRM RDS (Rapid Deployment Solution) on cloud, including IBM’s SmartCloud and even CRM capability in Business-ByDesign, but SalesForce is dominant in the market and needs to be considered.  Clearly there all alternatives to these 3 SaaS solutions in the market.  I use them as examples and your company needs be responsible and do a comprehensive review of each area to find the exact solutions that best fit your company.  I’ll simply use these as common examples.

The idea is if you can remove the scope of configuring SRM with Ariba, most HR / HCM scope with SuccessFactors, and CRM scope with SalesForce, the reduction in scope in the core and plus making them parallel projects can enable the overall implementation to move far faster and introduce some heavily requested mobile capability.

erp - using SaaS functions

In addition, by using SaaS based products you can potentially lower costs of procurement, implementation, and support.  You definitely can accelerate the roll-out of these functions and bring significant mobile capability to business in these areas which might help your business case by bringing benefits earlier.  These 3 areas are especially important since the touch so many individuals with mobile roles.

By design, every SaaS program I’ve seen is heavily mobile enabled.  Mobile and cloud are ideally suited for each other.  The more recent thought process of agility and velocity drives a simpler and more targeted design for most SaaS solutions.  The SaaS thought process better fits the minimalist mobile screens than the idea of highly optimized processes found in most core on-premise ERP systems.  Cloud serves mobile well since it is equidistant to all devices.  Mobile devices are not clustered like terminals around headquarters based system which up until recent was the assumption for on-premise ERP.

Even if the SaaS implementation is a wash on cost, the acceleration of delivery and the enhanced mobile capabilities may push the business case over the goal line.  Keep in mind that the mobile applications are native to most SaaS applications so you don’t have to build up a support staff to maintain the mobile interfaces like with many ERP add-on products.  They are as native as browser support is in SAP ERP.  You still will need to manage devices and may even want to build, but the native mobile capability will lessen your IT support burden.

SaaS is not a panacea.  For companies who require extremely high complexity or significant optimization of processes, it may not meet their requirements.  If your company is sensitive to OpEx over CapEx (utilities generally prefer CapEx for IT) then SaaS may not be a good solution.  Finally, SaaS applications require integration, most likely you require some optimization (custom functions), and require good project management, organization change, communication, and training which is not significantly different with SaaS than with on-premise based implementations.  Maybe a simpler program can demand less of these soft skill deliverables, but it is not the “SaaS” that changes the effort.

In your next transformation program you should consider the use of SaaS based applications to remove scope, increase velocity and agility, reduce the overall program timeline, accelerate benefits, and potentially lower total costs.

In my next blog, I’ll examine how this idea can be applied to an existing SAP landscape requiring renovation, optimization, or simplification.

2-tier ERP: A cure for the smaller markets in a global implementation

Many companies over-engineer, over-build, and spend too much for ERP as they begin to implement smaller markets where the needs are relatively simple when they try to shoehorn them into the larger global ERP system.  Even after implementation, the smaller “units” often find it difficult to get their requirements met as they account for such a small percentage (%) of revenue.  One of the biggest hassles in SAP is security and separation of duty (SOD) which often requires smaller offices with just a few workers to have special profiles, multiple login’s, or some special process to fit into the bigger office process.  There needs to be a better way to meet the requirements of highly optimized larger markets with large work forces and smaller, simpler, and more fickle markets with smaller work forces.  A 2-tier ERP solution might be the cure.

Up to now, companies have spent billions on  ERP implementations resulting in significant results.  Specifically for SAP, many of the fortune 100 companies I work with credit some portion of their ability to keep up, survive, and some cases surpass their competitors to their SAP systems.  The most successful implement SAP using standardized processes, strong governance, and fewer, and fewer instances.  Companies with lots of instances often ask me what is the right number of instances.  It is the fewest number of instances which can meet your business requirements.  Not 1, 2, or any specific number, but the fewest.  Each company has to look at its own situation, goals, and markets; however, I believe implementing a cloud based ERP (SaaS) such as Business ByDesign ( can make implementing or getting to “fewer” much more possible and ultimately better meet the requirements of all parties unilaterally.

In the examples below, the imaginary company has about 80 divisions, units, or countries (depends on how the company organizes and implements) it wants to implement.  A rough cut of revenue shows that 65% resides in top 10 and additional 25% in next group of 10 (11 – 20).  The last group of 60 only account for about 10% of revenue.  While this is fictional, it is a composite many of my experiences in the real world.  We often spend as much, or more, getting the last 60 units into core instance.

All in one ERP model
All in one ERP model

If we recognize that the goal of the fewer or even a global single instance is not simply being on one system, but to have consistent, audit-able processes globally, a new option opens up using a 2-tier ERP model.  Bottom line is in many of these smaller units, often countries, the objective is really to make sure the financial results are valid and that ultimately the CFO can count on them when he reports out to Wall Street.  Getting everything into single SAP system was the best way, and in some scenarios still may be the best way, but it might pay to look at a SaaS based ERP solution as shown below.

Two Tier (2-tier) ERP model
Two Tier (2-tier) ERP model

Often I’m asked, why not just take one of our ERP systems and make it the “light” ERP system and we can even place it on the cloud (IaaS/PaaS).  It does work, but it misses many of the advantages of moving to SaaS.  It is a good option if those other units require lots of optimization.  In contrast the SaaS option will provide a more generic solution focused at smaller organizations with shorter implementation periods, mobile enabled GUI, and pricing by user which may match the more volatile small unit markets where staffing may quickly shift up or down.  Finally, if you are already on SAP ERP, there are significant integration between SAP ERP and Busines ByDesign pre-built with new ones being rolled out in future versions.

I will continue to encourage clients to move to the fewest number of instances which can meet their business requirements.  Adding a SaaS based ERP system such as Business ByDesign could make that journey even simpler and faster.

SAP HANA MCOD – What I really want for my data center

The real SAP game changer will be when I have one (1) HANA DB for all my production applications.  I want single, giant in-memory DB where my ECC, BW, CRM, PLM, SCM, BOBJ, etc. all consume the same data.  I want a row  view for the OLTP ECC-like applications and column view for OLAP BW-like applications.  It would look like the picture below.

sap hana mcod system
What we really need from SAP! The SAP HANA MCOD system.

Right now, I can’t really recommend using HANA on anything but OLAP based applications.  In the future, when we can do the analytic transformations in memory without silly exports, extractors, DSO’s and the like, we will really have a very* different scenario.  For now, the cost of the HANA license and risk of losing transactions only committed to memory is not justifiable.

In this new vision with MCOD, there will be two (2) key issues.  First, how do we support MCOD.  I’ve seen MCOD come and go since 1993 several times. Each time, it was easy to build and impossible to support.  The overlapping requirements became overwhelming. Second, HANA will need a data aging architecture which can age data out of main memory to some slightly slower memory or device.

IBM is working on some important technology, Phase Change Memory, that will be of great value (   It may provide the near DRAM speeds while being cost effective and non-volatile.  Maybe IBM will build out series of servers specifically designed to run in-memory databases such as HANA with massive DRAM and massive PCM capacities.  PCM could then provide the roll-back logs and more at near DRAM speeds. PCM won’t solve the MCOD and data aging problems, but at least the risk of running rapidly transacting OLTP systems would go to near zero and certainly lower than that of even today’s highly cached disk writing databases.

It is going to be a fun watching HANA make it from infancy to toddler-hood.  I wonder how fast she’ll mature.

* Mark Twain said every time a writer was tempted to use “very” in a sentence, they should use the word “damn” and then the editor would strike the word and the sentence would read as it should.


Watching with pride and envy and gratitude

When I came to IBM, I said one of my aspirations was to help someone reach a Sr. VP in IBM.  I don’t mean promote them, but I mean be part of their path.  We all work in web of influence.  Helping others mature along their paths and achieve to their highest levels is critical.

At the same time, it can mean promoting people to your level or above.  It is impossible to not feel a twinge of jealousy.  For me, I have to acknowledge this, but then move on.  Good news is I think I got close.

My dear friend, colleague, and now Sr. VP Vijay at SAP has made it.  In all honesty, I had very little nothing to do with it.  Maybe an encouraging word or a bit of advice, but it was Vijay’s work ethic, willingness to take chances, and positive bright outlook on life, technology, and people that got him to this level.

It is not anyone, but all of these combined that has brought him success.  At a large client, he took on the latest Netweaver features when everyone including me said they wouldn’t work.  When they didn’t, he didn’t stop.  He just got some help from SAP establishing a relationship with those in SAP and then succeeded.  Later he turned his gregarious nature, sharp mind, and experience into a blog.  At the point he entered the digital public domain, there were very few and no real IBM policy.  Vijay has lead the way.

In the end, I think I gained the most.  I learned to take a more positive attitude and avoid my darker side.  I moved my blogging from inside IBM and inside of SAP, to this forum.  While I don’t expect to gather the response that Vijay’s blog gathers, it has been a learning experience for me.

Now that I have a colleague who made it to SVP in SAP; I’ll have to find someone to work with to make SVP in IBM.  And let me challenge you, who are you helping move their career and life forward?  I think you’ll find you get as much, or more than you give.