Classifying Integration Initiatives as Tactical or Strategic

Loraine Lawson

I've always thought of integration as a tactical issue. True, it's important and certainly critical to supporting strategic initiatives. But I just couldn't shake the idea that integration was akin to making the trains run on time -- people would certainly notice if there wasn't integration, but in an ideal world, integration was what happened behind the scenes, and smoothly, so that business could function as it should.


It's important to note that I do think IT can be a strategic differentiator. I just tend to think of integration as one of the tactical tools for making that happen.


I'm not sure how universal this view is. But this week, a few pieces have forced me to question my thinking that integration is the domain of IT. In fact, both of these items show that integration increasingly requires collaboration with the business.


The first item was a blog post by John Schmidt of Informatica. His thesis is that integration should be viewed a distinct discipline, not just a management practice and, as such, should be a strategy:

"Organizations that view integration as a 'strategy' and that focus their people, policies and investments around the strategy will have a clear competitive advantage. They will create an agile business where each link in the chain can change and adapt to meet local needs while the end-to-end chain remains strongly aligned with the overall operating model."

I have to say, I had a hard time buying that. I mean, trains running on time could be called a competitive advantage because it's a critical component of resource delivery -- but in general, trains are really more of a tactical concern. Isn't integration very similar? Sure, you've got a problem if it's not working -- but do you really notice when it is? Isn't that saying "competitive advantage" is just synonymous with "functional and competent?"


But Schmidt also pointed out that integration now requires more collaboration with the business units:

"... many large organizations today operate more like a federation than a dictatorship. And the people that work in the organizations have a mind of their own, come from all over the world (and even work all over the world) and often aren't permanent employees of the company. Traditional management practices are no longer sufficient in this new environment."

Integration, he notes, now requires "more of an agreement process rather than an analytical process."


The word choice caught my eye, because TDWI Research manager Philip Russom used the term "analytical" to categorize certain types of data integration projects. That's coincidental, I'm sure, but Russom struck a similar chord about integration's growing collaborative and strategic role during this presentation on "Second-Generation Collaborative Data Integration."


When Russom refers to analytical data integration, he's talking about master data management and data integration involving data warehousing and business intelligence projects.


He contrasts this with operational data integration, which applies to projects that involve consolidation, migration, upgrades or somehow synchronizing operational databases. As an example, Russom discusses a company that consolidated 13 ERP systems worldwide down to three regional ERP systems.


You would think that the bulk of data integration projects would be analytical, what with all the talk about business intelligence and MDM but, according to Russom, research from TDWI suggests that most data integration projects are actually operational:

"I'd say that operational data integration is growing even faster than analytic. Let that sink in for a moment. If you're a DI specialist you might want to be sure you've got a lot of stuff on your resume in the operational data integration area not just analytic, because it's very much a viable practice and it's going to be bigger. And as it gets bigger, you need more collaboration between data integration specialist as well as externally to the green data center programs out to the big consolidation programs due to mergers and acquisitions."

It's part of an overall trend Russom terms "second-generation data integration." There are several factors that differentiate first-generation data integration from second-generation data integration, and you can learn what those are by watching the presentation or downloading Russom's free paper on the topic.


But the number-one thing that marks second-generation data integration is collaboration. That's important because, as Russom points out, the focus on collaboration gives data integration specialists a chance to step outside their cubicles and do a new kind of work in the data center.


Data integration specialists are even getting a chance to interact with executives and support business goals with consolidations and mergers, he added.


After hearing that, I had to concede that integration sounds much more strategic than I previously believed.

More from Our Network
Add Comment      Leave a comment on this blog post
Jun 26, 2008 6:19 AM Quinton Quinton  says:
Great question/post and something that I have often been faced with through my many years of working for BIG integration vendors (BEA, Vitria), implementing most of the major products (BEA, Vitria, BizTalk, WebMethods, Tibco) and now product marketing for an Integration Appliance vendor (CastIron - . In my experience the discussion whether integration is strategic or tactical has to be predicated by the needs and type of the business. I am a big fan of Geoffrey Moores core vs context model (see for a summary) where an organization must determine what activities provide an organization competitive advantage and a unique differentiation and choose to invest here strategically as a core competency; everything else becomes context.Integration is one of those areas where, for the vast majority of organizations, it is not core to any unique differentiator but it may be critically important to doing business (synchronizing between on-premise ERP systems and on-demand CRMs for example). Such an organization should not invest in a large team of highly paid technical specialists just to connect system A to system B when these funds could be spent on more strategic activities such as closing more sales, bringing products to market etc. Rather, organizations should look at Integration as an enabler for their business and approach integration projects as a context activity with simplicity paramount. If you find yourself writing custom code or paying for large EAI solutions rather than investing in the core of your business, that which make you unique in the marketplace, then you have made missed the purpose of integration; which is access to the right information at the right time. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.