Objective Oriented Design


Why don’t I think the Enterprise Data Warehousing (EDW) approach works in most large organizations, except patient ones with a bottomless barrel of IT dollars in their pocket, or highly data driven or very collaborative ones? Because it takes too much time to produce one, and by that time, everyone has lost interest anyway.

For a DW framework to be successful, you have to think practically and recognize the political barriers in the organization, that tend to be functional in nature. By giving the responsibility of building a huge, centralized data warehouse to the IT department, you have probably set yourself up for failure anyway. The chances are likely that the entire effort is going to be data driven and low-level, and that the analytics is going to be done on spreadsheets that are tightly guarded within each function, treating the EDW as just another data source.

Why not consider giving each business function the resources and accountability to build their own data warehouses? This ensures that each function trying to analyze their own performance gets to dictate the objectives that the data warehouse supports, and the priorities. They get to decide what provides value to them. They have the freedom to use their own lingo, metrics and dimensional contexts. Add a global data warehouse to that mix, that would source from each individual functional data warehouse and come up with a global picture of corporate performance.

Besides considering the functional nature of the organization, the other huge advantage I see to this approach is that each individual initiative is objective oriented. Each one is focused on its objectives, and each group is responsible for their own success. No one gets to blame IT!

One huge caveat – each area takes care of its data quality issues, and any cross-functional quality issues need to be worked back into each individual effort. A cross-functional team across the organization can take care of that.

Another constraint – the technologies used need to be in alignment with the Corporate Technology Strategy.

Hardware can be shared or virtualized for optimal resource usage. So can development resources. Architects would need to work together on a common data dictionary and standardization. To avoid large scale data redundancy, common entities (dimensions) could be shared.

Call it a Federated Data Warehouse approach if you will, but I see this as a practical approach that could be successful in large organizations. I thought of calling this Objective Oriented Design, as a clever take on the more popular usage of the acronym OOD.

2 Comments

  1. I don’t know If I said it already but …I’m so glad I found this site…Keep up the good work I read a lot of blogs on a daily basis and for the most part, people lack substance but, I just wanted to make a quick comment to say GREAT blog. Thanks, 🙂

    A definite great read..Jim Bean

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s