Opinion: Miracle systems, like miracle drugs, are more products of planning than luck.
People often treat IT in the same way that they treat prescription
medications. When they walk into the IT architects office, they dont
want to be told to make lifestyle changes like cutting fat from their
organization charts and workflows. They want a technology pill that
will make them better.
Like patients who watch too much TV and read too many articles,
enterprise IT consumers tend to demand that pill that they saw
advertised the other day -- regardless of whether its really the
cost-effective solution for their own specific problem. And they want
their IT doctor to anticipate and deal with any and all possible
interactions and side effects, at the same time that they hound the
good doctor to pile one solution du jour on top of another.
This phenomenon is not confined to the demand side of the IT
equation. IT providers can also fall into the trap that medical school
professors call "treating the chart instead of the patient." An IT
application development team can focus on a single symptom: an
underperforming business process, perhaps, or a manual system that
seems to be a candidate for automation. They can solve that single
problem; then another single problem; then yet another single problem,
and only gradually (if ever) come to realize that their proliferating
and uncoordinated systems have now become the problem; moreover, that
their approach has calcified obsolete practices in ways that will now
make them far more expensive to streamline and modernize.
If IT builders can fall prey to misplaced Dr. Feelgood thinking,
they can also avail themselves of the same process analytics tools and
methods that pharmaceutical companies are urged to adopt by that
industrys analysts and consultants. While reading a current article on
the Web site of "Pharmaceutical
Processing," I was struck by the ease with which I could mentally
substitute key nouns in my mind to transform the recommendations from
the sphere of drug development to that of IT systems construction.
"Pharmaceutical quality assurance and control are predominantly
based on data taken from relatively small test batches," noted the
author. Ditto for predicting the actual performance in practice of any
non-trivial IT system, and therefore ditto the need for rigorous
monitoring and follow-up in the field. "Building quality into
pharmaceutical products requires a thorough review of intended
therapeutic objectives, patient population, route of administration,
and pharmacological, toxicological and pharmacokinetic characteristics
[as well as] the chemical, physical, and biopharmaceutical properties
of the drug." Ditto for clearly stating the goals of an IT system, the
execution and end-user environments, the means of service delivery, and
the core characteristics and failure modes of the technologies to be
If people are going to use phrases like "IT professional," then they
should also make a conscious effort to adopt the disciplines of a
profession -- rather than following the paths of least resistance that
one expects of a technician. Its our duty to understand the problem,
not to cater to the patients preconceived ideas about how to treat the
symptoms. Its our obligation to solve problems without creating at
least as many new ones. Its also our role, sometimes, to give the
unwelcome news that an organizations way of life is the real problem,
and that nothing else will really work until thats changed.
Tell me what symptoms youre being asked to treat at email@example.com
Check out eWEEK.coms for the latest news, reviews and analysis on IT management from CIOInsight.com.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.