Embracing the “Chief Integration Officer”

Like Tweet Pin it Share Share Email

Between real innovation and lots of marketing, the IT world is awash with newer, better solutions—for a specific business need or part of the organization.  This is a great time for software entrepreneurs and people with specific itches that need scratching.  Your business colleagues are finding amazing, innovative solutions they believe they can easily implement on their own. Whether it’s a SaaS tool, a mobile app, or an Excel plug-in, IT’s friends in the business think they can pull together a solution without involving the IT organization. We have arrived in the Golden Age of Shadow IT.

This column has talked about Shadow IT (aka “rogue IT,” aka “DIY IT,” many times before , and this particular blog post probably won’t be the last. What we Professionals need to do is change our way of thinking about this, and embrace the change, starting here, with a shiny new title. From here on in, “CIO” stands for Chief Integration Officer.

Well, what in the ham sandwich does this mean?  It means that our job has always been to focus the organization we lead on the hardest IT problems. And integration, my friends, is, of all IT’s responsibilities, front and center as the hardest. It’s harder than Operations (let me know if I need to address this in a future post). It’s harder than coding new functionality. And it’s harder than configuring COTS solutions (commercial, off-the-shelf solutions) to support how the business works.

What makes integration so hard is that, as someone once said, software is just an opinion. Integration means reconciling differences of these opinions – as hard to do with software as with human beings who disagree about political points of view.

I don’t mean to pooh-pooh all of the other priorities that you are also juggling. Security gives us all night terrors, legacy systems might stop “keeping the joint running” (sorry), and user support or hardware takes up a lot of time.

But integration matters more. To understand why, explore what happens when you don’t have it: “swivel-chairing” becomes the norm for creating a unified view of business data; manual re-keying becomes the norm for data synchronization; and when a business manager asks a question of two different databases they get conflicting answers.

Meanwhile, vendors are churning out useful solutions to vexing business problems, and at a pace internal IT can’t hope to match. Which is why addressing the need for integration by trying to stomp out DIY IT is like King Canute ordering the tide to stay away – a hopeless strategy. It’s why IT must master the fine art of Integration Engineering to meet these challenges. And it’s why CIOs must become Chief Integration Officers.

This change in perspective shouldn’t trigger our territorial instincts. That vendors are providing great solutions to vexing problems, and business users can deploy them without impinging on IT’s bandwidth, means everyone benefits. We’re merely changing our focus to where we’re needed the most—ensuring there is a clean, safe, complete architecture that meets the organization’s goals – especially its integration goals.

Over the years at the company I work for, we have found that the more we build integration into how we work with our clients’ teams, the more our clients trust us to deliver what they need the most, building friends along the way. We are seen as allies, slaying dragons together, as dragon-slaying entails managing the complex, multidimensional challenges of data models, asynchronous system event timing, creating a common operating picture, and creating fused information products that propel data-driven decisions.   Embracing integrations as a principal competency of our work helps eliminate the classic “Business vs. IT” nonsense that drives all parties crazy.

If you’re a CIO, this column is meant to convince you that your job title is changing. If you work in IT’s trenches it’s meant to help you prepare for what’s coming.

The next few columns will be about some of the practical considerations, and more importantly, how to have conversations about these considerations.

# # #

Bob watch: Currently appearing in CIO.com’s CIO Survival Guide: Managing CEO expectations is this year’s Priority No. 1.

Comments (11)

  • Hi there,

    I wanted to let you know that I read your article and really enjoyed it. I wanted to share with you that I recently completed a course in Citizen Developer Business Architecture PMI.org (r). The course focused on creating a business framework for low code/no code development and supporting the overall integration and architecture with a Center of Excellence. I found the idea of bringing Shadow IT to light quite interesting.

    Greg Maloney

  • Glad to read the post here. Reading the email I got scared some spammer had “integrated” with the KJR distribution list and maybe an AI to send out malicious links… But the links looked alright…

    • Author

      Sorry about that! Not sure how the email got garbled.
      I am sending a fixed version out!

      • Unfortunately the resend reads the same way.

      • The second version of the email you sent this morning had some fixes, but some new things broken. I might suggest sending out the content of the article on the web site as I found no spelling, punctuation, or grammatical errors in it.

      • Just to let you know, I received two copies of the email, but both were garbled.

    • I thought ChatGPT had written it. Our jobs are not in danger. LOL

  • Not to nitpick, but the second email also seemed to be a bit garbled…or in need of some additional proofreading. Or it could be that my 80 year old brain doesn’t understand the phrasing or style.

  • Long time reader and I’m excited about the “change in ownership” and looking forward to reading more. But…you’re starting to lose me already. Not by the obvious mistakes that can and will happen from time-to-time, but by the poor attention to the writing itself. This post was almost unreadable due to the sloppy writing and/or poor proof reading. Sorry…but you’ll need to clean this up to keep my attention.

  • The fixed version is still garbled (and missing some words and phrases)… 🙂

    We’ve always been doing integration, although sometimes it was all our own code, with each app dealing with a different perspective of the enterprise. If we happened to have a chief architect, the integration burden may have been minor but not non-existent. Changes in business requirements over time gradually increased the integration burden. Integrating with the outside world greatly increased the integration requirements.

    The dominant integration problem today is correlating the related business processes with the process design the application expects. Applications deal with this “customization” in varying ways, and those often are not considered in the acquisition decision, which is likely to occur if IT isn’t a party to that decision. The integration problem can become nearly impossible if there doesn’t exist some vision for the company’s direction and expectations of the overall IT infrastructure, which is what makes the CIO the chief integration officer (and the chief architect)!

    Leading IT isn’t just the most difficult job in the world, it’s close to impossible!

Comments are closed.