The Costly, Damaging, and Futile Myth of Business & IT Alignment

Replacing nonsensical ‘business and IT alignment’ with a newer, better environment

Contributors: Chris Foulkes and Neil Walker

“We’re not having fist fights but we don’t have lunch together…” a typical response to the question “How aligned is your business with your IT?”

As the “ERP Era” comes to a close and the market consolidates a shift to “Digital Transformation”, hoary old institutions should be cast aside in favor of organizations that empower business people rather than shackle them to “IT-engineered” processes.

Business Oil and IT Water. Align This? 

The term ‘information technology’ first appeared in a 1958 article published in the Harvard Business Review (Harold J. Leavitt and Thomas L. Whisler) with the comment, “the new technology does not yet have a single established name. We shall call it information technology.” Whatever we have called it since, it has required “alignment” with “business” and in this regard, it has tended to disappoint. Data Processing or Electronic Data Processing or Information Systems or Information Processing or Information Technology or Infotech or The Computer Center. The same dysfunction, the same disappointment.

The earliest IT departments date to the 1950s, when they were referred to as Data Processing Departments. In this decade, business computing made its initial expansion beyond pure accounting functions which were mathematical in nature to more complex business functions which are more process-oriented. From the outset, the arrangement was one in which business people expressed their needs to technical people, who then engineered a solution. At least, that was the theory.

Such was the origin of the recurring dynamic spanning the years since that article appeared in which business people have claimed: “I asked IT for a horse and got a cow.”

A perpetually rocky working relationship between business and IT, characterized by the gulf between the two in terms of culture, language, power curves, and priorities, has been the single greatest impediment to business and organizational evolution.

Senior management abdicates its business responsibilities by confiding key business software projects to ‘technical people’, so…

…IT strategies are too often focused upon technology and do not adhere to or advance the business strategy…

…resulting in the majority of major projects, especially for business software implementations, being very late and very over budget…

…as well as business processes being frequently over-engineered and thus user-hostile and thus inefficient when it comes to business process execution.

This is an arc of failure that has been repeated, from industry to industry, large firm to small firm, public sector to the private sector, and sea to shining sea for nearly six decades. Is not the “sell date” on this unwieldy and inefficient arrangement long past due? Can we conceive of an end to these sixty years of nonsense and work in a way that does not require impractical “alignment”?

Stop ‘Aligning’ Business and IT. You Will Never Succeed

Since 2001, CIO magazine has provided State of the CIO reports based on surveys of hundreds of chief information officers. Each year since, we find that CIOs persist in expressing a high priority given to business and IT alignment, whereas tangible evolution in this regard has not occurred except in rare instances. Interestingly, a 2004 CIO article asked “Why is Business and IT Alignment So Difficult?”

The most obvious answer to that question is that business stakeholders and IT leaders talk past each other (Mars vs. Venus). Business leaders often leave it to IT to plan for their systems needs while being unable to tangibly express those needs. IT leaders too often interpret business requests in engineering terms rather than business outcomes and the result is the construction of beautiful bridges that lead to nowhere or quite simply not to where they should lead.

Consider this stone-cold fact: The mere use of the term ‘alignment’ tells us that business and IT are disparate entities in need of alignment. In fact, once companies created the first separate IT departments, they created the alignment problem.

Even the term ‘business and IT alignment’ provides misdirection as it presumes an equal partnership between the two entities. While the working relationship can be termed a partnership, business must always be the senior partner because ITs only role is to serve business needs. In brief, business benefit is derived from applications, not technical platforms.

Expand the Business Blueprint Role so IT Will Not Fill in the Blanks

In past years, we heard about an ‘insidious and growing problem’ best known as “shadow IT” in which business personnel were increasingly investing in their own chosen applications while circumventing the IT budget procedures. Such spending was viewed (especially by IT management) as a damaging and rogue degradation of corporate IT disciplines and a sure route to business chaos.

However, as George Bernard Shaw observed, “all great truths begin as blasphemies.” Thus, through time and continued persistence of business leadership, what was once rogue became more and more mainstream and more and more best practice.

Going forward, business leaders must be the ones deciding what assets are required, how they will serve, and what they will provide. They should not have to learn all about the technology to be deployed any more than an airline fleet coordinator needs to understand jet propulsion, lift and drag, or Isaac Newton’s three laws of motion. But these business leaders do need to know how to express their needs in ways that will properly guide technologists charged with furnishing the requisite assets. They must be required to adhere to investment guidelines and to heed the contours of “doable” technology as in dialogues with IT such as:

Scope Limitations:

Business:   We are planning a voyage to Mars.
IT:    The technology, at maximum, can only get you to the moon.

Budget Considerations:

Business:   We are strongly considering telepathic reporting.
IT:   That feature costs three zillion clams. Our budget would have to be tripled.

Infrastructure:

Business:   We’re very enthusiastic about the new 12 terabyte Zoom Phone
IT:   Please leave the infrastructure to us.

Over the years, partial solutions to the ‘alignment gap’ have multiplied and usually contribute to a continued hierarchical layer of ‘hybrids’, in which people with operations backgrounds are assigned to IT to serve as translators and liaisons between the ‘business stakeholders’ (and their end users) and the ‘techies’. A formal name has even been given to such hybrids: Business Relationship Managers or, of course, the three-letter acronym, BRM.

Such a sprinkling of business acumen into a cauldron of technical engineering has only slightly improved ‘alignment’ and has not solved the root problem; i.e. that ‘alignment’, even at its apogee, is not mutual comprehension. An even more obvious white flag of surrender has been introduced by MIT, which has, in recent years, launched the subject of ‘data translators’ in big data and analytic endeavors to bridge recognition failures between analysts and the decision makers they support. The Italians have a useful saying for such a situation: “Traduttore, traditore”. Figuratively: “to translate is to betray”.

For more than fifty years of badly aligned business and IT, benefits of implementation efforts are too seldom satisfactory and the costs of IT have continued to climb while tension between business stakeholders and IT management continues to climb as well. While it is normal that CIOs are required to be change agents as well as custodians of current IT operations, it is, for them, excruciating to have to serve as arbiters in the constant struggles between business and IT leadership.

Today, a new generation of directors and managers embraces technology in ways that their predecessors did not. Personal technologies or Internet-of-Things devices have proliferated to such a point that today’s generation of management is often more in tune with new technologies than are their IT counterparts, and they are certainly more creative in how to use them to address their specific business requirements. They should no longer be required to negotiate with IT (with translators!) as some equal partner in the course of defining what assets they will possess and how they will be deployed. By the same token, IT should cede its place at the functional design table once and for all.

This does not entail a simple concession on the part of IT. In fact, much more is required of business than has been asked through previous decades. The business group, with IT now removed to a more arms-length distance, must provide more than a box-arrow-box chart and accompanying script for each of the major business processes. Such a scenario leaves too many blanks to be filled in by engineers who often know little of business process and nearly nothing of the stakeholders’ current business context. Thus, in the new environment, business must define and articulate, at minimum:

  •  A business strategy that exceeds the “bullet point” style of best intentions and is instead underpinned by numbers so that actual performance can be monitored and business process adjustments made in response to numerical (i.e. factual) reality rather than literal (i.e. perceived) results
  • An operating model and process map that covers the major processes to be enabled
  •  A business measurement layer for each major process at the key performance indicator (KPI) level
  •  A governance model that addresses all processes and their adherence to the strategy
  • Both a process maturity model and performance dashboard to guide continuous process improvements and monitor their efficacy.

Once this work is completed, a comprehensive business specification can be given to a coding or development authority. The fact that business now covers the above-listed bases helps to assure a coherence and complete specification and vastly reduces the perils of IT developers popping in for regular ‘clarifications’ that have historically led to disconnects and, by extension, disrupted business design and project time and cost overruns. The nearly complete separation of business and IT leaves a minimum requirement for them to ‘align’ and allows each to follow the disciplines that are inherent to them. And no more getting lost in translation.

More IT Simplification:  Shelter What is Strategic; Farm Out What is Not

One of the more frequent questions posed by IT leaders in regard to business applications is: “Which applications should be maintained in-house and which should be outsourced?”

Three reasons are often cited:

1. Provide more predictable costs
2. Bridge a skills/expertise gap
3. Free up staff from banal maintenance to concentrate on more strategic issues

Clients who cite reason number one lack vision. Bridging a gap in expertise is of course justifiable but is specific to only a fraction of support needs. Business and IT governance are best served with reason number three.

The most pragmatic and profitable fulcrum as to whether or not an activity should be outsourced is the measure of its strategic value. To work out which processes deliver strategic value, you first need to know what your processes are at the macro level, and how much they are costing your organization. Anticipated cost and benefit need to be reality-based and should adhere to an equally coherent business strategy.

If your organization is following the more elaborate business specification described in the preceding section, this will already be done.

‘Sheltering’ (i.e. improving and maintaining) your strategic applications may best be accomplished in-house. Advances in the application of Agile as an intimate and credible design method have positioned its suitability as a guide to such sheltering, with one proviso: The engineers tapped to scrum with business stakeholders must possess a minimum level of continuity and business process acumen in order to be sufficiently steeped in the business end of the exercise. When Agile fails, it is often because of a frequent changeability of engineers who are thus working without sufficient contextual background. They are tourists, not natives, and as such do not effectively ‘align’.

In this light, organizations need to downplay the notion that business process change is project-based. If it is viewed as such, the IT/technical resource provided will be viewed as temporary and, as projects end, this resource will be slated to disappear, only to be replaced by yet another “tourist” when the next round of process change work is embodied in a ‘project’. Business process change is common and perpetual. Thus, it is highly recommended to keep a permanent team together to address permanent change.

We are now moving into an era of what IDC has dubbed “hyper-agile” application deployment technologies and approaches. In laymen’s terms, we are taking the algebra and mystery out of programming and moving from “coding language” to “human language”.  The replacement to “code” may not necessarily prove  to be “hyper-agile” but at least can be human recognizable as opposed to hyper-formulaic.

In recent years, we have moved into the realm of Low/No Coding whereby, in the No-Code corner are the ‘citizen developers’ – business users who can build simple, functional, and limited applications without having to write a line of code. On the Low-Code side we find professional developers working in simpler and more streamlined fashion with a low level of “coding”.

Is this disruptive to classical IT? Yes, it is. And it is high time for such disruption to occur.

To this last point, it must be noted that technology remains relevant for every facet of an organization and the shifting of classical IT roles in no way diminishes its overall importance. How technology serves the business is what must change and the arrangement described here should be every bit as liberating to embattled IT “wonks” as it is to frustrated business “grinds”. These people might even start having lunch together again.

The IT department of the future should fill four basic roles:

  • Vet continuous process design provided by business for viability as described above.
  • Manage outsourced software development (coding) and maintenance based on the designs provided by business where applicable.
  • Acquire, manage, and maintain all required infrastructure.
  • Provide advisory and recommendations regarding emerging information and communications technologies to business stakeholders and take a lead role in acquisition and deployment justifications.

Prior to outsourcing support for non-strategic applications, they should be simplified to absolute minimal complexity (which may well involve stripping out decades of activities that no longer have any purpose and are thus obsolete).

Here is a comparative quadrant that should guide your decision-making:

Never try to outsource unnecessary complexity and avoid keeping non-strategic tasks in-house.

The result will be a far more streamlined, less expensive, and relatively stress-free mission of evolving business capabilities through information and communications technologies.

Now is the ideal time to partition business and IT in such a fashion. The emerging viability of what has been somewhat arbitrarily grouped into ‘digital transformation’ assets (Big Data, Machine Learning, Internet-of-Things and Analytics) can only be successfully adopted by an organization with an efficient and credible foundation of integrated business applications. With business stakeholders firmly at the wheel, such efficiency and credibility are more easily achieved than through an alignment effort that has been a dismal failure since the days of manual typewriters, hi-fis, black & white television, and rotary telephones.

CEOs and other business leaders wishing to hear more on this subject should give strong consideration to attending Enterprise Africa Summit 2019.  Read about it here.