企业信息化规划建设和IT治理管控能力提升思路分享

　　今天分享下多年前我和甲方企业IT管理部门进行信息化管理能力交流的方案材料。
　　对于大型的甲方企业IT部门，当前往往有两种团队组织模式。其一是甲方人员只负责整体的项目管理，需求和集中化运维，无开发人员。第二种情况是甲方本身有需求，开发，测试，运维完整的开发团队，整个企业内部IT建设包括了外购+自主研发两种结合。
　　任何一个甲方企业的CIO或IT管理人员，往往随时都在思考IT如何更好地支撑业务目标，体现IT服务价值，从信息化规划和IT预算，到每年具体的IT项目立项和执行，建设完成和实施上线，实际上涉及到IT规划，需求管理，研发过程管理，运维管理，IT治理等诸多方面的内容。
　　今天主要分享如下两方面内容：1. 甲方企业的信息化管理能力提升建议
　　2. 企业研发过程管控能力提升案例企业信息化管控治理能力提升
　　那么对于大企业的IT部门，如何提升IT治理管控能力就成为了关键。
　　包括在和客户交流过程中，我也提出了：
　　目标驱动，需求整合，统一规划，分步实施，集中运维
　　的总体解决方案思路。其中涉及到IT规划和企业架构，需求端到端管理，项目群和项目管理，运维管理，研发过程管控等各个方面的内容。
　　简单来说，核心包括如下几个方面。
　　首先是每年的信息化规划，三年滚动规划如何做？这个就涉及到各个业务部门的需求收集，收集完成后进行分析梳理，形成信息化规划和IT系统建设实施规划，预算和资源投入规划。
　　对于企业架构和信息化规划，可以进一步参考：
　　从企业架构到信息化规划，从现状调研到架构设计的核心逻辑
　　其次就是需求本身要实现从业务需求收集到最终的应用发布交付的端到端需求闭环管理。在需求实现的过程中还需要考虑加强对整个研发过程管控的能力提升。
　　最后是IT系统建设完成上线后，如何进行集中化的运维管理和需求变更管理方面。因此整个分享材料从IT系统建设，IT规划，IT运维三个方面进行展开，具体如下：
　　企业研发过程管控能力提升
　　这里站在甲方信息化部门的角度谈下对开发厂商质量和过程的管控。
　　统一开发技术框架和环境
　　在我前面文章讲解构建企业私有云PaaS平台的时候，里面有一个重要的内容就是应用开发框架，这个应用开发框架可以理解为包含了应用技术架构（分层架构，开源组件选择等）和各种规范约束（编码规范，接口调用规范，UI规范）的一个空框架。
　　各个开发厂商都必须遵循同样的一套技术架构来开发应用，这个不仅仅是解决开发的应用能够部署到PaaS平台的问题，更多的是解决后期的运维和管理问题，也进一步加强了各个开发厂商之间的可替代性。
　　在传统的应用软件招标中往往我们只强调了开发语言和数据库使用什么，而实际应用内部的技术架构，采用的技术组件仍然由开发商控制，对于甲方来说完全是一个黑盒，不利于后期的质量和过程管控。
　　在PaaS平台搭建到一定程度后，可以看到企业内部可以复用的各种IT能力逐步成型，这既包括了各种技术服务能力，也包括了业务服务能力。形成了一个很多的可共享的服务能力支撑库。而新的应用系统必须要基于已有的各种IT能力资产进行开发，加强复用，降低重复开发。
　　这也是我们说的后续应用系统开发能够快捷反应，逐步降低开发成本的一个原因。但是很多时候面对开发厂商固有的模式，推动上往往必须有强大的执行力。
　　平台+应用，一方面是通过平台实现敏捷性和成本降低，一方面是通过平台约束上层应用采用统一的开发框架，技术架构和标准规范，从而加强后续对应用的质量和过程管控能力。
　　统一研发管理过程
　　站在甲方的思路，要加强开发过程和质量管控的最好的方式就是加强对需求方案和验收发布两端的强管控能力，对于研发过程中加强里程碑评审的能力。
　　对于项目管理而言，则加强PMO对项目群管理的能力。在支撑域中最基本的配置管理和变更管理是必须的，要注意到甲方对配置管理的层面往往高于单个应用，往往涉及到的是更加全局跨系统的配置和变更管理能力，端到端的需求全程跟踪和闭环管理能力。
　　对于甲方驱动的研发过程管控能力，可以总结为三大类，具体如下：可固化：主要是指规范，流程和相关工具的制定和采用。可管控：主要是项目管控过程中的评审，决策，沟通汇报，问题风险管理和监控预警机制。可量化：主要是指研发管理中的基础度量和KPI指标体系的建立
　　可以讲做好上面三个方面的内容是甲方逐步深入研发过程管控的一个基础。甲方的研发质量和过程管控不是要替代单个应用开发商的研发项目管理和质量管理，而更多的目的是类似CMMI三级一样形成一个适合甲方管理的组织级的过程和管控机制，从单个应用厂商本身的成熟还不足够，更加重要的是组织级的基线和成熟度。
　　对开发厂商的管控逐步打开内部的黑盒，但是要注意不是完全接管，而是加强关键点的里程碑评审和结构化决策机制。基于这个思路，另外再提下研发过程管控的一些关键点。
　　对于需求层面，我们要注意往往不是简单的统一需求方案，特别是涉及到跨多个应用系统的方案制定的时候，需要的不仅仅是需求方案，同时包括了技术方案。这个方案会约束高层的的一些总体架构设计和实现思路方面的内容，以防止后续各个应用在实现过程中走偏。
　　加强对两端的管理，包括需求方案和验收发布两端的管理，而弱化对厂商开发内部的管理，对于开发厂商内部的过程管控只需要加强里程碑监控和评审即可。以做到最基本的闭环管理。对于开发商内部的研发过程重点是制定相应的标准规范和约束，加强QA管控。
　　配置管理要形成企业级的配置管理库，各个厂商最终的研发过程资产都必须入库，要加强各种配置审计工作，同时源代码配置管理也需要逐步深入管理，方便后续的统一发布和部署流程的对接。而取代原因的开发厂商在验收的时候才一并提交验收资产的模式。
　　在纵向团队的基础上，可以考虑形成各种横向的联合性质的虚拟团队。包括易用性团队，性能优化团队，技术专家团队，业务专家团队等，以专家团队的方式来解决各个应用可能存在的共享问题，并且在解决后逐步上升到企业知识库中。形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制。这一点往往是最难的，但是又必须执行，至少需要做到定性+定量的开发商考核和评估机制。
　　通过DevOps实施来提升研发管控能力
　　对于传统企业，当大量的IT系统开发和实施都外包的情况下，如何加强对开发商的管控是必然面临的一个重要问题。其中对于稍微做得好点的企业就是实现了需求方案和统一发布控制一头一尾，确保需求正确并并高质量发布，但是缺点就是中间都是弱管理，对于中间过程监控较弱，中间过程执行偏差可能影响到一头一尾，这也是很多时候甲方项目管理存在的关键问题。
　　对于这点，在早期我也提出了很多关键思路，总结来说包括了： 打开开发商过程黑盒，但是不是完全接管，而是增加各种管控点，包括评审，决策等 需求方案：不仅仅是简单需求，而是业务方案+技术方案，防止后续走偏 跨项目的形成团队决策机制，多维度结构化决策，用数据说话而不是简单个人经验 配置管理加强，特别是后续可能接管源代码管理和集中发布部署 加强各个项目执行中的项目执行监控，必须增加里程碑点监控和评审机制，及时发现问题 形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制 加强中间过程管理，要制定各个开发商共同遵守的大中间过程管控机制 形成专家团队，做好各项评审，专家团队为虚拟团队，包括业务专家团队，技术专家团队等 通过统一需求方案+统一发布真正可以贯穿整个软件生命周期 在需求收集完后做好统一的版本规划和计划，只有这样才能变为由计划驱动的发布。
　　在原来推持续集成的时候，我们还有一个重要目的就是能够打开开发商的黑盒，加强对中间过程的监控和管理，让质量问题及早地暴露出来，方面后续甲方能够顺利的接管运维。
　　从这个目的来看，完全是和当前的DevOps思路是吻合的，即协同好技术，质量和运维三者之间的关系。对于甲方如果作为后续运维方，那么从一开始就介入到整个IT系统开发和实施的全生命周期管理过程中。
　　在DevOps思路实施中，仍然注意要推进两个重点：
　　其一是组件化和微服务架构。
　　其二是和PaaS云和各种工具集成实现整个过程的自动化和流水线作业。
　　在实施DevOps的时候，我们对开发商可以提出更多的方便后续运维和管控的要求，从一开始的开发环境，开发框架，单元测试，代码静态检查，持续集成工具，服务接口标准，配置管理环境，版本发布规则，环境迁移规则，包括甲方需要做的各种质量方面的人工审核和检查，这些内容都可以嵌入到整个DevOps流水线作业中。
　　在这种情况下，开发商从一开始提交的代码，代码的质量，单元测试的结果就全部可视化给甲方和客户，开发商想在这块藏着掖着就相当困难，这既方面了一开始就监控和暴露问题，同时也方便了后续基于整个代码质量的检查和工作量，规模的度量体系的建设。
　　对于开发测试环境，开发框架和工具，配置管理等从开发商自己管理到迁移到由甲方统一配置和管理将极大的提升甲方对开发商的管控力度。虽然在前期推行涉及到甲方和开发商本身的技术能力和成熟度是否能够达到，以及开发商本身对该方式的抵触思想等，但是整个趋势应当如此。
　　这也是对于无开发人员的甲方信息化部门建设和实施DevOps的真正价值。对于企业实施DevOps的收益价值和难点分析可以进一步参考我下面这篇文章。
　　企业DevOps实施收益价值和难点解析