理論很重要猿诸。如果你不想成為象牙塔架構(gòu)師，那么實(shí)踐同樣甚至更重要狡忙。

• 嘗試并理解不同的技術(shù)堆棧 ：如果你想成為更好的架構(gòu)師梳虽，我認(rèn)為這是最重要的活動(dòng)。嘗試（新）技術(shù)堆棧并了解它們的起伏灾茁。不同的或新的技術(shù)帶有不同的設(shè)計(jì)思路和模式窜觉。你很可能不會(huì)從翻閱抽象幻燈片中學(xué)到任何東西谷炸，而是通過(guò)自己嘗試并感受到痛苦或緩解。架構(gòu)師不僅要有廣泛的知識(shí)禀挫，還應(yīng)該在某些領(lǐng)域有深厚的知識(shí)旬陡。掌握所有技術(shù)堆棧并不重要，但是了解你所在領(lǐng)域最重要的技術(shù)堆棧卻相當(dāng)重要语婴。同時(shí)嘗試不在你所在領(lǐng)域的技術(shù)描孟，例如，如果你對(duì)SAP R/3有深入了解砰左，你還應(yīng)該嘗試使用JavaScript匿醒，反之亦然。盡管如此缠导，雙方都會(huì)對(duì)SAP S/4 Hana的最新進(jìn)展感到驚訝廉羔。例如，你可以自己嘗試并免費(fèi)參加openSAP課程僻造。好奇并嘗試新事物蜜另。還要嘗試幾年前你不喜歡的東西。
• 分析和理解應(yīng)用模式 ：查看任何當(dāng)前框架嫡意，例如Angular 举瑰。你可以在實(shí)踐中學(xué)習(xí)很多模式，例如Observables 蔬螟。試著理解它在框架中的應(yīng)用方式此迅，為什么要這樣做。如果你真的很專注旧巾，請(qǐng)深入了解代碼并了解它是如何實(shí)現(xiàn)的耸序。
• 好奇并參加用戶組 ：例如，在德國(guó)鲁猩，我們?cè)诿總€(gè)大的城市都有Java用戶組（JUG）坎怪，討論各種主題，從低級(jí)編碼到高級(jí)架構(gòu)主題廓握。我非常喜歡這些活動(dòng)搅窿，因?yàn)樗鼈兛梢栽鰪?qiáng)你的思維能力和個(gè)人網(wǎng)絡(luò)。

（2）決定

架構(gòu)師需要能夠做出決策并指導(dǎo)項(xiàng)目或整個(gè)組織朝著正確的方向發(fā)展隙券。

• 知道什么是重要的：不要浪費(fèi)時(shí)間做不重要的決定或活動(dòng)男应。了解重要的事情。據(jù)我所知娱仔，沒(méi)有一本書有這些信息（如果你知道的話沐飘，請(qǐng)告訴我）。我個(gè)人最喜歡的是這兩個(gè)特征，在判斷某些事情是否重要時(shí)我通常會(huì)考慮這兩個(gè)特征：
  （1）概念完整性 ：如果你決定以一種方式做某件事耐朴，堅(jiān)持下去借卧，即使有時(shí)候有其他方式可以做得更好。通常筛峭，這會(huì)導(dǎo)致更直接的整體概念铐刘，簡(jiǎn)化可理解性并簡(jiǎn)化維護(hù)性。
  （2）一致性 ：例如蜒滩，如果你定義和應(yīng)用命名約定，它不是大寫或小寫的問(wèn)題（真的Ｄ坛怼）俯艰，而是要以相同的方式應(yīng)用于任何地方的問(wèn)題。
• 優(yōu)先考慮 ：一些決策非常關(guān)鍵锌订。如果他們沒(méi)有及早采取足夠的解決方法竹握，往往不太可能在以后去除，并且是維護(hù)的噩夢(mèng)辆飘，或者更糟糕的是啦辐，開發(fā)人員會(huì)停止工作，直到做出決定蜈项。在這種情況下芹关，有時(shí)做出“壞”決定甚至更好，而不是沒(méi)有決定紧卒。但在落到這種情況之前侥衬，請(qǐng)考慮即將到來(lái)的決策的優(yōu)先級(jí)。有不同的方法可以做到這一點(diǎn)跑芳。我建議看一下在敏捷軟件開發(fā)中廣泛使用的加權(quán)最短作業(yè)優(yōu)先（ Weighted Shortest Job First轴总，WSJF）模型。特別是時(shí)間關(guān)鍵性和降低風(fēng)險(xiǎn)的度量對(duì)于估計(jì)架構(gòu)決策的優(yōu)先級(jí)至關(guān)重要博个。
• 了解自己的能力：不要做出不屬于你職權(quán)范圍的事情怀樟。這是至關(guān)重要的，因?yàn)槿绻患右钥紤]盆佣，它可能會(huì)破壞你作為架構(gòu)師的地位往堡。為了避免這種情況，請(qǐng)與你的同行澄清你的責(zé)任以及屬于你的角色的部分共耍。如果有多個(gè)架構(gòu)師投蝉，那么你應(yīng)該尊重當(dāng)前部署的架構(gòu)級(jí)別。作為一個(gè)較低級(jí)別的架構(gòu)師征堪，你最好是只提出對(duì)更高級(jí)別的架構(gòu)的建議而不是決策瘩缆。此外，我建議始終與同行一起檢查關(guān)鍵決策佃蚜。
• 評(píng)估多個(gè)選項(xiàng)：如果涉及決策庸娱，請(qǐng)始終布置多個(gè)選項(xiàng) 着绊。在我參與的大多數(shù)情況下，總是有不止一種可能的（好的）選擇熟尉。只有一個(gè)選項(xiàng)在兩個(gè)方面是不好的：（1）似乎你沒(méi)有正確地完成你的工作归露，（2）它阻礙做出正確的決定。通過(guò)定義度量斤儿，可以基于事實(shí)而不是直覺(jué)來(lái)比較選項(xiàng)剧包，例如許可證成本或成熟度。這通常會(huì)帶來(lái)更好往果，更可持續(xù)的決策疆液。此外，它還可以將決策兜售給不同的利益相關(guān)者陕贮。此外堕油，如果你沒(méi)有被恰當(dāng)評(píng)估過(guò)的選項(xiàng)，在討論時(shí)可能會(huì)敗下風(fēng)肮之。

（3）簡(jiǎn)化

請(qǐng)記住解決問(wèn)題的原則Occam的Razor掉缺，表達(dá)的是更傾向于簡(jiǎn)單。我將原則解釋如下：如果你對(duì)解決問(wèn)題的解決方案有太多假設(shè)可能會(huì)出錯(cuò)戈擒，或?qū)е虏槐匾膹?fù)雜的解決方案眶明。應(yīng)該減少（簡(jiǎn)化）假設(shè)以得到一個(gè)好的解決方案。

• 搖動(dòng)解決方案 ：為了簡(jiǎn)化解決方案筐高，“搖動(dòng)”解決方案并從不同位置查看解決方案通常是有助的赘来。嘗試通過(guò)自上而下和自下而上思考來(lái)塑造解決方案。如果你有數(shù)據(jù)流或流程凯傲，那么首先從左到右犬辰，再?gòu)挠业阶笏伎肌Ｌ岢鲋T如以下問(wèn)題：“在一個(gè)完美的世界中冰单，你的解決方案會(huì)發(fā)生什么幌缝？”或者：“公司/人X會(huì)做什么？”（X可能不是你的競(jìng)爭(zhēng)對(duì)手诫欠，而是GAFA公司之一 涵卵。）這兩個(gè)問(wèn)題迫使你按照奧卡姆剃刀（Occam的Razor）這個(gè)建議減少假設(shè)。
• 退后一步 ：經(jīng)過(guò)激烈而漫長(zhǎng)的討論荒叼，通常會(huì)產(chǎn)生高度復(fù)雜的涂鴉轿偎。你永遠(yuǎn)不應(yīng)該把這些視為最終結(jié)果。退后一步：再次看一下大局（抽象層面）被廓。它還有意義嗎坏晦？然后再次在抽象層面上進(jìn)行重構(gòu)并重構(gòu)。有時(shí)停止討論并在第二天繼續(xù)討論是有助的兆解。至少我的大腦需要一些時(shí)間來(lái)處理并提出更好篇裁，更優(yōu)雅和更簡(jiǎn)單的解決方案。
• 分而治之 ：通過(guò)將問(wèn)題分成更小的部分來(lái)簡(jiǎn)化問(wèn)題盲镶。然后獨(dú)立解決它們仓蛆。然后驗(yàn)證這些小塊是否匹配在一起睁冬。退一步看看整體情況。
• 重構(gòu)并不邪惡 ：如果找不到更好的想法看疙，那么從一個(gè)更復(fù)雜的解決方案開始是完全可以的豆拨。如果解決方案遇到麻煩，你可以稍后重新考慮解決方案并應(yīng)用你的研究能庆。重構(gòu)不是邪惡的施禾。但在開始重構(gòu)之前，請(qǐng)記紫辔丁（1）有足夠的自動(dòng)化測(cè)試拾积，以確保系統(tǒng)的正常功能和（2）利益相關(guān)者的支持殉挽。要了解有關(guān)重構(gòu)的更多信息丰涉，我建議閱讀“ 重構(gòu)。改進(jìn)現(xiàn)有代碼的設(shè)計(jì)“由Martin Fowler撰寫 斯碌。

（4）編碼

即使作為最具抽象層次的架構(gòu)的企業(yè)架構(gòu)師一死，你仍然應(yīng)該知道開發(fā)人員每天都在做什么。如果你不明白這是怎么做的傻唾，你可能會(huì)遇到兩個(gè)主要問(wèn)題：
（1）開發(fā)人員不接受你的說(shuō)法
（2）你不了解開發(fā)人員的挑戰(zhàn)和需求投慈。

• 有一個(gè)側(cè)面項(xiàng)目 ：這樣做的目的是嘗試新的技術(shù)和工具，以了解如何在今天和未來(lái)完成開發(fā)冠骄。經(jīng)驗(yàn)是觀察伪煤，情感和假設(shè)的結(jié)合（ Kurt Schneider的 “軟件工程中的經(jīng)驗(yàn)和知識(shí)管理” ）。閱讀教程或一些優(yōu)點(diǎn)和缺點(diǎn)是好的凛辣。但這只是“書本知識(shí)”抱既。只有當(dāng)你自己嘗試一些事情時(shí)，你才能體驗(yàn)到情感扁誓，并且可以建立關(guān)于為什么事情好或壞的假設(shè)防泵。使用技術(shù)的時(shí)間越長(zhǎng)，你的假設(shè)就會(huì)越好蝗敢。這將有助于你在日常工作中做出更好的決策捷泞。當(dāng)我開始編程時(shí)，我沒(méi)有代碼自動(dòng)完成寿谴，只有一些實(shí)用程序庫(kù)來(lái)加速開發(fā)锁右。顯然，在這種背景下，我今天會(huì)做出錯(cuò)誤的決定骡湖。今天贱纠，我們擁有大量的編程語(yǔ)言，框架响蕴，工具谆焊，流程和實(shí)踐。只有你對(duì)主要趨勢(shì)有一些經(jīng)驗(yàn)和粗略概述浦夷，你才能參與對(duì)話并將開發(fā)引導(dǎo)到正確的方向辖试。
• 找到合適的東西試試 ：你不能嘗試一切。這根本不可能劈狐。你需要更加結(jié)構(gòu)化的方法罐孝。我最近發(fā)現(xiàn)的一個(gè)來(lái)源是ThoughtWorks的技術(shù)雷達(dá) 。他們將技術(shù)肥缔，工具莲兢，平臺(tái)，語(yǔ)言和框架分為四類：采用续膳，試用改艇，評(píng)估和保留。采用（Adopt） 意味著“為企業(yè)使用做好準(zhǔn)備的強(qiáng)烈感覺(jué)”坟岔， 試用（Trial）意味著“企業(yè)應(yīng)該在一個(gè)能夠處理風(fēng)險(xiǎn)的項(xiàng)目中嘗試”谒兄， 評(píng)估（Assess）意味著“探索它如何影響你的企業(yè)”，而保留（Hold）意味著“謹(jǐn)慎處理”社付。通過(guò)這種分類承疲，可以更容易地了解新事物及其準(zhǔn)備情況，以便更好地判斷下一個(gè)要探索的趨勢(shì)鸥咖。

（5）文檔

架構(gòu)文檔有時(shí)很重要燕鸽，有時(shí)也不那么重要。重要文檔有如架構(gòu)決策或編碼指南啼辣。在編碼開始之前經(jīng)常需要初始文檔啊研，需要不斷改進(jìn)。其他文檔可以自動(dòng)生成熙兔，因?yàn)榇a也可以是文檔悲伶，例如UML類圖。

• 清潔代碼 ：如果做得對(duì)住涉，代碼是最好的文檔麸锉。一個(gè)好的架構(gòu)師應(yīng)該能夠從錯(cuò)誤的代碼中判斷好的代碼。羅伯特·C·馬队呱（Robert C. Martin）的書“ 清潔代碼 ” （ Clean Code）是一本非常好的資源花沉，可以更好地了解好壞代碼柳爽。
• 盡可能生成文檔 ：系統(tǒng)正在快速變化，很難更新文檔碱屁。無(wú)論是以CMDB形式的API還是系統(tǒng)格局：基礎(chǔ)信息通常變化太快磷脯，無(wú)法手動(dòng)更新相應(yīng)的文檔。示例：對(duì)于API娩脾，如果你是模型驅(qū)動(dòng)的赵誓，則可以根據(jù)定義文件自動(dòng)生成文檔，或者直接從源代碼生成文檔柿赊。有很多工具俩功，我認(rèn)為Swagger和RAML是學(xué)習(xí)更多知識(shí)的好起點(diǎn)。
• 盡必要多碰声，盡可能少 ：無(wú)論你需要記錄什么诡蜓，例如決策文件，一次只關(guān)注一件事情胰挑，只包括這一件事的必要信息蔓罚。廣泛的文檔很難閱讀和理解。其他信息應(yīng)存儲(chǔ)在附錄中瞻颂。特別是對(duì)于決策文件而言豺谈，告訴一個(gè)令人信服的故事更為重要，而不僅僅是拋出大量的論點(diǎn)蘸朋。此外核无，這可以節(jié)省你和你的同事的時(shí)間扣唱，他們需要花很多時(shí)間閱讀它藕坯。看看你過(guò)去做過(guò)的一些文檔（源代碼噪沙，模型炼彪，決策文件等）并問(wèn)自己以下問(wèn)題：“是否包含了所有必要的信息以便理解它？”正歼，“確實(shí)需要哪些信息辐马，哪個(gè)可以省略？“和“文檔是否有紅線局义？”喜爷。
• 了解有關(guān)架構(gòu)框架的更多信息 ：此點(diǎn)也可以應(yīng)用于所有其他“技術(shù)”點(diǎn)。我把它放在這里萄唇，因?yàn)橄?a target="_blank" rel="nofollow">TOGAF或Zachmann這樣的框架提供了在文檔站點(diǎn)上感覺(jué)很重的“工具”檩帐，盡管它們的附加價(jià)值不僅限于文檔。在這樣的框架中獲得認(rèn)證將教會(huì)你更系統(tǒng)地處理架構(gòu)另萤。

（6）溝通

根據(jù)我的觀察湃密，這是最被低估的技能之一诅挑。如果你在設(shè)計(jì)方面很出色但無(wú)法傳達(dá)你的想法，你的想法可能只會(huì)產(chǎn)生較小的影響泛源，甚至無(wú)法成功拔妥。

• 了解如何溝通你的想法 ：在板上或活動(dòng)掛圖上進(jìn)行協(xié)作時(shí)，必須知道如何正確使用它以構(gòu)建你和同事的想法达箍。我發(fā)現(xiàn)這本書“UZMO - 用你的筆思考”是一個(gè)很好的資源没龙，可以提高我在這方面的技能。作為一名架構(gòu)師缎玫，你通常不僅參加會(huì)議兜畸，通常還需要開會(huì)并協(xié)調(diào)會(huì)議。
• 與大型團(tuán)體進(jìn)行對(duì)話 ：向你的小型或大型團(tuán)體展示你的想法應(yīng)該是可行的碘梢。如果你對(duì)此感到不舒服咬摇，請(qǐng)開始向你最好的朋友展示。慢慢擴(kuò)大小組煞躬。這是你只能通過(guò)做并離開你的個(gè)人舒適區(qū)來(lái)學(xué)習(xí)的東西肛鹏。請(qǐng)耐心等待，這個(gè)過(guò)程可能需要一些時(shí)間恩沛。
• 找到合適的溝通級(jí)別：不同的利益相關(guān)者有不同的興趣和觀點(diǎn)在扰。他們需要在他們的層面上單獨(dú)解決。在溝通之前雷客，請(qǐng)回過(guò)頭來(lái)檢查你要共享的信息是否具有正確的級(jí)別芒珠，包括抽象性，內(nèi)容搅裙，目標(biāo)皱卓，動(dòng)機(jī)等。 示例 ：開發(fā)人員通常對(duì)解決方案的細(xì)節(jié)很感興趣部逮，而經(jīng)理更喜歡知道哪個(gè)選項(xiàng)可以節(jié)省大部分資金娜汁。
• 經(jīng)常溝通 ：如果沒(méi)有人知道，那么精彩的架構(gòu)就毫無(wú)價(jià)值兄朋。定期并在每個(gè)（組織）級(jí)別上分發(fā)目標(biāo)架構(gòu)及其背后的思想掐禁。與開發(fā)人員，架構(gòu)師和經(jīng)理安排會(huì)議颅和，向他們展示所需或定義的方式傅事。
• 保持透明：定期溝通只能部分緩解缺失的透明度。你需要讓決策背后的理由透明化峡扩。特別是蹭越，如果人們沒(méi)有參與決策過(guò)程，就很難理解并遵循其背后的決定和理由有额。
• 隨時(shí)準(zhǔn)備發(fā)表演講：總有人有問(wèn)題般又，你想立即給出正確的答案彼绷。嘗試始終將最重要的幻燈片放在可以顯示和解釋的整合套件中。它為你節(jié)省了大量時(shí)間茴迁，為你自己提供了安全保障寄悯。

（7）估計(jì)和評(píng)估

• 了解基本的 項(xiàng)目管理 原則 ：作為架構(gòu)師或首席開發(fā)人員，你經(jīng)常被要求進(jìn)行估算以實(shí)現(xiàn)你的想法：多長(zhǎng)時(shí)間堕义，多少錢猜旬，多少人，哪些技能等等倦卖？當(dāng)然洒擦，如果你計(jì)劃引入新的工具或框架，你需要為這些“管理”問(wèn)題找到答案怕膛。最初熟嫩，你應(yīng)該能夠進(jìn)行粗略估計(jì)，例如天褐捻，月或年掸茅。不要忘記它不僅僅是實(shí)現(xiàn)，還有更多的活動(dòng)要考慮柠逞，比如需求工程昧狮，測(cè)試和修復(fù)bug。因此板壮，你應(yīng)該了解所使用的軟件開發(fā)過(guò)程的活動(dòng)逗鸣。你可以應(yīng)用以獲得更好的估算的一件事是使用過(guò)去的數(shù)據(jù)并從中推導(dǎo)出你的預(yù)測(cè)。如果你沒(méi)有過(guò)去的數(shù)據(jù)绰精，你也可以嘗試使用Barry W. Boehm的 COCOMO等方法撒璧。如果你部署在敏捷項(xiàng)目中，請(qǐng)了解如何正確估算和規(guī)劃 ： Mike Cohn撰寫的“敏捷估算和規(guī)劃”一書提供了該領(lǐng)域的可靠概述茬底。
• 評(píng)估“未知”架構(gòu) ：作為架構(gòu)師沪悲，你還應(yīng)該能夠判斷以前從未見(jiàn)過(guò)的架構(gòu)获洲。這不是一項(xiàng)容易的任務(wù)阱表，但你可以通過(guò)手頭有一套對(duì)每個(gè)架構(gòu)都很常見(jiàn)的問(wèn)題做好準(zhǔn)備。它不僅涉及架構(gòu)贡珊，還涉及系統(tǒng)的管理方式最爬，因?yàn)檫@也為你提供了質(zhì)量方面的內(nèi)容。我建議總是準(zhǔn)備一些問(wèn)題并準(zhǔn)備好使用门岔。一般問(wèn)題的一些想法：
  （1） 設(shè)計(jì)實(shí)踐 ：架構(gòu)遵循哪些模式爱致？它們是否因此被正確使用？設(shè)計(jì)是否遵循紅線或是否存在不受控制的增長(zhǎng)寒随？是否存在明確的結(jié)構(gòu)（clear structure）且關(guān)注點(diǎn)分離（separation of concerns）糠悯？
  （2） 開發(fā)實(shí)踐 ：已制定并遵循規(guī)范準(zhǔn)則了嗎帮坚？代碼如何版本化？部署實(shí)踐如何互艾？
  （3） 質(zhì)量保證 ：測(cè)試自動(dòng)化覆蓋范圍如何试和？靜態(tài)代碼分析到位并取得良好效果了嗎？同行評(píng)論到位了嗎纫普？
  （4） 安全性 ：哪些安全概念到位了阅悍？?jī)?nèi)置安全性如何？滲透測(cè)試或自動(dòng)安全分析工具到位并定期使用了嗎昨稼？

（8）平衡

• 質(zhì)量是有代價(jià)的：早些時(shí)候我談到了質(zhì)量和非功能性要求节视。如果你過(guò)度使用架構(gòu)，它將增加成本假栓，并可能降低開發(fā)速度寻行。你需要平衡架構(gòu)和功能需求。應(yīng)避免過(guò)度工程化匾荆。
• 解決相互矛盾的目標(biāo)： 矛盾目標(biāo)的典型例子是短期和長(zhǎng)期目標(biāo)寡痰。項(xiàng)目往往傾向于構(gòu)建最簡(jiǎn)單的解決方案，而架構(gòu)師則考慮到長(zhǎng)期愿景棋凳。通常拦坠，簡(jiǎn)單的解決方案不適合長(zhǎng)期解決方案，并且有可能在以后丟棄（沉沒(méi)成本）剩岳。為避免執(zhí)行錯(cuò)誤的方向贞滨，需要考慮兩件事：
  （1）開發(fā)人員和企業(yè)需要了解長(zhǎng)期愿景及其益處，以便適應(yīng)他們的解決方案拍棕。
  （2）負(fù)責(zé)預(yù)算的經(jīng)理需要參與了解財(cái)務(wù)影響晓铆。沒(méi)有必要直接使用100％的長(zhǎng)期愿景，但是開發(fā)的部件應(yīng)該適合它绰播。
• 沖突管理 ：架構(gòu)師通常是具有不同背景的多個(gè)群體之間的粘合劑骄噪。這可能會(huì)導(dǎo)致不同層次的溝通發(fā)生沖突。為了找到既能反映長(zhǎng)期戰(zhàn)略目標(biāo)的平衡解決方案蠢箩，架構(gòu)師通常也有助于克服沖突链蕊。我關(guān)于傳播理論的出發(fā)點(diǎn)是Schulze von Thun的“四耳模型” ∶冢基于這個(gè)模型滔韵，可以顯示和扣除很多。但是這個(gè)理論需要一些實(shí)踐掌实，這應(yīng)該在交流研討會(huì)上體驗(yàn)陪蜻。

（9）咨詢和教練

在咨詢和指導(dǎo)方面， 積極主動(dòng)可能是最好的贱鼻。如果有人問(wèn)你宴卖，通常為時(shí)已晚滋将。在架構(gòu)網(wǎng)站上清理是你想要避免的。你需要以某種方式預(yù)見(jiàn)接下來(lái)的幾周症昏，幾個(gè)月甚至幾年耕渴，并為下一步做好準(zhǔn)備。

• 有一個(gè)愿景 ：如果你被部署在一個(gè)項(xiàng)目中齿兔，無(wú)論是傳統(tǒng)的瀑布方式還是敏捷模式橱脸，你總是需要對(duì)你想要實(shí)現(xiàn)的中期和長(zhǎng)期目標(biāo)有所了解。這不是一個(gè)詳細(xì)的概念分苇，但更多的是每個(gè)人都可以工作的路線圖添诉。由于你無(wú)法一次實(shí)現(xiàn)所有目標(biāo)（這是一個(gè)旅程），我更喜歡使用成熟度模型（maturity models）医寿。它們提供了一個(gè)清晰的結(jié)構(gòu)栏赴，可以很容易地理解，并且每次都能提供當(dāng)前的進(jìn)展?fàn)顟B(tài)靖秩。對(duì)于不同的方面须眷，我使用不同的模型，例如開發(fā)實(shí)踐或持續(xù)交付沟突。成熟度模型中的每個(gè)級(jí)別都有明確的要求花颗，這些要求遵循SMART標(biāo)準(zhǔn) ，以判斷你是否已達(dá)到目標(biāo)惠拭。我找到的一個(gè)很好的例子是持續(xù)交付 扩劝。
• 建立一個(gè) 實(shí)踐社區(qū)（community of practice） （CoP） ：在共同利益集團(tuán)之間交流經(jīng)驗(yàn)和知識(shí)有助于分發(fā)想法和標(biāo)準(zhǔn)化方法。例如职辅，你可以在一個(gè)房間內(nèi)每三個(gè)月左右召集所有JavaScript開發(fā)人員和架構(gòu)師棒呛，并討論過(guò)去和當(dāng)前的挑戰(zhàn)以及如何解決這些挑戰(zhàn)或新的方法和途徑。架構(gòu)師可以分享域携，討論和調(diào)整他們的愿景簇秒，開發(fā)人員可以分享經(jīng)驗(yàn)并向同行學(xué)習(xí)。這樣的回合對(duì)企業(yè)而言也是非常有益的秀鞭，因?yàn)樗兄诮⒏鼜?qiáng)大的網(wǎng)絡(luò)并分發(fā)想法趋观。另請(qǐng)參閱SAFe框架中的文章社區(qū)實(shí)踐（Communities of Practice） ，該文章在敏捷環(huán)境中解釋了CoP概念气筋。
• 舉行開門會(huì)議 ：誤解或含糊不清的一個(gè)原因是缺乏溝通拆内。預(yù)定一個(gè)固定的時(shí)間段，例如每周30分鐘宠默，與同行交換熱門話題。這次會(huì)議不設(shè)議程灵巧，所有事情都可以討論搀矫。嘗試當(dāng)場(chǎng)解決小事抹沪。安排更復(fù)雜主題的后續(xù)工作。

（10）市場(chǎng)

你的想法很棒瓤球，你已經(jīng)很好地傳達(dá)了它們融欧，但仍然沒(méi)有人愿意關(guān)注？那么你可能缺乏營(yíng)銷技巧卦羡。

• 激勵(lì)和說(shuō)服 ：公司如何說(shuō)服你購(gòu)買產(chǎn)品噪馏？他們展示了它的價(jià)值和好處。但這不僅僅是因?yàn)橛?個(gè)要點(diǎn)绿饵。它們很好地包裹它并使其盡可能容易消化欠肾。
  （1） 原型 ：展示你的想法的原型。有很多工具可用于創(chuàng)建原型拟赊。在喜歡SAP的企業(yè)環(huán)境中刺桃，請(qǐng)查看build.me ，你可以在其中快速輕松地創(chuàng)建外觀漂亮且可點(diǎn)擊的UI5應(yīng)用吸祟。
  （2） 顯示視頻 ：你還可以顯示一個(gè)展示你的想法或至少方向的視頻瑟慈，而不是“無(wú)聊的幻燈片”。
  但是屋匕，請(qǐng)不要過(guò)度營(yíng)銷：從長(zhǎng)遠(yuǎn)來(lái)看葛碧，內(nèi)容是王道。如果你的話沒(méi)有實(shí)現(xiàn)过吻，這將在長(zhǎng)期內(nèi)損害你的聲譽(yù)吹埠。
• 爭(zhēng)取你的想法并堅(jiān)持不懈 ：人們有時(shí)候不喜歡你的想法，或者他們懶得跟隨他們疮装。如果你真的相信你的想法缘琅，你應(yīng)該繼續(xù)追隨他們并為之“戰(zhàn)斗”。這有時(shí)是必要的廓推。具有長(zhǎng)期目標(biāo)的架構(gòu)決策往往不是最簡(jiǎn)單的：開發(fā)人員不喜歡它們刷袍，因?yàn)樗鼈冮_發(fā)起來(lái)更復(fù)雜。經(jīng)理們不喜歡他們樊展，因?yàn)樗麄冊(cè)诙唐趦?nèi)更貴呻纹。這是你堅(jiān)持不懈和談判的工作。
• 尋找盟友 ：建立或?qū)嵤┳约旱南敕赡芎茈y甚至是不可能的专缠。嘗試找到能夠支持并幫助說(shuō)服別人的盟友雷酪。使用你的網(wǎng)絡(luò)。如果還沒(méi)有涝婉，請(qǐng)立即開始構(gòu)建哥力。你可以先和你（開明的）同行談?wù)勀愕南敕āＨ绻麄兿矚g它，或者至少是它的一部分吩跋，那么如果他們被其他人問(wèn)到寞射，他們很可能會(huì)支持你的想法（“X的想法很有趣⌒颗ィ”）桥温。如果他們不喜歡它，請(qǐng)問(wèn)為什么：也許你錯(cuò)過(guò)了什么梁丘？或者你的故事不夠令人信服侵浸？下一步是找到具有決策權(quán)的盟友。要求開誠(chéng)布公的討論氛谜。如果你害怕討論掏觉，請(qǐng)記住，有時(shí)你需要離開你的舒適區(qū)混蔼。
• 重復(fù)一遍履腋，相信它 ：“[...]研究表明，反復(fù)接觸意見(jiàn)會(huì)讓人們相信這種觀點(diǎn)更為普遍惭嚣，即使該意見(jiàn)的來(lái)源只是一個(gè)人遵湖。”（來(lái)源： 金融品牌 ）如果你經(jīng)常發(fā)布一些消息晚吞，那么它可以幫助你更輕松地說(shuō)服人們延旧。但請(qǐng)注意：從我的角度來(lái)看，應(yīng)該明智地使用這樣的策略槽地，因?yàn)樗赡苓m得其反迁沫，作為糟糕的營(yíng)銷手段。

呼吁采取行動(dòng)

讓我知道你的經(jīng)歷以及你如何努力提高你的架構(gòu)技能捌蚊。根據(jù)你的反饋集畅，我將提出更深入的文章。