3 Steps To Right-Size Your Architecture

By Bruce Johnson

The best place to start is at the beginning. Are you undertaking an effort to build a solution that involves reporting, analysis, mining, or running rules against your enterprise data? Before designing a data warehouse, data mart, or operational data store, take some time to really understand your business needs. Whether you are building a new solution or retooling a poor performing existing solution, the architecture and approach you undertake will likely be the single greatest factor in the success of your effort. Before coming up with an architecture, make sure you carefully define the real business needs. To clearly understand those needs, consider the following approach.

These 3 high level steps provide an outline for an approach to identifying all of the information you need to design the appropriate architecture for your business needs.

Step 1: Scope and Sponsor Identification

There is typically a person that is responsible for getting your effort outlined and staffed. However, that person is not usually your business sponsor. Digging into the nature of the business problem you are trying to solve should help you understand who needs to be your business champion. They may not know they are going to play this role, but before your analysis is complete they will assume that function. Frequently, the statement of purpose is very specific, but analysis of what is really needed can end up showing that what was requested is not at all what the business really needs. Keep in mind, the larger the effort, the more senior that business leader must be. If the analysis starts to show an enterprise effort, you must identify an executive level sponsor or your effort will be vulnerable to all of the politics and strategy that could suffocate it rather quickly.

Next, don’t forget to identify your IT sponsor. Make sure to identify the IT leaders that have some understanding or stake in the business issue at hand. They will be the ones that can lend the internal support and backing required as you are sent out to interview users that are normally served by other areas of IT. This individual will typically be the IT leader responsible for the relationship with the business sponsor identified. Without this crucial IT leader, you will find struggles getting access to other IT resources, funding, training, systems, and any external help you might need.

In the process of identifying these leaders much of the scope of the effort should have been clarified. Take that basis, interview the most knowledgeable resources under the business and IT leaders you identified, and document the business issue or result you are required to fulfill.

From the time you start your analysis, this step could take anywhere from a day on small efforts to a month for enterprise efforts. Depending on the nature of your organization, spending the time to share the business importance across your business could be critical and would thus take additional time.

Step 2: Usage Flyovers

Now that we know the general business need of our effort, we can start to dig into the actual analysis requirements that will allow the business to leverage their information for real business impact. “Usage Flyovers” must provide the real context to:

  • What general purpose is the solution to serve – is the solution in support of operational management, planning, in-depth analysis of operations or services, research, or monitoring of business activities.
  • How will the business navigate information? In “Corporate Information Factory”, the 4 types of users are defined as Tourists, Farmers, Miners, and Explorers. All of these usage types require potentially different solutions. Combinations of them require a sound, well-designed architecture.
  • Who will users provide results from their analysis to? Since information is generated out of the data, you can be assured that there will be value in sharing that information with other resources. Perhaps it is forwarding upward for leadership, conducting initial analysis and forwarding to researchers for more in-depth analysis, providing statistics for management, or even external reporting – to the extent of SOX compliance or in healthcare JCAHO.

This information is uncovered by interviewing the users, management, and leadership. These interviews are intended to be open ended questions that get the business to talk about what they real want out of the solution. I always suggest when you are doing this that you finish it by asking them “What is it you haven’t told me because you figured that it wasn’t reasonable or possible”? This doesn’t commit you to solving that, but when you present your findings, if that is something that is much easier than they anticipated, you have just won over some important backers. So make sure you clearly document the results of what you captured and provide it back to the business so they can validate it. This will help you further down the road when you present the request to approve the project timeline, resources, and funding. Tying all of the needs to the components will give the business a basis to start from. If they want to cut out parts or components, it will be easier to explain the impact that it will have on what was asked for.

Step 3: Data Flyovers

The goal of the “Data Flyover” is to get an overview of the types of data required to satisfy the business need, the amount of history needed, the timeliness required, and any known terminology issues/concerns. By classifying information at a high-level, you stay away from the analysis paralysis associated with trying to define every metric before you have even told the business generally what the solution will look like. If someone being interviewed explains that they need “age” information, I know that they are talking about demographics about a patient. Then I can quickly ask if they might also need other demographics like gender, marital status, household income, race, etc…

It also allows you to easily map the high level data requirements to an enterprise Subject Area Model (should you have one). In turn, this will give you the ability to perform a feasibility study on the data needed by the business. This data feasibility will answer questions like:

  • Is the data captured/available?
  • Is it timely?
  • What is the general quality of the source systems generating the data?
  • How much history do we have on this data?
  • How many versions of this data do we have?

The information generated out of steps 2 and 3 is more easily acquired through one series of interviews. That way you are not sending separate resources to extract business needs multiple times. The business would be easily frustrated with providing the same information multiple times.


It takes an experienced technical background in data warehousing and a highly professional set of business analyst skills to gather this information quickly and accurately. Anyone can learn to do this, but if you are new to it, go out and get some vendor independent help from an experienced expert to guide your resources. As you learn the process, you will be able to repeat it for future efforts. It also takes someone with the ability to sell their customer (the business) on the strategy. You will be asked to cut corners and slice off components that generally deviate from a sound plan. Only with significant technical experience can someone share all of the reasons why that corner cutting will ultimately change the nature of the solution.

Too often technical resources that have one answer to all data solutions apply that solution in all cases and just start building. Spending time at the beginning of your effort to outline the “Usage” and “Data” needs of your business users will cement the goals and needs that your solution must meet. It will also give your business sponsors clear documentation they can use to champion your cause, fund the necessary components, and ultimately support the effort going forward. It is now possible to outline the architecture that will meet those needs and the costs, timeframes, and resources required to deliver. Once you have the needs defined and the architecture outlined, then you can start looking at tools, technologies, and platforms.

In very large warehouse efforts, the above steps are crucial to the foundation of an effort that will be able to grow with the business. Once this is in place, many individual efforts can be done over years that build upon each other. In our situation, every business need that comes up is already accommodated in our architecture. That reduces the overhead of spending all of that time up front on every effort you undertake.

About the Author

Bruce has over 20 years of IT experience focused on data / application architecture, and IT management, mostly relating to Data Warehousing. His work spans the industries of healthcare, finance, travel, transportation, retailing, and other areas working formally as an IT architect, manager/director, and consultant. Bruce has successfully engaged business leadership in understanding the value of enterprise data management and establishing the backing and funding to build enterprise data architecture programs for large companies. He has taught classes to business and IT resources ranging from data modeling and ETL architecture to specific BI/ETL tools and subjects like “getting business value from BI tools”. He enjoys speaking at conferences and seminars on data delivery and data architectures. Bruce D. Johnson is the Managing director of Data Architecture, Strategy, and Governance for Recombinant Data (a healthcare solutions provider) and can be reached at bjohnson@recomdata.com

Free Expert Consultation