一、平臺架構的認識
1、平臺架構是用來促進發展的
1）、促進企業發展
很多軟件企業在發展過程中，爲了更好地規範開發過程、組織團隊合作、聚集技術力量、推動攻關突破、加強功能重用、促進項目水平、提升應對能力等，成立了各自的技術組、架構組、系統組、支撐組、平臺組，形成了各自的過程規範、技術方案、公用功能，乃至開發構架和產品平臺，希望集中技術力量、優化過程管理、整合能力資源，以促進產品項目交付過程的系統化、規範化和可量化。
這既是平臺架構產生的原因，也說明大家都想通過產品平臺或技術構架，來提高自身的生產力和生產效率，爲企業發展提供助力。
2）、解決企業瓶頸訴求
在軟件開發過程中，總會遇到一些類似的問題，比如工期評估偏差大、技術方案差別不一、技術問題不好解決、公共功能多種實現、文檔資料殘缺不全、特定人員依賴較重、代碼質量參差不齊、工作交接難度很大、技術資產難以留存等問題，這些問題影響或制約了企業的項目能力、開發效率、過程控制、質量管理等工作，甚至因爲人員變動等原因，導致其工作無人能接，技術成果從此無用，架構路線推倒重來，業務功能重新開發等尷尬局面。
而這些痛點或瓶頸問題，可以通過對技術的產品化思維，利用平臺架構思想或產品，進行有效地支持、控制和改善，幫助減少無謂的重複工作、技術成本和資源浪費。
3）、把握方向和認知
平臺架構有其形成的必要和應用的價值，但也需要對它保持正確的認知和很好地把握，平臺架構對認知能力、架構能力、把控能力等的要求都很高，對平臺架構的方向控制不好或認知不夠透徹，很可能走向錯誤的方向或退化的誤區，難以保證其繼續遵循合適、簡單、演化的架構三原則【注1】，那麼平臺架構就很難合理、穩定、健康地發展，逐漸失去其應有的價值，甚至產生負面的作用。
那麼什麼是平臺的正確認知呢？這也是我這幾篇文章想表達的內容，簡單來說，就是明白平臺是用來做什麼的，它需要有什麼特性，應避免怎樣的問題，以及它應該有怎樣的發展。
4）、避免失敗或束縛
盡信書則不如無書，如果認爲平臺構架能夠解決一切問題，那麼就可能會發生更大的問題。對於平臺架構，既要避免對其產生過多要求或束縛，制約其發展，也要避免其對開發過程過於限制，對開發造成很大的阻礙。
以平臺架構而言，首先應明確對它的期望和它需要承擔的責任，並考慮到可能面對的其它問題及對待這些問題的策略，然後在平臺架構發展過程中，儘量避免因超出預期的能力要求、不斷提出的功能需求和其它外力原因，讓平臺架構陷入不停擴充、疲於應對、代碼堆疊、臃腫複雜、難以進化、重負難承的境地，否則平臺架構很難發展起來，甚至終將成爲失敗品而被放棄。
另一方面，平臺架構應該提供充分的可擴展能力和可替換能力，使其在規範開發過程的同時，也允許產品開發人員在平臺架構的開放約定下進行擴展，甚至替換平臺架構的部分能力，以滿足產品項目的實際要求。當平臺構架對產品項目產生的阻滯作用，接近或超過其帶來的助力時，這個平臺架構要麼需要馬上重構，要麼就該放棄使用了。
5）、權衡價值與衝突
平臺架構提供的很多特性，其實是相互衝突的，比如規範性與靈活性、可控性與開放性、可靠性與可擴展性、簡單化與可配置化、輕量化與豐富功能等等，這些衝突的特性需要被很好的認識到，併合理地權衡他們在不同情況下各自的要求、影響以及效果，選擇更優化的決策和更平衡的處理，以實現他們的對立統一。同時，這些權衡結果應儘量不破壞平臺架構本身的合理性、健康性和優化性。
對於容易產生理念衝突、難於選擇或可能對規範產生影響的位置，要及時發現並給出意見或替代方案，指導開發人員按照相對合理的方法進行開發、擴展或替換，同時對其可能產生的影響，也要做出適當的解釋說明。
對於平臺架構自身也一樣，比如合理性和實用性，都需要建立在大量的時間上，只不過一個是對平臺架構內部，一個是對業務項目支撐，當業務急於使用平臺架構的能力，但此能力是平臺架構需要具備但無法在短期內保證其合理可用時，那麼應儘量以較合理的方案或方式提供此能力，並在後續過程中及時對其進行調整改進。而當平臺急於發展導致內部不再優化穩定時，一定要適時地停下腳步，對平臺進行必要的修正重構，否則當平臺架構問題重重、積重難返時，那麼它也快走到盡頭了。
2、平臺架構不是空中樓閣
1）、平臺架構不是遙不可及的
平臺架構其實是可大可小的，一個大的平臺，可以是很多個能力組件、大量的內置功能、全過程的管理支持，開放性的服務體系，以及成熟的規範指導，而一個小的開發架構，可能僅僅是幾個開源框架的粘合和一些開發方面的約定。
對於一個小型企業或項目團隊，因爲規模不大，平臺架構並不一定是必須的。當在需要平臺架構的時候，可以結合自身實際，將技術能力、以往經驗和網上的方案結合起來，嘗試並形成適合自身的架構方案和架構體系。
而對於中型或大型的軟件企業與團隊，架構乃至平臺則是很重要工具，而且他們有充分的技術實力、大量的經驗積累和充足的成本投入來構建自己的平臺架構，滿足項目保障、技術積累、行業發展等需要。有時在面對臨時項目、超短工期、非專業領域的需求時，還可以直接向外採購成熟的平臺架構產品，來支撐自己的產品項目。
對於更大的軟件企業來說，有幾套面向不同方向或支持不同特性的平臺構架產品，甚至引領平臺架構的標準，都是很正常的事情了。
2）、平臺架構不是一時衝動
有些企業高層或技術主管，認識到了平臺架構的作用，立志於建立自己的平臺架構產品，來支撐和促進企業的產品業務。但一個成熟、穩定、可持續發展的平臺架構，不是僅憑一時決定和一腔熱血就能實現的，起碼沒有充分的思考設計、大量的經驗積累、充足的技術實力、不斷的實踐改進，是難以完成的。
對於這種情況，要麼從實踐中慢慢摸索，逐步形成平臺架構的最佳方案，要麼借鑑其它成熟的平臺架構方案或經驗，並在實用中通過學習改進，漸漸演變成適合自己的平臺構架，總之對於一個平臺架構方面積累不多的企業，平臺架構之路不能想着一朝一夕就能達成，不能操之過急。
3）、平臺架構需要爲實用服務
平臺架構首先要爲本企業的當前項目和業務發展服務，它可以不用馬上達到全面和完善，但要能夠很快用於實際並帶來價值，否則如果只顧着平臺架構的先進理念、優美架構、前沿技術和廣泛價值而進行封閉構建，那麼平臺架構很容易陷入反覆論證、不斷填充、接連改進的書面，導致遲遲難以完工和交付應用，同時這樣完成的東西就像閉門造車一樣，真正使用時仍會發現存在大量不方便的、不適配的、不實用的，甚至不合理的、無用的設計和功能，結果與預期產生巨大的偏離，造成時間上、成本上的浪費，甚至更大的損失。
一些看上去很高大上的技術、功能和設計，如果短期內或相當一段時間內無法應用於實際並帶來價值，那麼就可以推遲，甚至無需加入到平臺框架裏。
4）、平臺架構需要踐行和提升
平臺架構初期很難保證其完全的實用性和合理性，需要儘快在實際產品項目中進行驗證和磨合，並及時收集意見反饋，進行分析論證，發現和解決設想上的、規劃上的、規範上的、結構上的、功能上的、質量上的偏差和問題，讓平臺架構更科學、更健康。經歷過很多個項目檢驗的平臺架構，其可靠度和支撐能力，也能讓企業領導、業務團隊，以及目標客戶易接受、易認可、易信賴。
5）、平臺架構需要探索與試錯
平臺架構不應只滿足對已有能力的維護和對已有產品項目的支撐，還要對現有內容進行改進、對行業發展進行預見，對流行技術進行探索，否則當客戶有更高要求、更多需求或發展要求時，平臺架構如果不能在較短時間內提供支撐方案，那麼很可能會讓各方降低對平臺架構的評價，而且在平臺架構上倉促補增的功能，在質量、合理性、可靠性等方面也很難保證，對平臺架構也是不利的。
平臺架構的優化探索，可能在穩定性等方面產生一定的風險，但爲了平臺的發展，既要承擔這個風險，也要做好控制工作。通過對平臺架構進行充分測試驗證，以及版本升級等方法，可以儘量降低平臺架構的BUG量，及其產生的影響。
3、平臺架構不是一蹴而就
1）、先要理解平臺架構思想
搭建一個簡單的平臺架構，並不太複雜，但搭建一個優秀的，有強大支撐力、廣泛適用性和長久生命力的平臺架構，就不是那麼容易的事情了。要搭建一個高質量的平臺架構，首先要理解平臺化思想，要懂得和堅持軟件工程化、過程規範化、結構模型化、組成構件化、能力複用化、調用接口化、業務隔離化【注2】、代碼標準化這些思想和要求，架構思想本身既有軟件工程思想，也包含着對豐富的規劃設計能力、開發支撐經驗、需求運維體驗的要求，忽視上述這些內容來建設平臺架構，是不會成功的。
而對於平臺建設參與者來說，至少要具備較強的技術能力、一定的項目經驗、面向對象思想，以及對代碼的“潔癖”和對技術的追求。
2）、還要清楚平臺架構使命
平臺架構大的目標和作用前文已經說過，不在贅述。但在具體企業裏，平臺架構初始的任務，並不見得非要這麼大，可能它當前只需要支撐一個或幾個項目，那麼作爲平臺架構的構建者，就要先掌握平臺架構當前最重要的目標、可以收攏的資源，以及對交工日期和平臺能力的要求，在此基礎上，還可以向平臺架構的廣義使命上靠攏，或在平臺架構設計上深化，並把握住平臺架構的結構和質量，讓設計開發出來的平臺架構，具備向深度、廣度、成熟度發展的良好潛質。
而一個大的、長久的平臺，它需要承擔的使命和需要具備的特質，是每一個平臺建設參與者都需要理解清楚和認真執行的事情。
3）、要認識平臺架構的生命
平臺架構並不能一直存在，這也是每個平臺建設參與者需要了解的。我把平臺架構的生命劃分爲：初生、發展、調整、轉變/衰退，共四個時期。
其中初生期，是平臺架構剛開始規劃建設的時期，這時平臺架構功能不全、Bug不少，但充滿着活力和希望，即將承擔重任；
到了成長期裏，平臺架構的基本目標已經達成，基礎功能大體完備，整體趨於穩定，已經有項目建立或運行在平臺架構上，平臺架構重點向縱深方向發展；
再往後發展，平臺架構進入調整期，這時平臺架構的初期目標已經大半或全部實現，平臺架構開始側重精細化或大而全，此時的平臺架構仍很有優勢，但有些問題也開始顯露，而平臺架構構建者對這些問題的認識和態度，也決定了下一步平臺將進入轉變或衰退；
再到下一階段，隨着目標行業的發展與擴展、開發技術的演變與轉化，以及平臺初始的核心缺陷與積累的龐大、複雜、混亂、封閉、不合理、低效率、難改進、難擴展等問題，導致平臺劣勢漸顯、矛盾漸深時：
- 平臺可能因設計架構合理、問題較淺和轉變及時，而用新結構、新技術、新組成來優化、替代或重構，提升活力，延長或煥發生命力。
- 或因設計缺陷、結構問題、缺少投入，以及體積臃腫或業務粘連【注2 】等原因而難以改進，等待衰退直到消亡。
4）、要有好的方向和設計
要做平臺架構，需要有長遠和眼光，具備良好的設計能力。有名話說：目光有多遠，你就能走多遠，格局有多大，你的世界就有多大，這句話對平臺也適用。代入一下，方向即是平臺架構的目光，設計即是平臺架構的格局。
在平臺初期和發展過程中，不僅要低頭幹活，還要擡頭看路，適時地整理一下平臺架構的狀況，展望一下平臺架構未來的方向，看看現在的路走的對不對，好不好，往下應該怎麼走。同時合理的架構、良好的設計，也是保證平臺能發展的基礎，充斥着不合理不健康設計的平臺，是發展不起來的。
5）、要大膽設想小心求證
做平臺要大處着眼，小處着手，既要明白平臺的遠期戰略目標與期望價值，也要制訂當前合適的戰術計劃和結果預期，並着力於具體工作。同時理論與實踐相結合，一方面印證戰略的方向是可行的正確的或需修正的，另一方面在實用中總結和昇華，形成更科學的目標和論斷。
想的不一定就是對的，如果只會空想忽略實際，並強行應用於平臺框架，那麼結果可能只是個花架子，中看不中用；而只專注當前需求，不考慮未來發展的平臺架構，雖然一時能用，但很快就會跟不上技術和需求發展的步伐。
6）、要從基礎慢慢積累
羅馬不是一天建成的，平臺架構也同樣。平臺架構對認知和設計的要求，需要借鑑成功的經驗或從實踐中慢慢摸索，並認真思考研究，同樣平臺架構對建設者的要求，也需要慢慢培養和引導。
建設平臺架構，首先要統一思想，明確目標，然後一步步完成設想，及時發現和解決問題，形成平臺架構的基礎並漸漸完善。應促進平臺建設者們的交流和討論，讓大家在交流討論過程中，解開思想和技術上的問題，逐步形成一致的認識，統一的標準，共同把握平臺的結構和質量。
4、平臺架構不是一個模子的
1）、不能照搬照抄
世界上的企業千千萬萬，平臺架構也多不勝數，但各個企業的主營方向、客戶羣體、業務場景、軟件構成、技術力量、管理策略等都可能會有差異，別人家的平臺架構和建設經驗，對自己的企業並不一定就是完全適用的，要會甄別和分析，哪些可以拿來就用，哪些需要做些改造，哪些對自己幾乎毫無用處，要知道只有合適的纔是最好的。
2）、不能畫地爲牢
平臺架構既需要用來規範開發，也需要能夠規範自身，但這個“規範”不能是死的一成不變的，要根據實際情況和發展需求，做適當的調整和變化。就整體而言，平臺構架是業務開發的基礎和支撐，它應該是牢固的，但就局部而言，平臺架構的組成和提供的能力，應該是開放的、解耦的、可替代的，這樣平臺架構既能建立起統一的規則，指導產品項目開發，也能靈活轉變，適應發展的需求。同時平臺架構自身，也要跟隨時代發展和技術進步，不斷演進和提升。
3）、理論實際相結合
平臺架構需要有指導思想和建設理論，這樣它才能看的更高，走的更遠，平臺架構還必須爲實用服務，這樣它才能印證設想，產生價值，這兩者既不衝突，又是相輔相成的。同樣的，很多的軟件工程思想，比如面向對象、模型驅動、設計模式等等，也都適合在平臺架構中應用，幫助其建立科學合理的設計和結構，但這些都必須以實用爲主，如果過度設計，那就得不償失了。
4）、以實用爲主以規範爲綱
平臺架構應面向應用，它的各項設計和能力，都應該能在現在或可預見的將來，爲企業進行服務併產生促進作用。平臺架構建設者應與公司領導和開發團隊、產品團隊多接觸交流，讓他們也瞭解和掌握平臺的目標和特性，幫助平臺架構健康發展，及時發現和糾正平臺架構中的不合理、不實用的設計和功能。同時平臺架構也需要建立起自己的、科學合理的規則和標準，引導和規範自身發展與業務開發，並在實用中磨合出更合適的標準和更明確的方向。
5、平臺架構是發展演進的
1）、平臺架構思想在變化
我認爲平臺架構思想的發展，經歷着由固定模式到最佳實踐、由一體化解決方案到適用生態、由項目能力到服務能力的轉變。
以前技術發展相對較慢，技術生態圈也很弱小和遲滯，知名的平臺架構，基本都有自己的固定模式，儘量涵蓋到面向行業的大部分需求，並由自身提供這些能力和技術支撐，而平臺架構的使用者，需要在它的限定範圍內進行開發和使用，如想跳出它的制約採用其它方案，則存在諸多困難。
當前的IT行業與軟件技術發展非常快，架構思想也更爲貼近、技術生態更爲活躍、協議標準更爲一致、功能組件多種多樣、能力積累豐富成熟，主流的平臺架構更多的是採用相近的架構理念和類似的搭建方案，對能力的支持也不限於自己提供或單一選擇，而是面向服務協議或接口標準，讓使用者可以自行在能力生態圈裏篩選組合，在提供解決方案的同時，爲使用者提供了更寬泛和自由的支持；同時倡導對既有能力以服務化的形式進行整合、優化、封裝、開放和管理，爲不同用戶需求和使用場景提供公共支撐【注3】。
2）、平臺架構構成在變化
以前平臺架構的能力組成，多由平臺架構本身提供，技術實現也基本相同，相互間依賴較重，能力間拆分較少或較淺，現在的平臺架構，更注重模塊化、組件化、服務化，能力構成之間各自獨立並以接口協議進行互訪，各能力支撐組件可使用不同技術實現、可拼裝卸載、可選擇替換、可單獨使用。
3）、平臺架構模式在變化
以前的平臺架構，更強調業務能力、行業經驗和產品化功能，而當前的平臺構架，則重注重能力組合、簡化過程、解耦功能、加強協作，提升能力面向範圍，簡化開發配置過程，減少相互引用和依賴，降低代碼量和協作成本，促進企業能力整合和高效收益。
4）、平臺架構體量在變化
以前的平臺架構一般是以“全家桶”方式提供，在當時情況下，它以自行開發爲主，能力較強、封裝較多、體積很大、部署複雜，顯得大而全，而現在的平臺架構，則向融合化、輕量化發展，大量採用公共標準和開源組件，開發代碼量大幅減少，平臺體量的伸縮性很強，既可以選擇全部功能，也可選擇部分能力，還可以進行局部的能力替換，使用平臺外的產品來替代平臺本身的能力。
5）、平臺架構的面向性在變化
我認爲，平臺架構經歷着單體->整合->融合方向的發展。以前平臺架構只要支撐單一項目或產品即可（單體），隨着軟件產品的擴充和數據孤島的增加【注4】，以及用戶的管理要求，軟件間互通的需求越來越多，要求平臺架構能夠支持軟件間的訪問和協作（整合），那麼當前平臺架構除了基礎的項目支撐外，還需要具備支持敏捷響應、業務創新、以及跨行業適用等特性，以滿足用戶對能力的快速提供、服務協作和用戶體驗等方面的要求（融合）。這也符合了軟件從單體到服務化，再到雲、互聯網+、移動化、微服務、大中臺、富生態的發展過程。
6、平臺架構不是萬能的
1）、沒有“銀彈”
平臺架構有它的好處，但也不是萬能的，“平臺”並不能解決所有問題，能解決問題的，最終還是人，還是對行業和企業的認識和發展的考量與決策。企業可以通過平臺架構思想，來構建自己的技術平臺、業務平臺、產品平臺、服務平臺，促進企業發展和提升，但“用什麼”、“怎樣用”，是與“要不要用”一樣重要的問題，需要想清楚。使用平臺架構應符合最佳實踐的理念，只有合適的纔是最好的，而不“合適”的平臺，比如能力不強、設計糟糕、代碼混亂、約束重重等，這樣的平臺不如不用。
2）、平臺架構需要明確並專注目標點
平臺架構要爲實用服務，爲企業創造價值，這需要爲平臺制訂合適的長期規劃與可行的短期目標，在平臺架構發展過程中，圍繞這些規劃和目標開展工作。平臺架構的目標與規劃可能會隨着企業本身、技術趨勢與管理意識等的發展而進行調整，但也要把握好尺度，過於頻繁的調整目標計劃，或不斷改變對平臺架構的能力預期，以及經常衝擊平臺已有的規則標準，這些就都是很忌諱的事了，這樣做往往會導致平臺架構的目標難以完成，健康性與支撐能力減弱，甚至更糟。
3）、平臺架構需要減負增效
平臺架構能力的提升過程，往往也伴隨着它體積的增長，以及健康度、穩定性、運行效率的下降，如果不重視這些問題，那麼平臺架構也會變成“胖的走不動路”，影響它的能力與發展。所以在平臺架構發展過程中，還要注意平臺自身的減負增效，對平臺進行評審、優化、拆分、重組，甚至是局部或整體的重構，使它始終能夠保持可控、合理、高效和可發展。
4）、平臺架構需要邊走邊看，不斷演進
軟件技術、行業標準、發展趨勢都在發展變化，那麼平臺架構也需要參照這些發展變化情況，以及審視自身狀態，及時進行調整、適配和提升。這與平臺的“專注”並不衝突，規則和標準，本身就是平臺架構的立身之本，但發展的道路不是一成不變的，規則標準以及平臺架構自身，可能並不會完全符合未來發展的趨勢和變化的要求，這一方面要求在制定規則標準及搭建平臺產品時，要有一定的前瞻性及可發展性，另一方面這些內容也需要不斷完善與演進，以適應趨勢，保證平臺能夠始終能夠在發展的浪潮中，得到存續並不斷提供充分的價值。
5）、平臺架構也有可能成爲負擔
如上所言，在平臺架構的發展過程裏，它的決策者和構建者們，要不斷地提升自己的認知、視野、敏感性和技術能力，同時也要保證平臺自身的合理、健康、可持續、可發展，這樣才能讓平臺沿着正確方向不斷提升演進，否則平臺架構就可能發生能力減退、不適應技術趨勢、不支持行業發展要求，甚至制約企業的產品項目能力等問題，由企業發展的助力者，變爲阻礙者。當出現這樣的情況時，這個平臺架構就是失敗的，難逃沒落的命運。
7、平臺架構本身也有價值
1）、平臺架構可以爲企業提升價值
用合適的平臺架構作爲企業產品項目的建設支撐，可以有效地爲企業提升業務承接能力、提高項目建設效率、降低項目建設成本、強化客戶對企業的認可、促進企業發展進步。
2）、平臺架構可以實現或推廣企業價值
在平臺架構中，還可以融入企業對行業的認知和對技術的引領意識，將企業對自身的總結和對發展的預見，體現在平臺框架，以及其支撐的產品中，來促進和推動客戶企業以及目標行業對本企業發展觀的認可，以及對本企業帶動作用的認同，助力企業價值的推廣。
3）、平臺架構也可以作爲產品
當企業的平臺架構比較完善或先進時，可以將平臺架構作爲產品，進行平臺架構的技術推廣和有償使用，以及提供諮詢、培訓、支持、出版等付費業務，爲企業獲取收益。
二、注：
1、來源於《架構設計三原則》，https://blog.csdn.net/program_guys/article/details/81007352
2、業務隔離化和業務粘連，是指在平臺架構代碼中，不要出現針對業務狀態或業務指標值的判斷和處理,避免架構業務之間的緊耦合，這樣即是平臺架構與業務的隔離化，反之則是業務粘連。
技術型平臺架構雖然是爲支撐業務開發而存在的，但其核心應該是單純技術化、功能化的，或者說是隻對當前模塊能力負責，而不考慮具體業務指標的差別。如果因業務場景或業務條件不同，導致平臺架構裏的處理出現不一致，這時就要通過插件、適配或可擴展性等方式，將與業務相關的處理從平臺架構中剝離出來，避免平臺架構與業務，或者平臺架構功能間出現邏輯沾染或深度耦合，特別是避免與業務開發間的粘連。
如果平臺架構出現業務粘連，一方面會導致平臺架構存在非平臺處理，變得腫脹和不純粹，另一方面因平臺架構修改會影響到業務，導致平臺架構難以優化和改造，拖累平臺架構的發展，甚至影響其生命。
3、實際上是說中臺的概念，簡單地搜索了一下，我對中臺的理解，與此鏈接及其評論相近：https://www.jianshu.com/p/86dc7ad52ad6。中臺是平臺架構的延伸，它是基於平臺架構和業務積累之上建立起來的。
4、指早些年企業裏相互獨立，互不相通，難以協作的各類管理軟件。
參見：
【我對軟件平臺架構的理解】第二部分：對軟件平臺架構的認識（一）