Researcher and consultant Colin White tackles the big view of information one piece at a time.

Not far north of the California border on Interstate 5, Ashland, Oregon, beckons visitors with beautiful scenery and outdoor attractions for which the Pacific Northwest is famous. Ashland is separately the home of a renowned summer Shakespeare festival that attracts thousands of visitors annually. Amid the oratory of the festival, you might misplace local resident Colin White's accent as part of the proceedings. Despite his gift for words, this British transplant is better known to followers of data warehousing, content management and collaboration as a speaker, consultant and researcher. White, president of consultancy BI Research, is more likely to be on the road than attending the Bard's works. DM Review Editorial Director Jim Ericson chased White down between assignments for a take on his view of our industry.

DMR: How does your job reflect what's going on in the business intelligence/data warehousing world these days?
CW: In my case, BI stands for business integration and business intelligence, both outbound from warehousing systems to the tools people use and inbound to the warehouses. About two-thirds of my work comes from business intelligence and data integration. The other third is on the business integration side. I get very heavily involved in portal, content management and collaboration systems, which suggests I do knowledge management, though those are dirty words these days. Mostly, I specialize in business integration technologies and enablers to capture information, analyze it and deliver it to business users. That includes structured information from transaction systems and data warehouses and also the kind of content that exists on Web sites and work groups.

DMR: That is covering a lot of ground.
CW: Yes, but I tend to look at the architectures delivering information to business users. Most of that is BI, but more and more companies see BI as just a piece of the puzzle of business information. That's why I get involved in these other areas. You'll meet people who specialize in content management, the Web or BI, but when it comes to the whole knowledge management and portals space,  you find people don't specialize in that because of the way organizations are broken into compartments. Business users don't care about compartments; they just want to access their information. You realize that you need to look at the information people need to do their jobs within their own business process.

DMR: Everyone is big on competency centers, but can you touch all those bases at once?
CW: It used to be that business intelligence was out in left field, but as you work in operational BI it becomes far more integrated into business operations. That poses a problem. If you are a company that runs SAP, the people who run that system don't understand data warehousing and data warehousing people don't understand SAP. So I think there are a couple of things to be done here. You don't have to become a generalist, but you have to become aware of the other technologies and systems your particular area is going to touch. You don't have to know the technologies, but you have to be aware of the strategy, which is often poorly defined. That's why you end up with all these one-on-one connections, every project with a new interface. This is where the concept of competency centers comes in as a way to bring skills together.

DMR: Yet you hear from different people that you should base your competency center around integration, process, BI or a half-dozen other things.
CW: What you're really trying to do is capture and share expertise. If you look at Gartner's figures for building a competency center, they're large enough that smaller companies will say, "We can't afford it." Big companies may build a separate physical center with people in it, but there are other ways of reusing your information. When I worked at IBM, for example, if the office systems group was developing a new application, the people responsible for all the database stuff would come to work in my applications support group, and we'd develop it together. They would rotate into the center while the project was being developed and then go back to their application group, taking the expertise with them. A competency center is a bit like outsourcing, but you want to have people from the group doing the outsourcing involved so they can bring the expertise back with them. You don't have to build a staff with hundreds of people. You may have some core expertise in a group, but you can rotate people in and out or just have a virtual relationship. I'll say it again: you are trying to capture and reuse expertise, and there are various ways of doing that. You want to ask, "What size organization are we? How much money have we got? Where is our expertise? How do we share it?"

DMR:It sounds like that could get political very quickly.
CW: That's the other thing. It is not only sharing expertise, it is removing the political barriers. If you've got one group made up of application and data people, there are no battles about who gets the budget. I'm often called in purely to solve these political battles and hear, "We've got an enterprise portal group, but the marketing group wants to build its own portal." I get involved in meetings where it is the first time these people have sat down together, and I end up acting as referee. You point out the issues they face and possible solutions. And sometimes in the end they don't choose those solutions, because they've got project deadlines, but at least they're informed. In other words, it's about understanding that if you make a tactical decision for business reasons, you're at least aware of the long-term impact of that as opposed to saying, "I'm just going to do this because I don't care."

DMR: You're still not saying which discipline a center of excellence should arise from.
CW: I'm biased because I work in integration, and I think that is the main thing you want to do. We've got content systems, we've got collaboration systems, we've got Web systems, we've got business transaction systems, we've got BI systems. We're increasingly trying to bring those together, and there are various ways to do that. But I firmly believe that if you had to choose one place to start, it is an integration competency center. The way I look at it, you can integrate systems at four levels: you can integrate at the user interaction level, the business process level, at the application level and the data level. You need a group of people who understand how to integrate at those four levels and can offer advice on how to do that. At the same time, it's wrong to go into a company and say, "You've got to do it this way and you can't do anything before you do this." You need a long-term game and you work out milestones to get there; you build tactically and think strategically.

DMR: To your point, we are seeing a lot of interest, even senior executive interest, in master data integration and management.
CW: Many so-called master data management projects I see are actually master data integration projects, such as building single customer data stores, CDI and so on. All they're doing is papering over the problem. The difference between master data integration and master data management is that MDM actually tends to fix the problem. It says, "Why do we have these disparate data stores? What is the long-term solution for fixing that?" Don't get me wrong. Master data integration is a tactical solution. It gives us a single view of the customer we never had before, but a lot of MDM projects are just following a new buzzword. There are, nevertheless, a lot of customers out there who are serious about true master data management, and I think they see significant business benefit from that. Our long-term objective should be to manage customer data so we don't have to paper over the cracks. What you're trying to do is come up with a common business model and a common set of business definitions for what master data means. You may decide it's profit margin or it may be revenue. In different parts of the organization they mean different things.

DMR: Let's shift gears. How do you feel about being both a market researcher and consultant? Is there an inherent conflict?
CW: I think the jobs go together, but I also see large analyst organizations full of people that have never actually used the software [they evaluate]. There are exceptions, but in many cases they're developing architectures and offering advice without ever having developed applications or built systems. I am highly biased here but quite happy with my position in the industry. People come to me because they're looking for someone who can act as an analyst but has a strong technical background and has actually built systems. My complaint about the large analyst companies is that a lot of the work they do is highly theoretical; they don't have the technical background to explain [their] positions about these systems.

DMR: Should companies rely on a mix of inputs?
CW: I think they need a mix. As an analyst you'll always be in a tough position when you've got both vendors and users for clients; that's a plain conflict of interest. Various [analyst measures] have a lot of power because vendors may not want to pump money into a large analyst company but they have to. Otherwise they don't get on the user's radar. And then if a user organization buys into it [the favorable analyst report] and the project doesn't go right, can they blame the analyst company? I think that whole process is broken. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access