Dimensional Lifecycle Road Map

Dimensional Lifecycle Road Map

            As we know, data warehousing requires the technological knowledge as well as the knowledge of business processes to build an efficient data warehouse, we follow certain life cycle to build our data warehouse. These steps manages our workforce to develop an efficient data ware house and most likely yield greater productivity out of our data warehouse, if followed wisely. Therefore, we can conclude that the dimensional lifecycle to build data warehouse acts as a road map to successfully build an efficient data warehouse (Kimball, Page 332).

            The lifecycle starts with the project planning and goes through numerous process of figuring out the requirements that contains technical as well as analytical requirements to develop and constantly maintain and grow the data warehouse.

            The first step in data warehousing life cycle starts with project planning. We need to access readiness of our organization if they are ready to proceed ahead for the project (Kimball, Page 334).

            If we take an example of a video store that is growing day by day and we felt as if we need to create a data warehouse for the business then we also need to figure out if creating a data warehouse is feasible or not. We need to consider culture and scoping of the video store (Kimball, Page 336). We need to see the cost of building the data warehouse and benefit that we get out of it. Then, we need to see if it is worth investing money on data warehouse for our store. We can hire individuals that are passionate about videos as well as sound on the database and data warehouse technology.

            We need to develop a project plan which would ensure our progress on the project life cycle that has certain time frame to accomplish the task and the task that we already accomplished.

            The second important phase of our life cycle is requirement definition. We need to find out the information that we need from our data warehouse, so that, the top level executives would find it easier to make a smart decisions to be productive and stay at the top in the competitive market. We can look at the current database of the video store and gather information for the questions that would not be answered correctly by our current database  which would hamper our productivity for the store.

            We can also set the requirements by asking questions to the dimensional model that we create for our store. The question would be the question that the top level executives would want the answer for the store to be more productive. Example of one requirement for our store would be, "How many people come to our store with our ongoing marketing promotions?".

            We need to document the requirements we come up with. We need to have the requirements for architecture we would have for our data warehouse. We need to create a dimension table and a fact table for the requirement we come up with.  We should also find out the analytical requirements for our video store.

            We finally deploy the data warehouse and keep on performing the maintenance and growth because with time, our requirements and business process changes and we need to accommodate the change. This is a never ending process and there is always a scope for change in the data warehouse.

            Basically, data warehousing process seems to be more organized with the application of dimensional lifecycle road map that only helps the team responsible to build the data warehouse of the organization. This life cycle doesn't have a hard and fast rules and could be different for different organizations. It is just a guideline for the project team members and the project managers which proves to be yielding productivity and they are followed by many organizations. I personally, feel that this is very helpful for the members of the data warehouse team to accomplish the milestone and deliverables on time and with greater efficiency.    

Works Cited:

Kimball, Ralph, and Margy Ross. The Data Warehouse Toolkit: the Complete Guide to      Dimensional Modeling. New York: Wiley, 2002. Print.

Advertisement: 

Contact us for Software Development, AI, and SEO Marketing - I Code Mind LLC

Agile Architectures: Creating and Evolving Data Architectures that Adopt to changing Business

April 5, 2011

Data Architecture - Why don't we go Agile?

            John O'Brien is with BI Data warehousing who has a lot of experience with data architecture and its evolution for the better business practices. His presentation at the "TDWI BI Executive Summit" is mind blowing in a way that it helped me to open my eyes, making me think about data warehouse and the importance of data architecture not only from the technical perspective but also from the organization view - profit making, decision making etc.

            We can use traditional data architecture for our business but with the faster-than-ever changing business environment more business are going agile (Powell, James E). Why do we want our data architecture to be agile?

            Business process is changing everyday and, more and more technology is evolving. By going agile, we can set small targets, making the balance between business needs and the future of the architecture. We can communicate with the business people to know more about the business needs and come up with the solution that is not final; yet, fulfills the basic requirements for the business to run (O'Brien, John).

            It is an iterative process where we constantly perform development of the reusable architecture that we developed to come up with better architecture that would serve our business more efficiently with the change in business needs or the process itself (O'Brien, John). If we didn't go agile and tried to build an architecture that would be solid but would take many years (time) and more money (investment); this may be not suitable to the business because it may not serve the business when it needed the most (return on investment) and may also get outdated with the business process changing (O'Brien, John).

            So, what is the use of such perfect system that the business may not be able to use? Therefore, we need to make a balance between the quick delivery as well as think about the consistency and efficiency of the architecture we are building with the agile method (O'Brien, John).

             Thin slicing by layers is very important when we go agile. First, we need to connect to the sources and then deliver data marts. If we are comfortable, we can directly go to staging. After it gets more complex, we can go to EDL (Enterprise Dimensional Layer). When the requirement gets even more demanding  for changing business needs, we can put data warehouse on the layer (O'Brien, John). Evolution is always on going and we don't go to the advanced layers unless the business really needs it. This is the advantages of going agile.

            Going agile, sandboxing may actually help us create the architecture efficiently. By creating the  sandbox, we would be able to actually play with the actual data by creating a medium sized database server (Singh, Amit). This would help us to explore the requirements for the process of building data architecture by agile methodology (O'Brien, John).

            Other important step going agile is to modularize - being able to create and write codes that can be reusable (O'Brien, John). Communication is very important between the team as well as with the management. As a team, working to create the architecture, we need to set the standards in our coding or applications we write, so that, others would have a value to follow our standards (O'Brien, John.). Over the time, we need someone to play the role of governance because the scope of the project gets huge and there must be someone who helps the team to leverage more of what the team has already delivered (Powell, James E).

            Basically, just like RAD (Rapid Application Development), building architecture for our data, going agile proves to be more practical and efficient in today's world which has so many positives to offer to our business and our changing business requirements.    

Works Cited:

O'Brien, John. "Agile Architectures: Creating and Evolving Data Architectures That Adopt to Changing             Business." TDWI - The Data Warehousing Institute. TDWI, 15 Feb. 2011. Web. 09 Apr. 2011.             <http://tdwi.org/pages/video/lv-wc-ss-videos/video-assets/agile-architectures-creating-and-    evolving-data-architectures-that-adapt.aspx>.

Powell, James E. "Q and A: Agile BI Architectures." TDWI - The Data Warehousing Institute.      21 July 2010. Web. 10 Apr. 2011. <http://tdwi.org/articles/2010/07/21/agile-bi-  architectures.aspx>.

Singh, Amit. "Sandboxing." A Taste of Computer Security. June 2004. Web. 10 Apr. 2011.             <http://www.kernelthread.com/publications/security/sandboxing.html>.