Architecturally significant design components. There may be any number of significant components that are part of your overall architecture design. Perhaps you are planning for extensive spatial data and analysis -- that is the level design significance that should be mentioned here. Or, your enterprise may need an ODS for tactical reporting, or you may be planning to implement a message broker or XML server as a data delivery mechanism for the warehouse. These are all examples of significantly important design components.
Standards. This applies to any standards that warehouse participants must adhere to. For instance, a standard may be to use a BI community to give final approval to any particular iteration sought.
The conceptual view provides a broad overview of your entire BI vision; it represents the "what" part of the strategy document.
Data Architecture
The data architecture, as shown in Figure 2, provides designers a venue to convey what data structures are going to be implemented, how that data is stored in each and how the data will propagate throughout the warehouse environment. Four possible subsections to support your documentation of the data architecture follow.
Figure 2: Data Architecture View
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. Planners might identify the following objective in pursuit of the goal: All warehouse-centric data must be incorporated into the atomic layer first. All subsequent use of that data will be sourced from this single data structure. Constraints might include third-party data or technologies.
Logical data architecture. This is your opportunity to provide logical models that support your data architecture goals. Remember that initially, you will be limited in the models that you can provide because you are not yet addressing a specific warehouse iteration. Therefore, you could provide a subject area model of your enterprise or a series of subject area models that describe core subjects within your enterprise. 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.
Architecturally significant design components. The establishment of an atomic layer is a significant architectural component, an ODS is another as is an enterprise cube farm. These are traditional design components. However, there are others, such as: geospatial data structures, specialized data staging and "living" warehouse databases.
Test plans. A component of the overall road map that is often overlooked 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 adherence and approval, criteria for test data selection and performance testing (including unit, suite and stress testing).
Data architecture view is obviously a critical section for any warehouse-centric initiative. As with the technical architecture, you will often start at a high level and grow the details of your architecture as successive iterations of the warehouse are undertaken.
Technical Architecture
When you first start to lay out your technical architecture, it may be limited. For instance, you may know that you want to implement star schemas in a relational database. What you may not know by the time the first draft of your BI plan is published is whose relational database management system (RMDBS) you are going to use or on what platform it will be implemented. That's okay. What is important is to start designing your architecture, including detail where possible, and ensuring placeholders where subsequent decisions will provide more information. That means you will revisit the technical architecture many times and publish updated versions as necessary to ensure communication to your audience. As shown in Figure 3, the technical architecture diagram gives a reader a general sense of the architecture as it is currently known and yet ensures a place for additional information as it becomes available.
As with the overall strategy, the technical architecture section can contain many topics. Following are a few to consider.
Technical architecture goals and constraints. The technical architecture focuses on tangible components of your BI environment. The goals, objectives and constraints outlined in this section should be specific to those topics.
Technical architecture. This diagram specifically identifies the hardware, software and network/communication components. Figure 3 illustrates how technical components of a BI environment are represented in diagram form.
Figure 3: High-Level Technical Architecture
Architecturally significant design component. Any significant technical component of your architecture must be identified in this section. For example, you may require a 7x24 implementation and therefore will establish mirroring across two distinct data centers. That would be considered significant.
Components of the technical architecture must be described sufficiently. This often means that your technical architecture documentation includes several technical diagrams and many pages of related narrative.
Implementation View
Within this section, designers and project planners begin to establish the guidelines necessary for building and maintaining the purposed warehouse structures and related technologies. The implementation of core processes and the sequence of establishing data structures are detailed in this section. As with the previous sections, the implementation view can start from a high-level perspective, with detail added to this document as it becomes known. Generally, the implementation view will contain three distinct perspectives: the overall strategy, architecture and process.
Strategy: The implementation view might cover a time span or discuss when resources will be available for BI-centric projects. Here, you can formalize how you plan to identify and prioritize BI iterations using process flows such as that shown in Figure 4. Finally, this section should outline how funding will be addressed.
Be the first to comment on this post using the section below.