软件设计面对的环境日趋复杂。对这种日趋复杂、难以驾驭的状况，很多软件人希望能有所改善。而标准化对提升架构设计效率和提高软件开发成功率很有裨益。本文探讨架构演进的另一个趋势，就是行业级标准化。
软件设计面对的环境日趋复杂。背后原因不仅有技术发展本身带来的复杂性，而且也有规模增大带来的复杂性。
从最初面向小型群体、具体领域的程序设计，到面向上亿用户、交叉需求的生态构建，软件设计似乎走上一条以复杂应对复杂的发展之路。我们看到，从方法到概念都日趋复杂。
一开始，很多软件的早期版本较为清晰，后来逐渐走向“大泥球”模式。最终，它们“活成了我们最讨厌的样子”。
“技术债务”成为软件生命周期中的常见问题，所以，对软件设计方法尤其是架构方法的探索始终未停。这些探索与软件工程方法的演进互相作用。
对这种日趋复杂、难以驾驭的状况，很多软件人希望能有所改善。众所周知，标准化对提升架构设计效率和提高软件开发成功率很有裨益。在架构方法发展的过程中，关于这个方面的标准化努力也一直在缓慢推进。这个标准并非指软件开发标准，比如国内的 GB8567-88，而是指能直接应用于具体开发的设计参考，比如行业级标准化模型。
本文探讨架构演进的另一个趋势，就是行业级标准化。
一、为何行业级标准化发展缓慢？
行业级标准化之所以较难达成，是因为背后有许多复杂因素。
首先，这是一项带有公益性质的工作。一旦做成功，大家都受益，但推动者的付出与其收益之间不成比例，要靠一定的“奉献”精神支撑。
其次，标准达成需要统一众多观点。而这种统一并非可以强制达成，标准本身的建立过程就会比较缓慢。时间一久，甚至不了了之。
最后，即便建立标准，更新维护的主体通常也难以确定和维持，“保鲜”难度大。
如此困难之事，为何今日应该重提？这又涉及另外两个原因，而它们却是今后软件或者数字化的发展方向。
1. 软件在生产、生活中的基础性地位还不够
我们现在常说，软件、互联网改变了人类社会，但实际上，并非所有行业和生活场景都充分线上化了。事实是，大部分行业中，软件的基础性地位还没有达到人们通过宣传所“认为”的水平，并且，软件行业总产值也没在 GDP 中有很高占比。
这表明，软件还未像工业制成品那样深入到社会的各个角落，软件生产也没像工业生产那样成为广泛的社会性生产。
根据埃文斯数据公司 (Evans Data Corporation) 2019 年最新的统计数据显示，2018 年全球共有 2300 万软件开发人员；到 2019 年底，这个数字将达到 2640 万，而到 2023 年，这个数字是 2770 万。其中，它对软件开发人员的定义很广泛，甚至包括技术作家。
与之相比，2018 年，世界各国青壮年和逐渐进入的劳动年龄段 (15 至 64 岁) 人口总数约为 49.6 亿（数据来源于互联网）。也就是说，无论是从行业规模还是劳动人口的数量来讲，软件行业仍处在上升阶段，还没有成为一个像农业或者工业那样可作为时代标志的行业，数字经济仍在发展初期。
从这种状况，我们可以推想，多数对于行业级标准化的真实“焦虑”可能只存在于少数软件从业者心里，还没真正上升为企业“焦虑”，更未成为行业“焦虑”。
所以，在开发中，尽管我们在项目管理中反复强调一些项目级的标准化要求，但这些要求没有真正走出项目以外，没有真正成为企业级、行业级的要求，所以行业级标准化的进程也必然缓慢。
但是，数字经济的发展速度正在加快，不少人认同未来的企业可能都是科技企业。软件会成为主要的生产工具，这也许会改变经济数据的统计口径，从而让数字经济规模得到更准确的计量。
随着这种发展，即便出于让工具更易用、更易得的角度，行业级标准化也应得到更大重视。
企业之所以要为软件付出更大代价，很大一部分原因就是软件无法像真正的工业制品一样批量化制作与获得，以及提供售后，甚至是其中无需太个性化的部分。当企业、行业越来越依赖于软件时，软件中的主要部分需要被标准化和真正量产。
当过度强调软件使用和软件生产中的个性化因素，这会让软件行业面对与工业化早期类似的问题，尤其是在“B”端，过度的“自由”可能会带来“不自由”。这些过度之处对“创新”的意义也许被夸大。
工业标准化没有让工业变得死板和缺乏创新，反而减少浪费，让创新能更好地分层次进行，比如设计创新、零件创新、材质创新和集成创新等，而无需经常从头开始。软件行业也应该通过行业级标准化减少“创新浪费”，这样才有可能让软件走出现在这种“大规模小团队手工作坊”的阶段。所谓的 AI 设计，需要的不也正是基础性的标准化吗？
也许满足标准化，我们才能把精力花在更有价值的创新上，而不是整天修改别人也改过的 BUG，成天担心踩别人踩过的坑。
标准化是工业成熟的体现，也是其在整个社会生产中基础性地位增强的必然结果，这也是软件未来必须要走的路。
2. 架构设计的开放性不足
在发展的大部分时间中，软件设计更多处理的是封闭边界内的封闭问题域。当处理复杂问题时，软件设计者的思考习惯是尽可能将复杂问题拆分成更小的独立问题。处理“封闭”空间会令软件设计者感到“舒适”，而“开放”空间则容易让软件设计者失去“焦点”，也会带来更大的知识负担。
处理好边界是软件设计的原则之一，不定义好边界的软件很可能无法交付。这种方式本身无可厚非，其隐含的问题在于，多数软件设计缺乏企业间的横向联通和行业级的定义。很多承载行业统一概念的行业术语虽然在设计过程中被软件人员学习和思考，但并没有发挥其在标准化方面应有的作用，“封闭”也成了一个一个软件实例的“封闭”。
现有的各类技术标准多数无法帮软件形成标准化的设计结果，它们更多是对工艺和技术的要求。
工业在发展早期，企业间的标准化和连通性也不强，一度出现囊括生产链条大部分环节的超大型企业集团。但是，随着精细化分工的发展，企业最终放弃这种不经济的“全都干”模式，采用供应链、生态圈模式。
标准化在提升企业协作上发挥至关重要的作用。
早在 1926 年，拥有国家级标准化组织的 25 个国家在国际上成立国家标准化协会国际联合会（ISA），由此，标准化活动从企业行为演进为国家管理，进而成为全球事业，活动范围从机电行业扩展到各行各业。标准化扩散到全球经济的的各个领域，从保障互换性的手段，发展成保障资源合理配置、降低贸易壁垒和提高生产力的重要手段。
软件行业现在也有些类似工业早期的状况，优秀开发资源的集中，从上到下的完整、个性化开发比比皆是。
此外，企业习惯于“封闭”设计成果，因为软件一旦跟核心生产领域接触，就自然地牵连上各类“商业秘密”，导致成果“封闭”，甚至包括设计过程中产生的模型资产，这也是大家需要重复建设的原因之一。
综上所述，软件开发中，思考方式、设计范围、设计成果方面都具有不同程度的“封闭”倾向。当然，这其中有其处理现实问题方面的必要性，但是，这也导致架构在设计标准和视野上不够开放，标准化发展缓慢。
现在，随着互联网技术对企业连接能力的进一步加强，生态圈构建从业务层面将下沉到软件层面，要求软件层面更多地支持联通和协同，这不仅仅是对 API 的关注，还需要在架构设计方面有更多的全局视野和开放性。各类新兴技术，无论是出于对应用成本的考量，还是对应用速度的考量，都需要其在转换为软件时，提升通用性，提升标准化水平。
从企业内部架构走向开放式架构、推动国民经济数字化转型的过程中，软件架构顺应经济模式的发展，必须要解决标准化短板对开放性、规模化的制约。这不仅有助于将设计人员从重复“搬砖”过程中解放出来，也让“砖”能更方便地盖成“楼”，不能总把软件设计当做个体行为和个别实例。
二、行业级标准化的核心方向
软件设计主要处理的对象就是数据和行为，架构设计的关键其实也在识别数据结构，划分处理数据的不同行为模块。
所以，从设计结果角度出发，架构标准化主要是对数据和行为的标准化，而标准化的范围，从对设计结果应用的角度看，行业级的标准化是较为合适的层级，这个层级具有合适的语境和语义范围，也有行业术语作为统一概念基础。
1. 数据标准化
数据是计算机程序的输入和输出，也是不同程序模块间进行衔接时必须要进行标准化处理的部分。在软件设计中，接口标准化已经是大多数项目必备的设计要求。目前行业级的数据模型也有实例，比如 IBM 之前为金融领域设计的 FSDM(Financial Services Data Model) 数据模型。
FSMD 是上个世纪 90 年代，IBM 针对金融行业建立核心应用系统或者数据仓库推出的数据模型。作为大机及大机开发服务的主要供应商，IBM 在这方面有独特优势，而金融行业也是大机的 VIP 级用户，因此，IBM 根据其丰富的行业经验设计这一经典的行业级数据模型。
FSDM 是一种分层级、逐级细化的数据模型，包括“ABCD”四个大的层级，具体分层如图 1 所示：
图 1 FSDM 数据模型的层级（来自网络）
FSDM 将数据分为九个大的类别，各类别概念如表 1 所示：
表 1 九大概念（来自网络）
九大概念之间具有一定的联系，其相互关系如图 2 所示：
图 2 九大领域数据关系示例（来自网络）
FSDM 金融服务数据模型定义了金融服务机构自身和业务运作所需的基本数据概念以及相互关系，包含银行业的绝大部分数据。在实际设计中，数据模型会在九大领域下再细分为不同的数据主题域，主题域包含数据实体，实体下包含数据属性，从而自上向下完成对数据的企业级模型化梳理工作。
FSDM 模型证明，只要坚持积累和钻研，构建一个具有一定影响力的行业数据模型是完全可行的，而且确实可以给软件设计提供一定的指导和便利。
但是 IBM 当初毕竟是与其商业行为进行一定的结合，有适当的驱动力。在没有足够商业利益结合的情况下，如何推动行业级标准化数据模型的建设是一个难题。此外，FSDM 更多承担的是指导性作用，还没有真的成为标准，需要金融企业依据其指导建立数据模型并自行维护。
2. 行为标准化
相较于数据标准化，行为标准化更为困难。如果想要建立对软件设计起行业级指导作用的标准化模型，这个模型必须能指导细粒度的开发，而非仅传递到概念层级，如果比照工业标准的效果，应当可以指导或者直接生产出可供复用的软件“零件”。
软件设计一直在关注如何提升对已有软件资产的复用，从对代码的“复制粘贴”到模块化、服务化、微服务化，通过对业务逻辑乃至数据封装和接口开放，实现软件资产的可重复利用。各种设计思路中，笔者认为，构件化作为推广标准化的理念而言，也许是更为合适的概念。
构件化设计，又称 CBD（Component-Based Development，基于构件的开发）或 CBSE（Component-Based，基于构件的软件工程）。关于该方法的讨论比较早，文献也较多，例如，Alan W.Brown 所著的《Large-Scale, Component-Based Development》（中译本名称为《大规模基于构件的开发》，2003 年由机械工业出版社出版，赵文耘、张志等译）。
按照构件化设计理念，构件可以独立部署，但一个构件可能会用到其它构件或平台提供的服务，或者说基于构件的软件系统通常是多个构件协作完成一定功能，所以构件依赖于组装环境或称为语境（context），而构件基础设施应是支持异构构件互操作的标准和通信平台，构件框架则是构件实例“即插即用”的支撑结构。
CBD 的实现方式之一就是大家耳熟能详的——SOA（Service Oriented Architecture ，面向服务的体系结构）或者 SCA（Service Component Architecture ，服务组件体系结构）。从发展脉络上讲，1990 年左右就开始出现面向构件的技术思想，也即，编程方法在面向对象后是面向构件，然后才是面向服务。
关于构件化设计，国家标准也早已有之，比如 GB/T11457-2006 软件工程过程、GB/T36445-2018 软件构件模型，都有相关技术标准约定，但是这些标准都未包含构件的设计方法，实践中大家更关心的是如何做出标准化构件的方法论。
有人经常用“乐高积木”一词来形容构件化或服务化设计方式，乐高积木之所以会吸引不同年龄段的人群，并能让大家充分发挥创造力，主要原因不外乎两点：一是接口的高度标准化，可以简单搭接；二是使用者能很轻易地理解每个积木块，自由运用它。
构件模型设计的关键也在于这两点。设计行业级标准化构件模型，首先是接口的高度标准化，这一点有赖于前文中提到的数据标准化；二是构件功能的标准化和可理解性，这就涉及到对业务行为的标准化，或者说对各种同类型企业（也存在同类型企业中按照规模等级再细分的可能）的业务活动标准化，这种标准形成需要以业务为核心的建模方法，也需要通过作为参照系的标杆企业来提炼标准业务行为。
在建模方法中，Alan W.Brown 在《Large-Scale, Component-Based Development》一书中给出的主要是基于 UML 的方法，该方法虽然与现实结合紧密，但对业务人员不够友好；DDD 也是可以应用于构件化设计的建模方法，尤其是在以构建微服务为应用方向运用 DDD 方法时，该方法也充分考虑了业务含义。笔者在《企业级业务架构设计：方法论与实践》一书中提到的构件模型也是一种可用的构建方式，其优点是具有企业级视角，与业务和技术两端结合紧密，也适合于推导行业标准模型这种精炼性工作。
综上，数据标准化和行为标准化的探索一直有人在进行，但需要更强有力的推动来真正形成行业级的标准，否则，软件的发展有可能在“凶猛”的创新下反倒出现“作茧自缚”的情况。
三、行业级标准化的深远影响
行业级标准化的价值有很多，比如有助于提升软件资产的可重用性、提升软件质量、减少不必要的改动、提升互联效率、提高需求质量、提升需求形成效率等，这些价值很多文章都提出过，笔者在本文中想阐述一个目前较少提及的远期价值：推动数字化思维转型。
数字化时代是依靠大规模软件生产支持社会生产的时代，如同今天工业的作用。而大规模软件生产能力的形成需要与之相匹配的思维方式，人们的思维方式总是要与时代的主要生产方式相适应，当软件成为主要的生产方式时，结构化思维就成为这个时代最基础的思维方式，提升所有参与者的结构化思维能力是面向数字化时代最重要的思维转型方向，包括业务人员的思维转型和技术人员的思维转型。
业务人员思维转型，是指能结构化地看待业务、理解业务，结构化的业务视角更有利于将业务映射到技术实现，也更有利于业务人员较为直接地应用已有的软件资产，如同业务人员看到“乐高积木”，具备结构化思维能力的业务人员，更容易适应在数字化时代看到的“事物”和从事业务活动、开展业务创新的方式。
技术人员思维转型，则是要能结构化地看待业务构成与技术实现的关系，从而更好地将业务分解成合适的“零件”，这是在技术人员原有结构化思维方式上的一种深化。对技术人员而言，这还意味着要更主动地去接受标准化的“约束”，从个体化的改进软件向公用化的改进“标准”发展，这是数字化时代进行大规模软件生产需要的技术思维方式。
换句话说，就是在业务侧，应当能看到“业务服务化”、“服务编排化”，业务人员具有利用构件化软件资产、协助生产构件化软件资产的能力；在技术侧，应当能看到“服务业务化”、“编排服务化”，技术人员具有按照业务含义准确设计标准化服务，将编排作为一种服务向业务侧提供的能力。
基于行业级标准化构件，我们应当能实现更为标准化的企业架构，企业内部以行业级标准化构件为基础搭建软件，而具备这样标准化架构的企业也必然会成为开放式架构中的标准化元素，实现行业级、社会级的开放互联。如图 3 所示：
图 3 以标准化为基础的企业架构设计目标
尽可能以标准化组件支持企业商业模式的构建，能达成这样的效果，软件对企业生产的基础性作用才能进一步增强，才能用软件大规模覆盖各类型企业的生产、管理，这正是数字化转型的前提。
数字化不是一个企业自己的数字化，而是整个行业、社会的数字化，也是所有从业人员的数字化。精炼行业级标准化构件的过程，正是业务和技术两侧同时进行数字化思维转型的过程。
数字化时代，各类企业都或多或少地转型为一家科技企业。数字化转型完成，大家走到同一起跑线，今天所谓的“跨界者”，在数字化时代将不复存在。大家比拼的是快速创新商业模式的能力，快速创新离不开快速搭建。而快速搭建离不开对标准化资产的快速利用，对要素的独特组合能力才是大部分创新的主要表现形式，重复造轮子在今天也许还情有可原，而在数字化时代很可能就真是“无情的浪费”。
可以回想下，对精益生产过程探索的动力正是对杜绝“浪费”的执着，如果软件生产想要靠近精益生产，那就从杜绝“浪费”开始吧。
四、行业级标准化的发展思路：大教堂与集市
Eric S·Raymond 所著的《大教堂与集市》被认为是诠释开源思想的最佳书籍之一。软件系统的开发模式因此出现“大教堂”和“集市”两种比喻，前者是传统的、大公司的软件开发模式，后者则是新兴的、社区化的软件开发模式。
行业级标准化这个想法，初次听起来，很多人自然会跟“大教堂”联系到一起，毕竟行业级标准化听起来就有很多“中心化”因素在其中，需要标准、跨企业共识、组织推动等等，而且，现有其他领域的标准化模式一般也都是“中心化”的，无论国内国外，国家标准都是标准层级中非常有影响力的部分。
软件行业是否会有些独特之处呢？当然会有，软件是一组可工作的计算机代码，而计算机代码的特点是，很容易“沾染”开发者的个人特点，也很容易复制。因此，软件制品同时具备“偶然性”和“难保护”的特点，也正是“偶然性”使软件的创新比现有工业制品更容易。
尽管应当保护开发者付出的辛苦，但是无论是现有专利制度的效率，还是软件保护本身给行业发展带来的弊端，都足以让所有人反思，软件行业该采用什么样的方式走向标准化，走向数字化时代。
软件行业从业者的核心竞争力到底是什么？Paul Graham 在《黑客与画家》一书中曾指出，解决困难问题才是程序员最核心的竞争力，而这种能力并非来自于对代码的保护。在国外，专利、收购、诉讼等都是大公司经常采用的保护手段，而非一个程序员可以轻易采取的手段。
解决困难问题的能力也并非是编写“前无古人后无来者”的代码，正如 Eric S·Raymond 所言，“好的程序员知道写什么，而伟大的程序员知道改写（或者重复使用）什么”。软件行业进一步发展，进入大规模批量化软件生成的数字化时代的前提条件，也许正是重新设置软件行业的管理、保护机制，推动开源“标准化”模式的发展。
为提高生产效率和软件质量，我们需要通过开源模式，提升构件的标准化程度、可用性和易用性，建立国家运营的行业级开源构件库，形成类似开源社区的机制。优秀程序员的价值既然可以通过在开源社区的影响力获得，也一样可以通过对行业级开源构件库的贡献来建立，优秀程序员依靠的并不是对他已有成果的封闭式保护。
对软件开发企业而言，企业的核心竞争力也应当是其设计和集成解决方案的能力。从这个角度来讲，构件的标准化和开源会对企业能力有更大的提升，“一招鲜吃遍天”并不是应该鼓励的发展模式。
对应用软件或者自主开发内部软件的企业而言，软件保护本就不应该是其业务的核心，软件代码不是可乐配方，一成不变的代码不会为企业带来持久的竞争力，只会随着时间的变化快速衰减。此外，架构并不是可以简单照搬照抄的东西，开放架构设计未必会让竞争对手快速赶超，不小心的追赶者甚至有可能掉进无意设置的“陷阱”。
未面向数字化时代深入思考的软件保护机制也许更多只是给行业笼罩了一层神秘面纱。“集市”方式并不适合直接孕育一套可用的软件，开源“标准化”模式的建立也需要“第一推动”。“集市”方式成立的前提条件之一是要先提供一套可以运行的软件作为起点，开源“标准化”也需要逐步建立每个行业第一套可用的标准构件库或者开源系统，然后再通过社区化方式不断发展为更具生命力的标准体系，这个“第一推动”和对构件标准体系的设计就是标准化组织的责任，这样的组织也应该是公益性的。
未来的大规模软件生产，也许正是用“集市”提供的构件建设“大教堂”的模式，基于这个认知，行业级标准化正是架构演进该有的趋势。
作者简介：
付晓岩，《企业级业务架构设计：方法论与实践》图书作者，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计，现就职于建信金融科技有限责任公司。即将发行新书《银行数字化转型》，公众号：晓谈岩说。
