Few weeks ago, when I published the article “The Future of IT”, I was planning to write something about technology.
But, as most bookworms turned practitioners, I know that a white page is tempting.
Most writings about the future are actually the typical side-effect of an attempt to find order within chaos- notably when it is an unknown chaos that you are trying to describe.
This article is published in four parts (no more than 1000 words each).
Of course, I tried to keep it readable- no more than 150 to 250 words per section.
This is the second article: destination.
My approach to change is: ask what the customers aim to achieve, understand where they are, assess the resources available, propose an itinerary, and, if needed (e.g. due to lack of resources), identify a realistic alternative target.
The sections:
Building blocks
Cash&carry IT
Hit parade IT
E-procurement on steroids
Building blocks
I closed the previous chapter discussing an approach to IT systems that includes stakeholders as an organic component of systems’ evolution.
As hinted in the introduction to this chapter, I prefer to discuss the future immediately, and then try to match with the available resources, before defining a “roadmap” to produce the desired change.
But future is built on the past- like in a Lego bricks game, you use what you have to build what you would like to have.
In IT, probably the last two decades have been spent on trying to standardize, engineer, structure, convert software into a commodity.
In the early 1990s, I was presenting and selling CASE tools, to generate automatically software, reverse-engineer and re-use approaches used to solve problems (algorithms).
I think that I have developed in my career dozens of visual representations that were just adapting the same patterns, with minimal differences, related to the specific needs of the specific customer.
Developing pattern-based software is an interesting approach, mimicking how we think and learn.
To stay within my self-imposed writing limits: a pattern is something that allows you to match a new experience with a previous experience, and limits your real learning to just truly new differences.
The interesting part is that patterns allow to introduce an “organizational memory”, as new patterns are anyway related to the closest ones, and new experiences re-enforce existing patterns.
If you want: good-bye, software and hardware packages; welcome, IT Lego bricks.
And IT systems? Just plug-in.
Cash&carry IT
The main side-effect? Instead of a software or hardware, you would have a pre-packaged solution to deliver a certain behaviour, based on the information that you provide.
And, as any brain pattern, it would not be limited to just one dimension: some patterns require a complex response.
The interesting part is that this approach could also convert any IT system into a service provider.
If you develop a new pattern, why not recover your investment by using a marketplace?
The pattern would include more than lines of software- processes, skills required, personnel profiles.
Replacing software publishers with IPR lawyers and online marketplaces.
And creating a new professional role: the “catalogue experts”.
But if you were an IBM mainframe system expert in mid-1980s, you were already doing that.
The system was so complex and diverse, that, as a senior expert from a large customer told me, “the real experts are those who know in which manual is the answer”.
If you want- whenever your own catalogue of patterns does not deliver a match for the new behaviour or “organizational experience” that you want to introduce, your own catalogue experts would go and scout for patterns close enough.
Maybe they would find a perfect match, describing the organizational and technical requirements (and, yes, the software/hardware components).
Or find a set of patterns that, combined, deliver what you need.
In this case, they could involve the technological and business experts to create a new “bridging” pattern.
Or create a new one.
Hit parade IT
And then, maybe after six months of exclusive use, start selling online the re-use rights to this new “organizational experience”.
If you read the previous chapter, you know that I consider IT systems development as an integration between the company and its environment- used to be called a “systemic” view.
If a new social or economical phenomenon requires a new regulation, I assume that the legislators will try to follow the same approach followed in regulations covering similar issues- to reduce the overhead on companies and institutions.
And laws and regulations are changed according to obsolescence, social pressure, etc.
If you worked long enough in IT, you know that usually systems are built by “layering”.
You keep old software and hardware (and associated processes or activities) because some bits and pieces are missing.
You keep WindowsNT PCs for applications whose publisher disappeared, along with the software sources and documentation.
You need to keep all the associated organizational and technical components, often impacting also on new ones.
Before building a new infrastructure, you have to survey and assess what you have already in place.
Moving to the “organizational experiences” approach, anybody involved (users, developers, managers, customers, suppliers) could “vote” on a specific experience, and that could feed your innovation.
Of course, there would be some “organizational experience” that, however low rated, would not be replaced- if it’s the law, it’s the law.
The issue is: understanding if a new “organizational experience” is producing a positive return on investment.
E-procurement on steroids
No, I am not advocating evolving IT systems by SMS voting.
But having a constant and automatic monitoring on how each investment on a new “organizational experience” is matching business needs could help in improving the evolution of IT budgets.
Anyway, you are already working by patterns.
Also when doing a new budget from scratch, you use prior experiences to guide you in identifying the budget lines and the allocation of funds to specific initiatives.
If you were to consider an “organizational experience” as a package, suppliers could “bid” on how to replace an existing provider, but knowing also the associated costs, instead of just “forgetting” some details (e.g. that you will need a new network infrastructure to support the new software).
Something similar is already used in outsourcing- but, except for some basic tasks, it is not so easy to change outsourcing supplier.
Moreover, most companies when outsourcing forget to keep the knowledge inside, assuming that the outsourcing provider will do it for them.
The concept behind shopping from an “organizational experiences” catalogue is that you look for what you need based on what you think you will provide to your customers or stakeholders.
Some options could deliver a fully outsourced process- you dump data in, receive data, and all the other activities (including customer support, etc) will be managed outside.
Or just deliver you a software embedded in a physical machine- again, you dump data in, receive data, but manage the relationships with your customers.
Tags: AGB2009, AGB2009SUMMARY, commodity, computing, department, FIT2009, future, ibm, information, innovation, it, microsoft, msp, prince2, summary, technology