我个人的专业技术领域是业务架构，做业务架构这一行应该有11年了，就我自己的体会而言，对于大多数人来讲，十年的时间足够在某一个领域里边成为专家了，但是很多人很难有机会干这么一个细分的岗位达到10年，我很幸运，能够在一个长达七年大工程中专注从事这项工作。

企业架构这个领域其实你要体会它真的需要很多年，只不过现在很少有企业会愿意投入大量成本去做，对企业架构的理解也确实需要很长时间，但其实这件事没有哪个企业是真做不了的，重点在于是否愿意下功夫去做。这个领域的方法论研究本身已经很成熟了，所以我们现在更多的是对工序的研究，即怎么用工序乃至工具的方式让大家做企业架构时能简化起来。

最近大家又开始关注企业架构，这其实跟数字化转型有很大关系，如果没有数字化转型，可能很多企业还不会有这么大的热情。现在数字化转型培训很多，但是企业做完培训后还是很难达成一致，或者说很难把零散的数字化信息串起来。

数字化转型现在至少要从五个维度认真看：一是要朝外看，不是只看企业内部；二是要理解这是国家级转型，全社会转型，不是只有来自企业的动力；三是转型是整体转型不是局部改良；四是转型的核心在从企业转向个人；五是转型结果要从人身上直接观察，要看人的思维和行为是否也有变化，让企业里面的每个人都觉得我该学点不一样的东西了，我该改变我以前的工作习惯了，我以前的技术技能不够用了。这第五个维度才是最难的。目前业务人员只需要考虑提出数字化需求而已，但是以后对他们自己对数字化的理解的要求是远远大于现在了。

所以在这篇文章要和大家分享的内容里包括三部分：一是企业架构对数字化转型的作用；二是企业架构对企业管理，尤其是数字企业管理的作用；三是对数字人才培养的观点。

数字化转型的必经之路就是软件会越来越多。现在的企业发展趋势就是这样，大家都在朝着系统越做越多的方向走，不管你是做简单的系统，还是做复杂的系统，都会把你企业内部系统堆的越来越多。那我们如果想让这些软件进行协作的时候能清晰一点的话，你可能就需要把我们企业数字能力的建设思路稍微调整一下，从在B端做企业软件，走向把一个企业做的像一个软件，这其实就逐渐回归我们做软件的本质了：做软件不是为了搞一堆系统，而是为了让企业的能力做一个全面提升。

做企业架构有点儿像做家务，所以我讲课的时候经常开玩笑，它就跟你收拾屋子一样，你家里要下不去脚了，那肯定就得做个大扫除，要么你自己扫，要么雇个人扫，反正你都得扫一遍。其实大扫除就是做一套架构，就是一个重构，并不是因为企业软件管理水平比较差，而是规模变化带来的一种常见现象，《架构之道——软件构建的设计方法》也提到：“软件开发行业是如此混乱，以至于对于大多数开发人员来讲，常识性的基本实践可能很陌生。”其实做软件之前先做好规划，这应该是个常识，但是这种常识呢，基本上大家都不太怎么遵守。软件工程最大的悲哀是什么呢？只有对研究它的人来讲它是个工程，对于企业实践来讲就只是个软件过程，但如果你忽视那些基本的设计要求，是不会加快进度的。布鲁克斯早在40年以前就说过，40年以后还是这个样子，导致问题的行为不可能用来解决问题，所以不好好规划呢，就没法解决问题，你要克服紊乱就得做出巨大的努力。所以有的时候大家都埋怨说做企业架构累，累其实是因为你攒的活太多了，攒到了一起干才会累。

很多人分享做企业架构的经历时会讲到一些后期要面对的问题，比如说我们要把这个组件理出来，要把企业的服务化做的更清楚。那么这两件事的基础是什么呢？其实就是在业务架构梳理的时候，把流程和数据结合在一起梳理。在我们过去的实践里，我们的流程架构，或者叫业务架构跟数据架构其实是高度结合在一起的，是融合的。并且我们的业务组件是拿什么归类的呢？就是数据架构，是用数据的主题域去推的。根据数据关系列出业务组件，再把操作这个数据的业务流程关联过来，变成这个组件里的行为，就是在这一个组件里边把数据和行为都聚到一起。那么这种分析方式跟拿流程去归纳业务能力相比有什么区别呢？就是这种方式能让行为和数据更好地聚合在一起，从而有利于后边去推导服务的设计。如果单纯的流程设计不考虑数据的话，那么这个流程在设计上只是用来做理解业务的参考，并不会真按照流程去做，且后边服务做的编排跟前面流程做的调整没有什么关系，这两边也就对不上。这个就是我们常说的业务架构、数据架构和应用架构是怎么打通的。

有关企业架构对企业管理的作用及企业架构与数字人才培养相关内容，我们将在下期推送中为大家介绍。