尝试一个“创建知识”的过程

 

 大多数的外在特性是容易从系统中辨识出来的。例如，咱们要作一个办公系统（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/]