企业架构是一个体系性非常强的专业方法论,在数字化转型中的应用,需要根据转型的不同阶段和侧重点,选择性的、裁剪式的使用。基于此,首要先理清企业架构在数字化转型中的核心价值,才能有效的应用。
我将企业架构的方法论的特点提炼为“全”和“联”两个关键词,“全”的含义是要素完整。企业架构覆盖到企业价值链的各业务,是对企业业务与管理的完整描述,企业架构包括的业务架构、应用架构、数据架构、技术架构等多个方面,是对从业务到系统的完整展现。“联”的含义是各要素的关联。企业架构中各要素的表述,强调业务逻辑的关联和业务流程的贯通,整体上是端到端看整个企业,无论是业务架构、应用架构、数据架构、技术架构,都是分层定义,逐层展开,层级间关联,同时业务架构各层级各要素高度关联并推导到应用架构和数据架构,应用架构与数据架构各层级也是对应关联的,应用架构与数据架构关联推导到技术架构。
作为企业数字化转型中业务和数字化统一与关联的语言,企业架构“全”和“联”从数字化落地视角上看,更像是一个企业的数字化总设图,描绘并定义了企业数字化该有什么内容、这些内容的关系是什么,以及如何演变发展,在数字化转型的蓝图建设中,体现了其完整性、关联性、管控性的三大特征,重点解决三个方面的问题以体现其核心价值。
(1) 解决管理壁垒与信息孤岛问题
企业在进行日常的信息化建设中,一种是根据当前业务管理对信息化的需要,推动对应业务的应用系统建设,更成熟的企业通过信息化规划来确定公司整体的业务管理在信息化方面的3到5年发展规划,这就确定了要做什么系统,但这个系统或这些系统之间是什么关系,反映和支撑什么管理逻辑,贯通什么样的端到端流程,其实是不清晰至少不完整的,通过是设计人员或开发实施人通过对业务管理人员的调研获得零散的关联关系,一方面,这些被调研的业务管理人员也仅仅是熟悉自己的业务,而不熟悉也不关心其它业务,其次,也是根据个体对企业和业务的认知来提出需求,可能比较全面,也可能非常零乱,这不是一个符合方法论的做法,这样背景下建设的信息系统,一定是信息孤岛。
(2) 解决技术与业务联动的问题
企业的业务管理总是在不断的优化、调整,通过变化来不断适应企业内外部发展要求,这些优化与变化点往往是离散的,大小不一的,可能是整个企业销售模式与流程的改变,也可能设计环节BOM结构优化,还可能是收款后增加了一个客户的信用评价环节等,这些优化调整点,对应到应用系统上,到底哪些需要改变,哪些不需要改变,是需要推翻一个系统进行重构,还是增加调整一个功能点,或调整后台一个数据表结构,这些调整对于中间件、对于基础设施及其容量是否也需调整,对信息安全的结构有哪些需要配套的修改,这些往往是开发实施人员根据对业务的(不充分)理解和了解做出决策建议。企业架构的“全”和“联”架构视图,能通过管理关系快速的定位到变化业务对应的应用系统点、数据结构点、技术与基础设施点,这样就能快速地将需要调整的内容进行聚焦与锁定,快速的调整后达到信息技术对业务管理变化的“随需而变”。
(3) 解决业务与技术保持一致的问题
也是由于业务架构是对企业业务管理的完整、准确反映,业务架构又与应用架构、数据架构、技术架构(有时候这三个架构统称信息架构)保持高度而全面的关联关系,因此,就保证了信息技术与业务管理的一致性,不会出现业务管理变化,信息化超前或滞后了,或信息化建设推动中,不能有效反映业务管理或不能有效推动业务管理同步发展。当然,企业架构也是一个动态发展的过程,这就引申出架构演进(企业架构随着公司战略的发展、管理的发展而不断演变发展)和架构管控(企业架构管理和约束应用系统或基层设施建设对企业架构的遵循)的概念。
企业架构(EA)无疑是企业级数字化转型与系统建设的重要方法,其价值毋庸置疑,但近年在IT界很少有企业真正采用完整的企业架构方法论进行企业信息化平台设计,我认为首先认识不到位,是大多企业并不熟悉和了解企业架构的方法,因此,在观念上认为“企业顶层规划一下就足够了”;其次企业架构方法过于严谨,操作周期长,而且是基础性的工作,大多企业等不这么久,也不愿意做不容易见成效的基础工作;第三是这个方法对参与人员要求高,无论是对业务的认识理解,还是数字技术的理解,都要有相当的水,通常企业难以找到这样的团队;第四是最后完成的企业架构需要对数字化各项目进行管控,而且需要根据业务发展不断迭代,这也对数字化管理团队提出很高的要求。此外,还有一个很主要的原因,是在互联网的时代,业务管理发展创新更快,现在更提倡“厚云薄端”、“敏捷开发”这样的架构和开发方法,倡导“以快制胜”,倡导“错了就删除重来”,企业架构(EA)这样的传统设法方法视乎不适合这个时代了。
我也不认可完全照搬按照企业架构(EA)方法进行企业数字化转型的架构设计,方法是为人服务的、是为管理服务的,需要灵活的变通和裁剪,就像管理没有绝对的好坏一样,数字化管理工作也是同样需要在各要素、各目标上平衡好一个“度”,好的数字化管理者是在数字化投资、数字化成效、数字化对业务的响应、数字化对管理变革的促进、运维的稳定性等多方面,追求最佳的平衡点。因此,正确认识和理解企业数字化战略规划、企业架构设计、敏捷开发方法等各类方法的原理、定位和优劣,并根据公司战略和当前业务管理发展的水平和要求,进行有裁剪的、有控制的综合应用,是企业信息化管理者的需要不断学习、思考和实践的。我认为数字化转型中必须用到企业架构这个专业方法论,但在具体使用中,应该区分不同的数字化转型建设的路径和策略,采用“实做”、“轻做”和“巧做”的方式,来应用企业架构方法论。
如下是将企业架构在数字化转型中的应用分为四类典型象限。
在横向上是建设方式策略,是采用成熟套装软件实施还是采用完全的自主开发系统;在纵向上,是对基础管理系统进行设计,还是针对转型创新场景进行设计。在这个四个象限中的企业架构方法论应用策略:
一象限-(轻做):采用成熟套装软件固化基本的业务管理,例如ERP、CRM、SRM等,在这个象限上,由于有成熟套装软件固有的管理逻辑会推动业务管理的优化,系统通过配置也可以快速完成,数据结构、技术架构都不需要考虑,因此,企业架构本身不需要深入太细,应该采用企业架构方法,从顶层设计上,定位好各系统的边界、明确好各系统的集成关系,确保各系统在专业性上又能促进整体业务的端到端贯通。
二象限-(实做):完全采用自主开发的方式建立企业基础的管理系统,固化基本的业务管理,这是最需要采用完整的企业架构方法论进行自顶向下建立完整、细致的企业整体架构蓝图,并通过架构管控的方式确保自主开发能最终实现蓝图。这就不仅仅包括顶层的设计,甚至通过5级流程和整体数据模型,来确定和约束自主系统的需求,以及一致的系统架构。
三象限-(无) :无此应用,或将成熟套装软件作为二次开发平台,在其上通二次开发完成创新场景。不需要用企业架构来指引和约束。
四象限-(巧做):通过自主开发建立创新应用场景,需要以企业各系统的数据作为数据源来创新,首先应从顶层定义创新应用场景在企业整体业务价值链中的位置与价值,巧用企业架构中应用服务和数据服务进行“重组”,快速形成新的创新应用场景,并与企业整体的应用、数据保持一致。
总之,企业架构是描述企业整体业务管理和及其数字化的完整方法论,企业架构方法更适用于企业内部管理体系的描述及其管理信息系统的框架,通过严谨的要素及其关联解决企业整体管理信息系统的框架与发展演进路径的问题,是企业数字化的基本盘和奠基石,在这之上基于场景和创新的数字应用以点状形式依附其上,因此企业架构并不能或不善于作为企业数字技术创新场景识别、定义和实现的方法论。
【案例分析】——建立稳敏双态的信息技术架构
某集团型企业专注大型水利工程项目,面对激烈的市场环境和企业不断的发展成长,急需打造一个覆盖公司基本业务的项目全生命周期平台。客户在系统架构和产品选型中一直纠结与犹豫是否该用全套的ERP产品,一方面认识到全套ERP产品管理逻辑严密、系统成熟稳定,另一方面又感觉企业发展快,需求快速响应市场,并不断在优化提升公司内部管理,担心成熟ERP产品过于严谨僵化难以满足企业的灵活快速发展。在我给该企业转型的信息系统架构方案中,提出了集团应基于建立“稳敏双态”的应用架构方案。做出方案依据首先是基于对该集团当前及未来业务管理的理解,其次考虑整体的实施效果与性价比,第三考虑当前业界的主流技术路线与产品,
一般来看,对于大型国企,行业与管理相对稳定,通常会选择大型成熟套装软件(SAP、oracle、Maximo、PeopleSoft等),这些套装软件管理逻辑严密、技术架构成熟稳定,将全球领先的实践引入到企业中,提高企业的规范化管理和强化管理的刚性。而以互联网为代表的创新型、快速发展型公司,由于管理的动态性和需求的不稳定性,则强调采用开源的自开发软件,通过敏捷开发和快速迭代,建立小而轻的系统,满足当前一定时期的管理要求,在管理与需求变化后,再重新迭代开发或重建。该企业既是一个典型的传统行业,其业务基本形态相对稳定,同时又是一个快速发展,希望能通过创新实现倍增式发展的企业,因此,其业务上兼具“稳”与“敏”这两个特征。如何让客户在“稳”与“敏”中找到兼顾企业信息化长期与短期,投资与效果的平衡,推荐“稳敏双态”的架构,让稳定的业务一次性被长期、稳定的固化下来,让变化与创新的业务能随需易变,以适应该企业在战略框定的主营业务下能稳定而快速的发展。
我理解该企业目前重中之重是进行以全生命周期的项目管理全贯通,实现对项目目标与客户满意度提升,通过信息系统更好地把管理思想体现在让人更容易感知到的应用之上,通过更友好、更智能、更先进的方法让这一转型更加容易理解,以及容易推动和操作。因此,我提出“稳敏双态”的应用架构,是将管理与系统结合的架构分成稳态的后台骨架系统和相对灵活的中台前台业务系统(项目管理、销售、供应链)。我提出的稳敏双态应用架构,其中“稳”指的是后端骨架系统,“敏”指的是前台业务系统和分析系统。具体如下图所示:
前台业务系统(敏态)基于一个组件平台的敏捷开发,通过采用Design Thinking加快速敏捷开发的模式,在Design Thinking中就是将管理思路通过头脑风暴中的互动、共创、用户体验,直观地将系统结合展现在大家面前。更注重顺应和符合管理思路,通过组件化平台降低开发成本,加快开发速度。最能完美体现管理与系统无缝整合的方法。
而骨架系统的采用传统SAP系统,覆盖稳定的基本财务、项目财务等核心基本的管理逻辑, SAP内在的严谨管理逻辑对及其蕴涵了管理思想对企业建立基本的管理要求非常重要,另一个方面从软件架构的稳定性和成熟性,能确保稳定的支撑核心后台业务。