It has been asked if IT needs to break out of the mold that
has enveloped it. In order to move beyond its stepchild role of tending to the
messy details of data management and to come into its own right as a new game
changing force that is no longer managed by bean-counting CFOs, it has been
suggested that it must evolve. The hierarchies of database administrators,
application managers, and the like must fade away and yield to the brave new
world of big data, analytics, and ubiquitous information, all managed by a
flatter organization structure – in short, to go where no man has gone before.
In many ways I agree with the spirit of assertion, but I
disagree with it in one very fundamental way, namely that IT suffers from being
a corporate fiefdom in which the urge to control impedes overall business
profitability. One area is in charge of security, another area is in charge of
databases, another oversees change management, and yet another is in
responsible for application implementation. The list goes on and on and is as
long as there are discreet areas of specialization. While IT personnel tend to
be more willing to collaborate than perhaps other kinds of business people, the
collaboration is hamstrung by the processes that are erected to produce
plausible deniability in the event of an error that impacts other areas of business.
IT people, perhaps more than any other kind of enterprise employee – except for
lawyers –, have a great fondness for paper trails that authorize them to take
actions at the behest of another. The end result is that while the business
leaders of a company might spend many hours of time spread out over several
months before reaching a decision that impacts operations, IT’s involvement may
well extend beyond a year or more for implementation, and that almost always
calcifies an organization.
If implementation takes such a long time and incurs the
attendant heavy costs for so doing, it makes business leaders less prone to
respond quickly to basic changes in the market for what it produces. They argue
that changes need to be batched so that the scope of work is big enough to
justify the expense of the life cycle of software development to a board of
directors and shareholders. While not always the primary reason, this is
certainly one of the main reasons that very large companies succumb to small
startups whose wedding to the IT undercarriage of their businesses is not yet a
done deal.
One of the bigger problems that is created by both the
business and IT arms of an enterprise is the disparity of applications that end
up being selected to accomplish the goals of the company. Often those
applications don’t talk to each other unless they are forced to do so using
multiple kludges consisting of the IT equivalents of chewing gum and bits of
string. One system exports a comma-delimited text file to a directory from
which another system picks it up. There is no real interactivity and certainly
no real chance of gracefully handling data consistency errors. End users assume
that the screens that they see represent the company gospel, but only the IT
people know just how uncertain and how poorly understood the entire process is.
Errors creep in via the most unexpected ways and are often undetected for
months or even years simply because each corporate department functions like
the silos one sees on a Midwestern farm: corn in one silo, wheat in another,
and nary the twain shall meet. As a test of the verity of this situation, try
listening in on a discussion between a programmer and an accountant as each
geek-speaks at the other and denies that there is any possibility of doing
things any other way than that currently in use.
At the root of the problem is the way that IT is still done,
even in this age of object orientation, RAD, and AGILE project management. The
tools used to develop software are, to be quite kind, clumsy and intentionally
so. Why? It is because the makers of software development tools market their
products either to developers or to developers who have been promoted upward to
management. Software developers, at least all the ones that I know and without
exception, regard themselves as artisans who produce elegant, efficient code
and not as robots that spew out hundreds of thousands of lines of code. Their
interest is in having the flexibility to produce code that gets the job done
and which also has a certain “zing” that allows them to put their mark on the
final product. This code craftsmanship would be wonderful if businesses did not
find that they have to reinvent themselves every five years or so. Because the
tools are what they are, it is often necessary to engage more high-end talent
for the task than would be sought for a similar sized task in any other area of
business. This provides a strong inducement to hire contractors who are there
solely for the project. Since they are not likely to become employees and thus
part of the human pool of knowledge with respect to developed applications, a
great emphasis is usually devoted toward the production of documentation.
There are few developers who thrive when instructed to write
documentation. Generally, they don’t like to do it, and when they are able to
offload the task to one or more technical writers, even then they dislike
having to educate the writer about all the messy details that went into the
production of the end product. The consequence of this is that the produced
documentation tends to be inadequate to educate the next contractor who will be
called in to fix the application when it fails. The customary documentation
contains an overview of the project; a checklist for the setup of the database
and application; a database diagram; a list of stored procedures with their
parameters, data types, and output; a description of security features; and so
forth. Unfortunately, this is not all that helpful. What is really useful for
subsequent techs that come along later to support the application is a process
map that describes:
1. How the
various reports and lists that end users consume are produced from start to
finish,
2. What
stored procedures are used in each function of an application,
3. Which
stored procedures are dependencies of other stored procedures,
4. What
automated processes are scheduled by the IT department that are essential to
the proper operation of the application,
5. When
those automated processes run, and
6. What
other systems consume data or add data to the database for the application.
Few technical writers or programmers include such
information in the total documentation package because it is so tedious to
produce, and yet it is precisely the kind of information that allows a
contractor to “cut to the chase” when an urgent issue must be addressed. Absent
this information, the engagement of an outside contractor tends to be much
longer than would be necessary if such information were available.
Should IT become an ascendant business force within the
organization that allows it to step outside of the financial controller’s
managerial domain? I contend that IT has a long way to go before it becomes
qualified for such a promotion. At the moment, it is too much in love with insular
management practices that many on the operations and marketing side of business
have long ago abandoned. Even the venerable IBM, which one would suspect would
be the paradigm of an ascendant IT mentality, has placed limits on such
thinking. When it found in the 1980s that its ability to get more business was
being hampered by a glacial credit approval process, the first impulse was to
automate what already existed. Two very wise business managers sensed that this
was putting the cart before the horse since determining what was the actual
obstacle to streamlining this critical step in gaining more business had not
yet been done. They decided to walk a credit application through the process,
going from desk to desk, and found that automation would only have saved a few
minutes of time out of what was taking in some cases several months. The
solution that finally worked and which reduced the process down to a matter of
a few hours was one that involved changing business processes and elevating the
permissibility of its employees to make decisions. Yes, automation was
ultimately done to reflect this transformational approach to business
processes, but the automation came after the fact, not before it.
The changes to IT that are needed to make its work product
more useable is to produce development tools that end users can employ
directly. To a limited degree, we can see this now in the form of ad hoc report
generators and products like Microsoft Office, but this needs to go much
further. It should be possible for an end user to describe what information he
wants to collect, store, and reproduce; to draw a process using drag and drop
tools that portray the collection, storage, and reporting processes; to click a
button to have it created for him; and to enable him to edit the results by
changing the screen positions of created elements and by applying levels of
security. There are some tools that can do part of this now, but there is no
tool that is designed for the end user that will produce bulletproof, hardened
code that works easily and reliably.
The production of such a tool would idle many programmers,
but like factory workers of a century ago whose time has come and gone, the
same kind of sunset needs to be foreseen as a necessary part of the life cycle
of IT workforces. In such a scenario, there would be no need for an evangelist
from the IT department to woo and to lead the business users to a higher plane
of greater business efficiency, largely because achieving it as an end user
would be so facile. The purpose of IT would be largely that of preserving the
safety of stored data, providing advice with respect to some of the finer
points of using such tools, and educating users about new products. In short,
IT would still tend to be a glass ceiling occupation for many within its ranks.
IT employees often find themselves uttering, like Rodney
Dangerfield, “I don’t get no respect.” The way to address this imposed
inferiority complex is to invent a better mousetrap than the kind that now
exists. Smart people in IT need to stop taking comfort in the ways they have
always done things and to start having the discomfort of treading into new
territory that can conceivably yield a solution to business’ conundrum of
needing to automate but not daring to do so because of the expense.
To be sure, a clever programmer who succeeds in creating
very high quality end user tools will paradoxically make his own tenure less
predictable due to a reduced need for people just like himself, but it is going
to come eventually. It cannot be avoided. Just as Detroit was dragged, kicking
and screaming, from producing land yachts with fins, lots of chrome, and
massive engines, so IT will likely have to be dragged from its comfort zone to
a new place in which it excises the vestiges of manually implemented, imperious
digital resource control and replaces them with smart tools and processes that
are so reliable that most will regard them as nothing more than process
appliances that any employee could use.
Robert DeFazio is president at Calabria Consulting. He can
be reached at rdefazio@att.net.
The opinions expressed herein or statements made in the
above column are solely those of the author and do not necessarily reflect the
views of WTN Media LLC.
