Complicated is not clever

There are many reasons why projects fall behind or fail altogether. I’ve talked about them before. Management and Employee buy-in. (Organisational Change Management) – bad Data Migration Practices and so on. If it is a technical project it can fall foul of “we don’t know how big it is, we don’t know how complex it is, but we know when it must be finished” syndrome. If you have a project that falls into this category you’re already at a severe disadvantage. You will uncover the real scope of the project as you go along so you have to start compromising early on.
Statements like “this will not fit into our timescale” should be par for the day. Reduce the scope to fit and make it clear upfront that this is the way it will be managed. If this is not acceptable and extra resources (not always a practical solution) can not be added, it’s time to walk away from this project.

I’ve mentioned the triple constraint before so I won’t labour the point here.

One way you can reduce the scope in a subtle way is to reduce the complexity. Complexity is a poison that eats into projects, increases TCO and can make a project a nightmare to coordinate, integrate and deliver. An Architects job should be to reduce complexity. period. If he or she can do that then half the battle is won.

A good developer is not, as some would have you believe, one who can deliver functionally rich, complex and “clever” solutions. Clever solutions are simple, elegant solutions that are easy to use and even easier to understand. There was a saying in the 60’s and 70’s that went along these lines:

If you can explain your system to your Grandmother – it’s a good system.
If your Grandmother understands it – it’s a much better system.
If your Grandmother designed it – it’s the best system.

In other words – it’s simple, elegant and to the point. Some complexity these days is unavoidable (security, for example). Most is completely avoidable.
A good developer and a good architect avoid complexity like the plague. They will argue long and hard to simplify processes.

If you are a client, let them simplify things as much as possible. Ask the question – “is this really needed?” – often.

Some complexity is acceptable – some people go as far as to call it “good complexity”. Personally I wouldn’t. Adding functionality that differentiates and puts your company ahead of others is acceptable complexity, but it must itself follow the rules of simplicity to become an elegant function.

The Global Simplicity index puts an estimate of $1 Billion dollars a year lost by the worlds largest companies, purely due to complexity.

That’s a lot to pay for someone to think you’re clever.

Leonardo da Vinci once said “Simplicity is the ultimate sophistication”.


The Small Team Phenomenon

In 1982 Tom Peters and Robert Waterman published “In Search of Excellence”. This remains one of the “must read” books on business. If you don’t have it. Borrow it from someone who does or go to and buy the darned thing. It really is that good.

Anyway contained in that book is a truism that I’ve come across quite often – even recently. This is that small teams- and by that I mean 5 people or less – can innovate and go to market in a very short space of time compared to large teams or even research teams in large companies. Typically there are too many levels of decision making and each one – to justify their existence I suppose – try to add their stamp.

This results in products – especially in a high innovation environment  – being constantly “behind the curve”. Large companies such as SAP, IBM and Oracle are always being made to look slow.

What we need to do is encourage the Sun mentality of paying people to go offsite and develop “something cool”.  It worked for James Gosling and Java. Lockheed have been doing this for years with their “Skunk works” program.

It seems a pity to me that these lessons have been out there since the 1960’s and our leaders of today still pay no attention to them. So just to make it easy to follow – here’s a checklist.

1. Make small teams – no more than 5

2. Put them off-site where they can be semi-autonomous with little or no red tape

3. Try to encourage innovation by making the requirements as wide as possible – but have a generous time limit.

4. Cash in the profits and make shareholders very happy.

There – not too difficult is it. Pah! You’d be surprised – especially when the bean counters hear what you plan.


State of Innovation at SAP

There has been a lot of noise recently that SAP is slow to innovate or has somehow slipped behind the curve on innovating new products. These comments are fair for an outside observer, but it’s a lot like saying that the US defense industry has no new products coming up. In other words, just because you can’t see them, doesn’t mean they don’t exist.

This month at CeBit the public had a very small glimpse of what the guys are doing at SAP Research. I’ve been lucky enough to have been  seconded to Research since the beginning of the year and I was also lucky enough to have a small involvement in the CeBit project.

I often hear that SAP is too complex and I think you’ll agree that this couldn’t be simpler. 

The demo involves ordering stock from a large wholesaler using only a generic cellphone (based on S60). The small store (“Spaza” shop) is owned by a 65 year old woman. The cellphone is used to order the stock needed and the stock is delivered and invoiced automatically from the back-end.

I thought you might be interested in seeing some screen shots – so here they are:

The first two are mobile screenshots and the final two are products of the back-end SAP system. (These are not the final screens – they were in development at the time – The final screens are much nicer)

The Main Menu
The Ordering ScreenBack-End Using GPS CoordinatesInvoice received from Supplier
Back-End Using GPS CoordinatesInvoice received from Supplier
Invoice received from Supplier

Planet Better Place

When Mr Agassi left SAP he founded Planet Better Place – If you believe in sustainability – check out the link above.
Visit Planet Better Place


The Oracle vs SAP War – Really?

Seriously now – I know I work for SAP, but since a thousand years ago I was a JDE consultant I like to think I have a fairly objective view of the world of ERP. I see an awful lot of analysts (who quite frankly – have probably never worked a day in their life in the “trenches” so to speak) spouting off about Oracle taking over from SAP as the market leader, why SAP should be worried, and blah blah.

Newsflash. SAP is not worried. This isn’t arrogance – it’s pure pragmatism. Oracle is years, no really, years behind SAP in the areas that matter.

Fusion Applications was announced in Q1 2006. Understand that since Oracle buys it’s software rather than growing organically (80/20 in my estimation) – integration and integrated applications are absolutely crucial to the average CIO. The sell from Oracle is that they are now a “one stop shop” able to supply and fully integrate the entire suite of enterprise applications. In Q1 2006 SAP already had a maturing Integration stack called NetWeaver.

SAP have implemented thousands of NetWeaver applications with some fairly heavy integration. Users literally could not care less where their data resides or their applications reside. Everything is fully and robustly integrated. Oracle have yet to deliver the first generation of Fusion Applications and now they are pitching 2010.

SAP is on the 5th Generation NetWeaver with some very well integrated apps and some mature middleware. Even the small amount of aquisitions that have taken place have now been integrated (Business Objects for example) and new aquisitions (BPC from Outlooksoft) will be integrated fully in their next release.

So – SAP has very little to worry about. Honestly if I was a CEO and my CIO told me he was going Oracle, I would ask him to consider his prospects at another firm.  I suppose analysts have to justify their existence by saying something, and I’m sure Oracle has very clever sales people to sway their opinion. The facts, however, speak for themselves.


The Oracle / Sun thing

Well it’s very interesting that this buy-out has generated a lot of discussion around an IBM/SAP merger or a Microsoft/SAP merger.  Of course because of the relative sizes of the companies concerned it would be SAP that would be bought out. Not a cheap purchase though at 45 billion market cap. I don’t think it’s likely – both Microsoft and IBM have explored this before and backed away, but it’s fun to speculate.

IBM buys SAP scenario

Well IBM would almost undoubtably form tighter alliances between WebSphere and NetWeaver. Few people realise that we already collaborate on products and we have a center in Germany staffed by IBM people and SAP people for this reason. This almost brings me to my point, but lets leave that until the end. IBM uses SAP itself and shares many customers with SAP already, so this wouldn’t be an “Oracle buys Peoplesoft”  type of situation – we already are very well “meshed” together. Let’s look at the next scenario.

Microsoft buys SAP scenario

What would Microsoft do? I think they would leave the core but redesign the GUI for SAP. We’ve already separated the front-end quite substantially on SAP, so this will be very easy to do. Oh! and we’ve already collaborated with Microsoft on “Duet”. This is a Microsoft Office / SAP mash-up that gives very tight integration at the front-end.

So to look at the likelyhood of a buy-out in this light – I would have to say why? We (at SAP) are already aligned strongly with IBM and Microsoft and we convert clients from Oracle on an almost daily basis. I might be wrong here but I think it’s an expensive aquisition to accomplish very little. Market share yes – but neither Big Blue or Microsoft want to play in the Enterprise Application arena.

Fun to speculate though and time will tell.