建立整合的業務與技術策略

產品類型在程式碼庫中的表示方式會對新增新產品或在出現新產品時調整類別的容易程度產生重大影響。尋找產品線資訊在其他系統中的假設。產品代碼可能在其他地方硬編碼，有些系統可能只假設某些類型的產品。尋找整個堆疊的變更，從您提供不同客戶體驗和在網站中導覽的使用者介面，到網域模型中的新條目，以及資料庫中潛在的新表格結構。

業務流程可能不適合未來考慮的產品。可能需要對共用服務後端系統（例如付款和發票系統、配送和倉儲管理系統以及業務報表）進行變更

在產品之間共用能力，讓您可以專注於新產品的增值區隔。整合共用能力可提升上市速度。但是，請注意強制共用能力，因為產品提供的流程不同，可能會導致能力中出現不必要的複雜性和負債。

不會增加產品差異化的能力，可以安全地指定給套裝軟體，無論是安裝版或 SaaS。建立此類能力的清單，可以推動考慮目前的供應商產品。產品線的變更有助於釐清哪些能力對產品差異化很重要。重新檢視提供合適產品的供應商，原因在於隨著時間推移而變更，以及重新評估差異化因素。

找出可以在各市場中多元化、複製、統一或協調的功能。多元化和複製的功能可以存在於每個市場，您希望透過全球平台提供統一的功能。

If you need to host your infrastructure in the new market due to regulatory, compliance or even performance reasons, you need to make deployment repeatable across your systems. This reduces inconsistencies across regions, which leads to high triage times when a fault occurs. It's too common for organizations to set up separate teams to customize and operate each region, resulting in configuration drift / snowflakes as code, and manual maintenance. Equal emphasis needs to go to maintenance - cost, staff effort, and results (things are patched, consistent, old versions retired, fixes of all sizes rolled out quickly and comprehensively). The running costs to scale geographically becomes near-linear, and improvements and fixes are not distributed quickly or consistently.

Commissioning new data centers in new markets in order to be compliant may take a long time. If there is no repeatability in the process, and it takes a while to commission, you could consider a move to the cloud. Cloud-based infrastructure will be easier to adhere to data sovereignty requirements in new markets but you may need to look at ways to partition your database to be compliant.

Look for any third-party systems which make you non-compliant by passing regulated information outside the country. This might include an examination of OLAs and SLAs.

尋找預設啟用此功能的 UI 架構。將國際化改造到 UI 中可能是一個繁瑣的過程。內容長度可能會因語言而異。尋找可以容納較長或較短文字元素的動態 UI 元素。如果 UI 架構已針對翻譯檔案進行設定，一個不錯的實驗是將所有翻譯改為較小的內容，例如「XXX」，以及改為非常長的內容，以了解頁面如何回應。

尋找能隔離變更的良好編寫程式碼庫。

是否需要在開發流程中增加時間，讓代理商翻譯您的檔案？這個額外的等待時間可能會影響您的小型回饋迴路。或者，是否需要將翻譯流程納入設計流程中？

難以變更的前端程式碼將使提供新的客戶體驗變得具有挑戰性。尋找硬編碼的導覽元素、難以變更的前端程式碼，以及缺乏前端測試。

未測試的程式碼，尤其是未測試的 JavaScript，將使變更體驗具有風險。僅透過緩慢（且不穩定的）端對端測試進行測試的前端將增加開發新體驗所需的時間。

在納入新的使用者介面體驗時，例如將您的網站擴充到原生行動應用程式，請考量您的數位平台如何容納和整合核心業務功能，同時提供各種前端互動的彈性。如果您已建立微服務或微前端網站，需要哪些架構調整，例如 BFF（後端對前端）行動轉接器。

儘管被收購的業務繼續獨立運作，但假設需要整合一些業務功能（例如財務），但可能不是全部。業務功能圖是說明業務層面交叉點的快速第一步，然後再轉到 API。API 策略是一種透過建構 API 生態系統來解鎖現有業務功能的方式，以允許大規模創新。它有助於縮短上市時間，方法是建立一個易於操作、整合和使用的 API 生態系統。API 與專注於系統整合的傳統方法不同。透過將業務整合集中在定義良好的 API 上，您將提高您未來創新的能力。

Investigation into the API strategy applies as equally in the independently run case as it does in this case, however there are a few other levers that you can take advantage of. For instance, you could share event streams or take advantage of shared storage.

As you look to work closely with the acquired business, you will need to look to consolidate across domain models. If you focus on getting this alignment in the domain model, the data matching and integration of systems will become easier to configure.

A unified customer experience across the two products will increase customer satisfaction and improve retention. It will also enable the amplification of the value that both businesses together provide your customers, as the customer doesn't face the burden of working across two disjointed systems.

The Operating Model Quadrant from Enterprise Architecture as Strategy, is relevant for organizations wanting to unify capability across their group of companies, or when addressing consolidation of inorganic growth.

Successful acquisitions dedicate resources and people to integrating the businesses. As a technology leader your input maybe required to help the integration efforts understand how the systems will be integrated. Runtime environments may need to be consolidated, data might need to be migrated into the new system, or archived for compliance reasons. A security review of the systems may highlight security remediation that needs to happen within the system before the migration. The systems themselves may need consolidation as libraries and frameworks are unified across the technology stack, to improve the developer experience moving across products.

Streamlining and consolidate the operational aspects of the systems reduces the operational cost and time it takes to manage across multiple disparate systems. You may need to change how running systems are observed, which could include changing the logging information, frequency or changing severity level of logs.

它是否反映網域？在多個層級考慮這一點：在類別或檔案中，一直到元件邊界。它們如何彼此互動？（考慮網域建模）。評估程式碼的向度包括：大小、複雜度、耦合、凝聚力。

測試範圍很容易衡量，但並不總是能很好地顯示測試品質，其他要查看的事項包括測試數量；不穩定性；執行時間；測試的一致性/結構；命名；以及與程式碼的耦合

在預生產或生產中發現的缺陷，其修復成本呈指數級增加，並會中斷增值工作的流程

尋找漫長的回饋迴路，例如漫長的建置時間、驗證跨功能需求是否得到維持

有哪些文件存在、是否為最新、是否相關 / 井然有序 / 容易找到，每個儲存庫是否都有關於程式碼目的以及如何測試和執行它的明確文件。

明智的預設值、慣例重於組態、安全的防護欄和良好的入門文件可提升新團隊成員的生產力速度。

認知稅會造成品質問題，大幅減緩交付。

團隊經常陷入建立許多對商業價值非必要的東西。運送過程中浪費的範例包括認知負擔/情境切換、在正確的時間找到正確資訊的能力、開發經驗中的摩擦以及緩慢的品質回饋迴路。尋找分散的開發人員生態系統，需要在多個地方和系統中瀏覽才能完成工作。衡量工作流程階段之間的工作佇列大小是量化瓶頸的好方法。查看流程指標以及循環和前置時間。

衡量將單行程式碼變更導入生產的時間。小型變更的長時間延遲會阻礙頻繁更新，導致更大、風險更高的更新，並降低對商業機會的反應能力。

元件缺陷率的熱點圖可以顯示最需要優先改善的重要區域。

如果將來功能開發計畫在風險部分進行，適當修正此區域可能會更有效率。通常需要架構變更才能解決這些區域的根本原因。

尋找您達到容量並隨著時間推移注意到模式的期間。如果您在成長後在預期的負載下接近容量，您現在需要開始處理系統效能。

在呼叫中心資料中尋找模式。將此資料中的任何模式與產品缺陷清單中的熱點圖進行比對。

尋找經常一起變更的元件，這表示它們緊密結合。變更熱點表示變動率高。

With the move to the cloud, some financial controllers and technology leaders alike have lost the financial visibility that they once had over infrastructure bought and run in data centres. Infrastructure buying centres have moved from the procurement office to the engineers keyboard, with credit cards stored on file with cloud vendor accounts. All too often, financial offices are only seeing the cloud spend once the bill arrives at the end of the month. There is a disconnect between the engineers who are spinning up new infrastructure and the controllers of the budget.

Democratising the financial decision making around cloud spend to the engineers that are responsible for instantiating the cloud components needs to be done with the right financial controls and alerts in place. Influencing the culture of the organisation to operate on the cloud is important to help optimise cloud costs with governance and collaboration as a discipline. Tagging infrastructure and surfacing the spend on operational dashboards, alongside uptime and usage metrics and alerting, will provide the right balance between financial control and governance.

Retiring or sunsetting systems that you are no longer using is the fastest way to reduce your cloud bill. Take a critical look at everything that appears on the bill to make sure that you are still getting value from it.

資料治理是指對組織的資料資產進行整體管理、控制和保護。它包含確保資料在整個生命週期中的品質、完整性、可用性和安全性之程序、政策和標準。資料治理的目標是建立一個架構，用於管理組織中資料的收集、儲存、使用和分享方式。

已屆使用年限 (EOL) 的軟體版本不再受軟體供應商支援。這表示供應商將不再提供軟體的安全性更新、錯誤修正或新功能。因此，使用 EOL 軟體可能會對企業構成許多風險，包括安全性漏洞、效能問題、相容性問題和資料遺失。EOL 版本提供了進行目前市場掃描的機會，以移轉至可支援下一個成長階段的新技術。

透過在中斷事件發生時備妥備用計畫，公司可以減少中斷事件對其營運的影響。使用技術來提升對供應鏈的能見度。透過取得貨物和材料位置的即時資料，公司可以更快速地找出中斷事件並因應。

定義數據架構以滿足分析用例。根據數據工程、軟體工程和持續交付的最佳實務設計和執行數據平台。您希望能夠輕鬆地擴充不同的數據來源和使用者，啟用分析用例，進而產生更豐富的洞察。

如果數據是一堆不相關的事實，那麼輕鬆存取數據可能對組織沒有那麼大的用處。建立精選檢視和治理資料集，其中包含來自各種來源的數據，以進行分析、機器學習、服務、應用程式等。

一位優秀的領導者應具備清晰的願景和目標，並能有效傳達以激勵他人。情緒智商至關重要，誠信和道德的行為也是如此。果斷、授權、適應力、協作和團隊建設是營造積極工作環境的必要特質。問責制、韌性和注重成果也是有效領導力的指標。此外，優秀的領導者會優先考慮指導和發展，以確保其團隊成員的成長，進而促成組織的長期成功。尋找能促進多元和公平文化、推廣包容性的領導者。

查看激勵知識分享行為的獎勵、認可或晉升。

尋找容易取得、瀏覽和回饋的系統。

查看留任資料和離職面談，看看是否有重複的模式

縮短系統存取要求的處理時間，讓員工能回到增值任務

衡量工作佇列（庫存）在工作流程階段之間的大小是量化瓶頸的好方法。支援許多溝通管道會增加成本，而許多管道會增加混淆，因為人們不確定要使用哪一個。交接點通常會產生摩擦

有些系統需要有差異，因為有國家/地區特定的法規和文化差異。但許多系統是在當地開發，同時與世界其他地區有實質上相同的行為。當地業務部門通常無法等待功能在全球優先排序，但這會導致許多類似的系統，而這些系統難以維持。

聊天評論可以作為員工對系統和流程滿意度的指標。情緒分析工具通常用於客戶評論，它們也可以用於評估內部系統。

收到大量支援票證的系統應檢討是否需要加強或更換

如果員工用腳投票支持外部系統，那麼我們應該檢討內部系統是否值得。

老舊、疲憊的系統不僅會磨損員工對組織的情緒，還會損害生產力。就像您希望專注於引人入勝的客戶體驗一樣，將您的員工視為您內部產品的客戶，並為他們提供實現目標所需的現代化工具。重要的是要像對待面向客戶的產品一樣，對待這些系統。這表示將您的內部使用者視為這些系統的客戶，並應用與對待產品相同的產品思考方法、客戶研究和客戶服務。

Thoughtworks 的 Looking Glass 報告和 Technology Radar 是兩份出版物，可以幫助技術領導者了解當前和新興技術，以及像 Gartner 和 Forrester 這樣的分析師報告。不過，小心新技術。不應為了技術而選擇新的閃亮技術。應為客戶或員工創造明確的價值。有些組織採用創新代幣。創新代幣的概念非常簡單：您獲得三個創新代幣。每次創新（即執行標準以外的事情）時，您就會花費其中一個代幣。一旦您將它們全部花光，您就出局了，您不能再創新了。

確保使用可靠的資料來源和歷史資料，重點關注與業務目標一致的相關指標。區隔市場，並考慮經濟狀況和技術進步等外部因素。與產業基準和競爭對手進行比較分析，尋求產業專家的意見，並驗證假設。持續監控趨勢、視覺化資料，並採取前瞻性方法來預測未來發展，並相應調整業務策略。

考量這些更廣泛的問題，讓您能快速適應快速發展的狀況。例如，我們最近為旅遊業的客戶完成了一項技術策略。我們使用旅遊見解資料和我們自己的客戶研究，探討旅遊的樣貌在 Covid-19 引發的封鎖後如何改變。在不確定的時期，人們重返旅遊時，取消和重新預訂的便利性已成為一項重要因素。因此，技術策略包含了專注於改善取消、通知和後端整合的能力。我們也找出一些良好的範例，其中機器學習有助於預測取消的可能性，因此我們將機器學習和資料工程的導入納入技術策略，以協助客戶重返旅遊並減輕客戶支援團隊的負擔。閃亮的技術解決實際問題，而不是為了使用閃亮的技術而使用。