If only enterprise IT worked like my iPad ... or at least my car
Architects and biz chiefs still not talking
Posted in Management, 4th April 2013 15:29 GMT
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
Opinion Do you remember when computers were hard to use?
Not so long ago our collective opinion was neatly summarized by the apocryphal GM press release which asserted that if they developed technology like Microsoft, we would all be driving cars that for no reason at all, would crash twice a day, shut down and refuse to restart.
Since then Apple has showed Microsoft the way, and we all use smart phones, tablets and PCs that are genuinely easy to use and remarkably resilient.
Because of this great leap forward in personal device usability the smart phone user on the proverbial Clapham Omnibus might reasonably expect that enterprise systems should be similarly easy to use and resilient. Unless of course she was a customer of the Royal Bank of Scotland (RBS), in which case she will have painful memories of last year’s high profile failure caused by the core banking system crash which corrupted tens of millions of accounts.
Once upon a time banks in general were regarded as leaders in the use of information technology. Yet last year several high profile systems failures signalled that banking systems, far from being leading edge, are in rapid decline. Banks aren’t the only culprits. Along with the banks, insurance companies, retailers and others are starting to offer their customers smart phone apps, notwithstanding that behind the scenes their enterprise systems are frequently held together with sticky tape and sealing wax.
The reason many enterprise systems are in such a poor state is commonly because there are three parties involved in managing the enterprise systems that have widely divergent goals and objectives. The line-of-business manager typically views the systems as support to the business process and a cost to be managed. The IT Architect views the enterprise systems as a set of capabilities that must be progressively modernized to support business innovation. The IT Project Manager is focused on delivering projects to time and cost.
These views are of course diametrically opposed. And under cost and time pressure the Architect is frequently the lower ranking player. In consequence the immediate needs of the business overrule longer term objectives of modernization, reduced complexity, flexibility and even cost of ownership.
The real issue is that the three parties do not have a shared view of the business problem. The line-of-business manager’s business process view does not correlate at all to the delivery project. The Architect should be the evangelist for business innovation but he or she is too easily squeezed in the cost and time discussion. And the Project Manager typically does not share the detailed technical project view with the line of business manager, and argues for a solution specific architecture that reduces project risk. The result is the existing enterprise systems get more complex and slower to respond to change. And the IT industry has been doing exactly this for as long as anyone can remember!
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
COMMENTS
The rot start started when...
Up till the mid 1990's you would find the top boss in IT was someone who had worked their way up to the top of the pile and had some reasonable IT knowledge (they'd done their time).
Then in the late 1990's you'd find that the top person was some weasel, who'd been crap at IT but worked in the IT department and had been good at sticking their proboscis in unpleasant places. About the same time project managers started appearing in IT, again they were not good at IT but they acted to keep an eye on admin but weren't in charge.
Then after 2000 I noticed that there was an influx into Project Management of people who'd been on a one week Prince course and used to sell snake oil in the dot com boom.
Next came the System Architects who had been again had very little IT experience (if you asked them questions you found this out) but had some sort of Microsoft authorisation, their golden rule was if it is not a able to run on Microsoft platforms or is written in house then kill the project - I worked on many projects that there was no software available to run on Microsoft so they all died in the end.
The final nail in the coffin was offshoring where any requirements were coded regardless of whether they were self contradictory and none of our bosses knew how to turn on a PC, yet made strategic decisions like "We haven't got time to test it just read the code, see if there are bugs and put it live tonight" (they'd never heard of the halting problem).
Then all of us who knew anything were surplus to requirement :o
My experience is everything was always done slap dash because all that was important was that the customer got what they wanted.
If you try to explain sensible ideas as shown in that diagram to the people "at the top" their eyes glaze over and they not and promptly forget everything you just tried to teach them.
Then they return to responding to whichever customer screamed at them the loudest 5 minutes ago.
Save us Apple
Granted I haven't followed the RBS fiasco, but the difference between your iPad, your car, and general IT service is that you paid an exorbitant markup on your iPad and car... You get what you pay for and no one wants to pay for good IT service. Many don't even really know what level of service they're really getting. They just want someone like Apple to make all their decisions for them so they don't have to think. Yeesh, when you drink the kool aid you really fall in love with it don't you.... Your iPad isn't nearly as special as you think it is; it does the 10 things Apple lets you do with it and that's it. Enterprise IT isn't allowed to say no. Ever.
Beyond that the idea that technical types in IT suck at business and business types suck at IT isn't new... Both sides need to put in more work to reach the other.
Oh dear, oh dear, oh dear... Part II
"It’s extraordinary, but with all our high tech knowledge and skills we don’t have a vocabulary to articulate the business problem in a way that allows effective communications between the participants."
Who is "we" in this case? If we are making sweeping generalisations then I would have changed the overall intent of the passage to read "we generally don’t have the time to get all of the key participants in a room to make sure everyone is on the same page".
Also, I think that blaming the RBS fiasco on technology alone is purely shifting the blame onto platforms that would have been architected technically to have been as available as possible - my understanding is that it was HR cost-cutting and staffing issues (i.e. outsourcing to less knowledgeable resources) that caused this particular failure.
So David, I noticed you are also at this Architecture Summit? I suggest you meet up with Gavin Payne who is also there - it seems you both need to drown your sorrows.
Wow! That was like being in a really extended Dilbert strip.
The new Office Garage series:
