James Governor's Monkchips

What if IBM Software Got Simple?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Last month I attended IBM’s 10th Annual [Steve] Mills event, when industry analysts converge to hear what Software Group has been up to, and where its going. There is always a ton of content, which makes it hard to summarize, so I won’t even try. But there are a couple of key narratives I want to capture, and I will use separate posts for them.

The first narrative is Get Simple.

Generally IBM doesn’t understand simple. IBM likes to create systems that are infinitely configurable, to meet every possible “need” that an enterprise might ever think of. As I like to say: IBM never met a requirement it didn’t like. But configuration is expensive – it requires consultants (go IGS!) and a lot of time and unnecessary pain.

I had a number of conversations at the Mills event however, which indicated IBM is getting a feel for the new simple. Rather than telling customers they can have all their old complexity and cloud operations too IBM is going to start being opinionated about system images. One of the first IBM products built to this way of thinking is the new Intelligent Operations Center, used as the basis for IBM Smarter City and water management plays. Customers can basically acquire the IOC in four different versions… large on-prem, large SaaS, small on-prem, small SaaS, and that’s pretty much it. But more products are likely to take the same approach.

When I have spoken to IBM Distinguished Engineers and senior managers in the past they have tended to believe that complexity could be abstracted, but after the failure of models such as Ensembles, it seems a new pragmatism at work. I talked to Jason McGee and Rob High, both DEs, and they both talked to the new simplicity as a better way of doing things.

IBM of course isn’t the only one with the config problem – its practically definitional for Enterprise software. In 2006 I said “Microsoft servers are a configuration fetishists’ wet dream”.

Unlike the enterprise however the Web thrives on simplicity – certainly on the config and operations side. Ruby on Rails, the favorite framework of many web developers, is based on a core concept – Convention over Configuration.

The idea is summed up pretty nicely here:“Design a framework so that it enforces standard naming conventions for mapping classes to resources or events. A programmer only needs to write the mapping configurations when the naming convention” fails.”

Or in my rambling fashion:

Ruby on Rails is interesting because it forces constraints on developers… and they like it.

Rails is about freedom in the Kantian sense-development has a categorical imperative – what you do should be morally applicable to anyone else in the same circumstance. Its about responsibilities rather than rights. The responsibility to ease of use.

Abstractions are aspects or constraints of the framework itself, rather than veneers to hide code behind and allow ever more configurations to be applied. Freedom comes from accepting and working within constraints. Beautiful code comes from limitations, not being able to configure everything in sight.

A related way of thinking is lesscode.

lesscode.org is a place to advocate, discuss, and practice the art of using less code to get more done. We shun complexity and challenge the status-quo when it impedes our ability to simplify our development tools and processes. We appreciate Python, Ruby, LAMP, REST, KISS, worse is better, and talk like a pirate day.

Back in 2006 (that year again!) I asked David Heinemeier Hansson, inventor of the Rails framework, if lesscode also meant less maintenance. He was good enough to offer a thoughtful response, which I will include in full.

“So my experiences would tell me that conventions of reward (“do it like this and you’ll get that for free”) has a really long shelve life. I remember when I worked in PHP, I would always tweak the configuration approach a tad going from app to app. This would lead to the code base of the previous project feeling really old really quick.

Rails applications don’t suffer from the same notion. Yes, we keep adding features and tweaking APIs to make the common stuff easier, but the majority of core conventions has been stable for a very long time now. It gives all applications a common culture and fix point.”

Java culture (more JAR JAR, more WAR WAR) is a long way from Rails culture, though early Spring (and latterly Roo) made some valiant efforts to make Java more of a convention oriented system for development.

Now I don’t want to go down a Rails is more maintainable than Java rathole, especially because Web Companies seemingly turn into Java shops when they grow up (Twitter, for example, recently took a seat on the JCP). As Eric Baldeschweiler, founder of Hortonworks and the guy that hired Doug Cutting to build Hadoop for Yahoo, told me recently he learned to love Java precisely because it allowed Hadoop to evolve, because of its maintainability.

But its inarguable that reducing configuration options makes support and maintenance easier. You can’t automate your way out of complexity.

That’s the real lesson of the web. How does Twitter support a user population of hundreds of millions of people with such a small ops team? The answer is limiting the range of deployment options in terms of servers. The same is true of any of the major web firms.

As I wrote recently, VMware seems to understand this trend lessons of the web: on vmware, cloud and what comes next. I have to say its good news to see another client, in the shape of IBM, thinking the same way. The Web can teach the enterprise something about Cloud Computing – after all, that’s where it came from, right?

Am I saying that all IBM products are now easy to install? Of course not. This will be a multiyear effort with missteps along the way. But consider- when you build a new data center you don’t retrofit it with a bunch of old intel gear. You build out for scale, with the latest hardware. That’s the kind of model we need to move to in software.

As much as anything, I think its worth calling out that IBM is thinking this way.

IBM is a client, and paid T&E to the Mills event.


  1. Simplicity is not the same thing as dumbing things down.
    Layers of abstraction for complexity need to be there.
    Also see Dave Winer’s excellent post illustrating this point:

    Simplicity intended as simple minded poverty of features is backwards thinking.

    1. vruz- “a simple minded poverty of features”. you read this post as a call for that? weird

  2. […] My friend, foil and friendly adversary James Governor posted an blog entry today entitled “What if IBM Software Got Simple?“ […]

  3. Brilliant post, but I have to admit, when it comes to IBM and simple, I’ll believe it when I hear that global services has shrunk its workforce by half…

    IBM does some great things, but it’s current business model largely seems to be “Make great software so hard to operate that our customers get us to run it for them”.

    IBM global services now ranges from business process outsourcing teams providing actual users of the software as if they were members of staff, right through to the more traditional technical implementation and support teams, and a “Simple” IBM would need a lot less of this.

    It might well be more profitable for IBM to go down this path, but it’ll be very disruptive internally, and a lot of internal empires will need to be destroyed on the way.

    1. thanks ewan. frankly i don’t think we can expect *simplicity*, but more simple would be a big step forward – even just a reduction in SKUs and system images. Scale out works in environments that are limited. that’s the key lesson.

  4. I don’t see it in ops the same way I’m seeing it on the dev side. Cloud, virtualization, etc lay the groundwork for future simplicity, but everyone still does all the admin work setting up images. What needs to happen for this to reach ops is distributing more software appliances and pre-configured images.

    1. right on the money donnie. that’s exactly the stated direction from ibm…

  5. Unfortunately The Answer Is Not That Simple…

    To use American football metaphors, IBM and others have been caught offsides. It’s hard not to notice an illegal formation when they try to sell an enterprise a 10 million dollar ELA while trying to chop block commodity infrastructure. In other words why would anyone in their right mind in 2012 purchase a Rational, Weblogic, and Tivoli stack when a majority of all web scale business’s run on SVN/GIT, Hudson, Tomcat, Chef/Puppet and Nagios. Oh year and let’s not forget about the IBM services revenue that relies on that complexity. Also, let’s not even go into the open source government solutions as opposed to IOC

    The real question becomes do really want to make it easy…

    I think your post hit the nail on the head, it’s about the cost of complexity. Therefore, the fact that the commodity solutions mentioned above are free (or close to free) is not the point. It’s the cost of that complexity, as you have pointed out. The complexity is the real horse-collar around the “enterprises” neck and unfortunately for IBM and others commodity solutions are far less complex.

    In my humble opinion enterprises have two options in 2012. They can punt and wait and see if IBM and other can count on their defense or they can go for it on forth down by switching to commodity infrastructures. Now if IBM really wanted to be bold and productive they could also punt and switch to a commodity infrastructure and count on their offense.

Leave a Reply

Your email address will not be published. Required fields are marked *