Where does IBM go from here ?


As always – all of this is just my personal opinion here .

As a former IBMer, I was absolutely delighted to see that the IBM CEO finally said last week that the company is letting go of its 2015 EPS strategy. The best time to do that was the day she took over as CEO, but better late than never.

It was a ridiculous goal to begin with. The board and the previous CEO Sam Palmisano did not set Ginnie and the company up for success with this EPS of $20 by 2015 goal. I don’t know too many employees or executives in the company that truly believed this goal was achievable. IBM is like the military in many senses – it is a command and control style organization. So when the marching orders came, people shook their heads and then dutifully went out to try their best to make it happen. If there was a corporate equivalent of a death march – this would surely have made the shortlist.

There are only three ways in general to boost EPS

1. Cut cost
2. Increase revenue
3. Buy back shares

IBM tried as hard as they could on 1 and 3, but doesn’t look like they did much on 2.

For sure – IBM has a LOT of management overhead. Between all the companies I have worked for and have consulted to – I don’t think there is a more matrix management oriented company than IBM. When I had my first quota carrying role at IBM, I remember five or ten people (most of them I did not know ) would check in to see if I am on track to close a given deal. Most of them just managed spreadsheets . This is just the sales side of the equation. Similar kind of overlay functions existed in every part of IBM. So, yes – Sam absolutely was right in assuming that he can cost cut his way to EPS nirvana just by firing people if nothing else worked .

Unfortunately – that is not what happened, at least as far as I know. The top heavy organization more or less continued to exist – probably because they were the decision makers. Instead the people who got cut were the ones who were paid a lot less, and who actually had skills to do actual work. Well eventually some of the top management also got their pink slips – but more of a too little too late case.

The double whammy of a result is there for all of us to see – revenue going down all the time for last several quarters and then later profit stopping to go up .

IBM did try to buy back shares as a way to boost EPS . (IBM also pays a good dividend every quarter ). It helped for a while – but then that is the money that did not get spent on buying companies or reinvesting back in its own business . This is money that could have resulted in new revenue , but that is not the path IBM took. I don’t have the exact math – but I think IBM spent probably four or five times the money they spent on M&A on share buy backs .

So now what is next ? How will IBM regain its glory ? Here are a few thoughts that I wish IBM Management will consider

1. Minimize the management over head . There is absolutely no way to justify 10 people checking in on every deal .

2. Sell off aggressively every part of the business that is low value . I would start with hardware and consulting – both have low value parts . What is low value for IBM might actually be what another company might need to grow . Like say consulting – there are multiple indian outsourcers who might do well to buy parts of IBM services business to move up their value chain

3. Bring back “respect for the individual” as a core value . Start treating employees on par with the customers and shareholders . Employees are the ones who need the most attention now . Take care of them , and they will take care of customers better . And that will take care of shareholders a lot better over the long term than buying back shares . It’s the sustainable model unlike the last attempt

4. IBM has an amazing leadership training program – I know that first hand . And it has more leadership bench than most of its peers . What is missing is that such enablement is not there lower down the ranks . If IBM needs to be a powerhouse in IT again – the customer facing organization needs the kid of leadership training and attention that executive ranks get .

5. Put the best sales and technical teams possible on cloud , big data and Watson . There are plenty of good people in IBM who could be retrained on these areas. And there are experts who can be – and need to be – hired . For existing business, automate everything repeatable like crazy . Make delivery excellence truly mean customer success as much as profitability .

6. Set realistic expectations with employees , customers and the street . Set stretch goals – IBMers can meet and exceed stretch goals . Just don’t venture again to the realm of impossible targets .

Despite all its current troubles – I am still an optimist on IBM returning to its past glory . There are three things that make me an optimist on IBM’s future

1. IBMers – past and present – are a special breed . I have all the confidence that the good people left in the company are as good as any in the industry to make the turn around possible

2. IBM has a brand value that opens doors at customers across the globe . IBM needs that brand to sell more cloud , Watson and bigdata solutions to customers .

3. Through thick and thin, IBM has invested billions of dollars on research . The time to plant a shade tree was in the past and IBM got that right big time . That has already paid back IBM many times in past and I am fully confident that it will continue to do so .

As they say , Once and IBMer , ALWAYS an IBMer !

Logo changes


Yesterday someone mentioned that SAP changed its logo again . Dennis Howlett even posted a blog saying he loved it . http://diginomica.com/2014/10/22/digibyte-new-gold-sap-logo/

Den says the logo looks masculine , gold is an unusual color (to me it looks like an orange not gold ) and will get more attention and that the cross bar of A looks more like a smilie now . I don’t disagree with any of that

What I don’t understand is – what is the outcome SAP expects from this logo change ? Will it make more customers click on SAP digital content? Will there be more leads for SAP ? How does this change connect to Bill’s theme of simple ?

Logo does look beautiful and I want to congratulate its designer . Personally I preferred the old Blue , but that is just my taste . But I have no idea how it adds value to SAP or its customers . Would be great if a marketing expert could explain it . I am not saying this is a bad logo – just that it has picked my curiosity seriously . It’s a non trivial undertaking for a company like sap to roll out a new logo . I am just looking to understand the rationale of doing this .

Geeks , Suits and Their Database Choices


Who chooses the database for an application? how do those decisions get made in a company ? Is it a suit or a geek or both ?

Conventional wisdom says geeks are the best qualified to decide on a database, and suits are better for selecting applications – especially packaged applications. I think the conventional wisdom is still largely true – but would add that suits have a more important role to play in selecting a database today than say a decade ago.

Say, there is a conversation happening between a suit and a geek about budgeting for building a custom order management application . And to get to my point quickly (?) – lets say the last remaining question on the table is which database to buy. Since it is a technical decision, the suit is mostly looking at the geek to start the thought process.

BEGINNING OF THE FICTIONAL STORY

The geek says – “well, it is a transactional application – so unfortunately we cannot consider these modern technologies like MongoDB which are not ACID. We should consider one of the traditional relational databases.”

Suit asks “what does that mean in terms of time and money?”

Geek : “Oh these things are expensive. Think big $$. We probably need to nail down schema design and put some strong change control in place for the project.  Once we start development, schema changes will set us back big time in schedule. Probably best to stick to a waterfall methodology. On the bright side – there are plenty of people who know this technology, and there are many tools and utilities to manage it”

Suit asks ” err…as you know, we don’t exactly know what to expect from customers since it is a brand new market. Can we deploy quickly and then change as we learn more?”

Geek : “I hear you – and if it was not a transactional system, I could have saved you a lot of time and money by choosing something way more agile and less expensive like MongoDB. See for order management transactions, you need this thing we geeks call ACID. We get that only with these expensive relational systems which have been around for decades. We have done a lot of these projects on relational . With some good project management discipline – we can deliver the first code drop on the date we planned even if we have to do it in a waterfall and not agile as methodology. But the iterations you want as we learn more – well that might be the thing that is not easy to accomplish. Once we nail down a schema , and we learn months later that we need to change it, it is not very easy to change in short time”

Suit : ” ok got it – not ideal, but then if you tell me there is no other way then we should go with your recommendation. Lets revise our business plan to make it realistic with what technology can do”.

Geek : “ok – looks like we have a plan. I will call a few vendors and get quotes and will work on a project plan”.

THE END !

These kind of conversations happen all the time in enterprises around the world – I have participated in many of these as a suit and as a geek. Neither the suit nor the geek said anything wrong in this fictional conversation above. However what is interesting is what they DID NOT say – and those nuances could have completely changed the climax of this story, and maybe in some cases saved the business a lot of time and money.

Taking MongoDB itself as an example – it is not correct to say “its a modern NoSQL database, and it is not ACID”. MongoDB is ACID within a document . And a document can be quite rich in what data it holds. An order – something that in the relational world is made of a header table, and item table, a schedule lines table, and many master data tables for holding names and addresses and so on – can be held in one document, mapping to one object in the application program. Documents can be nested too . So while MongoDB is not ACID across an entire big sharded cluster – not many apps really need it to do so either. If the application needs multi-step complex transactions – by all means consider a relational DB for persistence, but if not – there is usually a way to make it work nicely in a non-relational DB too (often with nice side benefits like scaling horizontally and keeping data well organized for access using geo tagging, as is the case with MongoDB).

The big questions that were missed in the fictional story above are specific details around business priorities and business logic. Lets consider the simplest case of any order management system – making sure that orders match quantity of finished goods available for sale. It is totally possible that there is only one widget to sell and two customers see it on their screens and want to buy it .

The geek might want the database to make sure only that one customer gets to buy the widget – and the other customer should get an error on his screen. And hence the geek might make a recommendation that a relational DB with fully ACID functionality is the right persistence layer for this scenario.

However – the Suit might think rather differently from the geek, if only someone asked him !

Case 1:

I always want my customers to place an order, even if there is an out of stock possibility. In case I don’t have stock for that customer – I can find it from somewhere else. Or I can make it up to him with a discount for something else. By keeping the customer happy – I have higher chances of getting repeat business. Maybe he was planning to buy this widget and a necklace for his wife – if I did not let him order the widget, he might have probably been annoyed enough to not order the necklace either which is more profitable for me.

What is a big priority for me is to make sure I get this app online at the earliest and keep tweaking it till I get it right. I also want to make sure the user gets extremely good response time on his browser anywhere in the world.

Case 2:

The reconciliation effort of having 2 customers both ordering the last widget is a horrible idea for my business (say I am selling antiques where no replacement exists for a piece)  . My customers actually understand that I sell unique things and that they need some luck and not just money to buy my wares.

That is my priority – I can live with changes that take a little longer to implement, given they are few and far apart.

ENDCASE

What we discussed above is just one of many tradeoffs in an application’s design – albeit a very common one. The devil is in the details. Those important details do not come into light without geeks and suits sitting together and understanding the business priorities and trade offs before choosing a database.

A database is a foundational component of an application. And unlike a decade ago – now there are plenty of choices of databases. If our fictional conversation happened in 80s or 90s, probably we would have picked a relational DB as the answer in either case. And since that was the case – there was not much of a reason for geeks to have any deep conversations with suits to find the best database for the job. That is also why databases are now a $30B plus market – customers did not have much choice and all applications worked on relational databases even if they were not a perfect fit.

Not any more – now a customer can choose whether to use SQL (still plenty of great use cases for SQL exist) , or they can choose a more modern database like MongoDB ( or others – there are other choices too depending on the nuances) for other requirements. But either way – to exercise the bounty of choices, it is imperative that geeks and suits both work together to find the right database.