一些非常年輕且極具創新性的公司正在推進形成一些引人注目的“顛覆性工作”,迫使更多的傳統公司對數字化轉型舉措做出反應。高德納公司(Gartner)表示,“90%的企業領導者將數字化視為首要任務”,這并不令人感到意外,而“83%的領導者都努力在數字化轉型方面取得有意義的進展。”
自主性IT團隊采用各種敏捷的方法來加快數字化轉型的步伐。然而,僅通過敏捷實踐往往難以實現其公司的業務戰略和目標。正如我在之前的白皮書中所寫的那樣,“乍一看,精益及敏捷開發和架構似乎在交付軟件項目上是兩種相互矛盾的方法。實際上,它們是非常互補的。敏捷性具有非??焖俚姆磻獣r間和在連續流程中方便地提交項目,這在快速變化的公司環境中是必要的。做一個類比,敏捷性可讓你跑得非常快。另一方面,架構可以讓你看得足夠遠,這樣在你敏捷地奔跑時不會全速地撞到墻上。”
在組織內使用和利用其企業和業務架構路線圖的公司會更好地理解業務架構的功能,以與其業務和IT利益相關者進行充分溝通,并提供符合組織策略且以客戶為導向的計劃,如上圖1所示,以及在題為“戰略執行的轉念”的博客中所述。
使用架構進行數字化轉型主要涉及以下步驟:業務架構、路線圖開發和敏捷交付解決方案。
業務架構
業務架構涉及以下步驟:
1. 使用商業模式圖(如在題為“連接商業模式圖和業務架構”一文中所述)、客戶價值圖、客戶旅程圖和/或業務激勵模型,自上而下以及橫向地闡明和宣傳目標和策略,并至少將其與價值流和功能聯系起來;
2. 使用價值主張、客戶導向的價值流和價值階段來提供價值(每個價值階段都與客戶旅程的一個或多個步驟相關聯,如在題為“使用角色和業務架構來優化客戶旅程”一文中所述);
3. 通過詳細檢查價值流的啟用功能來確定功能的優先級;
4. 評估和衡量那些支持以客戶為導向價值流的有問題的功能;
5. 明確以客戶為導向的價值流(從“目前”狀態到其理想狀態)的每個有問題功能的差距;
6. 為每個有問題功能來詳細說明預期的方案結果;
7. 然后才能選擇最終的計劃/項目路線圖。
路線圖的開發
與業務架構相反,路線圖開發是在企業內企業架構實踐中的一個眾所周知的課題。如上圖1所示,我建議路線圖開發步驟如下:
1. 在業務架構中所檢查和衡量的那些有問題的功能應與其支持軟件應用程序/系統交叉映射,有時應與其他IT或非IT資產交叉映射,尤其是涉及物聯網技術的項目;
2. 應從技術上審查所有可能實現預期成果的項目方案,并做出預算收入和成本;
3. 還應詳細闡述每種方案的路線圖;
4. 然后應根據目的和目標、財務標準和各種風險因素來評估每個方案;
5. 然后才能選擇投資組合/計劃/項目路線圖。
敏捷方式交付解決方案
正如題為“提供和使用業務架構模型:敏捷數字化轉型的關鍵”一文中所述,一旦選擇了路線圖,業務人員的工作和企業架構師的工作就不會結束。優秀的架構師將始終確保通過與高級業務流程、業務需求、史詩故事(epics)甚至用戶故事建立關系,為參與計劃、項目和“沖刺”工作的人員提供詳細的架構模型。
如上圖1所示,我建議敏捷交付解決方案應包括以下兩個步驟:
1. 將選定路線圖所涉及的業務和企業架構元素(功能、信息概念、組織、應用程序等)與業務規則和業務流程相結合,以確定需要修改、刪除或更改的內容—這會節省業務流程專家很多時間;
2. 在開始“沖刺”工作和與業務利益相關者交流之前,根據所選路線圖所涉及的業務和企業架構元素(功能、信息概念、組織、應用程序等)來構建業務需求、史詩故事(epics)和用戶故事,從而讓業務分析師和軟件開發人員能更高效地實現其組織的業務戰略和目標。
結論
公司正在以前所未有的方式致力于其組織的數字化轉型。然而更多時候,他們并沒有在轉型工作中表現得很好或足夠好。IT驅動的敏捷團隊往往孤立工作,與其他同事相隔離,他們往往不能根據公司的業務戰略和目標交付成果。首先,必須在敏捷計劃/項目的規劃階段盡早使用企業和業務架構,以最大限度地減少業務利益相關者和業務分析師之間在收集信息時浪費的時間,其次是在能真正滿足企業業務戰略和目標的解決方案交付之前要大幅降低敏捷迭代的次數,最后確保來自不同計劃/項目的敏捷團隊不會提交相互矛盾或部分冗余的軟件解決方案。