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