2025

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

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

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

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

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

Managing Up as an Enterprise Architect

In a world obsessed with technical mastery and digital transformation, one truth remains unchanged: organizations are made of people. For Enterprise Architects, the challenge is not just about designing scalable systems or aligning technology with strategy; it is about managing up.

Every day, we navigate a web of senior stakeholders: bosses, directors, business heads, and sometimes entire leadership teams, each with their own ambitions, anxieties, and decision-making patterns. Managing up is not manipulation or flattery; it is the discipline of partnership. It is about helping leaders make better decisions by shaping how we communicate, when we engage, and what we emphasize. In essence, it is the art of human intelligence, the soft skill that no AI will ever replace.

Effective Enterprise Architects are translators between vision and execution. But to do this well, we must first understand the personalities that shape those visions. Some leaders are directors: fast-moving, results-driven, and impatient with detail. They want clarity and confidence, not complexity. Begin with the conclusion, lead with outcomes, and always show progress. Others are feelers: people-oriented and emotionally attuned. They value relationships over reports and stories over statistics. What builds trust with them is not logic but empathy. Then there are judges: reserved, cautious, and selective. They weigh risks carefully and respond to options, not ultimatums. Finally, there are analysts: methodical, data-driven, and precise. They listen to facts, not feelings. What earns their confidence is evidence, not enthusiasm.

Mastering these styles is not about becoming someone you are not; it is about being agile enough to meet others where they are. People change, circumstances shift, and leadership dynamics evolve. The key is rapport: we naturally trust those who reflect our own values and pace. Adjusting your communication style does not mean abandoning authenticity; it means amplifying effectiveness.

A powerful mindset shift begins with one question: “He or she is my __. I am his or her ____.” The way you fill in those blanks defines the relationship. Are you a subordinate, a trusted partner, a consultant, or even a successor? Seeing yourself as a partner, not a passenger, reframes every conversation. Managing up is not about deference; it is about co-creation. It is not about avoiding friction; it is about channeling it productively toward shared goals.

Consistency builds credibility. Predictability earns trust. Schedule regular check-ins, maintain a simple project tracker, and communicate before you are asked. Responsiveness shows respect; silence breeds uncertainty. At the same time, great Enterprise Architects do not just meet expectations; they redefine them. Acting one level up signals readiness for bigger responsibilities. Leaders notice those who anticipate problems before they are raised and who propose solutions instead of waiting for instructions.

Being a problem solver is the most enduring form of influence. Ask yourself: “How can I make my stakeholder’s life easier?” Think from their perspective, the pressures they face, the trade-offs they weigh. When we think like them, we do not just deliver work; we deliver peace of mind.

Ultimately, managing up is about trust, the invisible currency of leadership. Trust is built through credibility, reliability, and intimacy, and it erodes when self-interest dominates. Credibility comes from mastery and follow-through; reliability from consistency and accountability; intimacy from genuine connection, the small human moments that turn colleagues into allies. The less the relationship is about you, the more influence you gain.

Managing up is not submission to authority; it is alignment with purpose. It is the ability to transform hierarchy into collaboration and transactions into partnerships. For Enterprise Architects, who often sit at the intersection of strategy and execution, this is our real architecture: the architecture of trust.

Ask yourself this: if you had complete trust in your leaders, what would you do differently? Then start doing that now, because managing up is not just about influencing others. It is about becoming the kind of professional others want to trust.

企業架構師的向上管理之道

在一個專注於技術精通與數位轉型的時代，有一個真理始終不變：企業的核心是人。對企業架構師而言，挑戰不僅僅是設計可擴展的系統或將技術與策略對齊，更關鍵的是學會「向上管理」。

我們每天都在穿梭於複雜的高層利害關係網絡之中——上司、總監、業務主管，甚至是整個領導團隊。每個人都有不同的目標、焦慮與決策模式。向上管理不是拍馬屁或逢迎，而是一種合作的藝術。它關乎於如何在對的時間，用對的方式溝通，讓領導能做出更明智的決策。這是一門人性的智慧，也是一種 AI 永遠無法取代的軟實力。

優秀的企業架構師，是願景與執行之間的翻譯者。但要做到這一點，首先要理解塑造願景的那些人。有些領導是「行動派」：速度快、結果導向、沒有耐心聽細節。他們要的是結論與信心，而不是複雜的過程。對這類人，要開門見山，聚焦成果，展現進展。有些是「感受型」：重視人際關係與情感連結，他們看重的是關係勝於報告，故事勝於數據。贏得他們信任的不是邏輯，而是同理心。另一類是「判斷型」：謹慎、保守，喜歡權衡風險。面對他們，應提供選項而非命令，呈現利弊，讓他們有安全感。最後是「分析型」：理性、細緻、以數據為本。他們聽的是事實而非感覺，信任的是證據而非熱情。

掌握這些風格的關鍵，不是改變自我，而是具備適應力，能在不同情境中與他人對齊。人會改變，情勢會變，領導的需求也會變。建立融洽關係的關鍵在於「共鳴」——人天生傾向信任與自己步調與價值觀相似的人。調整溝通風格不是虛偽，而是讓訊息更有效。

心態的轉變從一個問題開始：「他或她是我的__。我是他或她的____。」你如何填空，決定了關係的定義。你是下屬？是可信賴的夥伴？顧問？甚至是接班人？當你將自己定位為合作夥伴而非執行者時，所有對話的意義都會不同。向上管理不是服從，而是共創；不是避免衝突，而是讓衝突變得有建設性，朝共同目標前進。

一致性建立信譽，可預測性帶來信任。定期安排檢視會議、使用簡單的追蹤工具來報告進度、主動溝通而不是被動等待。快速回覆代表尊重，沉默則會讓人產生不安。同時，優秀的架構師不只是達標，而是重塑標準。以「領導者思維」行事，提前思考一層，讓領導看見你具備更高層次的洞察與擔當。那些能主動預測問題並提出解法的人，才是真正值得信任的夥伴。

成為問題的解決者，是最持久的影響力。問問自己：「我能如何讓我的利害關係人更輕鬆？」試著從他們的角度思考，他們的壓力是什麼、他們在取捨什麼。當我們能以他們的視角思考，我們交付的不只是成果，更是一份安心。

最終，向上管理的核心是信任——領導的無形貨幣。信任建立在可信度、可靠性與親密感之上，卻會因自我中心而瓦解。可信度來自專業與實績；可靠性來自一致與負責；親密感則來自真誠互動，那些讓同事成為盟友的小瞬間。關係越少關於「我」，影響力就越大。

向上管理不是對權威的屈服，而是與目標的對齊。它是一種將階層轉化為合作、將任務轉化為夥伴關係的能力。對企業架構師而言，我們的真正架構不是技術藍圖，而是信任的架構。

問問自己：如果你完全信任你的領導，你會做些什麼不同的事？從今天開始去做吧。因為向上管理不只是影響他人，它更是成為值得他人信任的那種專業。