End user computing

If you give a large enough end-user community a tool, sooner or later, it is going to get used. Even if you don’t tell them you’ve given it to them.

In so many large organisations, this has resulted in a very large number – thousands upon thousands in some cases – of specialised little applications that have been built by users for themselves. They might not be very complicated, or do all that much, but they make the job easier. The best of them get shared around, often spreading virally.

The big IT reaction to this, often, is that all this “unauthorised” development is going on which must be contained, controlled, and centralised. Big IT, you see, thinks any system not under its control must be inherently risky. They worry about the potential risks to data, to security, and to the integrity of their business processes. They see end user computing as a problem that must be managed into elimination.

I have a different view. I see it as a huge opportunity. All these employees working around the clock building free IT systems to do their jobs better. Yes, they may not be as robust as the massive IT systems more normally employed, but the fact is they are often good enough. End User Computing, in other words, shifts the burden of systematisation away from the centre and out to the edge where it belongs.

Moving design and implementation tasks away from the centre to the edge is something I’ve talked about before. This is what you do whenever you employ crowds of people and hope you get emergent behaviour.

Crowds have been shown to produce very big, important outcomes without much in the way of centralised control. Linux is a great example. So are the various BarCamp type conferences that have been going on around the world. T-Shirt designs. Encyclopaedias.

Distributing work to the edge and waiting for big outcomes to emerge works. And that’s the real reason to do end-user-computing. It is the opportunity to do harness the power of distributed design and implementation to do far more than you could from the centre.

My observation is that a particular piece of functionality in an EUC environment is quite like social media. It is either popular, in which case it will be used by greater and greater numbers of people, or it is not, in which case it dies.

Now, you may initially get 10 different ways to create a parking space booking tool, but sooner or later, one will emerge which is better than all the others. It swiftly becomes the “one true way” to do parking booking and all the others get dropped by their authors as their audiences dissolve. The best tool “emerges” by itself without anything much in the way of design, other than that dictated by satisfying the greatest number of users.

That’s quite different to the dictates of big IT,which does development at the centre, of course. In that case, what you’re getting is a system that satisfies the needs of system owners, which may be important, but don’t represent  the whole picture. Especially if those system owners are remote from the front line of the business problem they are solving, which is often the case.

End user computing is a big strategic play, actually. It may not be ready for big system prime time right now, but the writing is on the wall. Sooner or later, I believe, all major systems development will be distributed to the edge and will emerge without much in the way of centralised design. People will work with people to build tools to make their jobs easier, and in so doing, will create a framework that helps everyone else.

In the meantime, those entrusted with managing Big IT have a challenge on their hands, because EUC is actually a disruptive innovation. It enables individuals to build systems which are too small for Big IT to bother about initially, which quickly become big enough to be threatening to Big IT the more they are used. The natural reaction – completely understandable - is to try to kill them off. Doing anything truly new always has risks and consequences, and IT people are trained early to take as few as possible.

The big challenge here is to find those IT managers who can read the writing on the wall, and nurture the nascent EUC capability in their organisations. The ones that can see the advantage, and make a measured judgement on the actual level of risk. The ones, actually, that will support emergence as the key principal that makes their IT organisations more, rather than less valuable to their business colleagues.

They will not have an easy time of it though. Big shifts in the dynamics of the ways things are done are never comfortable.

But, as in so many other fields that have already been through such technology driven change, there will be winners and losers. The winners are those invariably who spot the trend and get on the bandwagon early. Even if getting on it initially is painful and results in a few cuts and bruises.

Comments

[Jon Ayre (The Enterprising Architect)]

My view are twofold and somewhat split-personality on this issue. On one hand, the internet has demonstrated that community involvement has created a type of "cloud-development" world which is incredibly powerful and reactive. On the other, within an organisation, there are those who would rather fill their time writing mini-apps, rather than doing the job they have been hired to do. There is a fine balance to be struck between a managed level of creativity and natural selection (good) versus total anarchy where everyone does what they feel like while taking company money. Personalities play an important part and crowd mentality and market forces do not always lead to the best solution being adopted (it is more the best marketing that wins out). So, in essence I agree with your sentiments, but I believe the best situation is a balance between the traditional centrally controlled approach and the on-the-edge evolutionary approach. Perhaps IT can continue to be centrally involved by making more public its vision for the future and allowing the wider community to offer up solutions that fit the framework?

Regards
Jon Ayre
The Enterprising Architect
http://theenterprisingarchitect.blogspot.com

[John Januszczak]

I understand your sentiments. What is the point of putting a machine with any computing power on employee desktops, if you want to control computing centrally and restrict innovative uses of the hardware you give them to use? (or perhaps equally, what's the point if all they use it for is a typewriter?)

[Mark Higgins]

James, I don't dispute that EUC's have an important part to play in the enterprise, but I think you underplay the importance of big IT in the overall picture.

It is all very well having a useful EUC application universally loved by the people who use it, but when that EUC is hosted on a flaky file server or on a PC sitting under someones desk, it can expose the organisation to considerable risk.

Imagine the finance department a company using EUC's to complete their regulatory returns, and those EUC's sit on a server that fails due to a hardware failure. Not too far fetched I feel. They are left without their beloved EUC's for several days. Who are they going to call to dig them out of the whole - you've guessed it, big IT.

It highlights the importance of assessing the criticality of the activity which is undertaken with the EUC. Booking the carpark spaces: fine. Completing regulatory filings: probably not so wise.

[James Gardner]

Mark: I'm not certain that I actually said I believed EUC belonged on the flaky file server under the desk. Your points, in that case, are quite valid.

But what if the EUC was a central infrastructure that people could configure at the edge?

[Jon Ayre (The Enterprising Architect)]

On thinking further I have another comment to add relating to the relevance of Big IT. In my experience of IT development (which is extensive) I have never seen an IT problem that genuinely deserved the full Big IT approach in all its clunking glory. In essence there are a large number of people in IT who quite frankly shouldn't be there. One of the hardest elements of any project is determining exactly what the users really want - I can't think of a better situation for a developer to be in than to have a ready made, tried and tested prototype to productionise...

Regards
The Enterprising Architect
http://theenterprisingarchitect.blogspot.com

[Thomas Barker]

I know that in a lot of IBs, successful teams have their own infrastructure. It's just too expensive to force them to wait 6 months for a server. Other departments just re-purpose desktop PCs into key part of their systems. That works great for IT in the short-run, but eventually people begin questioning why they're there at all.

On a day-to-day basis, most of what business people tack-together are just spreadsheets that need a few input forms and multiple users. There's really no need to have professional developers working on an internal CRUD app with less than a few MBs of data.

(I'm actually building stuff on Google Spreadsheets for work. It's an easy way to grab some data off the web, interpret it and draw a chart. And I can tell the user to update it himself!)

[Peter Evans-Greenwood]

Big old IT is rapidly going the way of the dinosaurs, caught between (new school) BPO and SaaS. It's a cost driven business; the business case for most (if not all) applications over the last couple of generations of enterprise IT (all the way back to UNIVAC) is cost reduction through the automation of manual tasks. Our business cases haven't changed much since they were cast in celluloid for The Desk Set (http://www.imdb.com/title/tt0050307/). Big old IT won't be replaced by EUC, it will be driven out of the market by more reliable and lower cost service deliver models.

Companies are already starting to move to models where corporate data is maintained off premises (via cloud, or BPO, or ASP) and delivered via the web, and they're giving up the desktop to the users. Holes in this approach are being patched with applications installed in VMs and distributed on UBS keys. I know of a couple of companies who are working under the assumption that BYO laptops will be a condition of employment in the next couple of years, embracing EUC and empowering users to create their own computing environments.

[Mohan Alapati]

I feel business should be given a framework to develop only non-critical applications as EUC applications and must approach their IT department to develop a business critical application

At the same time, from business point of view they are happy with EUC from many long years and have no reported problems and not interested to invest in rennovating the EUC application

[Henry law]

I don't disagree with all of what you say: after all the users know intimately what their requirement is, so they above all will write software to meet it.

But the problems of End-user development cannot be ignored; as another poster suggested, they rarely have the right characteristics to be business-critical, and sometimes they're hard to scale up or to share. Moreover they often pose a serious problem when the time comes to make upgrades. I have personal experience of a major UK bank -- not your previous employer! -- faced with the problem of upgrading thousands of Excel spreadsheets on which much of the most profitable work in the Bank was based. Nobody knew how many there were; nobody knew which ones needed changes during the upgrade and which not; and actually working out how to make the upgrades -- given that the spreadsheets were on PCs under every desk in the organisation -- was a really hard problem.

And lastly there's continuity. EUC applications are often not developed in a logical fashion and usually not documented, so when the person who wrote them leaves it's very hard for someone else to take them over.

So some form of control in this area is essential; it just needs to be done in such a way as not to eliminate the basic benefits of the approach.

[Mel Glass]

Hi James – just found your piece on Banker Vision from Sep 09….I know you’re right – I live in the world of EUC and opposition to it.

Your promotion of EUC as a means to an end will always face attack from the ‘centralists’…unless EUC can be centralized. Not an oxymoron but a reality. EASA owns and licenses a technology that takes the very EUCs you refer to – tactical solutions built by users that really work – and deploys the same EUCs as web applications – without change.

So the owner retains control of his EUC AND can stand firm under scrutiny from audit – IT – regulators and skeptics.

Users access the EUC via a browser and a smart interface – exposing only those parts of the EUC that the users need to do their job.

When the EUC owner makes a change to V1.0 and publishes V1.1…..ALL users see the latest version – without having it on the desktop – without having access to change the underlying functionality, intentionally or accidentally.

In essence EUC behaves like a core business system but retains all of the qulaities of flexibility, speed of devewlopment and low cost.

www.easasoftware.com