Like most people, I’m a sucker for a compliment. So, when I received one via e-mail in response to my June/July column on “Ethical Computing,” I had no choice but to respond to the writer of those kind words. She wanted to know whether I had ever seen a job description for a business solution integrator. I told her that I had not, but that this would make a good topic for a future column, so here we go.
Having served both as a functionary within corporate IT and as a senior consultant for a couple of international systems integrators, it seems clear that the meaning of integrator is really what is at issue in this job title. Integration, the word from which integrator is derived, is a marketing term almost completely devoid of meaning these days.
In the ’90s, a friend of mine wrote a book in which she identified at least 119 definitions of the word integrated based on her reading brochures from vendors of network management software products. Integrated software meant everything from “sharing a common code base” to “sharing a common database” to “providing a common window from which many applications could be launched” to “listing many software products in the same brochure” (which is still a popular use of the term). Many storage management software suites today carry on the tradition of offering what I like to call “brochure-level integration.”
Clearly, a business solution integrator is tasked with integrating technology to solve well-defined business problems using available technology. Such a person would have a Herculean set of tasks to fulfill and would require a substantial and rich background of knowledge and experience, gained from hands-on work with a wide range of technologies, to do his job.
By my definition, a business solution integrator would first need to understand the business process (and its objectives) for which a technology solution is being sought. He would need to understand the business process within the context of a web of processes in which it exists to perceive its dependencies upon and contributions to other workflows.
Second, the business solution integrator would need to understand business parameters that set limits on the range of technology options that can be considered as potential solutions. This involves the identification of budgetary, regulatory, legal, and cultural constraints, and an appreciation of those parameters from the customer’s point of view.
I emphasize the customer’s point of view because the customer is paying the bills and is therefore always right— even if the customer is objectively wrong. Objectivity is the hobgoblin to which many of the failed business process reengineering efforts fell prey back in the ’90s. While there may well be, objectively speaking, better ways to undertake a specific business process, or even ways to change other business processes in order to make a new business process unnecessary, it is the business leader’s job, and not the solution integrator’s job, to identify the process changes that may be required.
Understanding the business process and its context, and having set up parameters for an acceptable solution set, the business solution integrator must next turn his attention to the problem of finding suitable technology options. Suitability is defined by several things:
First and foremost, a suitable technology will have a solid business value case—one that can be defined and measured in terms of cost-savings, risk reduction, and business enablement. The integrator is proposing to solve a business problem and should be able to frame his proposal in business terms.
Second, a suitable technology option should be compatible with technology already deployed or planned for deployment by the company. A radical departure from current technology “standards”—regardless of the good intentions of the integrator—is the proverbial road to Hades.
Finally, the technology option must be internally sound and suited to testing prior to deployment. Internal soundness means several things: It should be vendor neutral— if possible, standards-based—if practicable, and, of course, it must work as advertised. The solution should also be proposed with a comprehensive testing plan and methodology to validate assumptions and limit financial exposure for the customer.
A business solution integrator who can understand a business process, appreciate its context, and identify appropriate technologies to meet requirements is worth his weight in platinum. However, he is not worth as much as an integrator who can do all of these things, plus communicate effectively. Presentation skills, writing ability, and good, old-fashioned confidence, empathy, and diplomacy cannot be taught in school. They can, however, make or break the effectiveness of the integration effort.
Hope this helps, Deborah, and thanks for writing! Z