|
在项目策划阶段，就需要针对组织的背景和项目需求，设计了详细的技术路径。项目技术路径非常重要。虽然技术路径的原理都是按照架构方法从战略到业务到IT的正向设计过程，但往往会结合项目实际需求在某些环节进行简化，同时对部分关键内容进行细化，以突出显示项目的实际情况，并聚焦项目目标的达成。 
按照上面的技术路线，首先开展的就是基于战略的能力分析。形成了战略分析模型。此模型我们在前述文章和视频课程中已经多次介绍过了，各位应该已经非常熟悉了。
在战略分析的基础上，结合组织现状和未来发展需求，形成了面向TO-BE的业务架构。
注意，因为本项目的目标是完成IT规划设计，所以一定要形成面向未来的业务架构，才能指导IT规划设计。我见过很多企业在开展架构项目的时候，对现状架构（AS-IS）和未来架构（TO-BE）有很多疑问，主要有：- 能不能不做AS-IS架构而直接开展TO-BE架构设计呢？
- 如果战略目标还没有完全明确，是否应先把AS-IS架构说清楚，后续再开展TO-BE架构开发？这样做是否有价值？
- 如果组织的战略经常变化，如何据此推导TO-BE架构呢？
- AS-IS架构开发要进行评审和技术状态冻结吗？如果要冻结状态，那么AS-IS应该开发到何种颗粒度合适呢？如果认为AS-IS架构也需要不断迭代而不进行技术冻结，那么又在什么时候开始TO-BE架构的开发呢？
具体到我们今天的项目，推导业务架构是为了充分考虑IT架构的现状，为面向未来的IT架构而定位需求和发现问题。基于这种思想，项目开展了IT对业务架构的支撑情况分析。
以及IT系统集成现状分析（注意，因此时聚焦的是组织的IT现状，所以开展的是IT系统的集成关系分析，不是逻辑上的应用组件集成关系分析。）
以及基于业务架构的数据流分析。架构的方法是正向设计和逐层细化的，在设计业务架构的时候，开发的架构制品都是为了能够后续有效的使用。这也是为什么本项目没有在业务架构阶段细化至流程，但是却详细分析业务-应用，以及业务-数据之间的关系的根本原因。换言之，架构项目中的每一个制品都要发挥其相应的作用和价值，在项目整体交付物中起到逻辑衔接和正向推导的作用，而不是为了形成制品而开发制品。
在针对业务架构进行分析的基础上，本项目还分析了应用架构、数据架构和技术架构存在的问题，并针对问题进行提炼形成了指导IT架构开发的信息化需求。在充分考虑战略目标、信息化需求和标杆案例的基础上，形成了IT总体架构（包含应用、数据、技术和架构治理）框架。
IT总体架构对应用、数据和技术架构的描述是相对高阶和宏观的，所以在应用架构层面，还进一步开发了应用集成关系、应用与实体软件系统关系、应用与组织矩阵、应用-业务矩阵等架构制品，并设计了若干应用架构的核心场景，从而定义应用架构在不同领域的集成和协同水平。
在数据架构开发过程中，从定义数据架构原则开始，确定了组织数据的分类，定义了主数据、业务数据和主题分析数据，形成了数据应用分析矩阵（UC矩阵），规划了主要应用场景的数据流图，并制定了数据治理机制。针对组织即将开展的数据中心建设，给出了建设数据中心的逻辑架构。
在技术架构开发过程中，为了支撑组织业务管控模式的变化，基于技术架构管理原则，确定了技术架构框架、物理层和逻辑层的网络拓扑机构。当然，架构治理和架构开发同等重要。本项目按照架构方法，从组织、流程和技能三个方面提出了架构治理要求，并建设和完成了架构存储库，在架构存储库中对所有架构制品进行了建模，并持续进行管理。可以看出针对TOGAF给出的架构制品进行了大量的补充，也剪裁掉了大量的架构制品。始终聚焦项目目标的达成和价值的创造，这才是一个真正的架构项目实施过程。 
最后，信息化规划是一个持续的工作，采用架构方法开发IT战略规划，能够保证业务和IT人员的深度参与，保持信息化规划的适宜性。但是在IT战略规划开发结束和后续的具体实施过程中，还有遵循架构治理的总体要求，不断完善IT战略规划的职能和流程，对规划方案实行常态化管理，保持规划方案的持续有效性，积极落实规划实施的监督与考核机制，按照既定路线开展建设。
|
