TACTICAL MANAGER WAREHOUSE MANAGER META DATA MANAGER
As with the overall strategy, the technical architecture should address certain issues, including:
Technical architecture goals and constraints. The technical architec-
ture focuses on hardware, software, and communication components of the warehouse effort. Therefore, the goals, objectives, and con- straints outlined in this section should be specific to those topics. An example might be the implementation of a specific relational data- base management system over the entire BI initiative.
Technical architecture. Figure 3.5 illustrates how technical compo-
nents of a warehouse are represented in diagram form. It specifically identifies the hardware, software, and network/communication com- ponents. Components in the BI conceptual model must be found somewhere in a technical architecture diagram, and as more detail becomes available, the technical architecture diagrams can become more specific. For example, if you have a large effort with regard to data marts, you may have a diagram that focuses only on that com- ponent of your architecture.
Architecturally significant design component. Any significant tech-
nical component of your architecture must be identified in this sec- tion. For example, you may require a 24x7 implementation and therefore must establish mirroring across two distinct data centers. It should be noted that each diagram is associated with sufficient narra- tive to describe the components identified. This often means that your technical architecture documentation includes several technical diagrams and many pages of related narrative.
Designing the Data Architecture
The data architecture provides designers a venue to convey what data structures will be implemented, how that data is stored in each, and how the data will propagate throughout the warehouse environment. It is obvi- ously a critical section for any warehouse-centric initiative. Just like the technical architecture, you will often start at a high level and grow the details of data architecture as successive iterations of the warehouse are undertaken. Following are core topics to consider for a data architecture design document:
Figure 3.5 High-level technical architecture.
Data architecture goals and constraints. All the goals, objectives, and
constraints to your strategy should be documented in this section. For example, the goal might be data integrity in the sense of creating an architecture that maintains a single version of the truth. As one of the objectives to achieve such a goal, planners might identify the follow- ing: All warehouse-centric data must be incorporated into the atomic layer first. All subsequent use of that data will be sourced from this data structure. This objective may even serve as a constraint. Other constraints might include three-party data or technologies.
Production Environment Data Mart Departmental Server Vendor: Model: OS: Location: Data Mart Database Ethernet
Atomic Level Warehouse and Staging Area
Disk Storage
Vendor:
Model: (RAID Level-5) Location:
Atomic Level Warehouse
Central Server Vendor: Model: OS: Location: Data Warehouse DBA Workstation Vendor: Model: OS: Location: Data Warehouse Developer Workstation Vendor: Model: OS: Location:
Logical data architecture. This is your opportunity to provide logical models that support your data architecture goals. Remember that ini- tially you will be limited in the models that you can provide, since you are not addressing a specific warehouse iteration yet. Therefore, you could provide a subject area model of your enterprise or a series of subject area models that describe core subjects within your enter- prise (see Figure 3.6). You can include rules for mutating raw source data into atomic-level data and even guidelines defining how and when to use star schemas and OLAP cubes. You will want to update this document as subsequent iterations of your warehouse rollout.
Architecturally significant design components. The establishment of
an atomic layer is a significant architect component, along with an ODS and an enterprise cube farm. These are traditional design com- ponents; however, there are others, such as geo-spatial data struc- tures, specialized data staging, and living warehouse databases, just to name a few.
Figure 3.6 Specific subject area used as part of a series.
Party
Product Subject Area High-Level Model
Product Package Party describes role for is described by is described by describes describes is part of is offered by Product Feature Product Package Product Feature
Test plans. A component of the overall road map that is often over- looked is how iterations will be tested before rollout. This section provides planners an opportunity to establish a standard to follow for all subsequent warehouse iterations with regard to testing and acceptance. Topics should include test templates to be completed by future project sponsors and planners, criteria for enterprise adher- ence and approval, criteria for test data selection, and performance testing (including unit, suite, and stress testing), to name just a few. Chapter 4 discusses in greater detail the data architecture and related models.
Implementing and Maintaining the Warehouse
Here designers and project planners establish the guidelines necessary for building and maintaining the purposed warehouse structures and related technologies. The implementation of core processes and sequence of estab- lishing data structures are detailed in this section. As with the previous sec- tions, the implementation view can start from a high-level perspective, with details added as they become known. Generally the implementation view contains three distinct perspectives:
Strategy. The implementation view might cover a time span or dis-
cuss when resources will be available for warehouse-centric projects. Here is also the place to define how iterations will be selected. Describing, for instance, the use of the DIF Matrix defined later in this chapter is excellent content for this perspective. Finally, this sec- tion should outline how funding will be addressed. For example, funding might be the responsibility of the requesting department, or there may be some form of shared funding between corporate and individual departments.
Architecture. This perspective includes topics such as size and perfor-
mance requirements, data quality issues, meta data control, and retention policies. Decisions made on retention, for instance, will impact data architecture issues such as partitioning of the data, as well as technical architecture considerations regarding disk storage.
Process. Here the architect must outline, at a high level, process issues
such as refresh rates, backup/recovery, archive, workflow, and secu- rity. Again, you will address as many of these topics as possible even though no particular iteration of the warehouse is being discussed.
Your BI plan should start with high-level diagrams, broad policy state- ments, and general definitions. As your warehouse matures, so, too, will the formal documentation and depth of detail identified in your BI plan.