β

谈传统企业IT架构转型(8.9)

人月神话的BLOG 20 阅读
在6月初已经基于《企业IT架构转型之道》写了两篇笔记,可以先参考:

读书笔记01:
http://blog.sina.com.cn/s/blog_493a84550102wv5w.html
读书笔记02:http://blog.sina.com.cn/s/blog_493a84550102wv6n.html

这本书基于阿里的中台战略,服务中心,SOA服务治理给出了相对多的最佳实践,也给了传统企业转型很多有借鉴意义的思考,但是对于传统企业IT架构转型还是有许多问题值得思考。

企业IT架构为什么要转型或优化调整

传统企业内部信息化部门的核心目标仍然是基于业务驱动IT的思路,通过IT规划和应用的建设更好的支撑企业业务流程,IT本身的价值都体现在IT系统建设对业务核心价值链的绩效提升和增值上面,而不是体现在各种先进技术的应用,技术只是工具手段,最终业务能力提升才是最终目的。

企业信息化推进可以理解为三个阶段,第一阶段是基础应用建设解决基本的业务和流程协同自动化,提升基本的效率;第二阶段是提供管理层的管理能力,实现基本的业务全流程协同和管控;第三阶段则是到了决策层的辅助决策和商业智能能力。

虽然我们一直在强调业务推动IT,但是了二和三阶段,你会发现往往强势的IT部门会反推业务进行优化和变革,这也是在传统企业经常会碰到的现场。

企业IT架构为什么要调整?核心原因仍然是在业务敏捷性和IT成本投入上。

首先是企业业务高速发展,IT系统的建设和能力无法匹配,这里面包括了业务功能,接口,性能,安全的匹配;也包括了对于有新的业务开展如何快速的迭代和版本升级后的变更匹配。在业务系统不能提供快速,准确,高性能和高易用的功能时候,往往IT就成为业务发展的瓶颈,业务人员也花大量时间在系统响应等待,数据协同等待,变更功能需求开发等待,数据核对等大量事务上面。对于如何更加敏捷的响应业务这个问题,我们就需要去考虑哪些是通过IT架构调整能够更好的解决的。

虽然我们常说是SOAC参考架构的思想,但是和制造企业的敏捷和柔性生产思路完全一致,即面对前端需求的变更,我们如何做到整个IT应用的柔性和快速响应能力。

其次就是信息化部门经常遇到的问题,业务系统越建设越多,很多相同的业务系统还3到5年就换一次,反复建设和重复投入,各种服务器,存储硬件资源也大量购买而利用率低下。对于外包给供应商开发的业务系统后续自己无法运维管理,只能依托和受制于厂家,系统间的交付和接口也越来越复杂,很难真正看得上整个信息化建设后的全局应用架构视图,以及IT对业务当前的支撑情况,包括差距分析等。

而这些问题最终都体现在能否通过IT架构的调整和统一规划,来尽可能的建设IT建设和运维期的重复投入,同时能够将已经建设完成的企业应用真正变化为企业能够自主掌控的IT资产。

企业IT架构优化做的目标

当我们和传统企业交流的时候,一定要避免两个方面的问题。一个是企业直接就提出需要参考互联网企业做法,要做企业内部私有云,要参考工业4.0的做法建设大数据平台和ESB平台等,或者还有直接就提出要实施容器化技术和微服务架构;还有一种情况就是我们在没有了解企业当前业务和IT的现状和问题的情况就直接先入为主的方式给客户推广某种主流技术和产品,这些都是双方应该避免的做法。

IT架构优化的目标一定是为了解决前面说的两个问题。

第一个问题:业务敏捷性和响应能力的提升上面,要解决这个问题就必须要考虑IT架构如何更好的基于SOA参考架构进行分层,真正将共性业务和技术能力下沉,变成服务中心和能力中心,同时各个中心暴露可以高度复用的能力接口,那么上层业务在新增或变革的时候,我们就很容易基于已有能力进行组合和编排。

你要做到这样,正是SOA核心思想,即首先要找到可复用的业务组件,同时将业务组件能力通过服务化的接口暴露出来,通过这个做法也正是阿里说的中台战略和各中心建设的核心思路。

第二个问题:如何节约成本,我们在考虑应用层组件和服务复用的时候本身已经节约了成本,但是到了IT建设阶段还可以考虑的就是资源层如何规划提升利用率(IaaS平台),平台共性能力如何集中建设并复用,避免重复建设(PaaS平台),后续功能如何灵活扩展而不是全部要新建系统(微服务架构和组件化),如何更加自动化的监控和管理整个业务环境(IT管控治理,DevOps,运维自动化等),当这些问题都思考清楚后,在如何降低成本上面的目标和思路也就清楚了。

企业IT架构转型的实施策略

企业IT架构转型一定要明确清楚相关的业务驱动力和业务需求,同时在转型实施过程中还需要有企业当前本身的IT治理水平相匹配,而不是盲目跟风各种互联网先进技术。企业在信息化发展到一定阶段后,往往随着业务的高速发展,IT建设已经无法满足和快速响应业务需求,这个实施转型驱动力是最大的。

但是在IT架构转型过程中,不是对原有IT架构的完全否定和推翻重来,而是应该考虑如何在转型过程中对业务的影响最小,已经如何尽可能的复用已有的IT资产,这是IT架构实施过程中重要的实施策略。

对于传统企业IT架构转型,其最终要达到的目标仍然是我前面大量的SOA和云计算思想在企业内部的应用,企业私有云PaaS平台建设,平台+应用的构建模式,微服务架构+DevOps的全程贯通等。整体来说实施策略可以分为如下几个大的步骤:

横向统一:基础和共性能力下沉

对于业务系统中的共性能力下沉是SOA参考架构和私有云平台中平台+应用的核心构建策略思想。对于传统企业内部横向统一就包括了几个核心内容,第一个就是底层基础平台的建设,包括了4A平台,公共流程平台,基础主数据平台等,而对于上层则包括了统一的用户门户,统一认证和单点登录等。

因为这些内容都是偏技术平台的内容,因此这些共性能力的提取对已有的业务系统相对影响最小,同时在统一平台化建设后,在后续新规划的业务系统中就完全可以复用。

纵向统一:软件工程和研发管理

对于纵向统一包括软件工程和研发过程管理两个方面的内容。对于软件工程本身包括了开发框架,技术框架,主流技术,服务接口标准,单业务系统架构选型,分层模式等常见的软件工程域的相关内容。同时也包括了持续集成和当前DevOps实践方面进一步的要求等。

对于研发管理则包括了标准的技术标准规范,UI/UE规范,开发规范,测试规范的统一。同时也包括了业务系统在交维后的ITIL标准规范流程等方面的统一,安全管理标准规范的统一等。

内部统一:业务能力组件化和模块化

在上面两点统一后可以看到,剩下的就是业务系统的各个业务模块了,那么要做的事情就是如何让业务系统内部的各个模块进一步的组件化和服务化,逐渐变化到我们常说的微服务架构,并且对于传统业务系统的概念逐渐消亡,更多的就是基于平台上建设了不同的多个微服务模块,微模块模块可以朝上层灵活组合各类应用。

对于微服务架构的实施,我前面已经专门有文章讲到过,企业IT能力成熟度如果没有达到一定阶段,实施微服务架构往往是增加了整个IT开发和后续管控的复杂度,因此对于微服务架构的实施核心建议策略也是需要从单独新的的业务功能模块逐步开始,或者从已有的共性基础能力剥离开始,而不是完全推翻原有业务系统。
作者:人月神话的BLOG
原文地址:谈传统企业IT架构转型(8.9), 感谢原作者分享。

发表评论