Chapter 4 - The Futurist versus Archivist Paradox
At its onset, the chief problem in advocating technical solutions was building awareness of the capabilities and getting people interested - but now that the Internet and mobile devices have become "consumerized" the situation is reversed and there is too much demand for technology.
Enthusiastic users who wish to use their "favorite new technologies" are nothing new - but many more people are now enthusiastic about technology, and given the variety of technologies and the pace at which they evolve, it is not feasible to support everyone's flavor of preference right away.
Neither are IT departments particularly supportive of any technology that is not their idea. There is presently a great deal of resistance, under the banner of security and performance, to allowing employees to use their person devices to access corporate resources. It's the same cry raised a few decades ago by mainframe support teams when PCs started appearing in offices.
The net result is that, in terms of technology, the sense is that "when I come to work each morning, I feel like I am stepping back in time," given that employees have more access to more, newer, and better technology in their private lives than they have at work. Which leads to another paradox: the more your employees love technology, the more they dislike their own technology department.
The author obliquely relates the problem of work backlogs: managers do not generally have idle workers that can spring to work at a moment's notice - everyone is already engaged in meaningful work - such that when something new pops up and there is significant interest in having it (and not in hiring the resources to deliver it), it either does not get done, or gets done at the expense of other things.
Moreover, the "other things" people are working generally entail ongoing maintenance of existing systems: the new IT manager is carrying forward the weight of his predecessors, sometimes providing constant intensive care to decades-old systems that are still mission-critical and cannot be abandoned or neglected for other work. Few executives in other departments are as chained to the past and, ironically, few executives in other departments are expected to plan for the future in the same degree.
Learn to Sell Legacy Improvements
A common problem in all technology departments is a devotion to legacy systems, which require so much attention that little else can be pursued.
One method to finding space to innovate is to consider it within the context of legacy systems: there is much that can be done under the guise (or umbrella) of maintaining the old system, and the occasional instances in which a legacy is being replaced provide significant opportunity to include new ideas as features.
One way to make the case is to develop a map of existing systems - few companies seem to realize their enormity and complexity - along with a legend that indicates how often they fail. In one example, a company developed a "heat map" of eight critical applications, which showed that 45 of them fai8led at least once a month. This enables you to communicate how much of your time and resources are spend on maintaining mission-critical applications, the reason you people haven't the time to dream up improvements is because they are busy putting out fires in the engine room.
This is valuable because, unless this is known, many CEOs are under the impression that, as the salesmen likely suggested, systems take care of themselves after being set up. When you can show the network topography, the number of help desk calls about outages, and map one against the other, you're ready to move from an emotional discussion to a fact-based conversation.
Another exercise from the same CIO was to develop a map of data resident in current systems and applications - asking the CEO what he might want to know about a customer, and showing him where the information resided and what path it would have to take through the various systems to get where it was needed.
The author speaks of the "burning platform" - the combination of systems that, if they were to go out, would stop the business dead. This drives home the importance of the information systems in place, and makes it clear to the business why investment in the stability and efficiency of these systems is a worthwhile investment, not something that can be neglected to pursue a whim.
All of this seems to point to recognizing the value of legacy systems and convincing others that you need additional resources to be innovated of build something new. There's also the explicit warning "don't turn your infrastructure people into change agents," as they are often wedded to the systems they maintain, and likely disinterested in anything that threatens to change or replace them.
Focus on Architecture
There's a pause to consider how often there are significant changes or "paradigm shifts" in information technology. Every several years, something comes along that completely turns IT on its head - and this is not true of any other part of the business. Double-entry bookkeeping hasn't changed much since its appearance in Venice in the 1400s, nor have human resources or marketing undergone transformational changes - yet IT does so repeatedly. Is it any wonder that the CIOs colleagues have no understanding?
(EN: This said, I wonder how much of it is self-inflicted. That is, if accounting hasn't changed since the time of mainframes, why aren't businesses still using mainframes to do their accounting? Or more aptly, why does a business that uses a mainframe to do a task that has not changed since seem ludicrous? I strongly suspect that IT departments made their own beds in this regard, "selling" a new accounting system that did nothing different or better than the last one, for the sake of using a newer technology to do the same things.)
The last big thing for IT was systems integration - or at least data integration - to bring together a number of disparate vendor systems so that data can be shared and redundancies eliminated, which still remains only a partial success from most companies. This often involved third-party software to bridge the gap between other third-party software, which was a mid-term solution to developing a service-architecture. In turn, this has been abandoned to pursue something else.
The problem is not technical in its nature: the systems architects can figure out a way to get the companies data systems communicating with one another - the problem is in commitment to actually build what has been architected.
Just Do It
The paradox of legacy-versus-innovation is exacerbated by legacy systems that are a total mess - they barely function as they were originally intended, and extending them to do more is highly inadvisable. How do you innovate on a broken platform?
The author turns to healthcare: how amazing it would be to take make all data about a patient accessible via an iPad like device throughout the hospital, and across the healthcare system. The problem is that existing systems are so specialized, opaque, and stove-piped that they cannot share information, and are even worse than paper-based medical records.
Some of the practices put in place by one healthcare systems provider pave the way for mitigating further damage to start the healing process:
- No more shrink-wrapped solutions. All such solutions come with the same fundamental flaws: they are rigid, don't play well with others, cannot be customized to work as needed-, and are decidedly one-sided in favor of keeping the client dependent on the vendor.
- Find the innovators. Rather than firms who are incumbents in the industry and have settled ideas about the way things should be done, seek fresh ideas from technology experts outside the industry, who are excited to discover what is possible.
- Be flexible about data. A solution that requires all data to be consolidated into a single gigantic data warehouse is no more flexible that a system that retains all data in a proprietary data source. Systems must be flexible enough to take data where they can find it, and leave it where it is.
- Separate performance from analytics. The analytics that are built into vendor systems are rigged to show that the systems is working well. In order to get real insight, use a different source to analyze the performance of systems.
- Become client-agnostic. Back-end systems should be entirely indifferent to the device used to access their data. Given the adoption rate for smartphones and tablets, a device that can only serve data to a desktop PC will soon be archaic.
As an aside: consider that many people have two devices - the one they were issued for work, and one they pay for themselves. That's significant evidence that their employer's choice is not suitable. Once CIO, in choosing to do away with company devices and instead subsidize the employee's device of choice, commented that the firm might not be able to play to were the puck is going, but should at least play to where it's at.
(EN: I expect there's some counterpoint about the difference between "business" and "personal" devices - but given that most voice/data plans are all-you-can-eat, there isn't much validity to that argument anymore. On the other hand, many firms lock down company-owned devices for security reasons - your business email contains sensitive data - though when a device must be crippled in order to be secure, it says something about the company's technical competence and level of paranoia.)
Tighten Your Connection to the Business
In the present workplace, technology permeates the organization and is embedded in everything people do. Meanwhile the IT department remains detached and isolated from the rest of the organization. And at the same time, it's increasingly easy for any business executive to hire IT work outside - which leads to yet another CIO paradox: being held responsible for the performance and security of systems which business peers purchased without their input, or even against their advice.
The author has encountered some objection to the suggestion that IT should seek a closer relationship with business - some CIOs prefer to keep a distance, such that the business is required to innovate and identify their own technology solutions, which the IT department will support. In essence, such technology executives have given up and accepted a supporting role.
Depending on the firm, it may likely be a balancing act - between serving and leading. The author maintains that IT should be more than a passive supporter of business decisions. At the very least, It should ensure the stability and security of the technology the business wants to purchase. Better still, the IT department can help analyze alternatives and make recommendations that consider not only the immediate goal, but they way in which the desired solution plays with the overall architecture, to prevent fragmentation.
One tactic in retaining involvement is to use the data to show that the organization's systems are more secure and cost-effective when IT is involved in technology decisions. He suggests that being able to leverage the numbers is critical to address the paradox and regain control. (EN: I sense this is an overly simplistic approach - there are other factors that cause business units to regard their own IT department as a poor service provider - that the author dismisses them as emotional and irrational suggests she doesn't quite get it.)
There's another bit, heavily skewed but not entirely invalid, in which the author implies that business units behave like spoiled toddlers and expect IT departments to fix things immediately - no response is ever fast enough to please them. As such, IT departments have a reputation for indifference and failure to overcome before they can win trust and cooperation.
Installing a client-management function in the IT department has also been successful for some companies: this gives business units an account manager from IT who is involved in all their technology efforts and can develop more of a relationship with business partners and help to encourage a more inclusive and less fractured approach to technology.
There are a number of different roles that serve client-management functions: account managers, solution designers, enterprise architects, and others who must have familiarity with the business as well as technical expertise - and as such have the breadth of vision and frequency of involvement that can be leveraged to build an ongoing relationship and partner with the business.
There's some talk of people with a blend of technical and business expertise being "rare birds," and some caution about hiring consultants into this role. While they have seen a number of approaches in a number of firms, they tend to be acculturated to a fast-paced and short-term perspective and have never had to live with the long-term consequences of their decisions. Not all can make the adjustment, and some can do considerable damage.
(EN: This really doesn't provide a workable suggestion, and it is also one-sided. In my experience, a person who claims to be expert in both areas is strong in one and weak in the other. However, if a strong technical person on the IT side who has some business acumen can get together with a strong business analyst on the business side who has some understanding of technology, the two of them can collaborate ... provided they are not encouraged to combat one another.)