嘗試一個「創建知識」的過程

 

 大多數的外在特性是容易從系統中辨識出來的。例如，咱們要作一個辦公系統（OA，Office Anywhere），那麼咱們能夠確定幾點事實：

(1) 這一系統老是某些辦公室成員使用的；
(2) 這一系統老是提供上述人員的平常工做所需的功能；
(3) 這一系統既包括對現實工做的映射，也包括一些試圖改變現行工做的電子化需求。
這幾點事實顯而易見，是由系統自己決定的。咱們能夠所以找到一些系統的組成部分：
(1) 觀察辦公室成員的工做，因此須要郵件、日程、考勤、審批等功能；
(2) 考慮到電子化管理，因此須要新聞發佈、消息通訊、文件管理、討論區等功能。
據此很快咱們就能夠描述出這一系統的架構，如圖2所示。

但這些只是一些共性的功能，也就是你們都須要的。隨着你對辦公室成員的調查進一步地展開，你必然面臨一些特定的須要，例如：

(1) 人力，即檔案、招聘、培訓；
(2) 營銷，即客戶、活動；
(3) 經營，即資產。

據此咱們進一步補充這一系統的架構，如圖3所示：

回溯咱們對這些「功能性模塊」進行分類的依據，咱們能夠爲這個系統的三個主要部分命個名，分別爲「平常辦公」、「電子化管理」與「特定業務」，如圖4所示：

幾幅架構圖的演進關係並不難理解，但有一點點差別：圖2至圖3的標題中的版本號是「v0.0….x」，而在圖4中倒是「v0.0.0.1」。更深層次的問題是：何以認爲前者連「一個架構的階段性版本都算不上」，而圖4卻能夠稱爲「一個最最最初級的架構版本」？
咱們能夠依賴種種視角對系統加以觀察，並添加種種分類依據來獲得前兩幅圖所示的「v0.0….x」版本的架構。可是，這些「識別」與「分別」的方法，無助於你獲得「v0.0.0.1」中的幾個關鍵概念：平常辦公、電子化管理與特定業務。關鍵的區別在於，在你作出這些定義以前，現實系統（個人意思是須要你開發這個系統的客戶、辦公室成員或部門）並不會向你提出這三個概念；除非你主動說起，不然這些概念也不會對現實系統的實務有任何影響；除非你將這些概念獨立出來，不然即使現實系統的確是由這些規律內在地驅動着的，也不會有人發現。

可是，是何種思惟方式，讓你：從現實系統中「發現」這三項知識，並將它們設定爲這樣的一些概念，併爲這些概念設定了有別於其餘的依據？
又或者問：你何以在系統中作出一些設定，而非僅僅陳述現實系統

的事實？

如前所述，瞭解系統的一些具體方法，大致來講相似於圖5所示的一個認知過程的方法樹。

咱們事實上只討論了認知行爲中很小的一個部分①。「識別」與「分別」是這個樹上較低層次的方法，它們能獲得系統知識而沒法概括之，能分辨出差別而沒法梳理之，能構建功能模塊而沒法推演之。由於概括（概念）、梳理（關係）、推演（邏輯）這些架構活動所須要的，都是較高層次上的思惟方法。
現實中，基於所面對的計算機系統，咱們大多數的系統抽象與建模過程當中都會用到「分別」這一認知方法。好比說，咱們將已知需求規劃爲條目，而後分門別類，進而整理出子系統、模塊、服務，以及規劃出服務器、集羣等的方案。對系統中的組成、要件、關係等加以分別，是上述這些活動的基點。

而這只是系統的一部分。若是咱們能據此「架構」出系統，那隻能慶幸：這個系統在絕大多數狀況下表現爲一個數字系統，於是如前所述——是能夠基於「數的值」這一抽象概念來進行「分別」的。
或者反之，咱們沒法架構出系統，由於咱們沒法經過這種方法來構建系統的知識。

 

摘自：周愛民【個人架構思想】 

https://aimingoo.github.io/content/images/attachments/Thinking_in_Architecture.zip 

電子書《個人架構思想》小述 https://blog.csdn.net/aimingoo/article/details/75948953

Aimingoo's Blog - [https://aimingoo.github.io/]