架构三问【1】：架构规划 如何撑起数字化转型
The following article is from 张靖笙讲数 Author 张靖笙
本文内容来自资深架构顾问张靖笙老师的分享！
张靖笙老师介绍：
（向下滑动查看）
粤港澳国家应用数学中心战略拓展委员会委员
数治应用技术（佛山）研究院 院长
中国智能制造百人会专家委员
中国通信工业智能制造专家委员会委员
南海区大数据产业协会专家委员会委员
中山大学计算机工学硕士研究生毕业，曾任职于国际商业机器(IBM)中国公司、马恒达.萨蒂扬软件技术(上海)有限公司等大型全球IT公司和中国农业银行等本土企业，通过二十五年的企业信息化工作经验积累，多年从事企业数字化转型、金融科技和数字银行、数字政府、创客教育创新等领域战略咨询、应用研究、解决方案设计与培训及相关科技服务工作，已构建出一整套可有效提高学员的创新意识、创新思维和创新能力，启发学员运用互联网大数据思维，顶层设计和战略规划的方法，得到政府界、企业界和教育界的广泛关注。
获2019年中国讲师50强，2018年“广东省最具影响力讲师”第三名，2017年度中华讲师网500强等众多商业讲师名誉。
个人陆续出版专著《大数据革命》、《智造：用大数据思维实现智能企业》、《5G大时代》等畅销书作品，另参与国家工信部智能制造专家百人会《解密智能》、国家计算机技术与软件专业技术资格（水平）考试2005年版大纲审定和教程教材编写工作，参与编写《系统分析师教程》《数据库系统工程师教程》等计算机资格考试教程教材。
说到软件工程，我想起了信息产业界曾经一个很燃的说法---“软件定义世界”，这是由Gartner在2014年发布的10大战略技术趋势中提出来的，其中第8个趋势是Software Define Anything，简写为SDX，翻译成中文为“软件定义世界”。
现在，国民经济和社会生活中各个行业几乎都有计算机软件的应用，比如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量，在人类世界中软件的痕迹已经无处不在，“软件定义世界”所言不虚。
当前，十四五和2035远景目标规划的开局之际，我们要迎接数字时代，激活数据要素潜能，推进网络强国建设，加快建设数字经济、数字社会、数字政府，以数字化转型整体驱动生产方式、生活方式和治理方式变革。虽然软件工程不是数字化转型的全部，但肯定仍然要担当数字化转型的核心工作。
在数字经济发展与产业全面数字化转型的过程中，软件将要服务于充分发挥海量数据和丰富应用场景的优势，促进数字技术与实体经济深度融合，赋能传统产业转型升级，催生新产业新业态新模式，壮大经济发展新引擎。
▊ 用户需求驱动的传统软件工程
关于软件工程，业界有多个定义，比较认可的一种定义认为：软件工程研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。
软件是由计算机程序和程序设计的概念发展演化而来的，是在程序和程序设计发展到一定规模并且逐步商品化的过程中形成的。软件工程的发展大致分为4个阶段。
无软件概念阶段（1946年~1955年）：此阶段的特点是尚无软件的概念，程序设计主要围绕硬件进行开发，规模很小，工具简单，无明确分工（开发者和用户），程序设计追求节省空间和编程技巧，无文档资料（除程序清单外），主要用于科学计算。
意大利面阶段（1956年~1970年）:此阶段的特点是硬件环境相对稳定，出现了“软件作坊”的开发组织形式。开始广泛使用产品软件（可购买），从而建立了软件的概念。但程序员编码随意，整个软件看起来像是一碗意大利面一样杂乱无章，随着软件系统规模的壮大，软件产品的质量不高，生产效率低下，从而导致了“软件危机”的产生。
软件工程阶段（1970年至今）:由于“软件危机”的产生，迫使人们不得不研究、改变软件开发的技术手段和管理方法。从此软件产生进入了软件工程时代。
面向对象阶段（1990年至今）:这一阶段提出了面向对象的概念、思想和方法。包括面向对象的分析（OOA，Object Oriented Analysis）、面向对象的设计（OOD，Object Oriented Design），以及面向对象的编程实现（OOP，Object Oriented Programming）等。
传统企业信息化一般是通过ERP、CRM、MES、PLM、OA 等业务和管理应用软件系统的建设，构建覆盖企业完整业务线的信息平台，从而基于信息实现对企业人、财、物等方面的精细化管理。传统企业信息化系统的软件研发主要侧重于实现业务运行过程的规范性和合规性，这样，软件工程基本上是基于现有业务场景作为需求分析对象的，用户需求驱动是传统企业信息化的基本假设。
国外大的软件公司和机构一直在研究软件开发方法这个概念性的东西，而且也提出了很多实际的开发方法，比如：生命周期法、结构化方法、面向数据结构的软件开发方法、面向问题的分析法、原型化方法、面向对象方法等。
这些软件工程的方法形式不同、各有千秋，可都还是以用户需求驱动软件开发作为软件工程的基本假设，而用户往往是在其当前的业务环境和工作场景中提出对软件的各项需求，这本质上就是一种依葫芦画瓢的方法，以当前的业务场景为葫芦，画出信息系统这个瓢，业务信息是葫芦里的药，数据是瓢里面的水，有瓢才会有水。
虽然软件工程在指导单个软件项目的研发工作时是有效的，但我们必须看到过往企业信息化中大量的软件项目是在缺乏企业层面统一部署和统筹安排下，完全在各业务领域和部门的用户需求驱动下“依葫芦画瓢”建设出来的。
这样搞出来的软件系统，虽然也发挥出规范业务、支持管理、提升效率的作用，但由于缺失在战略和企业架构指引下建设的众多软件系统，而且在建设过程中用户需求存在局限性和短视性，遇到各种问题采用“头疼医头、脚疼医脚”打补丁的升级改进方式，因此给企业留下了大量互不兼容、参差不齐的集成陷阱、信息竖井和数据孤岛，这些软件系统虽然代码凌乱，但貌似稳定并且能勉强支撑当下的业务和管理需要，就是动不得、改不得、拆不得，往往不知道哪块砖抽掉整个房子就都哗啦啦地崩塌了。
这种没有在企业架构指导下形成的企业信息化现状，会让我们的企业信息化决策者们犹豫要不要改造，而长此以往，这样的企业信息化建设路径无论如何都无法从企业战略全局的高度推动和促进整体性转型和高质量可持续发展。
▊ 纵向到顶、横向到边的规划方法
而当我们进入数字经济时代，这种传统的软件工程方法已经明显不能满足数字化时代企业对业务运行创新和变更的要求，新的数字化时代给软件工程带来了新的问题和新的要求，并且成为严重影响转型的结构性矛盾。
下面来分析几点比较普遍性的问题：
首先，数字化转型是从企业发展战略出发的，推动数字化转型的软件工程中的技术决策和管理工作一方面要服从企业转型发展战略的需要，这需要企业掌舵人具备跟上时代技术发展前沿的数字化转型认知能力；另一方面，软件工程中一些具体的技术选型也会深刻影响到企业战略的发展走向，这又需要企业内部IT组织的决策者们能全方面掌握企业的战略发展方向和业务全局，毫无疑问，这对大部分的中国企业来说是件极具挑战的事情。
其次，数字化转型的软件工程服务于转型，本身就是以驱动生产方式、生活方式和治理方式变革为使命的。
目前，业务场景不能再作为软件开发直接参照依据，传统企业信息化那种依葫芦画瓢的软件工程方法遇到极大的不适应，提需求的业务用户讲不出数字化后的业务是怎么回事，靠用户需求驱动的软件工程方法如何能画出那些本质上还不存在的业务场景呢？这些业务场景又是从哪里来的？这些只能从企业掌门人的战略意图中推导出来，通过规划和顶层设计将未来业务发展蓝图描绘出来，而传统软件工程虽然在需求分析环节也有对业务上下文环境的分析，但明确缺乏勾勒未来业务场景的指导思想和方法能力。
再次，根据传统软件工程所定义的软件生命周期，主体工作聚焦在软件定义和软件开发阶段，在数字经济时代，数据是生产力的关键要素，企业要更关注各种数据资源的采集、分析和应用，而这些数据资源既有企业内部现有的信息系统，也有来自外部合作方和互联网的外部数据源。一方面，大量的软件项目要在这样多样性的数据环境中实施并推动一些新生产方式和商业模式的形成；另一方面，软件的运维也涉及大量的数据管理、治理、应用和运营工作，围绕数据资源边治理、边开发、边应用、边（业务）创新、边经营将成为软件工程的新常态。
由此，我们可以总结出几点总体要求：数字化转型中的软件工程必须从战略发展大局的高度、企业全局的宽度、结构性改革的深度、创新与变革全周期的长度来进行，以数字技术为抓手，以数据要素形成数据生产力为核心任务重新定位。与之比较的传统软件工程，只能说是覆盖了其中很少一部分工作。
温昱老师在其新书《业务架构 应用架构 数据架构 实战》中指出：“多年来，全球业界已在业务架构、应用架构、数据架构、技术架构方面积累了大量经验。近几年，数字化转型呼唤‘懂行人’打通四种架构，确保技术支撑业务、业务支撑战略。”
在我看来，在“懂行人”看来，这本书将不啻于提出了一个符合数字化转型要求的软件工程实践的全景图。
当我们祭出The Open GroupArchitecture Framework (TOGAF) 这个企业架构最主流的方法论时，传统软件工程恐怕只能覆盖其应用架构中很少一部分工作。
数字化转型千头万绪、牵一发而动全身，软件工程是数字化转型的核心工作，而如前分析，为了满足数字化转型对软件研发工作的新要求，必须要从企业架构的角度统筹组织数字化转型中各软件工程项目全生命周期的各项任务，这样才能纵览全局，明细战略、业务到技术三层级工作内容的关系。
俗话说“一图胜千言”，采用架构的形式，可以帮助决策者在纷繁的具体事务中快速识别出关键元素，并澄清要素之间的逻辑关系，从而帮助组织减少在剧烈变化的转型过程中很容易引发的混乱和混淆，就此而言，我认为企业架构应该成为企业未来每一个软件工程所必须依据和遵循的总体策略指引。
▊ 规、管、建、用、评五个环节
从企业架构的角度来看，我们同样必须要重新定义软件工程的生命周期。
如果我也算一个温老师所言的“懂行人”，那么我愿意结合自己在咨询工作中对企业架构方面的经验和理解，在业界现有工作成果的基础上，给出我的一点补充和调整。
我在TOGAF9.2框架的基础上，把面向数字化转型的软件工程工作内容分到"规、管、建、用、评"五个环节。
评价环节：评价代表了价值主张，这是一个既是开始也是结束的环节，愿景最终要落实到可以实施评价的成功标准和规范要求，这样才能完成战略的有效闭环。
规划环节：战略进（输入）架构出，这是规划和顶层设计的具体工作，没有经过架构设计的战略，诚如没有地图指引下带兵出征的统帅，焉有不败之理？
管控环节：业主是每一个软件工程的需求责任人，需求管理体现了业主对工程从目标到成果的管控依规，而与传统软件工程显著不同的地方，体现在业主战略发展权益的大需求，而非仅仅软件功能和用户界面的小需求上。
建设环节：这可以看成是传统软件工程方法仍能发力的环节，只是基于企业架构的建设工作可以解决传统企业信息化中“一统就死、一分就乱”的结构性矛盾，在企业架构的总体统筹下，组织每个具体部门和业务应用系统形成了一个分而不裂、散而不乱的有机整体，就像一个框架结构建筑中的功能房间，每个房间都可以按照自己的用户需求装修布置拆解组合，但是只要不破坏框架基础设施，不改动负责建筑整体结构受力的四梁八柱，就不会破坏整个建筑的可靠性。
应用环节：为了支持业务中对数字系统的应用，这里包含了系统运维、数据治理与运营管理两方面工作，分别对应支持业务连续性的IT保障、数据治理和数据资产经营工作。
为了做好数字转型过程中众多软件工程中"规、管、建、用、评"五个环节的工作，我提议每一个企业都应该考虑成立一个数字化总规办公室，从总控层面统筹安排好组织内各项相关能力和资源，在数字化转型的每一个阶段发挥好各自的作用，确保完成转型中的各项工作任务。
接下来，我打算针对企业市场中各类企事业单位对数字化转型的迫切规划咨询和实施方案需求，依托粤港澳国家应用数学中心和业界朋友资源，建构一个为业主们提供全战略周期咨询顾问服务，从战略到架构，从架构到过程，从过程到资产，全面覆盖"规、管、建、用、评"五个环节的管家式数字化转型一篮子战略咨询顾问服务。
▊ 后记
我多年老友温昱的新书《业务架构 应用架构 数据架构 实战》最近大热上市了，这本书去年8月份他曾经把手稿给我，并征询我的意见和建议，说起来惭愧，我当时手头有些忙，对老温给我的文稿囫囵吞枣翻了一遍，虽然又一次感叹于老温写作风格的图文优美、深入浅出，可对老温的书稿由于没有仔细读也就没有认真想，除了给了一两份过去自己咨询项目脱密后的交付成果供参考，也没给出什么太有价值的建议，有些对不起老友。
老温是国内久负盛名的架构师，以逻辑通畅、结构清晰的风格把对任何一个企业来说都是宏图大计的话题全景式陈述出来，这方面的匠心努力实在让我佩服。坦白说虽然我也有多年做企业架构顶层设计（或者称为信息化战略规划）的咨询项目经验，我却没有勇气像老温这样系统地写出一本关于企业架构的书籍。
在咨询项目的实战中，我们往往扎进不同企业的组织环境和千奇百怪的具体问题中，这里一方面涉及大量业主机密的细节，不敢披露；另一方面，从纷繁交织的经验材料中萃取出普遍性规律性的知识和方法，这又是一件需要极高知识建构能力的文化大工程。
这次拿到出版后的书细细品读，我也回顾了这么些年相关工作经验。这两天还和老温热烈地通过电话与微信沟通了一番，我们初步达成一个共识，传统软件工程的理论与方法已经不能再全面支撑数字化转型的需要了，非常有必要做一些创造性的思想工作，我想通过自己的想法先来抛个砖，希望能够给大家带来启发。
▊《业务架构 应用架构 数据架构 实战》
温昱 著
每一页都是实践经验的总结，参考性超强
每一页都简洁明了重点突出，可读性超强
大局＋架构＋文档，三大篇，操作性超强
本书思路清晰，每一个概念、每一项方法都给出了简要透彻的阐述。同时又结合实践，给读者看得见、摸得着的项目实感，帮助读者迅速上手。本书还有一个作用，就是能提升读者对IT及其业务的认知层次，为长远职业发展提供助力。
（扫码了解本书详情）
热文推荐