定義項(xiàng)目
討論的職責(zé)之一是創(chuàng)建簡(jiǎn)單但可擴(kuò)展的解決方案。要承擔(dān)起這一責(zé)任，必須采用迭代方法開(kāi)發(fā)數(shù)據(jù)倉(cāng)庫(kù)。而不是從一開(kāi)始就規(guī)劃完整的解決方案，只計(jì)劃接下來(lái)的幾個(gè)沖刺。這并不意味著我們沒(méi)有一個(gè)總體的想法或數(shù)據(jù)倉(cāng)庫(kù)的總體目標(biāo)。這只意味著我們不會(huì)立即計(jì)劃每一項(xiàng)任務(wù)到達(dá)那里，也不會(huì)對(duì)交付最終解決方案所需的每一個(gè)可用的源或信息集市進(jìn)行建模。 開(kāi)發(fā)團(tuán)隊(duì)必須先問(wèn)客戶(hù)需要什么，什么對(duì)業(yè)務(wù)最有價(jià)值。這是首先交付的，因?yàn)榻桓兜囊蕾?lài)關(guān)系是滿(mǎn)足的。
有時(shí)，這需要首先構(gòu)建一些依賴(lài)關(guān)系，例如設(shè)置初始數(shù)據(jù)倉(cāng)庫(kù)基礎(chǔ)設(shè)施。然而，最初應(yīng)該避免建立最終的數(shù)據(jù)倉(cāng)庫(kù)基礎(chǔ)設(shè)施。起步要小，但要使其具有可擴(kuò)展性。以不斷增長(zhǎng)的需求來(lái)增長(zhǎng)基礎(chǔ)設(shè)施。
通常，架構(gòu)師試圖逐層創(chuàng)建數(shù)據(jù)倉(cāng)庫(kù)解決方案：他們決定最初的一組源系統(tǒng)，以交付所有所需的報(bào)告或OLAP（在線(xiàn)分析處理）立方體。然后，它們實(shí)現(xiàn)整個(gè)集結(jié)區(qū)以捕獲所有源表，包括加載表的ETL。一旦他們完成了集結(jié)區(qū)，他們就開(kāi)始最大限度地建模企業(yè)數(shù)據(jù)倉(cāng)庫(kù)，因?yàn)橐院蠼佑|它代價(jià)太高了。在實(shí)現(xiàn)ETL負(fù)載作業(yè)后，創(chuàng)建數(shù)據(jù)集市以最終滿(mǎn)足業(yè)務(wù)用戶(hù)。 這種方法通常需要幾個(gè)月，如果不是幾年完成，包括幾個(gè)階段的調(diào)試和錯(cuò)誤修復(fù)。然而，當(dāng)需求發(fā)生變化（本例中的架構(gòu)師會(huì)說(shuō)“太頻繁”)或業(yè)務(wù)需要額外功能(在許多情況下，初始架構(gòu)師已經(jīng)離開(kāi)組織)時(shí)，問(wèn)題就會(huì)出現(xiàn)。
鑒于Data Vault2.0標(biāo)準(zhǔn)中的可擴(kuò)展模型和架構(gòu)以及敏捷方法，數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)師不再需要遵循這種方法。 數(shù)據(jù)倉(cāng)庫(kù)不是以一種水平的方式、一層一層地構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，而是以一種垂直的方式按特征構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)。數(shù)據(jù)倉(cāng)庫(kù)倡議的總體目標(biāo)是相同的，但現(xiàn)在是在逐步交付功能方面實(shí)現(xiàn)的。BI團(tuán)隊(duì)的目標(biāo)是在快速和頻繁的發(fā)布中交付所需的功能，如本章前面的章節(jié)所述。為了做到這一點(diǎn)，必須將功能范圍限定為盡可能與其他功能分離的單個(gè)功能。
實(shí)現(xiàn)這一目標(biāo)的建議方法是在需求工程和單個(gè)特性的實(shí)現(xiàn)中使用范圍界定的方法，如圖3.11所示。
圖 3.11 界定報(bào)告
如圖所示的示例中要實(shí)現(xiàn)的特性是報(bào)表，但可能是用戶(hù)所需的任何其他工件。例如，它可以是OLAP立方體中的一個(gè)新維度或?qū)傩?、一個(gè)單獨(dú)的新OLAP立方體（具有最小維數(shù)）或用于文本挖掘的語(yǔ)料庫(kù)。一旦業(yè)務(wù)對(duì)該工件進(jìn)行了范圍劃分和描述，IT就開(kāi)始識(shí)別構(gòu)建此單一報(bào)表所需的源(源系統(tǒng)中的表。接下來(lái)，確定信息集市目標(biāo)，以評(píng)估已經(jīng)到位的內(nèi)容，以交付所需的報(bào)告（或其他功能）。一旦執(zhí)行了此標(biāo)識(shí)，工程師就可以對(duì)所需的數(shù)據(jù)進(jìn)行分級(jí)、構(gòu)建和加載Data Vault實(shí)體，并構(gòu)建集市。在遵循此過(guò)程時(shí)，源表中的所有數(shù)據(jù)都在Data Vault中加載和建模，而不是部分屬性集。因此，源表只能接觸一次，而不是多次。為了評(píng)估數(shù)據(jù)的可用性，應(yīng)該可以跟蹤哪些數(shù)據(jù)已經(jīng)加載到企業(yè)數(shù)據(jù)倉(cāng)庫(kù)中。部分加載的數(shù)據(jù)使此評(píng)估更加復(fù)雜，這是我們想要避免的。此外，只從源表加載部分?jǐn)?shù)據(jù)會(huì)產(chǎn)生更復(fù)雜的Data Vault衛(wèi)星。
定義迭代中要開(kāi)發(fā)的工件（即需求變更）是迭代成功的重要前提。適當(dāng)?shù)姆秶缍p少了團(tuán)隊(duì)無(wú)法在一個(gè)沖刺的時(shí)間框架內(nèi)完成和部署更改的風(fēng)險(xiǎn)。如果不確定所需的變化范圍，也不可能實(shí)現(xiàn)兩周甚至一周的短沖刺。此外，由于Data Vault2.0模型，團(tuán)隊(duì)現(xiàn)在能夠跨業(yè)務(wù)行增量地構(gòu)建解決方案——因此它們可以在實(shí)現(xiàn)范圍內(nèi)具有靈活性。
應(yīng)該注意兩個(gè)共同的反對(duì)意見(jiàn)：第一個(gè)反對(duì)意見(jiàn)是從一個(gè)源實(shí)現(xiàn)所有表，以保持集成源系統(tǒng)的成本低-在這種情況下，加載當(dāng)前解決方案不需要的數(shù)據(jù)。加載這些數(shù)據(jù)需要額外的ETL容量，這需要更大的初始基礎(chǔ)設(shè)施。此外，從一個(gè)源系統(tǒng)實(shí)現(xiàn)所有源表可能不會(huì)在一個(gè)sprint中完成，并綁定可以用于實(shí)現(xiàn)要交付給業(yè)務(wù)的特性的人力。這種努力往往超過(guò)了評(píng)估Data Vault中已經(jīng)存在的數(shù)據(jù)的復(fù)雜性（在關(guān)注表時(shí)很容易）。另一個(gè)問(wèn)題是，當(dāng)將源表實(shí)現(xiàn)到集結(jié)區(qū)時(shí)，將數(shù)據(jù)集成到Data Vault中也是一個(gè)很好的實(shí)踐。否則，當(dāng)兩個(gè)系統(tǒng)都可能不同步時(shí)，就需要額外的復(fù)雜性來(lái)評(píng)估數(shù)據(jù)倉(cāng)庫(kù)的當(dāng)前狀態(tài)。加載所有源表完全需要完整的建模和加載相應(yīng)的Data Vault表，如果應(yīng)該遵循這種做法。
第二個(gè)反對(duì)意見(jiàn)是，為了實(shí)現(xiàn)最終解決方案，多次接觸目標(biāo)是代價(jià)高昂的。這可能是正確的，但最終的目標(biāo)是在一個(gè)sprint中為業(yè)務(wù)提供可運(yùn)行和有用的功能，因?yàn)樗档土耸〉娘L(fēng)險(xiǎn)：業(yè)務(wù)不接受解決方案，例如因?yàn)椴粷M(mǎn)足書(shū)面要求，需求在此期間發(fā)生了變化，或者一旦業(yè)務(wù)用戶(hù)實(shí)際使用了解決方案，解決方案就會(huì)被證明是錯(cuò)誤的。
這種垂直的信息傳遞方法是在一個(gè)sprint中執(zhí)行的。根據(jù)組織能力的不同，這可能是兩到三周的時(shí)間。因此，Data Vault的建模不應(yīng)該需要幾個(gè)月。相反，模型應(yīng)該在sprint的持續(xù)時(shí)間內(nèi)創(chuàng)建。如果需要更長(zhǎng)的時(shí)間，這是一個(gè)很好的指標(biāo)，沖刺的范圍太大。在這種情況下，應(yīng)該從sprint中刪除功能。 刪除所有不需要以單一特性交付的內(nèi)容，這是本次沖刺的重點(diǎn)。 確保業(yè)務(wù)用戶(hù)理解此功能仍有待交付——但在以后的沖刺階段。通常情況下，業(yè)務(wù)用戶(hù)認(rèn)為功能完全被刪除是因?yàn)樗谟?jì)劃中從sprint中刪除。然而，這是錯(cuò)誤的，因?yàn)槿笔У墓δ軐⒃谙乱淮位蛳乱淮蔚蠛芸旖桓?。一旦業(yè)務(wù)用戶(hù)看到了項(xiàng)目的進(jìn)展，他們自然會(huì)接受這個(gè)程序。
敏捷需求收集
在sprint中實(shí)現(xiàn)新功能之前，需要定義它。然而，需求收集過(guò)程與實(shí)施過(guò)程非常相似。通常，業(yè)務(wù)對(duì)要在數(shù)據(jù)倉(cāng)庫(kù)中實(shí)現(xiàn)的功能有一個(gè)大致的想法。但是IT還有很多問(wèn)題需要回答，比如關(guān)于數(shù)據(jù)源的問(wèn)題，聚合或轉(zhuǎn)換數(shù)據(jù)的業(yè)務(wù)規(guī)則，數(shù)據(jù)類(lèi)型，用例等。為了回答這些問(wèn)題，使用了需求集合。
為了支持需求收集的敏捷方法，需求是沿著過(guò)程收集的，與傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)不同，這些需求是在項(xiàng)目開(kāi)始時(shí)收集的。在我們的項(xiàng)目中最有效的方法是使用Raw Marts（原始集市）并將數(shù)據(jù)快速推出到需求會(huì)議以供審查。 這些Raw Marts（原始集市）用于向出席需求會(huì)議的有限數(shù)量的業(yè)務(wù)用戶(hù)創(chuàng)建報(bào)告或立方體，而不是用于分發(fā)。這是因?yàn)?strong>Raw Marts（原始集市）包含有或不完全實(shí)現(xiàn)業(yè)務(wù)規(guī)則的原始數(shù)據(jù)。通過(guò)演示，向用戶(hù)展示這些報(bào)告，并問(wèn)他們：“這個(gè)報(bào)告有什么問(wèn)題？”事實(shí)證明，業(yè)務(wù)用戶(hù)可以很容易地指出報(bào)告中的問(wèn)題，并通過(guò)這樣做，提供IT實(shí)現(xiàn)最終報(bào)告所需的所有業(yè)務(wù)規(guī)則。
這種需求收集方法的程序如下：
- 確定所需的數(shù)據(jù)：如上一節(jié)所述，第一步是確定Raw Mart及其報(bào)告的數(shù)據(jù)來(lái)源。 再次，只應(yīng)將范圍內(nèi)的數(shù)據(jù)加載到集結(jié)區(qū)并進(jìn)入企業(yè)數(shù)據(jù)倉(cāng)庫(kù)。如果可能，甚至應(yīng)減少數(shù)據(jù)以實(shí)現(xiàn)快速輸出。例如，在第一步中，應(yīng)只保留最終報(bào)告所需要的數(shù)據(jù)，而不包括中間原始報(bào)告所需要的數(shù)據(jù)。
- 生成Raw Mart（原始集市）：一旦數(shù)據(jù)被加載到Raw Data Vault（原始Data Vault），就會(huì)從這些原始數(shù)據(jù)中創(chuàng)建Raw Mart。在加載Raw Mart時(shí)沒(méi)有實(shí)現(xiàn)業(yè)務(wù)規(guī)則。取而代之的是，數(shù)據(jù)的格式簡(jiǎn)單地從Data Vault模型更改為維度模型。虛擬視圖最適合這種方法，因?yàn)樗鼈兛梢院苋菀椎貥?gòu)建。
- 生成原始報(bào)表：一旦數(shù)據(jù)在維度Raw Mart中，就可以創(chuàng)建原始報(bào)表。 由于沒(méi)有對(duì)數(shù)據(jù)應(yīng)用業(yè)務(wù)規(guī)則，所以報(bào)告包含好數(shù)據(jù)、壞數(shù)據(jù)和臟數(shù)據(jù)。
到目前為止，IT控制了交付時(shí)間。他們有責(zé)任敏捷到這一點(diǎn)。下一步從項(xiàng)目的業(yè)務(wù)方面驅(qū)動(dòng)：
- 在墻上張貼原始報(bào)告：當(dāng)原始報(bào)告已經(jīng)從Raw Mart（原始集市）創(chuàng)建時(shí)，報(bào)告將提交給需求會(huì)議的與會(huì)者。好的方法是打印，把它們貼在房間的一邊。如果這是不可能或不可行的，也可以使用液晶投影儀向小組展示報(bào)告。然而，墻上張貼報(bào)告的優(yōu)點(diǎn)是與會(huì)者可以花時(shí)間審查報(bào)告，并將他們的評(píng)論或更正直接添加到打印件中。報(bào)告中的大多數(shù)問(wèn)題都很容易得到。他們可以向IT解釋報(bào)告有什么問(wèn)題，以及為什么他們不能在這種狀態(tài)下使用它們。
- 收集業(yè)務(wù)規(guī)則和其他要求：IT應(yīng)該直接詢(xún)問(wèn)與會(huì)者是什么使報(bào)告無(wú)法使用，以及如何使該報(bào)告對(duì)業(yè)務(wù)有用。為了使數(shù)據(jù)正確，需要對(duì)數(shù)據(jù)進(jìn)行哪些修改？業(yè)務(wù)方面的答案是缺少的業(yè)務(wù)規(guī)則，這些規(guī)則需要記錄在需求文檔中，并應(yīng)用于進(jìn)入原始報(bào)告的數(shù)據(jù)。請(qǐng)注意，應(yīng)該更少關(guān)注報(bào)告的安排，因?yàn)檫@種討論應(yīng)該由業(yè)務(wù)方面驅(qū)動(dòng)，在最好的情況下，不依賴(lài)于IT。
一旦需求被收集，至少部分地，IT通過(guò)執(zhí)行業(yè)務(wù)規(guī)則和其他需求再次驅(qū)動(dòng)項(xiàng)目：
- 轉(zhuǎn)換業(yè)務(wù)規(guī)則和其他需求：最后一步是將業(yè)務(wù)規(guī)則和其他需求，由業(yè)務(wù)給出并記錄在需求文檔中，轉(zhuǎn)換為程序邏輯。這可以在ETL流中完成，也可以在SQL視圖中完成。業(yè)務(wù)規(guī)則將原始數(shù)據(jù)轉(zhuǎn)換為從原始Data Vault到業(yè)務(wù)倉(cāng)庫(kù)或信息集市的途中的信息。
在這些業(yè)務(wù)規(guī)則由IT實(shí)現(xiàn)后，項(xiàng)目的業(yè)務(wù)方可以對(duì)輸出進(jìn)行審查和測(cè)試，如果它們還不滿(mǎn)意最終結(jié)果，則要求進(jìn)一步修改。然而，這些修改成為需求變更，并在隨后的sprint中實(shí)現(xiàn)。所描述的敏捷需求收集過(guò)程幫助業(yè)務(wù)用戶(hù)表達(dá)他們的業(yè)務(wù)規(guī)則。對(duì)其中許多人來(lái)說(shuō)，傳統(tǒng)上對(duì)需求文檔的關(guān)注過(guò)于抽象，并阻止了所需的標(biāo)識(shí)與報(bào)告草稿一起識(shí)別問(wèn)題。
建議的做法是記錄這些要求會(huì)議，并建立一個(gè)Wiki網(wǎng)站，供組織中的每個(gè)人使用。會(huì)議記錄，包括對(duì)已發(fā)現(xiàn)的業(yè)務(wù)規(guī)則的說(shuō)明，應(yīng)登記在網(wǎng)站上，以確保需求收集過(guò)程的透明度。 Web2.0機(jī)制使參與者能夠根據(jù)自己的理解發(fā)布評(píng)論甚至修改業(yè)務(wù)規(guī)則。這種方法首先確保需求是正確的。如果在網(wǎng)站上進(jìn)行了大量的討論，可能需要另一次需求會(huì)議來(lái)澄清任何開(kāi)放的問(wèn)題，然后才能開(kāi)始實(shí)施。在實(shí)際實(shí)施之前進(jìn)行這些討論意味著對(duì)本組織的巨大好處和生產(chǎn)力的提高，是項(xiàng)目總體成功的一個(gè)促進(jìn)因素。為了對(duì)團(tuán)隊(duì)的功能做出正確的假設(shè)能夠在一個(gè)沖刺中完成，這對(duì)于范圍界定很重要，團(tuán)隊(duì)必須能夠?qū)ν瓿赡承┕δ芩璧呐ψ龀稣_的估計(jì)。本專(zhuān)題將在下篇文章中討論。
