The IT Skeptic - Comments for "Talk of IT innovation is the last gasp of the IT cowboys"

Sounds familiar

morticia — Wed, 29 Jun 2011 16:52:17 +0000

I agree, but management are culpable for letting the cowboy culture flourish. Especially those managers who have been promoted from that very culture.

a recipe for disaster

skeptic — Tue, 23 Mar 2010 14:07:00 +0000

Letting the cowboys loose without restraints on the 95% just so the poor darlings won't have their creativity stifled on the other 5% seems to me a recipe for disaster.

that isn't how engineers do it. In the rare % of cases where something creative has to be done outside standard models and processes, the most senior international experts are brought in to nut out something new, under peer review by other consulting engineers.

Give it up. IT is becoming Information Engineering and we're gonna do it professionally to rules, controls and standards.

(For readers: here is Todd's post "Process Stifles Creativity" which set off my tweet )

Relegating all creativity to Silicon Valley

Todd C. Williams — Tue, 23 Mar 2010 13:33:30 +0000

Rob,

I agree with you for 95%of the work that we have to do. However, relegating all creativity to Silicon Valley, as you tweet (Um, don't think so: "All this folderol about creativity! If that's what you want, go work in Silicon Valley" 6:32pm PDT, Mar 22) implies is literal, is ludicrous. There are insurance companies that do come up with innovative products that need innovative IT solutions to support. It is rare but it does happen. Keeping that team in the constraints of a strict overburdening process designed for a maintenance team will not meet the business goals. Hence my point, creativity needs minimal process, leadership (not managers) and the right team that has the capability (implied in my article).

Of course, living in New Zealand, you have some experience I do. Maybe you need to ship all creativity to Silicon Valley. :-) I am not sure your mates would agree.

Cheers,
Todd C. Williams

The last bit is the easy bit

Visitor — Mon, 07 Sep 2009 07:44:02 +0000

Much of the time, the existing "business process" barely deserves such an elevated name - its a matter of Excel files, Emails and Post-It notes, held together by some information gatekeeper who "knows how it's done". And God help the organization when she leaves..... At least with an automated [http://www.enterprisewizard.com/reducing-costs-with-bpa.pdf workflow], you have a process diagram.

I have also seen IT operations that are drowning in a wave of projects, but this is usually because they are hand-coding the damn things on a POS technology that some IT manager is familiar with because that is what he grew up 20 years ago. If it take more than a few months to complete a project, it may -never- get finished because requirements will have changed by the time that the spec has been implemented. And IT wonders why the business managers hate them?

I also agree that the long term cost of ownership for custom code exceeds the initial development cost by a factor of 4 to 1, which is why IT needs to get away from writing custom code. If you don't write custom code, you don't have to maintain it. New browsers to support? New release of the server OS? The platform supplier should address all such headaches

But as you said: People, Process, Technology. The last part is the easy one. I would add that the second part is not too hard if it is easy to modify the process to meet changing needs. But the first part.... well that's a problem that no one has ever really solved.

the last one is the easy bit

skeptic — Mon, 07 Sep 2009 04:20:26 +0000

I see your POV. I understand that development times have fallen. I just don't see development time as a large part of the cost.

Having dealt with a series of clients whose IT operations are drowning in a wave of projects, I'd say as an industry we do portfolio management very badly and in particular we don't budget for ongoing cost of ownership. it's all very well to bang up an app. Who determines the impact on existing business processes? Who designs the new processes and trains the users in changes to work procedures? Who modifies monitoring and backup and DR? Who trains the helpdesk and writes support documentation? Who provides level 2 and 3 support? And most of all a new system should be subjected to unit, sociability, user acceptance and service evaluation testing before being unleashed.

People, Process, Technology - the last one is the easy bit.

Building an app in 25 minutes

Visitor — Mon, 07 Sep 2009 03:33:26 +0000

I fully agree with your point about user requirements, which is why I called this a prototype in the last paragraph, but I would like to push back a bit on some of your other points:

The link in my first response actually demonstrates building a simple application for travel expense management in 25 minutes so if someone else has done the hard work of writing up the user requirements, it is not totally unrealistic

Financial Approval: Spending 25 minutes to build an application hardly needs financial approval, any more than you need formal approval to linger over coffee at lunch.

Testing: If you are not writing code, you are not writing bugs. Of course, you need testing, but it now means "Does the application do what the user wants or not?" and the best way to answer this is to actually show them. I have never seen a spec that proved to be 100% correct first time, whe the app is actually used, some refinements are always needed. Specifications are of course still essential to make sure that the first iteration is reasonably close to what the user wants.

Warranty Support: The [http://www.enterprisewizard.com/adaptive-software-platform.htm platform] on which the application is built certainly needs a warranty, just as you need a warranty for your word processor, but does it make sense to talk about having a warranty for every document that you write with it?

Enterprise Architecture: Every application built on the platform conforms to the architecture of the application, so web services support, [http://www.enterprisewizard.com/adaptive-software-platform.htm security], [http://www.enterprisewizard.com/enterprisewizard-scalability-and-redundancy.pdf scalability], etc is covered. Someone in IT needs to vet the platform before the first deployment, but there's no need to vet the architecture of every application built on it because they are all the same.

I could go on, but for complex applications, you are right. It does take more than 25 minutes. It takes about as long to build the application as it does to write up the user requirements. But this is typically a matter of weeks, rather than years. By way of example, ManuLogic was developed in 2 weeks and we built a global [http://www.enterprisewizard.com/chevron-case-study.pdf Sarbanes Oxley] application for Chevron in 8 weeks

As for wearing spurs..... well, I used to gallop as fast as anyone, but those days are long gone and I do not miss them.

you miss my point I think

skeptic — Sun, 06 Sep 2009 20:22:00 +0000

Hi Colin

Two points: I too find road building interesting (maybe not exciting exactly but it doesn't drive me away either). My point is that those who call it boring had better get used to it.

But I disagree that you can build an app in 25 minutes. It takes weeks or months or years. Why? user requirements, busienss case, financial approval, enterprise architecture and other reviews, support planning and training, user training, documentation, change control, service evaluation, testing (remember testing?), deployment planning and execution, warranty support.... When you say things like "you polish the app over the weekend" it makes me suspect you miss my point entirely and also wear spurs :)

Building roads can be VERY exciting

Colin Earl — Sun, 06 Sep 2009 19:55:00 +0000

OK, maybe I am a geek, but the very things you deride as boring are exactly what I get excited about because these are the things that make an organization function. Businesses run on IT and they run efficiently if IT supports a enterprise architecture, addresses business cases, uses common off the shelf software, etc.

What is boring about this? Technology has advanced to the point where you can [http://www.enterprisewizard.com/flash/Building-a-custom-application.html build a custom application in 25 minutes] and it is not some hacked together script, but a full blown enterprise app, that supports thousands of concurrent users, with full web services support, automated backups, fully audit capable, etc. Further, it is built on off the shelf software and addresses the issues that some apparently find "boring". Building an application like this is an act of pure creation.

I guess the "artists in code" may be unhappy because there is no coding involved, but was hand-coding ever really fun or just a necessary evil when it was only way to create something new?

In any event, unless you work for a software company, the days of hand-coding are over and there are plenty of other ways of having fun - for example one morning you might chat with a VP about some urgent need in the organization, then swing by his office that afternoon to demo a custom application that solves it and watch his mouth drop open.

Of course, you would have to call it a prototype unless you had a formal spec to start from and emphasize that you need an un-interrupted week of work at your home office to build the "official" app. So you polish the app over the weekend and spend the week in Hawaii learning how to kite-surf if you need some excitement. Meanwhile, the cowboy code-artists take 3 months to build anything and another 6 months to debug it.

a wake-up call

skeptic — Thu, 03 Sep 2009 19:32:19 +0000

Like any good debate we're actually on the same page.

I think any past staff of mine will tell you I encourage innovation (and I innovate). At the level of an individual organisation who have their act together I'm all for it.

At the industry level I took an extreme position here (something I've done once or twice before) to balance what i see as a nutty extreme on the other side (democracy is the balance of opposing positions). As a profession we do indeed lack professionalism and that is the solution is as you rightly point out. But folk complain publicly about how professional disciplines stifle innovation, and it is that position that this blog article attacks. Other well meaning folk promote thet idea that "IT must be innovative" without pointing out (or indeed understanding, sometimes) that innovation is a good thing after you have the basics under control. This is a wake-up call to them. "Innovation" is one of those motherhood terms that is becoming an unthinking assumed given, like "best practice".

The first thing you do...

mbuzina — Thu, 03 Sep 2009 13:27:38 +0000

... is to become professional. To become professional you stick to your promises and you do your job. Yes. But you will not make your organization more professional by hammering on "innovation" as a lousy thing. If you do that, you will become less professional. Your key people (professional & creative at the same time) will start to feel unappreciated and think about leaving. All the mediocre people will start to assume you are making their jobs boring, they will put less effort in and lousy people will be happy, because they can hide pretty well in your formalistic approach. Result: Productivity & professionalism goes down.

To do it right you emphasis the importance of innovation and focus it on becoming more professional! That is hitting both nails with 1 hammer (quite hard, true). Let them be creative about standardizing their work! Let them be creative in defining the common coding standards and let them be creative in defining ways to share critical data.

If making a "culture of innovation" is the last thing you do, it may very well be the last thing you do (pun intended).

So Rob, why are you bickering on the word innovation, while you should be complaining about the tremendous lack of professionalism? Or, even better, boast about the advantages of being professional! A skeptic may still be creative ;-)

EDIT: Forgot to answer your high-scool example. In that case you may need the tough schoolmaster first. But you would have to really be the schoolmaster, the janitor wouldn't cut it. And neither would the english teacher.

Edit 2: Changed would to wouldn't

whatever people want it to mean

skeptic — Wed, 02 Sep 2009 10:37:16 +0000

See here's the disconnect. I'm talking about innovation to mean whatever people want it to mean. I'm talking about innovation as an excuse to ignore the professional standards of accountability and quality and consistency and good practice. I'm talking about how encouraging IT peope to be innovators can be taken as carte blanche to ignore the rules we're trying ot introduce and do their own thing. About how change control and enterprise architecture control and other formalisms such as ITIL process and COTS and... are apparently stifling their flexibility and productivity and CREATIVITY.

I understand the definitions of innovation - we discussed it way back in this thread. There is innovation as invention and there is innovation as cross-pollination of fresh ideas. The meaning isn't relevant - people are not paid to be innovators. Innovation is a value add. innovation is a part of continual improvement. Innovation is something you do after you get the basics right. If people keep tinkering with the servers or SAN or network because they consider change control to be impugning their integrity, if programmers ignore coding standards and toss out slapdash documentation, if DBAs can't see the problem with knocking up embedded database procedures to provide core operational functions, if business analysts want to pass critical data across hosted collaboration tools.... if you can't get basic levels of professionalism and control, the LAST thing you should be doing is trying to introduce a "culture of innovation" or slagging off IT because they don't "lead the business".

It's like walking into a dysfunctional concrete-jungle high school and encouraging them all to express their inner selves. You'd be better off by starting with haircuts and no drugs in lockers and be here for class.

shonky Perl script = innovation?

mbuzina — Wed, 02 Sep 2009 09:20:02 +0000

Somehow I have the feeling that you are using the term innovation not meaning: "Creating something new from existing components or methods which improves the current situation" but meaning "doing something in a way which noone has done before and probably no one with a brain of his own would do".

According to your comment above the following equations are true:

Innovation = "shonky Perl script that nobody else can read or support"
Innovation = "clever constructs nobody else can debug"
Innvation = "...too risky or expensive"
Innovation = stop working towards a goal

In addition to that you use unverified and unproven figures (see the chokey comment above) to back your statement. Rob, this is below your standard. Usually you are right on with a skeptic view and you use common sense and real figures (and good sarcasm, I can appreciate that). But in this case you are "guilty" of the errors you usually blame software manufacturers for.

Or maybe, you have a different definition of the term innovation (which maybe many people share, according to the comments on this post). What do you mean when you are talking about innovation?

Marc

back the truck up

skeptic — Mon, 31 Aug 2009 21:11:00 +0000

Innovation as one duty does not make someone an innovator. Assembly line workers are not innovators. their job is not to innovate - it is to bolt the doors on. One idea a month does not change the description of their role. that kind of innovation is a minor (but extremely positive) activity happening over and above the day job.

Sysprogs are not innovators. We don't want them writing a shonky Perl script that nobody else can read or support just to show how clever they are.

Programmers are not innovators. We don 't wan thrm using clever constructs nobody else can debug.

Even architects should seldom be innovators. Most of the time innovation is too risky or expensive.

As i said, production line analogies break down dangerously if not used with care. I prefer road building. If a road or bridge or culvert is in a particularly challenging location, or if we just want a set piece to show off our innovation skills, they we need to invent new ways to do certain parts of the job, but the rest of the job will still be done the same old way. We don't need to invent a new kind of asphalt or concrete every time we lay a new road. We don't want to do anything new. We want to do it the same proven way, we want to do it the best we can as cheaply as we can. If the road crew innovate in the way they back the truck up or park the roller, good on them. That doesn't make them innovators, and telling them that's what they are would only encourage counterproductive behaviour.

Another perfect example: New Zealand's post-modernist new age primary teachers are screaming blue murder because the government wants to measure whether they are actually teaching the children anything and == GASP == tell people the results!!! One school principal, in charge of our children, condemned this because teachers would focus on basics and not do anythign creative. Quel horreur!

I for one would rather the teachers teach my kids to read and write than be trying new methods at my son's expense. If a school is utterly dysfunctional and a teacher invents a new way of getting to the kids - as heartwarmingly portrayed from time to time in the media - then good on them. If a school specifically designed as a research establishment develops new techniques, good on them. But I'm paying teachers, and I want them at a minimum to teach Jack maths and literacy. There are many other things we - the teachers and I - can teach him but I'd be pleased to measure that set.

Chokey the Chimp!

mbuzina — Mon, 31 Aug 2009 14:39:52 +0000

Your coneception of the production line is so 30 years ago.

Today a production line is devided into groups of people that form a team and that will manage their own work. They will innovate on their own methods and see themselves as service providers to the rest of the production line. And in contrast to your text, this does not reduce quality nor does it increase the variance. These people all work towards a same goal and they use all the resources they have (and that includes their creativity!)

I just have to assume you are ranting, since your claims could trigger chokey the chimp with a crap factoid (high I would guess, did you make the criteria catalog public yet).

Again (and again and again) innovation is and should never be confined to a small and elite group of R&D staff. i do not mind having an R&D team to TEST innovation, but they should never be the (only) ones regarded to create innovation. They are basically there to filter innovation to select the more usefull ideas.

Who are we to judge the "size" of an innovation

mbuzina — Mon, 31 Aug 2009 14:19:52 +0000

Innovation never appears by itself. Innovation can best be described as combining tried methods in a new and yet untried way.

In my opinion you have a twisted perception of innovation. The time that a single genius sits in their solitary cell and comes up with a bright new invention (that is then turned into a weapon of mass-destruction by the establishment) is long gone. Innovation and improvement occur constantly when people get together and the environment enables it. Talking like you do is one of the best innovation killers and gets you back to the dark ages of disrespecting employees.

With respect to innovation as a duty of every employee, there is a company which particaptes (quite successfully) in the Great Place to Work awards (http://www.greatplacetowork.com/) which requires each employee (and each managing employee as well) to come up with one improvement idea per month at least (their bonus depends on it!). This company is not only very succesfull as an employee, but also as an enterprise and earns above average within it's sector (as do almost all great places to work).

I have good news for you, even if you yourself may doubt it: By fusing discussion you (and this blog) are driving innovation. By bringing fresh ideas to your clients you innovate (have you ever implemented an idea from a different source without adapting it to your client?) and by giving your employees a channel to focus their creativity on (INNOVATION MANAGEMENT) you get the benefit of it, without the hazards of untested new ideas for bridges.

If you have time I would like to invite you to our 3rd innovation & future management symposium (27th of October in Münster, Germany), this would give you some thoughts to be skeptical about (http://www.noventum.de/).

P.S.: Before I meant triggering of course.... no way to edit the title

the miracle of innovation

skeptic — Mon, 31 Aug 2009 08:35:23 +0000

I dunno, why are you reading it ? :) perhaps because I take a stimulatingly different view of ITSM. Does that make me an innovator? I don't think so but even I'm not egotistical enough to sit in judgement of myself. Maybe I'll come up with an idea that is innovative one day - I try hard. Don't think i have yet - most of my ideas are just common sense. If you only read innovative blogs I think you are in the wrong place. Of the two million practitioners of ITSM in the world, the number of innovators in the sense of truly inventing something new is tiny, really tiny. Less than 0.05% LOL

Am I an innovator in that I introduce fresh ideas to my clients? Absolutely - that's one of the things many of them pay me for. But that wasn't what you meant.

Yes ideas rise from the shop floor. Yes that should be encouraged. Should employees spend all day thinking of innovative ideas? No. Should we be telling them they aren't doing their jobs if they can't be innovative about it? No. 99% of the time 99% of them are not innovating. Is the only good IT department an innovative IT department? No.

innovation is inspiration. it happens rarely and unpredictably. Nurture it when it does, but get on with work when it doesn't. I think it is cheap to say but almost miraculous to achieve.

No discussion on control & testing

mbuzina — Mon, 31 Aug 2009 08:03:19 +0000

And you are missing my point (on purpose?)

I have never said that innovation means to change your work immediatly (without consent, testing, etc.) and continuously just because someone has a new idea! That is redicolous, and has nothing to do with proper innovation. Since when did we say:
"abandon all logic, common sense and processes, let us all start innovating NOW"?

But your description of the 0,05 innovators is just as crazy. To come up with one usefull and aiding idea you will need many (many, many, many) raw ideas to find the brilliant one. Most organizations can not rely on the one bright individual that will be their innovator (as you are describing) but innovations are created as a team effort. If you just put innovation into your ivory R&D tower, you will get a few (well thought out) innovations after the rest of the world already put them into place.

If your last sentence would be true, this really is a sad world. You do seem to have a low appreciation of your fellow humans.

Marc
http://buzina.wordpress.com

P.S.: You did not answer my question: Do you believe yourself to be one of the few hundred innovators? If yes, you obviously hold yourself in quite high esteem (prove you are on of a few 100s!), if no, then why am I reading your blog ?

Almost right :-)

DavidM — Sat, 29 Aug 2009 00:45:35 +0000

Service providers have two sets of services, core services and supporting services. Core services tend to be standardized according to the model in your post. Supporting services is where the innovation and differentiation typically occurs. Typically 20 to 30 percent of staff are assigned to the supporting services and one of the requirements is that they be capable innovators.

I have seen the reverse, standardized supporting services and innovation at the core level, but it's not as common and staff innovators typically are in the 10% range.

David

Innovation should be tightly controlled and rigorously tested

skeptic — Fri, 28 Aug 2009 20:29:00 +0000

You are missing my point.

I never said there should be NO innovators in IT. i said there is a school of thought that every IT organisation should innovate, that innovation is ther thing to do. And there is a desire by every IT person to be an innovator - to invent, to create, to show how clever they are. This is wrong and dangerous. Innovation should be tightly controlled and rigorously tested.

Every few hundred years someone invents a better culvert. In the last century innovation was faster and every decade or so someone improved the design.

Every culvert that is built is different, slightly. You can tell the one you built if you see it in a photo. But the materials are standard, the thicknesses and angles and diameters are standard, the shape is standard. Nothing is invented on site, except in a tiny percentage of cases where the site forces innovation, in which case an expert engineer is brought in to design a one-off. He/she will still stick to as many stadards as possible and is almost certainly NOT going to make an engineering breakthrough such as inventing a new concrete. Hundreds of people will be involved in a culvert. The number of innovators will vary between none and one, averaging 0.05.

there are untold millions of people building bridges around the world. every one is different. The number of innovators worldwide is in the hundreds. At Volkswagen it would be in the dozens.

Innovation is anathema to service providers

skeptic — Fri, 28 Aug 2009 20:16:36 +0000

A service provider "mass produces" in the sense that they try to drive all clients to a standard lowest common denominator of process, reporting, server builds, service levels etc in order to achieve economies of scale. In that sense they mass produce yes. And NONE of their staff are allowed to be innovators - they are production line workers.

they only mass produce one part of their product though: server builds, hardware, contraxcts, SLAs. They build only one process model, only a small number of standard builds/SOEs, only one organisation or reporting system or or IT operations etc etc The automobile analogy for IT would work only if everyone bought their own seat but rented time in the same car.

they also depend on being low risk and high dependability. Innovation is anathema to service providers. Service providers adopt good practice which is the opposite of innovation. Good practice is proven and widely adopted. You can build the best product using good practice if best is measured by quality, dependability, affordability etc etc

Even if a service provider decides to launch out into innovative new products - and most don't - they have a small research team who test the innovation, then they standardise it and put it on the production line just like an automobile manufacturer. Google and Amazon spring to mind.

So 90% of service providers don't innovate at all. 10% differentiate by having innovative products, which are created by innovators who are less than 5% of their staff. So 10% of 5% of service provider staff are innovators. The rest are production line workers, abeit highly skilled ones. And they need to get used to that idea - that's the point of my article.