Skip to content

2025

Achieving Strategic Goals Through Measurable Small Actions

Achieving strategic goals is often framed as a grand pursuit, a bold vision, a multi-year transformation, a sweeping program to reshape the organization. Yet, in practice, strategy rarely fails because the vision is unclear. It fails because the path between the present and the future is too abstract for people to act on. Leaders speak in outcomes; teams operate in tasks. The gap between the two is where momentum is lost.

As an enterprise architect, my role is to translate strategy into motion. This means making the strategic small enough for people to move, not by diluting its intent, but by expressing it as measurable, achievable steps that build toward meaningful change. Large goals are inspiring, but it is the deliberate execution of smaller actions that makes progress real.

This year, I will contribute to a high-performing architecture team with deep domain expertise and a culture of continuous learning. A team does not become high-performing through declarations alone. It grows by institutionalizing knowledge sharing, challenging assumptions with curiosity rather than judgment, and creating an environment where learning is continuous and safe. Every conversation, every reusable pattern, every time we help a colleague understand the why behind the architecture, these are the small, compounded actions that shape capability and confidence.

I will design and implement scalable, efficient architecture frameworks and standards to enable APAC business operations optimisation. This will not happen through a single document or a single workshop. It will happen through cycles of refinement, engagement, and validation with real business workflows. Standardization is successful only when the people who rely on it understand its intent, trust its value, and are empowered to apply it. The strategic outcome is operational excellence; the daily work is clarity, consistency, and guidance that lowers friction and accelerates decision-making.

I will enable APAC business growth through architecture-driven innovation and technology alignment. Growth depends on identifying where technology can reshape the business model, improve customer experience, or unlock new revenue streams. Innovation at scale comes from disciplined experimentation. Small prototypes, targeted pilots, and measurable learnings build confidence before broader transformation. Big impact begins with controlled, learnable steps.

Small actions do not mean small thinking. They represent achievable momentum. Organizations that execute strategy well normalize progress. They create systems where learning is valued more than blame, where effort is recognized as the precursor to outcomes, and where teams feel psychologically safe to initiate change instead of waiting for permission.

By focusing on whether we are applying the right architectural patterns, reinforcing shared principles, and continuously learning, we make improvement sustainable. When we evaluate success not merely on whether we have already arrived, but on whether we are moving with purpose, we create an environment where progress is repeatable and predictable.

Strategy becomes real when people can act on it. And people act when they believe they can succeed, one aligned, measurable, meaningful step at a time.

透過可衡量的小行動實現策略目標

實現策略目標常被形容為一場宏大的追求、一幅大膽的願景、一場跨年度的轉型計劃,旨在重塑整個組織。然而,在實際情況中,策略失敗往往不是因為願景不清晰,而是因為「從現在到未來」之間的路徑過於抽象,讓人無法真正付諸行動。領導者談論成果,團隊著眼於任務,兩者之間的落差正是行動力消散之處。

作為一名企業架構師,我的角色是將策略轉化為行動。這意味著要把宏觀的目標轉換為每個人都能採取的具體行動,不是削弱策略意圖,而是將它表達為可衡量、可達成、可累積的步驟。大的目標固然能激勵人心,但真正帶來進展的,是小而持續的行動。

今年,我將致力於打造一支高效能的架構團隊,使其具備深厚的領域專業與持續學習的文化。一支高效能團隊並非靠口號建立,而是來自知識分享的制度化、以好奇心而非批判面對問題、並創造一個學習安全且被鼓勵的環境。每一次討論、每一次可重複使用的架構模式、每一次耐心解釋架構背後的原則,都是累積能力與信心的小行動。

我將設計並落實可擴展且高效率的架構框架與標準,以支持亞太地區的業務營運優化。這並非透過一份文件或一次工作坊就能完成,而是透過持續迭代、實際情境驗證,並與業務流程深度結合。標準要成功,必須讓使用者理解其意義、信任其價值,並具備靈活應用的能力。策略成果是營運卓越,而每日的工作則是明晰性、一致性與降低決策摩擦。

我也將透過架構驅動的創新與技術對齊,支持亞太地區的業務成長。業務成長往往源自於識別技術能改變商業模式、改善客戶體驗、或開拓新收入的切入點。真正能規模化的創新來自有紀律的試驗:小型原型、限定範圍的試點、可量化的學習。大的影響往往始於可控且可反思的第一步。

小行動並不代表小格局,而是「可持續的動能」。能持續執行策略的組織具有共同特徵:它們將「進步」正常化。它們建立重視學習而非責備的系統,將努力視為成果的前提,並讓團隊感到安全,可以主動推動變革,而非等待指令。

當我們聚焦在是否運用正確的架構模式、是否強化共同設計原則、是否持續學習時,我們就能讓改善變得可持續可複製。成功不僅是「是否已經達成」,而是「是否正朝著正確方向持續前進」。

策略會在「人能夠採取行動時」變得真實。而人之所以願意行動,是因為相信自己能成功,一步一步,清晰、對齊、有意義地前進。

Enterprise Architect Goals and KPIs - Aligning Strategy, Outcomes, and Real Value

The role of the Enterprise Architect (EA) sits at the intersection of business strategy, technology direction, and organizational change. Yet when it comes to defining goals and KPIs, many organizations struggle to articulate what success looks like. Unlike delivery teams where progress is easily measured in terms of completed tasks or shipped features, the EA operates primarily in the domain of outcomes. These outcomes are multi-dimensional, interdependent, and influenced by forces well beyond the architect’s direct span of control. The value of the EA is real, but it is often indirect, systemic, and revealed over time.

Many challenges complicate goal-setting for Enterprise Architects. In some organizations, business strategy shifts rapidly or is not clearly communicated, making it difficult to define stable goals at the start of the year. Goals set in January can become irrelevant by July as market conditions, leadership priorities, and transformation programs evolve. Additionally, while the EA can directly produce outputs such as roadmaps, reference architectures, capability models, and governance frameworks, these outputs are not where the value ends. The true value lies in the outcomes those outputs help create, like reducing technology fragmentation, accelerating product integration, improving customer experience, or enabling faster innovation. These outcomes depend on collaboration across teams and functions, which means the EA’s contribution is essential but not always isolated or easily quantified.

Traditional HR-driven performance frameworks often do not reflect this strategic complexity. Many goal-setting approaches value short-term deliverables and activity metrics, which can unintentionally push Enterprise Architects toward documenting rather than enabling change. At the same time, strategy alignment between global and regional teams further complicates measurement. What makes sense for a global strategy may require adaptation at the regional level due to regulatory, cultural, or market differences. The EA often plays the crucial bridging role here, translating strategy into execution in a way that balances consistency with contextual relevance.

A more effective approach is to define EA goals and KPIs across two levels: outputs and outcomes. Outputs are the tangible deliverables within the EA’s direct control, such as architecture roadmaps, standards, and steering forums. Outcomes describe the organizational movement these outputs enable, such as reduced duplication of systems, faster integration cycles, improved stakeholder alignment, or increased architectural maturity. For example, output goals may include delivering a multi-year architecture roadmap and establishing clear technology standards. Outcome goals may include reducing duplicated systems by a meaningful percentage or improving time-to-market for new products.

For this to work, goals should align to strategic themes rather than fixed projects. Themes such as customer experience, operational resilience, innovation readiness, or cost efficiency remain relevant even when individual initiatives change. Goals should be reviewed and recalibrated quarterly rather than annually to reflect evolving priorities. Influence and alignment are also valid dimensions of measurement. A key indicator of EA success is whether stakeholders trust architectural direction and whether teams adopt recommended patterns proactively rather than reactively.

Ultimately, goals and KPIs for Enterprise Architects should be treated as a framework for structured discussion rather than a rigid scorecard. The aim is clarity of direction and shared understanding of value, not micromanagement or justification. The Enterprise Architect’s value is not measured in the number of documents produced but in how the organization moves more coherently, more efficiently, and with greater strategic intent as a result of their work. When defined thoughtfully, EA KPIs become not just a mechanism for performance evaluation, but a tool for alignment, empowerment, and meaningful transformation.

企業架構師的目標與績效指標 - 策略、成果與真正的價值

企業架構師(Enterprise Architect, EA)的角色位於商業策略、技術方向與組織變革的交界處。然而,當談到設定目標與績效指標(KPI)時,許多企業往往難以清晰界定成功的樣貌。不同於交付團隊可用任務完成度或功能上線等明確指標衡量進展,企業架構師的工作主要影響的是「成果」。這些成果具有系統性、多維性,並受多方因素共同影響,並非僅靠個人或單一團隊就能決定。因此,企業架構師的價值是真實存在的,但往往較為間接、長期,且不易立即量化。

在許多企業中,為企業架構師設定目標面臨不少挑戰。有些組織的商業策略快速變動或未被明確傳達,導致年初設定的目標在年中便可能失去相關性。市場變化、政策要求或領導層優先事項的調整,都可能影響原本的方向。此外,企業架構師能產出的具體項目,例如架構藍圖、技術標準、能力地圖與治理機制等,這些屬於「輸出」。但真正的價值往往來自這些輸出所促成的「成果」,例如降低系統重複性、縮短新產品整合時間、提升跨團隊對齊效率,或強化客戶體驗。這些成果依賴跨團隊協作,因此很難由單一角色獨立衡量貢獻。

同時,許多企業的人力資源制度仍以可預測與短期可量化的工作為基礎設計,往往較難體現企業架構師這類「戰略性、系統性、影響性」角色的特質。再加上全球策略與區域市場需求常常並不一致,企業架構師必須扮演「翻譯策略、調整架構、促進共識」的橋樑。但這些工作雖極具影響力,卻不容易以單一數據反映。

因此,更有效的方法是將企業架構師的目標與 KPI 分為兩個層次:輸出(可直接掌控的交付物)與 成果(輸出所促成的長期價值)。輸出可以包括定期更新的架構藍圖、明確的技術標準、以及跨部門架構審查流程。成果則可以包括降低系統重複度、提升產品上市速度、或增強組織對架構方向的共識度。

在設定這些指標時,建議將目標對齊到「策略主題」而非「固定專案」。例如:客戶體驗、營運韌性、創新速度、成本效率等主題,即使專案變動仍具持續性。此外,目標應定期(例如每季)檢視調整,以反映最新的組織方向。衡量「影響力」同樣重要,例如跨部門協作品質、架構共識程度、標準被採用的比率等,都屬於合理且有意義的評估方式。

最重要的是,企業架構師的目標與 KPI 應被視為「對話與共識的框架」,而非僅是評分表。目標的目的,是為了對齊方向、建立透明度、促進跨團隊合作,而不是侷限角色或增加行政負擔。企業架構師的價值不是來自文件的數量,而是讓組織能夠更有方向、更一致、更具策略意識地向前推進。

若能以這樣的方式定義與管理 KPI,績效評估不只是管理工具,更會成為推動轉型、強化組織能力與提升策略落地成效的力量。

Practical AWS FinOps for Cloud Success

Cloud has fundamentally changed how organizations consume technology. In the traditional IT world, engineers would submit infrastructure requests that flowed through long procurement cycles. Capacity was purchased upfront, often with estimates based on peak demand, and the result was frequently over-provisioned resources that sat idle. Cost was predictable, but it was also disconnected from actual usage and the pace of innovation was slowed by waiting for hardware approvals and manual provisioning.

Cloud consumption flips this model. Access to resources becomes democratized so that teams can provision environments and test ideas instantly. The cost of failure is low because the cloud enables rapid experimentation without heavy upfront investment. Capacity can scale elastically in line with actual demand, procurement happens through code rather than purchase orders, and cost and usage data is available in real time. However, this flexibility introduces a new challenge: without proper discipline and shared accountability, cloud environments can accumulate waste, sprawl, and unpredictable spending.

This is where FinOps comes in. FinOps is the practice of bringing together Finance, Technology, and Business teams to understand and optimize the unit economics of cloud usage. It reframes cloud cost not as a technical problem or a financial problem, but as a shared responsibility across the organization. To succeed with FinOps, organizations must ensure buy-in from business stakeholders so that cost becomes a normal part of engineering and operational decision-making, rather than an afterthought.

The journey toward effective FinOps typically begins with education. Teams need to understand how cloud billing works, what drives cost, and how different architectural choices impact spending. Ownership is a foundational principle: it must always be clear who is responsible for each workload, environment, and cost center. AWS Organizations, Organizational Units (OUs), linked accounts, and resource-level tags form the structure of accountability. A tagging dictionary that defines mandatory tags such as Owner, Environment, Application, and Cost Center is crucial. Clear ownership enables meaningful cost visibility and cost reporting.

Visibility comes next. AWS provides native tools like Cost Explorer for high-level analysis and the Cost and Usage Report (CUR) for detailed raw billing data. These feed into dashboards such as the Cloud Intelligence Dashboard, CUDOS Dashboard, KPI Dashboards, Compute Optimizer Dashboard, and Trusted Advisor Organizational Dashboard. These dashboards allow teams to see trends, identify outliers, and detect opportunities for optimization. When cost is visible, conversations shift from blame to informed decision-making.

Cost optimization is an ongoing process rather than a one-time activity. Some improvements are simple, such as rightsizing underutilized resources, shutting down unused systems, or adjusting storage tiers. Others require deeper architectural changes, such as shifting workloads to serverless models or adopting autoscaling patterns. Commitment-based savings mechanisms like Savings Plans and Reserved Instances help lower compute costs for predictable workloads. The key is to balance savings impact with technical complexity.

Tracking progress is essential. Good cloud financial operations show a trend where unit cost decreases over time while usage grows to support business expansion. For example, cost per transaction, per GB stored, or per CPU-hour should decline as systems become more efficient. Commitment utilization rates should rise as teams align their capacity planning with business growth. Dashboards enable these trends to be monitored continuously, and regular review cadences reinforce accountability and progress.

Communication underpins the success of FinOps. Teams must speak openly about cost drivers, trade-offs, and priorities. Different stakeholders require different reporting formats: business leaders need cost-to-value clarity, developers need actionable recommendations, and finance teams need forecasting and variance visibility. When communication is consistent and transparent, the organization builds a healthy feedback loop where decisions become intentional rather than reactive.

AWS provides numerous native tools to support this process. Cost Explorer, AWS Budgets, Cost Anomaly Detection, Savings Plans and RI recommendations, Compute Optimizer, Trusted Advisor, AWS Config, CloudWatch, and S3 Storage Lens all play roles in visibility, governance, and optimization. The Cloud Intelligence Dashboard suite ties data together into contextual intelligence that teams can act upon.

Ultimately, FinOps is not a project with a start and end date. It is a cultural shift in how technology, finance, and business collaborate. It aligns cloud cost with business value and enables organizations to use cloud deliberately rather than accidentally. When implemented effectively, FinOps transforms cloud consumption into a strategic advantage, allowing organizations to innovate faster while maintaining cost efficiency and financial accountability.

實用 AWS FinOps推動雲端成功的關鍵策略

雲端已經徹底改變了組織消費科技資源的方式。在傳統 IT 世界中,工程師需要提交基礎設施申請,經過冗長的採購流程。容量通常以峰值需求為基準提前購買,結果往往是大量閒置的資源。成本雖然可預測,但與實際使用情況脫節,而硬體申請與部署流程的延遲也限制了創新速度。

雲端的消費模式顛覆了這種運作方式。資源存取變得民主化,團隊可以立即建立環境並驗證想法。由於不需前期重資本投入,失敗的代價大幅降低,使團隊可以快速試驗與迭代。容量可依實際需求彈性調整,採購透過程式碼自動化完成,而成本與使用量資料也能即時取得。然而,這種高度彈性的背後,若缺乏良好管理與責任劃分,容易造成資源擴散、浪費與成本不可控。

這正是 FinOps 的價值所在。FinOps 的核心是讓財務、技術與業務團隊共同理解並優化雲端運算的單位經濟效益。它強調雲端成本不是僅屬於財務部門或 IT 部門的問題,而是整個組織共同的責任。要讓 FinOps 成功,企業需要取得業務團隊的認同,將成本視為與延遲、安全性、可靠性同等重要的系統品質指標,而不是事後檢討。

邁向實踐 FinOps 的第一步是教育。團隊需要理解雲端計費模型、成本驅動因素,以及架構決策如何影響支出。而責任歸屬是最關鍵的基礎:必須清楚每個工作負載、環境與成本中心的擁有者。AWS Organizations、組織單位(OU)、子帳號,以及資源層級的標籤(Tagging)是實現責任的技術基礎。標籤字典應定義必填標籤,例如 Owner、Environment、Application 和 CostCenter。只有清楚的責任歸屬,才能產生有意義的成本可視性與分析。

可視性是下一個步驟。AWS 提供原生工具,例如 Cost Explorer 用於高層分析,Cost and Usage Report(CUR)提供完整明細資料。這些資料可被整合至 Cloud Intelligence Dashboard、CUDOS Dashboard、KPI Dashboard、Compute Optimizer Dashboard,以及 Trusted Advisor Organizational Dashboard,讓團隊可以觀察趨勢、識別異常並發現優化機會。當成本變得透明,對話就會從「指責」轉為「共同改善」。

成本最佳化是一個持續的過程,而非一次性的活動。有些改善相對容易,例如縮減未充分利用的資源、關閉無人使用的系統或調整儲存層級;而其他改善則涉及架構重構,例如改用無伺服器模型或實施自動擴展機制。對於穩定工作負載,Savings Plans 或 Reserved Instances 能有效降低運算成本。重要的是在「節省效益」與「技術複雜度」之間取得平衡。

追蹤成效至關重要。理想的雲端財務運作模式顯示:隨著業務擴展與使用量增加,單位成本應逐步下降。例如每次交易成本、每 GB 儲存成本、每 CPU 時間成本等,都應隨著系統成熟而降低;承諾用量的利用率應提高。透過儀表板持續監測,並建立例行審視節奏,可以有效鞏固改善成效。

溝通是 FinOps 成功的核心。團隊必須能夠公開討論成本、權衡與優先順序。不同的利害關係人需要不同的報表形式。業務需要看到成本與價值的關聯,開發者需要具體可行的資源優化建議,而財務需要能支援預測與差異分析的資料。當溝通透明且持續,組織內會形成健康的回饋循環,決策也更具前瞻性與一致性。

AWS 本身提供多種工具支援這些流程,包括 Cost Explorer、AWS Budgets、Cost Anomaly Detection、Savings Plans 與 RI 建議、Compute Optimizer、Trusted Advisor、AWS Config、CloudWatch 與 S3 Storage Lens。Cloud Intelligence Dashboard 則協助將資料轉化為可行洞察。

最終,FinOps 不是一個專案,也不是一項短暫的成本削減計畫。它是一種文化轉變,讓技術、財務與業務真正協同合作。FinOps 的目標是讓雲端成本與業務價值對齊,讓組織以更具策略性且更有效率的方式使用雲端。而當這種文化落地後,雲端不再只是技術選擇,而會成為推動創新與成長的競爭優勢。

Reflections as a Mentor

This year, I returned to New Asia College at the Chinese University of Hong Kong as a mentor in the Mentorship Programme. More than a decade has passed since I graduated in 2012, yet walking back onto campus still feels familiar and different at the same time. During my student years, I received support, guidance, and encouragement from professors, seniors, and alumni. Now, it feels meaningful to give back and to walk alongside younger students who may be feeling uncertain about their direction in life, stressed about academic expectations, or anxious about the future.

The Academic Code of New Asia College states: “While pursuing knowledge, also learn how to cultivate your moral character. The two goals are to be achieved as an integrated whole.” This principle influenced me greatly when I was a student and continues to shape my life today. Learning is not simply about gaining qualifications or technical skills, and being a good person is not merely about following rules. The goal is to allow knowledge and character to grow together. A meaningful life comes from aligning what we know, how we think, and who we choose to be. This is one of the most valuable insights I hope mentees will take with them.

However, becoming a mentor has been more challenging than I initially imagined. Many students today seem to lack a sense of hunger, motivation, or direction. Some are studying fields that do not reflect their interests. Others feel limited by academic requirements, which narrow their perspective on what is possible. Many do not fully realize how many opportunities exist around them. Scholarships, overseas exchange programs, internships, alumni support, cultural activities, and mentorship networks are widely available, yet often remain unused. The resources are present, but the drive to explore and take initiative is weaker than it could be. I understand that this generation faces new pressures, including uncertainty and a fear of making mistakes. Yet, personal growth requires curiosity, active questioning, and the willingness to try.

One aspect that inspires me is the long-standing culture of the Mentorship Programme. Many mentors have contributed for twenty years or more, offering their time, stories, and encouragement. This is a form of informal education that helps students understand life beyond textbooks. Mentorship is not a formal teacher-student relationship. It is a friendship built on trust, time, sincerity, and shared experience. Much of what we pass on is not technical knowledge. It is perspective, judgment, values, and the ability to make thoughtful decisions.

For mentees to get the most value, it is important to be proactive. Initiate conversations. Ask questions, even if they feel uncertain or incomplete. Share your concerns and goals. Meet your mentor at least once each semester. Explore the many opportunities that the college environment offers. University is one of the rare stages of life where knowledge, freedom, connection, and support are available in such abundance.

For mentors, we can support mentees by sharing our personal experiences honestly, including our struggles and mistakes. We can create shared experiences such as workplace visits, hikes, museum trips, cultural events, or exploring historical areas. These activities provide natural opportunities to talk about identity, purpose, career choices, and the process of becoming oneself.

In the end, mentorship is not about providing fixed answers. It is about walking with someone as they learn to find their own answers. It is not about shaping a mentee into a particular version of success. It is about helping them recognize that they have choices, resources, and the ability to grow.

If mentoring can help even one student feel more confident, more grounded, and more willing to take responsibility for their life and future, then the effort is worth it. The spirit of New Asia College lives on when we learn, grow, and support one another.

May we continue to walk this journey together.

Reflections as a Mentor

今年,我以學長的身份回到新亞書院,參與書院的學長計劃。距離我在 2012 年畢業已有十多年,但再次踏進香港中文大學校園時,依然感到熟悉與親切,但又有點陌生。在我求學的日子裡,曾得到不少老師、學長和校友的指導與支持。如今,能夠回饋並陪伴年輕一代在成長道路上前行,對我而言是一件意義深長的事。

新亞書院學規指出:「求學與作人,貴能齊頭並進,更貴能融通合一。」這一句話深深影響了我,不論在校園中或畢業之後。求學不只是累積技能與知識,為人也不只是遵守規矩。真正重要的是讓知識、價值觀與品格相互融合,使內在和外在的成長達致一致。人生的意義在於如何將「懂得的事」與「想成為的人」統一起來。這是我希望能與書院同學分享的一個重要觀念。

然而,成為學長並不是一件容易的事。我發現如今不少同學缺乏方向感、動力或目標。有些人選讀的科目並非自己真正有興趣的領域,有些人被課程框架所限制,難以拓展視野、難以想像更多的可能性。也有許多同學未能充分認識身邊可以利用的資源,例如:獎學金、海外交流、實習機會、校友網絡、文化活動、以及學長計劃本身。資源其實一直存在,只是缺乏主動探索與尋求的意願。我明白,這一代面對的壓力不同,包括不確定性、社交比較、以及害怕犯錯。然而,個人成長需要好奇心、需要提問、需要願意跨出第一步。

令我深受感動的是學長計劃的文化。許多學長已經投入超過二十年,持續分享自己的時間、經驗和心力。這是一種「非形式教育」,通過真誠的交流、陪伴與故事傳承生活的智慧,而不是靠課本或講義。學長關係並不是上下級,而是一種跨世代的友誼,建立在信任、耐心和共同經歷之上。學長所分享的,往往不是單純的知識,而是思考方式、處事態度、價值判斷及成為自己想成為的人的過程。

對於同學,要從學長計劃中獲得最大收獲,主動是關鍵。主動提問,即使問題還不成熟;主動分享,即使感到不確定;每學期至少與學長見面一次,讓交流能夠延續。書院提供的學習環境、文化活動和人際網絡都是難能可貴的資源,在未來的人生階段中,未必會再有這樣豐富而開放的支持系統。

對於學長,我們能做的包括坦誠分享自己的經歷,不只分享成功,也分享迷惘與失敗。可以邀請同學參觀工作環境、一起行山、參觀博物館或歷史空間,或參與文化活動。這些共同行動能自然引發有關人生方向、個人目標和職涯選擇的深度對話。

最終,學長關係的核心不是提供標準答案,而是陪伴學生走向找到自己答案的過程。不是將同學塑造成某一種樣子,而是幫助他們看見自己擁有選擇、資源以及成長的能力。

如果能夠讓一位同學變得更自信、更踏實、更願意為自己的人生負責,那麼這一切都是值得的。當我們彼此學習、共同成長,新亞的精神便延續下去。

願我們在前行的路上,一同同行。

The Hidden Cost of Outsourcing Strategy

In many large organizations, it has become almost instinctive to bring in external consulting firms whenever challenges arise. Firms like Accenture, Deloitte, or PwC arrive with polished slide decks, ready-made frameworks, and a promise of quick impact. And indeed, they often deliver rapid results. But the pace at which these “wins” are achieved, and the incentive models that underpin them, can lead to deeper structural issues that only surface after the consultants have already moved on.

One of the underlying problems is that consulting incentives are rarely aligned with the organization’s long-term architectural health. Consulting delivery teams are measured on project completion, perceived business satisfaction, and sometimes the potential to secure follow-on work. This often leads to a focus on short-term solutions that demonstrate immediate value rather than thoughtfully investing in foundational capabilities that may take longer to show returns. In other words, the system is designed to reward tactical success, not strategic stewardship.

High turnover further complicates the issue. Many consulting programs see rotating resources, new faces every quarter, junior staff learning as they go, and knowledge continuity becoming increasingly fragmented. Critical architectural rationale is often lost because consultants seldom remain in the organization long enough to experience the downstream effects of the decisions they influence. What remains is a trail of tactical fixes without a coherent narrative toward the intended future state.

A common manifestation of this dynamic is the rise in robotic process automation (RPA) as a default answer to operational inefficiencies. RPA is appealing because it offers fast relief: “We can automate this manual process in weeks.” And while this sounds beneficial in the short term, it is, in many cases, a strategic anti-pattern. RPA automates the symptoms of underlying system fragmentation, rather than addressing the cause. The resulting bots are tightly coupled to UI quirks, fragile against system changes, and notoriously difficult to govern at scale. Over time, organizations find themselves owning an invisible labyrinth of automation scripts, each one a brittle workaround for legacy complexity that could have instead been resolved by building API-first integrations and modernizing the core systems.

The deeper issue is that RPA placates the organization. It buys temporary relief, allowing decision-makers to defer real transformation, preserving legacy constraints rather than dismantling them. The consultant leaves with strong performance metrics. The business sees short-term efficiency gains. But the architecture becomes more tangled, harder to evolve, and more expensive to maintain. The future is quietly being mortgaged.

This is not an argument against consultants, they provide valuable expertise, industry perspective, and acceleration when used appropriately. The issue is the outsourcing of architectural ownership. Architecture is not a “project.” It is a capability. It requires context, continuity, and stewardship, from people who are embedded in the organization, who understand its culture, constraints, long-term vision, and who will still be present to answer for decisions made today.

Organizations must shift from consuming solutions to cultivating architectural maturity. This means establishing strong internal architectural governance, empowering enterprise architects with authority, and aligning transformation with clearly defined long-term business outcomes. Consultants can still play a role, but as advisors and accelerators, not decision owners.

The organizations that thrive are those that retain accountability for their architectural destiny. They recognize that every short-term optimization is either a stepping stone or a trap. And they adopt a long-term mindset: design for 5–10 years, not the next quarter’s performance report.

Strategic architecture requires patience, discipline, and internal commitment. Quick wins have their place, but not at the expense of the future.

外包策略的隱性代價

在許多大型企業中,當面臨挑戰時,第一反應往往是聘請外部顧問公司。像 Accenture、Deloitte 或 PwC 這類顧問公司,總是帶著精緻的簡報、現成的框架,以及「快速見效」的承諾登場。的確,他們常能在短時間內交出成果。然而,這些「快速成果」的實現方式,以及背後的獎勵機制,往往會為組織埋下長期結構性問題的種子,而這些問題通常只會在顧問離開後才浮現。

問題的根源在於,顧問的獎勵機制很少與組織的長期架構健康掛勾。顧問團隊的評估重點通常放在專案完成度、業務滿意度,以及爭取後續合約的潛力上。這種機制自然導致他們更傾向於追求短期可見的成果,而非長期、具延展性的架構投資。換句話說,這個體系獎勵的是戰術上的成功,而非戰略上的持續成長。

高流動率更讓問題雪上加霜。許多顧問專案中,人員更替頻繁——每季都有新面孔、初階顧問邊學邊做,導致知識傳承支離破碎。關鍵的架構決策脈絡往往隨著顧問的離開而消失。留下的,是一串串戰術性修補,而非一個通往未來的整體藍圖。

這樣的動態在實務上常表現在「機器人流程自動化」(RPA)的濫用。RPA 看似是效率的福音:「我們可以在幾週內自動化這個人工流程!」這聽起來很吸引人,短期內也確實能帶來成效。然而,RPA 在許多情況下其實是一種戰略反模式。它解決的是「症狀」,而非「根因」。這些機器人腳本通常緊密依賴於前端介面,對系統變動極為脆弱,且在大規模推行時難以治理。久而久之,組織會陷入一個由無數自動化腳本組成的迷宮——每一個都是為了快速止痛而產生的技術債,而非通往未來的橋樑。若當初採取的是 API 為先(API-first)的整合策略,問題本可從根本上被解決。

更深層的問題在於,RPA 會麻痺組織。它讓企業獲得暫時的舒緩,延後真正的轉型決策,繼續維持既有的技術負擔。顧問離開時帶著漂亮的績效報告,業務單位看到短期的效率提升,但企業架構卻變得更加脆弱、難以演進,也更昂貴。未來,其實正在被悄悄抵押。

這並非否定顧問的價值。顧問能提供專業知識、外部視角與變革動能,這些都極具價值。真正的問題在於,企業不應將架構的所有權外包出去。架構不是一個「專案」,而是一種能力。它需要對組織文化、限制、長期願景的深入理解與持續守護。這必須由內部人員主導——那些會長期留在組織中、願意對今天的決策負責的人。

企業應從「消費解方」轉向「培養架構成熟度」。這意味著要建立強健的內部架構治理機制,賦權企業架構師,並將轉型行動與長期業務成果明確對齊。顧問依然有其角色——但應是顧問與加速者,而非決策者

真正能在變革中長存的企業,懂得為自己的架構命運負責。他們明白,每一次短期的優化,都是通往未來的墊腳石,或是一個陷阱。長遠思維,是架構成功的根本:設計時看的是五到十年後,而不是下個季度的績效報告。

戰略性的架構設計需要耐心、紀律與內部承諾。快速成果固然重要,但絕不能以犧牲未來為代價。