The Pacific Rim is the true birthplace of the modern global business consortium, but we’re getting the hang of it in the United States. The importance of sharing strategic alliances with other companies, and the sharing of resources in lean times, are increasingly clear. So it will be no big surprise if your company has begun entering into such relationships with other companies for their mutual benefit. You may share a fleet of vehicles, or a group of clients, own some buildings together, or cooperate in offering services. Now take a more focused step: Consider pooling your data for a super-charged business intelligence system.

The sharing of a data warehouse is not quite a new idea. It is not commonplace, but it’s been done: Cooperation between companies in extended IT systems is on the increase, and the data warehouse itself is of increasing strategic importance. Consider the possibilities—your own warehouse brings forth performance trends, strengths, and weaknesses that are specific to your company and can give you hints about your industry or market.

Now, imagine all of that data combined with similar data, gathered by other players in your industry. How much better will the industry or market picture be? It’s as though you’re both painting pictures, and you can each turn to the other’s work and add meaningful detail. Or better yet, you can each abandon your two-dimensional portraits and work together to create a three-dimensional picture.

Who should partner?
Ideally, this kind of data-sharing for predictive analysis will work between two companies who do the same thing—i.e., two manufacturers who are partnering to create new products cooperatively —or between companies that work together in a complementary way, like manufacturers and distributors. In the first case, one company’s data adds depth and reinforcement to the other; trends that are hinted at in one’s own data become stronger when the same hints are seen across the fence.

In the second case, functionally distinct partners can provide each other with refined supply-chain metrics. However certain one can be of one’s own performance or strategic acumen, the metrics only tell the local story. Knowing how your performance directly affects the performance of your partner(s)—which you can learn from their metrics—enhances your effectiveness in the chain, and suggests ways you can improve your game.

Share the old burdens, prepare for the new ones
You’d guess that a cooperative data warehouse isn’t going to be as simple as a local one, and you’d be right. While there is some comfort in sharing the misery—working ETL together, putting more heads together to pound out schemas and query strategies—there are also some new problems that will pop up. Here’s a list of things you’ll need to think about.

Who is leading this, and how will it be done?
Whatever your degree of cooperation, it’s inevitable that one company will be leading and the other following. How this gets decided is your own business, but there will be the question of methodology. Whoever is in charge of the implementation, there must be continuity in the methodology of the project. A single developmental method must be adopted and adhered to by all parties. It is not necessarily best that the administrating company’s method be used! Politics, and even short-term costs, should not drive the decision. Instead, it is best to look at potential methodologies and choose from among them on the basis of an agreed-upon trade-off between situational effectiveness and ease-of-use. The near-term learning curves and cash outlay will not have nearly the long-term impact of warehouse management, expansion, and user-friendliness. Make this decision based on how you want the partnership to look two years from now.

Who establishes the standards?
In any multicompany IT partnership, there will be haggling over standards, and usually it’s the bigger guy imposing his will on the smaller guy. In the case of data warehousing, however, you may be in for some surprises. Unless you’re implementing a canned warehouse on top of a canned ERP system (i.e., SAP BW on top of SAP R/3), you’re going to find that your conventional IT standards don’t always carry weight in data warehouse implementation decisions. Odds are you’ll be starting from scratch in many phases of the implementation, and you can safely sit down at the brainstorming table with your partner company’s people and work together with less politics than you might expect.

What about sensitive data?
This is the first protest you’ll hear from the lips of many senior managers. In our security-conscious age, do we really want to be dumping our historical data into some bucket that people beyond our own walls can see? Do we want our sales records to be scrutinized by anyone other than our own people? Do we want our customer files made available? Do we need anyone knowing the details of our seasonal performance fluctuations? Obviously you’d be foolish not to make careful decisions about what you should and shouldn’t include. Proprietary data is and should be a carefully-guarded asset. Are the potential rewards of including this information worthwhile? These are important questions, but they should be asked and carefully examined, not arbitrarily dismissed. In some cases you’ll want to keep your data to yourself. But in others, you may find that you can compromise in a way that ultimately benefits you a great deal.

Who guards the door?
In any IT system that crosses company boundaries, new security risks are generated: If I tie my system to your system, then my system takes on the security weaknesses of your system, and vice versa. The opposite is also true, though less easy to appreciate: If I have stronger security, then it may be possible for me to impart some added security to you. You can’t do this, however, without careful examination of the strengths and weaknesses of both systems. You are certainly going to make changes on both sides, and you will certainly both be better for it in the long run.

Who pays for what?
It always comes down to this, doesn’t it? Well, when it comes to data warehousing, it’s once again a different haggle than you’re used to. Billing time and materials and so on during the build is arbitrary: What you really are going to be haggling over is the on-going support costs.

Well, consider this: What does your data warehouse deliver? It provides you and your partner company with “business intelligence.” How can you assign relative values to that? We can look at various arms of the federal government—the Department of Transportation, for instance—and have a solid sense of what we’re getting for our money. But when we try to do cost justification on our foreign intelligence-gathering services, it gets much murkier. How do we assign value to that kind of product?

Make it simple on yourselves. Assign warehouse support costs proportionally, regardless of who took the lead. The whole point of the investment is to make both of your companies more efficient, and therefore more profitable. Figure it pays for itself in the end.