內容：擴充套件自己的系統；不要依賴供應商的解決方案來實現可擴充套件性。

場景：每當考慮是否使用來自供應商的新功能或新產品時。

用法：依靠本書的規則來理解如何擴充套件，儘可能用最簡單的方式使用供應商提供的產品或服務。

原因：遵循這條規則有三個理由：掌握自己的命運，保持架構簡單，降低總的成本。要知道是客戶而不是供應商要你對產品的可擴充套件性和可用性負責。

要點：不要依賴供應商的產品、服務或系統功能來擴充套件。保持架構簡單，把命運掌握在自己手裡，控制住成本。如果依賴供應商的專有擴充套件解決方案，那麼有可能違反所有這三個規則。

這麼做的三個理由：

1.保持自己的核心競爭力，選擇採用供應商的部分東西，維持自己架構的可擴充套件能力。

例如：自己公司的產品必須是基於自己人員的架構設計的，而不是完全是供應商來解決。如果這麼做了，你會發現這些結論：a：系統架構的擴充套件能力徹底交給了供應商，而且除了問題也不會在第一時間解決；b：供應商正在成為公司的一個IT部門，而且是獨立運營的一個IT部門；c：即便是想從這種關係中解綁，發現耗費的代價遠遠超過了一開始就有自己獨立的架構設計的方案。這個也是我遇到的一個現實中的例子。

2.我們都希望可擴充套件的系統架構越簡單越好，那麼基本上我們都把服務組成獨立元件的形式，而供應商會想辦法把元件整合到一套大的框架中，要麼用全套花大價錢，要麼自己想辦法。在這個時候，如果你沒有獨立架構設計的能力和方案支援，不好意思，除了花更多的錢沒有辦法了。這是成本和擴充套件性問題，額外的複雜性。

3.使用供應商的解決方案，特別是有形成單一供應商局面的方案，這個會不斷提高成本。

例如：某公司採用了某個IT供應商的全套解決方案，但是它不完美或者是有新的擴充套件性需求，這個時候通常會不斷強化這個供應商的地位，最終這個供應商就是這家公司的IT部門了，而且是成本高昂的不能解綁的那種。這個我接觸到的IT外包基本上都會採用這種策略，不是每家公司都會很明智的有自己獨立的架構設計。

這些內容只有在經歷了足夠多才會明白。