Regular readers might remember me agonising last year when I subscribed to a pretentious business journal. Well my year’s subscription is about due and the last issue is IT heavy. So, I’ll probably renew for another year. Its not that I read every article in every Sloan Review but I read enough that are of sufficient quality to make it worth the money. Yes it takes time to read an article but the return on investment (financial and temporal) makes reading the journal cost effective compared to books. That is, I get more new ideas and insights from per page than from most books.
There are two articles in the latest issue that are particularly interesting. I’ll leave one for another blog entry and talk here about Cynthia Rettig’s piece ‘The Trouble With Enterprise Software’. This is a well researched and thoughtful piece. It should even win credibility with hardcore coders because it quotes Bjarne Stroustrup and James Noble and Robert Bridle. (Although she forgets the reference for Noble and Bridle;naughty, naughty, wait till I see James. I suspect it is from their notes on post modern programming report.)
Rettig uses ERP software implementations to argue her case but the same argument could be applied to many other IT implementations. ERP is a good example because it shows many of the problems large (internal) IT projects suffer from: multiple stake holders, poorly defined goals, vendor lock in, consultants everywhere, difficulty seeing value, etc. etc.
She argues that basically ERP has failed to fulfil the promise. I has proved expensive, time consuming and locked companies into software, processes and practices. Companies have lost their agility by the very thing that was supposed to enhance it. (She actually uses the word ‘agility’ but doesn’t link it to agile software development or agile anything else so don’t read too much here.)
Further she dismisses SOA as a solution. At the moment a lot of vendors are making a lot of noise, and possibly money, offering SOA as a cure all. I think Rettig is right to be sceptical, those people I know working on SOA problems are finding all the old problems (and a few new ones) just one level higher.
Part of the problem as she points out is that the Lego-brick approach doesn’t work. It is really attractive, like most software engineers I had lego as a kid. (Actually I still do, I just don’t find enough time to play with it, luckily Christmas is coming.) We extend this love of lego building into software. If we could just have simple interfaces... like the 8 studs on a lego brick...
Actually if you look at my lego bricks you will see that only 10% or so are the classic 2x8 blocks. Even before you look at the technical blocs there are 1x1, 1x2, 1x4 ... and windows, and slanted ones, and smooth on one side... although we love this metaphor to build the really cool stuff in lego you need special bricks - and you never have enough of those. The same is true in software, the interfaces get more complicated. The difference is an order of magnitude in complexity.
A further complication Rettig doesn’t mention is our tendency to work at the edge of complexity. As soon as we solve one problem we attempt something more difficult. When we invent technology to solve one problem we find we can use it to do something new. Take XML for example, we could have used it to solve file format problems, instead we are using it to implement function calls (SOAP, XML-RPC) and then SOA on top of that.
We do this because we are chasing innovation and value. If ERP was easy then everyone would have it and it would be no advantage, so you have to do more difficult ERP for it to be worthwhile.
In the end Rettig is pessimistic about our ability to fix the problem, which is nice in some ways. All too often you get into one of these articles and the author says at the end: “the solution is some new technology from my new company.”
Again I tend to agree with her, this stuff is difficult. But I’m not so pessimistic. It is valuable because it is difficult. If it was easy it wouldn’t be worth while. Still, too many companies get into new systems when they should just accept what they have and make it work better.
Rettig does come close to proposing a solution. She correctly notes executives could learn more about IT, and the business schools that teach them could do a better job of educating them about IT. I think this is the answer. Executives need to accept IT is a necessary skill. How many CEO’s would say ‘I don’t understand marketing, I leave that to the Chief Marketing Officer’ or even ‘Accountancy makes my head hurt, I just want the CFO to make it work’ ? But you they can say things like that about IT.
To my mind, more educated executives are a big part of the answer. Which, as it happens, fits with the findings of another Sloan review piece I blogged about last year - Companies who understand IT get the benefits.
This also takes us to the second Sloan piece I want to blog about, but that will have to wait a day or two...
There are two articles in the latest issue that are particularly interesting. I’ll leave one for another blog entry and talk here about Cynthia Rettig’s piece ‘The Trouble With Enterprise Software’. This is a well researched and thoughtful piece. It should even win credibility with hardcore coders because it quotes Bjarne Stroustrup and James Noble and Robert Bridle. (Although she forgets the reference for Noble and Bridle;naughty, naughty, wait till I see James. I suspect it is from their notes on post modern programming report.)
Rettig uses ERP software implementations to argue her case but the same argument could be applied to many other IT implementations. ERP is a good example because it shows many of the problems large (internal) IT projects suffer from: multiple stake holders, poorly defined goals, vendor lock in, consultants everywhere, difficulty seeing value, etc. etc.
She argues that basically ERP has failed to fulfil the promise. I has proved expensive, time consuming and locked companies into software, processes and practices. Companies have lost their agility by the very thing that was supposed to enhance it. (She actually uses the word ‘agility’ but doesn’t link it to agile software development or agile anything else so don’t read too much here.)
Further she dismisses SOA as a solution. At the moment a lot of vendors are making a lot of noise, and possibly money, offering SOA as a cure all. I think Rettig is right to be sceptical, those people I know working on SOA problems are finding all the old problems (and a few new ones) just one level higher.
Part of the problem as she points out is that the Lego-brick approach doesn’t work. It is really attractive, like most software engineers I had lego as a kid. (Actually I still do, I just don’t find enough time to play with it, luckily Christmas is coming.) We extend this love of lego building into software. If we could just have simple interfaces... like the 8 studs on a lego brick...
Actually if you look at my lego bricks you will see that only 10% or so are the classic 2x8 blocks. Even before you look at the technical blocs there are 1x1, 1x2, 1x4 ... and windows, and slanted ones, and smooth on one side... although we love this metaphor to build the really cool stuff in lego you need special bricks - and you never have enough of those. The same is true in software, the interfaces get more complicated. The difference is an order of magnitude in complexity.
A further complication Rettig doesn’t mention is our tendency to work at the edge of complexity. As soon as we solve one problem we attempt something more difficult. When we invent technology to solve one problem we find we can use it to do something new. Take XML for example, we could have used it to solve file format problems, instead we are using it to implement function calls (SOAP, XML-RPC) and then SOA on top of that.
We do this because we are chasing innovation and value. If ERP was easy then everyone would have it and it would be no advantage, so you have to do more difficult ERP for it to be worthwhile.
In the end Rettig is pessimistic about our ability to fix the problem, which is nice in some ways. All too often you get into one of these articles and the author says at the end: “the solution is some new technology from my new company.”
Again I tend to agree with her, this stuff is difficult. But I’m not so pessimistic. It is valuable because it is difficult. If it was easy it wouldn’t be worth while. Still, too many companies get into new systems when they should just accept what they have and make it work better.
Rettig does come close to proposing a solution. She correctly notes executives could learn more about IT, and the business schools that teach them could do a better job of educating them about IT. I think this is the answer. Executives need to accept IT is a necessary skill. How many CEO’s would say ‘I don’t understand marketing, I leave that to the Chief Marketing Officer’ or even ‘Accountancy makes my head hurt, I just want the CFO to make it work’ ? But you they can say things like that about IT.
To my mind, more educated executives are a big part of the answer. Which, as it happens, fits with the findings of another Sloan review piece I blogged about last year - Companies who understand IT get the benefits.
This also takes us to the second Sloan piece I want to blog about, but that will have to wait a day or two...
Personally, I find "product lock in" or "producer lock-in" as a source of all evils. If every producer is somehow forced to disclose the source code, to integrate well etc. (don't know how to achieve this) then the whole development process would change dramatically. And many troubles will disappear.
ReplyDeleteyuryr