My first computer was a ZX Spectrum 16K. It was actually a birthday present for my older brother, but within a year of owning it, my brother gave it to me to settle a debt between the two of us. I was only 8-years-old, and given that experience, I feel I can safely say I have a lifetime’s worth of both computing and finance experience.
As a career technologist now working for a tier 1 global bank, I’ve had time to reflect on the lessons I’ve learned, and I’ve developed three key principles that guide my IT decision-making. I refer to them as the “KnowIT principles” to make them easier to remember and communicate. My hope is that by naming these principles it will encourage others to elaborate and critique them, thus increasing their value to the community at large.
I stress to the reader that these principles are just that, propositions that serve to inform decision making. In the overwhelming majority of cases, I believe they will help you arrive at a good IT decision quickly. They are not however, laws to be obeyed without thought or reason.
Redefining what “computer” means
To best understand how I developed these principles, I believe we have to redefine a word that is at the center of IT - “computer.” The various definitions of the word "computer" offered up by the Oxford English Dictionary seem outdated with their focus on calculation. 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 to 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, here are the three guiding principles in the KnowIT management ethos.
1) 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 may be 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 the 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. It has been predicted for decades.
Acting in recognition of this long and maturing trend, it is incumbent upon IT decision makers to exercise far greater control in the approval of any project that demands internal development effort. 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.
2) NoOps - The term NoOps is not new (unlike NoDev for which I have found no precedence) and I strongly recommend readers visit Adrian Cockcroft's Blog: "Ops, DevOps and PaaS (NoOps) at Netflix" where he explains:
This is part of what we call NoOps. The developers used to spend hours a week in meetings with Ops discussing what they needed, figuring out capacity forecasts and writing tickets to request changes for the datacenter. Now they spend seconds doing it themselves in the cloud.
All the activities described above, the information exchange between developers and operations, capacity forecasts, change requests, etc. are needless dependencies created between developers and operations that, once removed, naturally allow the simplification of processes, their standardization and ultimately their automation.
Simplified, standardized process with broad adoption and use are the ideal targets for automation. They yield the largest benefit in terms of productivity gains per cost unit and also have the benefit of increasing stakeholders’ confidence in IT every time a process is quickly automated. Once a culture of automation has been created, a virtuous spiral of Simplification, Standardization, and Automation is established, resulting in continuous improvement.
Bonus: A culture of automation will also attract the right kind of talent to the business, i.e. knowledgeable workers who want to generate value for their co-workers and customers, not IT workers who want to plumb hardware into datacentres.
For me NoOps is simply the way I would design my IT systems given the constraint to maximize productivity (profit) while securing the business.
3) NoIT - Eliminate IT systems that demand the attention of humans.
To put it another way, when you decide to introduce that shiny new risk tracker, architecture taxonomy repository, knowledge management system, document management system, procurement system, etc, etc, etc, if the intent is to expose these systems to others to populate with data and use, then it has to be the responsibility of the team that is introducing this system to ensure the highest standards of user experience. The highest standard of user experience for any administrative function is that the user doesn't experience it at all.
Let me be clear, I am an advocate of self-service, but only for services that improve my productivity, not functions that are required to satisfy the administration of the business. The distinction I draw between a service and a function is simple, services generate revenue, improve productivity and create value. Functions pertain to process efficiency for administrative, bureaucratic, audit, compliance and regulatory demands. Well-designed functions can save time and money, but they never generate revenue.
The notion of NoIT also includes these two assertions:
- Use IT to expose services to customers and employees, not administrative functions that should be carried out by specialists. It is easy to spot when a function is being exposed to employees in the guise of a service. When you attempt to use the "service" you end up learning a huge amount about the underlying process from all the various people that you have to liaise with in order to guide you through the system. In effect, all the IT is doing is shielding the team responsible for the function from doing their work. Instead it is offloading the work to unsuspecting employees that have ended up straying into an administrative malaise.
- Eliminate IT duplication across the enterprise. It's bad enough to have to deal with a myriad of administrative IT systems that demand human attention, but the problem is compounded by duplicate and competing systems owned by different divisions. Sometimes the duplication is in IT services as well, for example having two "Enterprise Standard" service buses.
These three key “KnowIT” principles continue to guide my IT decision-making. Again, I do not see these as laws that must always be obeyed. But as it becomes increasingly important for IT leaders to make good decisions quickly, they help save me time.
What do you think of these principles? Do you have any of your own?
Hussein Badakhchani, is a distinguished technologist with over twenty years professional experience of applying IT to business goals in Finance, Banking, Biotech and Telecoms sectors. Hussein's current focus centres on innovation and transformation. Liaising with startups in the FinTech sector, Hussein acts an enterprise entrepreneur involved in all stages of the service delivery life cycle. Combining deep technical expertise with commercial experience, leadership and a passion to deliver value, Hussein has spearheaded both regional and global, innovation and transformation programmes.
