出于同樣不太明顯的原因，太多的數(shù)字化轉(zhuǎn)型努力未能達到預期：在匆忙實現(xiàn)基礎設施和應用程序現(xiàn)代化的過程中，數(shù)字化轉(zhuǎn)型領導者忽視了轉(zhuǎn)變底層數(shù)據(jù)的關鍵步驟。這是一個疏忽，導致了解決方案的不足和自我限制，即數(shù)字化轉(zhuǎn)型應該以某種方式基于舊有的非敏捷數(shù)據(jù)管理系統(tǒng)。

幸運的是，CIO和他們的團隊正在學習如何利用多種可用的方法和工具集，這些方法和工具集可以消除信息孤島，實現(xiàn)更統(tǒng)一的數(shù)據(jù)視圖。讓我們來看看這些選項是如何消除有關數(shù)據(jù)限制的瓶頸的，以及高層領導在做出關鍵決策以支持整個企業(yè)更廣泛的數(shù)字化轉(zhuǎn)型工作時應該考慮哪些因素。

數(shù)字化轉(zhuǎn)型對任何企業(yè)來說都是一項重大任務——其中有很多挑戰(zhàn)，數(shù)字化轉(zhuǎn)型轉(zhuǎn)型團隊有時會因為數(shù)據(jù)限制而阻礙數(shù)字化轉(zhuǎn)型的進展。

【資料圖】

以下是四個最常見的問題：誤解1：在開始之前，數(shù)據(jù)必須是干凈的和整合的

許多企業(yè)錯誤地認為，在進行任何設計之前，他們必須進行數(shù)據(jù)清理，并將所有內(nèi)容格式化為原始狀態(tài)。這種信念可能會將必要的數(shù)字化轉(zhuǎn)型舉措推遲數(shù)年。事實是，這些活動可以與正確的數(shù)據(jù)管理方法同時進行。

誤解2：遺留應用阻礙了真正的現(xiàn)代化

數(shù)字化轉(zhuǎn)型團隊通常認為他們的遺留應用程序不能現(xiàn)代化，并且遺留數(shù)據(jù)將永遠受到跨多個不協(xié)調(diào)系統(tǒng)的低可見性和檢索的影響。大多數(shù)人錯誤地認為，“淘汰和更換”是實現(xiàn)投資回報的唯一方法。在現(xiàn)實中，訪問遺留數(shù)據(jù)的正確方法可以使構(gòu)建現(xiàn)代應用程序更具戰(zhàn)略性和敏捷性。

誤解3：所有架構(gòu)決策都必須事先做出

即使數(shù)字化轉(zhuǎn)型團隊對如何整合他們的數(shù)據(jù)有很好的想法，他們也可能會認為他們的應用程序基礎設施沒有現(xiàn)代化到足以利用這些預期的變化的程度。這是一個難題，可以通過在數(shù)據(jù)駐留的地方處理數(shù)據(jù)而不是將數(shù)據(jù)加載到特定的應用程序中進行分析來快速解決。

誤解4：認為合規(guī)是一個復雜的事項

在孤立的應用程序和數(shù)據(jù)中苦苦掙扎的企業(yè)，也將在孤立和不協(xié)調(diào)的合規(guī)性信息中苦苦掙扎。這讓合規(guī)性感覺像是減慢數(shù)字化轉(zhuǎn)型努力的額外步驟?，F(xiàn)實情況是，高級數(shù)據(jù)管理技術(shù)可以將合規(guī)性無縫集成到整個業(yè)務的流程和工作流中。

以下是使用靈活的數(shù)據(jù)體系結(jié)構(gòu)助力數(shù)字化轉(zhuǎn)型的一些方法。

以上所有誤解都是自我限制的，因為它們低估了當今在整個企業(yè)中解鎖和連接數(shù)據(jù)的可能性。幸運的是，數(shù)字化轉(zhuǎn)型團隊現(xiàn)在有越來越多的選擇，以便在整個IT產(chǎn)業(yè)實現(xiàn)更具活力和更互聯(lián)的數(shù)據(jù)生態(tài)系統(tǒng)，從而實現(xiàn)更好的可見性、可用性和敏捷性。

對于權(quán)衡今天的選項的高管來說，記住過時的信念最初來自哪里是有幫助的;它們是企業(yè)可以在傳統(tǒng)本地數(shù)據(jù)倉庫的靜態(tài)和豎井體系結(jié)構(gòu)上生存的時代的遺留問題。

從那時起，一系列更靈活的數(shù)據(jù)框架，包括數(shù)據(jù)湖、數(shù)據(jù)網(wǎng)格和數(shù)據(jù)交換矩陣架構(gòu)已經(jīng)發(fā)展，以利用現(xiàn)代云部署的潛力和云中可能發(fā)生的API驅(qū)動、以應用為中心的DevOps的靈活性。

數(shù)據(jù)湖方法

數(shù)據(jù)湖代表著超越傳統(tǒng)數(shù)據(jù)倉庫的最早飛躍之一，它消除了在加載數(shù)據(jù)之前對數(shù)據(jù)進行清理、格式化和轉(zhuǎn)換的需要。數(shù)據(jù)湖允許你首先加載數(shù)據(jù)，然后通過各種分析過程確定數(shù)據(jù)的相關性和業(yè)務潛力。

取舍或限制是，數(shù)據(jù)湖仍然涉及到將數(shù)據(jù)加載到某個地方，加載后分析仍然是編碼密集型的，需要高技能(和高薪)的數(shù)據(jù)科學家。

數(shù)據(jù)網(wǎng)狀網(wǎng)方法

數(shù)據(jù)網(wǎng)格方法不需要加載或移動數(shù)據(jù)，而是直接連接到數(shù)據(jù)源。微服務、容器化相關技術(shù)，然后將單一服務分解為更小的數(shù)據(jù)組件，并通過強大的API集成來管理和定制這些數(shù)據(jù)連接，以根據(jù)業(yè)務或運營需求進行管理。

其結(jié)果是使用DevOps實現(xiàn)更大的靈活性和更強的創(chuàng)新能力，但代價是仍需要復雜的數(shù)據(jù)工程來運行數(shù)據(jù)網(wǎng)格架構(gòu)。

數(shù)據(jù)交換矩陣方法

最后，數(shù)據(jù)結(jié)構(gòu)本質(zhì)上是一個數(shù)據(jù)網(wǎng)格，帶有一個附加的“抽象層”，它將所有數(shù)據(jù)虛擬化為一個集中的平臺。好處是所有數(shù)據(jù)都可以通過單一管理平臺進行虛擬化和情景處理，以便更廣泛的業(yè)務用戶使用。

需要權(quán)衡的是，這種突如其來的可見性可能會讓新的數(shù)字化轉(zhuǎn)型團隊望而卻步，這些團隊的任務是解決所有以前看不見的依賴項、漏洞、治理問題以及突然出現(xiàn)的合規(guī)性或安全漏洞等問題。

所有這三種方法在當今的市場中仍然具有代表性，供企業(yè)選擇。雖然根據(jù)每個公司的數(shù)字化轉(zhuǎn)型目標和技術(shù)專長水平，做出選擇的考量會有所不同，但成功的一個共同因素是通過盡可能的自動化和低代碼來確定可擴展和可重復的流程的優(yōu)先級。

自動化對于數(shù)據(jù)湖和數(shù)據(jù)網(wǎng)格實施中的開發(fā)人員尤其有用，以加速和擴展技術(shù)流程。低代碼平臺可進一步節(jié)省時間;尤其是在部署數(shù)據(jù)交換矩陣架構(gòu)時，低代碼平臺可使更廣泛的企業(yè)用戶群體的訪問變得大眾化，并使采用曲線更加平緩。

你為什么要釋放互聯(lián)數(shù)據(jù)的轉(zhuǎn)型潛力?

選擇正確的底層數(shù)據(jù)體系結(jié)構(gòu)需要不斷權(quán)衡各種方法的優(yōu)缺點，以滿足企業(yè)的特定業(yè)務和運營需求。

無論確切的戰(zhàn)略和實施方法如何，使用更靈活的數(shù)據(jù)架構(gòu)發(fā)展業(yè)務將幫助企業(yè)擺脫有關數(shù)據(jù)靈活性的自我限制的誤區(qū)——將數(shù)據(jù)轉(zhuǎn)變?yōu)檎麄€企業(yè)數(shù)字化轉(zhuǎn)型工作的強大驅(qū)動力。

關鍵詞：