So Easy a User Can Do IT

Theresa Regli recently posed the question – “Should IAs be building Applications?” Well, I suppose it comes down to your definition of an application. I would argue that the types of configuration she describes don’t constitute the creation of an application in the first place – you are simply operating within an application with a broader context. This inevitably takes you on a long and winding trip down the Semantic Highway that  leads you to arguing dogma instead of technology.

What interests me more is the motivation. Vendors freely push the mindset that it is so easy that anyone can do it. They play to a common theme. Everybody loathes IT.  So much so that vendors are constantly trying to configure or host them out of existence. Business users blame them for their own inability to make decisions. Then they look for any way they can to use someone else’s IT to get around their own company rules.

Chuck Hollis has an entire series of blog posts on what he terms as Frictionless IT. Throughout the series I believe there is an undercurrent suggesting that most IT organizations are better at preventing change than implementing it. Get them out of the way and everything goes faster and (in theory)  better.

The core of the problem though is really mitigating the risk of incompetence. On average, IT is no more or less competent than any other organization. In most manual processes though – the impact of individual acts of incompetence is constrained. With IT it’s deployed. The broader the impact – the greater need for controls. Necessary evils at times.

Don’t get me wrong. IT is it’s own worst enemy. More than one development manager has contemplated unspeakable acts in the middle of a change control meeting when common sense was overwhelmed by the neurotic prudence of a weak minded admin.  But just because the head of the review committee is an idiot does not mean he is always wrong – or malicious. He may Just be stupid and inarticulate.

It is the “re-education” of operations managers while redefining what “change” really means that is perhaps the greatest obstacle to overcome as systems blur the boundaries between code and configuration.  This is really nothing new for formal content management.  I have argued in the past that the modification of content within the content management system is not “change” from an application perspective. If the content is approved and the system behaves as it should – then let the users push what they want. Just don’t call me if you don’t like the results.

A mentor of mine years ago summed it up this way. CMS applications have to deal with change in 2 dimensions.

• Vertically against the SDLC where content that affects state is modified – This has to matter to operations.
• Horizontally along the Content Development Lifecycle where content that is informational is managed – This shouldn’t matter to operations.

Configuration (like content management) is highly desirable within the domain of a given platform – I will always prefer to configure over code. Configuration though drives you away from the constraints of a software development lifecycle and discipline must be maintained.

Long term IT owners of big platforms clamor for configuration features over coded customizations just as much as anyone else because of a perceived reduction in total cost of ownership and theoretically faster deployments. But often there is poor if any support for packaging the configurations for deployment in higher life cycles and this works against their acceptance.

At the end of the day and to the chagrin of the accounting department, you can’t remove the IT professional yet. The technology needs the ability to overcome the incompetence of the people you charge with configuring it. You need more Self Healing Information Technology.  Exceptionally large systems with mission critical functions require Deep Self Healing Information Technology capabilities. Without better Self Healing Information Technology, plain ole IT will be around for a while.