Between “Rogue” and “Pure” IT

An interesting blog post landed in my in-tray this morning: The verdict is in: ‘rogue’ IT is cool by ZDNet‘s Joe McKendrick.

I agree wholeheartedly with Joe although the term “rogue” IT is perhaps a little (no doubt deliberately) provocative.

What is certainly true is that IT Architects are often faced with situations where compromises have to be made.  This could be due to budget constraints, the need to deliver very quickly, or the demands of users who have found their own way of solving the problems, albeit not using “pure” IT.

I think there is a middle ground between “rogue” IT and “pure” IT that potentially can square the circle.  The last thing anyone wants is for the user community to be so frustrated at the lack of IT support, that they find someone within their midst to “hack” a solution together using amateur programming skills and a VB licence.  This ultimately leads to the IT department having to suddenly support a mission critical system it didn’t even know about.

Perhaps the IT function can deliver “rogue” tools to the business that have a degree of central control but are maybe based on non-pure techniques.

My self interest here is using tactical interfacing methods like UI integration (connecting to the user interface of applications using proprietary APIs, EHLLAPI and screen scraping for example).  But there are many other examples of vendors who have taken an essentially rogue solution and applied some level of control so the solution can:

a) be placed back in the control of the IT function so when the solution becomes mission critical (and it will), proper management and controls can be maintained;

b) allow the user community to have a very great degree of flexibility and control over the solution and to be able to make changes regularly without having to wait for IT support; and

c) allow for a bottom up approach (but with the end game in mind).

After all, the business community are the people who understand their business best.  The more control they have over the final solution the more likely it is to be good for the business as a whole.  Furthermore, if business improvements are examined and tackled in bite sized chunks, it is much easier to measure the success of the improvements.

In my experience it is also amazing how quickly large business benefits accrue from a series of small steps.

Leave a Reply