Category Archives: Enterprise

Every Enterprise IT Department is Like a Start-up – They Have the Same Challenges

I’ve been noticing a lot of comments on enterprise technology on Hacker News and elsewhere about it’s old, boring, and very easy to disrupt. I’d just like to clear the air about a few things.

First, the challenges of providing solutions to the enterprise business organizations are no different than the challenges any good business to consumer start-ups face. A couple of those being:

  1. What on earth is that the business actually want? How do we define? How long will it take? How much does it cost?
  2. Budgets, budgets, and budgets
  3. Security – the single greatest barrier to getting ANYTHING done technically in almost any environment. Imagine dealing with oAuth, but times 100.
  4. What interfaces are supported and connect to each other (Facebook’s API broken again??)

As probably most people would point out, no IT department can afford to house a development team with the likes of development talent at say Google, Facebook, Apple, etc. First, it’s not economically feasible. Second, it would be nearly impossible to attract that level of talent. Third, it’s not a reproducible process that can happen at every company.

So while we hear the massive failures about IT projects everyday, I would argue this is statistically (percentage wise) no different to millions of failing start-ups who don’t make it. This is another reason why many people choose to just use standardized (or “vanilla”) software and then customize it to suite specific business needs.

To take this a step further, I sometimes argue that any good project manager in enterprise IT consulting has the ability to be an entrepreneur. Therefore (like any good market), those that do have the capability to do so are more likely to leave IT consulting and start their own business. Thus reducing a large supply of good project managers.

I feel like I defend enterprise IT, and the reality is I’m not. I think we can do much in enterprise technology, but this requires a massive shift in thinking. Something we are still years away from.

How are we going to make Enterprise Cloud profitable?

The largest provider of enterprise software solutions, SAP, has made a bold statement on cloud. First it claims it will be the largest cloud provider in the world. Second it claims it will be the first large cloud provider to be profitable. Here is the article: SAP Sure of Profitability in Cloud Business – Co-CEO Snabe

I had a very open and honest conversation with an SAP Sales Director about this (who’s name will remain anonymous for obvious reasons) and he suspects that the Enterprise move to cloud will do a few things:

  • Expand the reach of software to encompass more markets
  • Reduce the cost of sale (or pay-per-sale) of new customers

Unfortunately these are based on two assumptions about cloud:

  1. Hardware costs are efficiently allocated. This means efficiencies in cost for servers, disaster recovery, network, infrastructure, etc. Amazon seems to be on the only ones who are doing this right and yet still have razor thin margins. I don’t see how this is reproducible model at Amazon’s scale and efficiency, while still competing with Amazon’s prices.
  2. The people developing the software continue to support the software going forward. Cloud isn’t just about economies of scale in hardware. We need to get our heads of the Industrial Revolution thinking – economies of scale aren’t possible with human information workers. Engineering software is not like engineering a kitchen cabinet. It’s a craft.

Remember enterprise licenses yield roughly a 90% profit margin on support and companies like SalesForce are still not profitable. A couple of scenarios I see playing out:

  • In order to get margins back in line with the previous ones the software will no longer be supported by the people who built the software. Customers will get disgusted with their poor support and just leave. This has happened in on-premise software, but the external exposure was mitigated by support teams (such as my previous role within SAP, where I served as a De-Escalation Architect).
  • Cost of sale must go down and therefore expensive middle-management (VPs mainly) will need to be cut out. Unfortunately this means large vendors such as SAP will have less clout when speaking it enterprise clients.

The challenges I see is that SAP is not following the Innovator’s Solution, which is to keep disruptive technology in isolation and are clearly they are trying to integrate it: SCN Blog – My Attempt to Explain SAPs Cloud Strategy  This would motivate a smaller company to keep better knowledge workers and build better efficiencies in hardware.

I still believe SAP should have invested (or outright bought) SalesForce half a decade ago, left it alone and then let it cannibalize itself.

The Cyclical Nature of the Hammer Industry

I love the hammer and nail analogy. Why? Because it’s so easy for people to understand what the purpose and role of a tool is. Sounds trivial, but I think it’s very hard for humans to separate the utility of the hammer, the carpenter and how these translate into the utility of the output of their work. It’s way too often we correlate the output of the tool simply with the features of the tool. The technology sector is rampart with this type of thinking. There are literrally millions billions of dollars spent every year on technology tools that we, as customers, believe are the sole reasons we either fail or achieve to “build our dream house”. Have we forgotten the importance and weight of the carpenter’s role?

Let’s say you decide one day you want to build a table. This table is going to be made using wood, nails and a hammer.  All things being equal, let’s say you build this table with hammer A that has a utility of 10. You build a second table with hammer B and it has a utility of 15. You, the carpenter, have now created two tables, table A and table B, respective to their hammers. The tables are identical, but the utility is different. Now let’s say your utility as a carpenter is 5 (we’ll call this carpenter ‘ME’). The value of the tables is now: Table A – 50 and Table B – 75. Now, my carpenter friend (we’ll call this carpenter ’FR’) has a utility of 4 and he builds the same tables using the same respective hammers. He now has two tables at the following values: Table A – 40 and Table B – 60. So we can build a simple comparative matrix now. Table B built by FR has a higher utility than Table A built by ME but it was built by a less skilled carpenter! We therefore logically assume the hammer is the key driver for the overall utility, not because it has a higher multiplier, but because we believe we have better ability over assessing what the utility of the hammer is. We then therefore place much more importance on it.

There is so much discussion about our tools being broken and I believe that statistically it’s the carpenter that is affecting the overall output. Unfortunately it’s much easier for us as humans to draw the simple conclusion – the tool is broken, update my tool.  Thus the hammer industry, or rather the technology tool industry, will continually go through cycles. New companies will be created year after year promising the dream house because you bought their shiny new hammer. I don’t doubt the necessity for these shiny new hammers, but I question how much weight we as humans put on them in order to create our dream house. Find a way for me to find a better carpenter, or fix the carpenter, and I’ll have my dream house…or maybe my dream table.

Innovator’s Dilemma at its Finest – SAP, Oracle, and the Cloud

I wrote previously about how disruptive technologies will save SAP. However, it’s worth understanding the large dilemma that SAP, and Oracle alike, are facing and why it’s important to understand how success is made with innovation. Let’s first start by stating the definition(s) of innovation as coined by Clay Christensen from the Innovator’s Dilemma.

Sustaining Innovations: What all sustaining technologies have in common is that they improve the performance of established products, along the dimensions of performance that mainstream customers in major markets have historically valued.

Disruptive Innovation: Disruptive technologies bring to a market a very different value proposition than had been available previously…Products based on disruptive technologies are typically cheaper, simpler, smaller, and, frequently, more convenient to use.

It’s clear – cloud computing has been disruptive to the enterprise space. As it’s popularity increases it will begin to “cross the chasm” and eventually become a clearly defined market. If you look at the early history of cloud computing (or actually really known as SaaS – Software as a Service) you’ll notice early adoption was quite low. No one understood why you would decide to use a CRM system hosted by someone else. Crazy right? It’s now starting to hit the bend in the hockey stick and is ripe for growth. In order to understand disruptive innovation, let’s look at first why this type of technology historically hasn’t been a sustaining innovation for Enterprise software houses:

  1. Both companies have not executed any real ability to create their own organic SaaS platform. SAP’s Business ByDesign has been around for about 5 years and hasn’t turned the corner yet.  I believe the reason for ByDesign’s failures were largely due to adding too many features too soon, and not really understanding how companies would use the technology. Yes, what I’m saying is that they tried too hard to create a product.
  2. SAP recently bought SuccessFactors for $3.4bn and Oracle has now bought both Taleo and RightNow.
  3. Cloud/SaaS solutions have done nothing to improve the performance of any existing technologies in the markets that SAP and Oracle have traditionally served, which is mainly large enterprise using on-premise software. In fact SaaS is about to eat their lunch.

Now let’s lay out why cloud is so disruptive:

  1. There is a different value proposition (hosted software, maintained by the vendor)
  2. It’s cheaper (straight forward subscription model), simpler (doesn’t require an army of consultants), and more convenient to use (have a web browser on your computer?)
  3. SAP is hurrying to use it’s RDS (Rapid Deployment Solutions) to combat and milk it’s existing on-premise software while it can
  4. SAP and Oracle make a staggering 90% profit margin on enterprise support. Even more interestingly, SAP is now trying to tell the market that they will be the first company to make the cloud profitable. I’m confused as to what core competency SAP possesses that will make that true. Throwing money at a problem doesn’t increase a profit margin.

Ultimately, I’m scared largely for SAP, and less scared for Oracle. Why? First, SAP is really damn good at selling on-premise software. This is one of the most important aspects of Clay Christensen’s theory on innovation. The firms that are most successful at sustaining innovation are also the least likely to succeed in disruptive innovation. Second, from my talks with sales/pre-sales/etc people at Oracle, their products largely operate in silos and tend to compete with each other. Yes, this already happens between Hyperion, JD Edwards, PeopleSoft, etc. So culturally they will embrace an internally competing technology much easier than SAP can.

On a somewhat related note, Mike Eacrett, VP of HANA Product Management in SAP Labs, talks about thinnovator’s dilemma for SAP HANA:

“We’re trying to manage disruption,” said Mike Eacrett, vice president of product management for SAP HANA at SAP Labs in Palo Alto, Calif. “It’s the innovator’s dilemma,” Eacrett said, “figuring out how to take advantage of new opportunities while managing change.”

I’m not so worried about the success of SAP HANA because the product was built largely out of a group within SAP (and from the Hasso Platner Institute) that has been known to be very autonomous from the rest of the business. This is exactly what Clay Christensen offers as a solution to the Innovator’s Dilemma – an autonomous group that acts solely without discretion of the overall firm. It could theoretically be seen as a sustained innovation in that is improves performance on an existing and established market (databases). The big question will be: if cloud consumes on-premise software, than where will HANA sit?

The truth is, SAP is in an identity crisis. It’s largely been seen as an organically growing giant. It’s now spent nearly $10bn+ over the last half decade on acquisitions and it simply cannot be the organic juggernaut it once was. This is largely due to the externally facing pressure from disruptive technologies. What’s worse is it still boasts it’s ability to innovate using its €1.7bn cost (2010) on R&D as justification. Again, the firms that are so certain about growing their portfolio of sustaining technologies in an existing market are largely in a worse position to support disruptive technology.

So what’s the solution? Simple. Well, simple for me to articulate, but not simple for SAP and Oracle to execute. As Christensen says:

“Survival depends on being able to disrupt yourself. Once you let others disrupt your business, you are heading down the path to death.”

In other words, SAP’s cloud computing division (led by Lars Dalgaard) has to aggressively compete against SAP’s own on-premise software. It has to act completely autonomously. Dalgaard is a visionary with some quirky and non-traditional management practices. Which is why I think he’s perfectly suited to lead the charge. But will SAP’s top Executives give in to the Street and become another software graveyard or take a short term hit for long term growth?

What do you think? I’m interested to hear others’ opinions on this.

EDIT: Changed some sentence structure in the second to last paragraph. Didn’t make sense before. EDIT2: Changed to ByDesign, not ByDemand. Good thing I don’t get paid to be a full time editor. 

What’s happening to the next generation of the SAP ecosystem?

It seems obvious to me that the ecosystem of SAP is aging. I’d love to be told wrong, but I just don’t see much evidence of it. Where the heck are all of the young guns? Why is Silicon Valley kicking ass with talent straight out of school? There are CEO’s and CTO’s who are 23, just graduated, and solving real world business problems. Where are these guys in the SAP ecosystem?

Over at Bluefin, John Appleby was touting an incoming graduate application base of nearly 2000 graduates interested in getting into the SAP ecosystem. Despite this I get the impression that the highest skilled graduates are not trying to get into SAP’s ecosystem. (note – no discredit to Bluefin – 2000 applicants is unprecedented and surely they will find some top level talent in a pool that large) They’re still going to banking and now with the crazy valuations in Silicon Valley, they’re going to San Fran.

My personal opinion:

1. SAP is not sexy. ABAP is not sexy.
I just read this article (the article itself is kind of terrible): Tech Leaders Don’t Win By Saying They’ll Crush Somebody. The author mentions the following tech companies “Apple, Oracle, Microsoft, AOL, HP, Palm” as “Tech Leaders”. Yet, no mention of SAP? This is not new. Before the crazy marketing buzz that is HANA, when was the last time you read a tech blog talking about the technological excitement around SAP? The problem here isn’t SAP, but rather that enterprise business software is not sexy. It also doesn’t help that if you read the wikipedia article on ABAP one of the first thing it mentions is: The syntax is somewhat similar to COBOL.

2. Big data is sexy. Ruby on Rails is sexy.
Today, big data is about petabytes of data, not terabytes. In 2008 Facebook had 2-3 TB of photo data uploaded every day. I too lazy to research what it is now, but I think you can speculate. I’ve worked with multiple TB in-memory systems in SAP – they’re fun, challenging, and usually raise some eyebrows when you tell someone about them. However, they are peanuts compared to the servers and data Amazon and Google are working with. Where exactly is the data explosion in the enterprise? The younger generation likes these challenges and they like frameworks (like RoR) that easy to use and well documented – tools that make talented individuals deadly.

3. No openness
Do you know why it’s possible for someone like Zuckerberg to start a multi-billion dollar business or for Mark Bao to start up multiple companies by the age of 18? It’s because they could go learn something new very rapidly and implement it very rapidly with very low costs. SAP – not a chance in hell. And what’s worse is that even areas like mobility where this should be possible today, SAP is now asking for licences for doing the trial of SAP Unwired Platform. Yes, the trial. It’s well documented and well known that collaborative communities lead to innovation. I wish SAP was more open to this. Sorry, but SDN doesn’t cut it for me. SAP certifications and trainings are great, but as it stands right now nothing beats hands-on experience. I think the fact that a majority of the SAP mentors are not certified is anecdotal evidence alone.

The Potential Issue
So who are filling these jobs and why is this important? It’s obvious there is a continued trend to ship everything overseas. This means nearsourcing has less importance, less emphasis and will drive everything in SAP to become commoditized. This will lead to less innovation and less support for real technological innovation. Who the heck is going to implement HANA? India? Good luck with that one. SAP – you need partners and you need their help. I know it sounds radical, but why not deliver HANA to partners under a “AS-IS” warranty and let me us go wild implementing it on Mac-Mini’s, Amazon servers, or whatever? Let us build it, break it, hate it, destroy it. You thank us later when we can give valuable feedback. Face it, SAP technology is not vastly superior in a technical sense, nor does it have to be. It’s purpose to help business to be better at what they do – and it does. It has a robust ecosystem, with robust controls and a great customer base. But please if you want the ecosystem to support disruptive innovation be more open and you’ll get the forward looking talent needed to support. Otherwise companies will continue to ship it overseas and the aging population of techies in the SAP ecosystem will become managers. Then who’s left? The SAP ecosystem needs techies and the techies are hiding under a little rock called the university.