企业架构建设思考碎片

需要明确进行企业架构建设的定义

官方文件中是xxx的一件事情，始终没有触及本来目标。需要以通俗、明白的语言阐明其定义。

我认为进行企业架构建设是一件不易快速见效的大计，如果建设得好，可能在后续十年中能够受益，而当下可能并不能立刻见到效益。所以，我认为这件事情在其最后完成落地时，本身带来的效益可能只会体现百分之三十。

需要承认，不可能抛弃当前的业务发展和项目建设，另起炉灶单独进行一套全新的企业架构建设，必须在当前项目的实施中进行实践、提炼；但是，有另外一点需要额外强调，那就是，当企业级架构建设与当前项目建设产生相互冲突时，比如，有一个项目有工期的要求，而如果在项目建设的同时综合考虑企业级架构建设的要求，可能延期，那么此时我认为必须以企业级架构建设为重，要有牺牲局部成全大局的视野。

说回目的，需要明确的是企业架构建设不仅是瞄准当前的顽疾，而且是瞄准未来发展面临的问题的，所建设的架构必须能够在未来的一段时间内不经过大的调整，即能适应时代的发展提出的新要求。这里所说的，即这个架构必须具备一定的适应变化的能力，在能够想象到的变化下，这个架构能够满足新变化下提出的各种要求。

需要明确范围

提到企业架构，那么，就不仅仅是IT架构，必然涉及到业务架构，甚至可以说，更重要的是业务架构。而一旦涉及到业务架构，就不可避免的涉及组织架构。

结合上文提到的适应变化的能力，那么这里讨论的架构，从不是非常基础的层次上，必须是能够适应变化的，更进一步的，这里讨论的架构，不是某种将要形成的固定的组织存在或者系统组成存在，而是一种理念，一种风格。这种架构理念和架构风格，是面向变化并且能够适应变化的，更进一步地，这种架构可能是一种持续变化的架构，不存在一个长期稳定的形式，其天然的处在动态调整当中，而这种动态调整，组织和系统都不需要付出太多的成本，或者说只需要付出轻微的成本。为了达到低成本迅速、持续动态变化的目标，组织和系统必然在底层具有坚实稳固的基础支撑其做出动态变化。

组织形态的调整

延伸开来，为了满足这种动态调整，组织中的每一个小的动态单元（这个单元最终可能是个人，也可能是一个小的团队）需要具备快速适应这种动态调整的能力。因此，人员能力的培养和组织形式就显得十分重要。首先，提到的这个小的动态单元不可能十分巨大，一般地，按照已有的经验，不应该是一个超过7-10人的队伍，这样的队伍能够在内部形成比较强大的内聚性，协作沟通的成本比较小。其次，这里的动态单元必须具备快速适应动态调整的能力，因此，这个动态单元其能力必须是全面的，与业务或者其进行的当前工作解耦的，不能是当前的某一个单元被调整至其他的项目建设或者系统建设后，其能力不满足。必须指出，为了达到这种能力，所提到的这种动态单元，其内部构成必须是全面的，即是一个完备的独立作战单元。为了达到这种要求，需要进行简单的罗列：架构师（资深技术）（1）、产品经理（1-2）、前端开发（1-2）、后台开发（2-3）、测试人员（2-3）、SM（1）(工程流程维护及事务性外部对接)。

流程及实施规模的调整

为了适应这种所提出的小作战单元的基本组织形式，当前的若干流程必须做出调整。当前的需求落地流程（从需求提出到落地运营），我认为有不常被明确提出的三个短板。

第一，在需求的初始阶段，没有合格的需求规划能力。第二，在运营阶段，运营能力还停留在“农业时代”。第三，在需求的落地阶段，流程间的间隙造成的时间浪费以及为弥补这些浪费而做出的努力消耗，使得在IT实施过程中战斗能力不能被充分发挥到应有的地方。那么新提出的流程，就必须对这三个问题提出保证，使得这三个问题能够依赖于流程得到限制和解决，而不是依赖于人的能力及其主观能动性。

实施规模的调整，在当前的思考中，主要有两点。第一，不能频繁出现跨单元的管理，例如，某个项目的项目经理是TEAM A的产品经理，而该项目的实施由TEAM B 和 TEAM C 完成。第二，项目必须是足够小的，不能也不必要出现若干个单元需要同时协作才能够完成的项目，这里根本的考虑是如果需要多个单元同时协作完成，那么单元间的协同以及沟通管理将是一个难题。（这一点还值得考虑，是否多个单元间的协同管理真的无法解决？）

IT实施原则的转变

有一个在在银行IT发展中长期贯穿的现象，那就是采购基础IT能力，从10年代提出的去IOE开始，银行业开始意识到采购基础IT能力对自己发展的制约，从而转向分布式，而由于在分布式领域几乎没有积累以及后续在这一领域的积累受制于当下的制度及流程，使得其最终走向在云计算时代，仍旧采用采购基础IT能力的老路（需要说明，这里的基础IT能力，不仅包括广义上物理的计算资源及其管理能力，事实上这部分本就应当是采购的，还包括了例如PASS平台，数据中台软件基础）。本质上，主机、小机时代对厂商的依赖，在云计算时代只不过换了一种形式存在，发展都最后，银行都面临由于在基础IT能力上的不足受制于厂商而影响发展效率的老路。影响发展的缘由不仅仅是能力上的不足，还存在于为了弥补这部分不足和管理厂商而制定出来的制度补丁，在加入本来的治理体系后，引起的流程混乱、职责不清、效率低下以及实施反复。