Three Guiding Principles for IT Decision Makers Part 1: NoDev

My first computer was a ZX Spectrum 16K which was actually bought as a birthday present for my older brother and from whom I managed to appropriate in the settlement of a debt within a year of the anniversary. As this transaction took place when I was around 8 years old I can argue, with some credibility, that I have a lifetime’s experience of both computing and finance. As a career technologist now working for a Tier 1 global bank I have had the chance to distil from the many lessons learned, over 20 years of professional experience, some key principles that have informed my IT decision making.

I stress to the reader that these principles are just that, principles i.e. propositions that serve to inform decision making. They will serve one well, in the overwhelming majority of cases, to arrive at a good decision quickly. They are not however, laws to be obeyed without thought or reason.

To make these ideas easier to remember and communicate I refer to them as the 3IT principles and my hope is that by naming these principles it will encourage others to elaborate and critique them and thus increasing their value to the community at large.

To understand the perspective that these principles illuminate and the context in which they where forged I believe we have to redefine a word that we are all familiar with and which is, for me, at the centre of IT, the computer. It is my conviction that redefining the word in the context of the enterprise will better equip IT decision makers to make the right decisions for the business they serve.

The various definitions of the word “computer” offered up by the OED seem out dated with their focus on calculation. They do little inform our decision making, for example and somewhat surprisingly, the word automation only appears in the use of “computer typesetting” by the Times 22 Oct 1963:

The adoption of the system would prepare the way for further automation, possibly for the introduction of computer typesetting

To fail to explicitly point out that computers automate calculation is to overlook the quintessential nature of these machines and perhaps explains why we still see so much needless manual intervention in their use. We would do well remember a quote from one of the fathers of computing, Charles Babbage:

The economy of human time is the next advantage of machinery in manufactures.

I therefore suggest the following definition of a computer:

computer, n. Any device or machine (physical or virtual), that increases productivity by automating cognitive and algorithmic processes.

With this definition in mind the rest of this post will focus on the first of three guiding principles in the 3IT management ethos.

NoDEV — Only engage in development projects that deliver applications which demonstrably, unambiguously and unequivocally generate revenue for the business or enhance customer experience.

To put it another way:

“If you’re not in the business of IT stop making IT your business”

This maybe a difficult message for many IT decision makers to hear, including those in the financial sector with mature IT divisions, but history is on my side and trend is inextricable. Many aspects of IT are fast becoming commodities or being delivered and consumed as utilities. This should not be surprise to anyone, as it has been predicted for decades and the last barriers that will open the flood gates for the current expression of commodity computing, public cloud computing, are legislative (in which I include privacy and security), the key barriers to adoption are not technical.

Acting in recognition of this long and maturing trend it is incumbent upon IT decision makers to use far more critical criteria in approving internal development projects. If your business is not IT you need to exercise far greater control in the approval of any project that demands development effort.

Everyone believes their project is critical to the business and will generate revenue so how can we decide which development projects to pursue, which should be killed and those that can be turned into integration projects utilising Community Software or otherwise delegated to third party service providers? This seems to be a difficult and time consuming task for many large enterprises, and in my experience one that rarely produces optimal results.

To help identify development projects to which enterprise resources should not be allocated, NoDev suggests avoiding development effort in any non-core or ancillary system, or developing any product for which existing mature third party products already exist. This may be stating the obvious, but often application projects are miss-represented in order to present a an “original” solution, when in fact it is nothing of the sort. Over the last 20 years I’ve seen commercial business build databases platforms, portal platforms, application servers, enterprise services buses to name but a few, they were however, never represented as being what they actually were. There was apparently always a good reason why these products had to be built in house, and that reason always came from the application team…

If you are not in the business of IT and you are developing software in any of these categories, I would question that decision, some examples are provided below:

• Service Bus
• Database
• Application Server
• Workload Scheduling
• Messaging
• Security (seriously building your own security…)
• Portal
• CRM
• ERP

The list above is far from exhaustive, I’d appreciate any feedback from readers that can elaborate it or find exceptions.

It would be wise to remember that every line of code you write is liability for the company, not an asset. It is a liability with potentially and enormous total cost of ownership, which the application team (or frankly almost anyone else) will be ill equipped to calculate.

Community software has exploded (by Community Software I mean any Free and Open Source Software that is viable for use by the enterprise because it has a well established community to sustain it). The range of applications and API’s available have reduced the need to code from scratch enormously. If you really have to write code ask why? What is it exactly that requires you to dedicate precious development resources and exactly how will it generate revenue or enhance customer experience. What metrics are being used to measure the performance of this delivery and who set them? I’m pretty sure you won’t get a very satisfactory answer to these questions.

There will, of course, be a need to write some code in commercial business, but it often seems to be the first choice where in fact in most cases it should be the last option exercised in the delivery of a new product or service. This is really what the principle of NoDev is espousing. As technologists and developers we sometimes think, rightly, that we have a Swiss Army Knife, and can therefore deal with all problem using it. I’ve rarely had the privilege of seeing a development team tell the project initiators that they are better off using a third party application or indeed question the validity of the project outright (but it has happened occasionally).

My next post will be on our second principle NoOps. Why on earth do have to have expensive, highly trained operations personnel carry out repetitive manual interventions using tools that were conceived and designed 200 years ago preciously to eliminate this wasted labour? I find this one of most abhorrent uses of computers, Babbage would have wept…