今天准备谈下IT规划咨询的核心方法论和思考逻辑。在这篇文章我不会详细的去谈当前主流的企业架构方法论理论框架和内容。而是根据多年IT咨询实践，将一些关键逻辑点和你分析。
01 为什么要谈核心IT规划和咨询逻辑
可以毫不客气的讲，大部分的做IT规划咨询的人是不具备进行全局架构规划咨询能力的，这个一方面是需要你有大量业务和技术双领域的实践经验积累，一方面是需要你真正做过大型的咨询规划项目并在这个过程中将实践内容，各个架构之间输出关系想清楚。
系统学习下类似TOGAF课程当然有用，但是这不代表你具备了咨询规划能力。
理论可以指导实践，但是没有通过自我实践证悟的理论没有价值。
很多IT顾问完全叫PPT顾问都不为过，完全拿着已有的咨询规划模板到处套内容。如果你本身做同一垂直行业，比如拿着某家电制造行业的规划输出去给另外一家做咨询。这种场景下基本还能够像模像样的的输出一个规划报告。
但是生搬硬套最大问题就在于，你即使有了输出结果，你也无法自己详细论证清楚这个结果如何分析得来的，即无法实现自我论证。
类似的场景，我们可以看下讲课和培训，很多人能力强但是怕讲课，即虽然这类人可以快速的输出结果，但是具体是如何分析和解决问题的过程，这个确出来没有考虑过系统化。因此这类人本身能力也很难做到很好的知识分享和转移。
比如我们常说的架构规划里面这个业务架构图如何一步步形成的？这些接口你是通过什么方法一步步的分析识别出来的。这些问题大部分人无法清晰回答。即使对于TOGAF，我们也很少从官方材料里面看到类似业务架构，数据架构，应用架构和技术架构之间的内在逻辑关联在哪里。
整体规划方法论
IT规划涉及到咨询方法论、流程管理和分析、信息架构、应用系统分析和设计、技术架构、项目管理和实施等众多方面的内容。从企业战略到业务目标，从业务目标到IT目标，从IT目标到应用蓝图，从应用蓝图到分阶段实施落地，任何一个步骤的脱节将导致规划内容无法落地。
再完美的规划和架构，如果脱离企业业务目标，都不能带来企业业务价值的提升。此外，IT规划之难，不在于IT本身，而在于流程；不在于技术本身，而在于业务。
业务驱动IT是核心
对于IT规划，遵循的思路主要是：从业务到技术，从流程到IT，围绕价值链分析和优化的核心模型往前驱动。核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键步骤。
现状分析包括业务现状和IT现状，根据企业战略提出业务目标和发展规划，分析现状和目标之间的差距提出和整理问题集（定义IT建设目标），根据差距和问题给出规划蓝图，根据目标和问题分解到的子目标和子问题以及蓝图规划内容，多维度评估和确定后续的实施规划，定义IT系统建设实施的优先级。
IT规划始终围绕业务和IT两条线展开和协同
从以上的描述可以看出，整个IT规划始终围绕业务和IT两条主线，业务包括了业务流程，业务数据，岗位组织和角色，业务管控体系；而IT包括了数据架构，应用架构体，技术架构和平台，基础设施建设。业务驱动IT，端到端业务流程最终落地到应用系统的功能上，业务数据最终映射到数据模型并沉淀到数据库中。
各类架构标准规范体系和最佳实践是关键输入
随着各种思路的不断融合，IT规划核心指导思想应该转化为企业架构层面。
企业架构的提出，主要是为了解决业务和IT“两层皮”的问题，企业架构整个方法应该融入到整个IT规划思想中。此外，核心业务模型和业绩标准作为核心指导思想，虽然有裁剪，但是必须参考，如供应链SCOR模型，产品研发IPD方法论，项目管理PMBOK体系，战略和人力资源的平衡记分卡，CRM的4P和4C，财务域的核心模型等。
针对不同行业可能又有不同行业的业务标准和模型，如电信行业的eTom业务模型等。
与此同时，在前面基础上再融入云计算和SOA的核心思想，它将很好的解决我们多年前IT规划经验里的多个竖井式IT系统的集中化和协同化的问题。若现在规划仍走以前老路是不妥当的。那么，今天规划重点在开始之初就应该考虑集中化和协同的问题，将SOA思想融入到IT规划当中。当今的信息化规划，要务必避免出现IT重复建设和信息孤岛，流程断点和业务无法协同的局面。
02 中台和微服务发展趋势下，原有规划是否调整
可以很明确的讲在新的中台和微服务发展下，原来的企业架构相关方法和内容必然做出调整。比如在我最近中台规划思考里面提出了业务架构和应用架构合并，基于SOA思想增加中台 服务 前台的分层逻辑规划，单独增加服务架构规划，在数据架构规划中增加数据库拆分规划等。
以上内容后续我会专门写文章来进一步详细说明。
调研和现状分析
现状分析的核心思路是把战略目标、业务目标调研清楚，如果客户不清楚我们可以给出参考目标；其次是把实际的现状了解清楚，如客户现状流程、IT支撑现状；最后是将潜在问题识别清楚：一是在当前目标和当前现状被识别后客户意识到的问题，二是在我们提出参考目标和业界实践下，客户意识到潜在存在的问题。
对于整个调研仍然要体现业务驱动IT，从业务流程和IT系统两个方面入手，但是最终两个部分内容不能散，在调研阶段还需要完成当前的IT系统是如何支撑现有业务的分析。
一个完整的调研阶段流程逻辑如下：
业务流程和现状分析
业务现状分析重点在于业务流程和业务数据上，建议采取自顶向下逐层分解的方法，找到关键的几个端到端流程为主线进行逐层分解，分解时抛开业务部门的隔离，IT系统的约束，进行跨业务域的流程分析和梳理。
在流程分析和梳理的过程中进一步分析子流程和活动，业务组件和数据，跨业务域的协同和交互等一系列问题。业务分解的方法可以参考价值链分析方法，业务模型可以参考针对各个业务域的一些标准业务参考架构和模型，如供应链的SCOR模型，电信的etom模型，研发领域的IPD和PACE方法，CMMI成熟度模型，项目管理知识体系，营销和客户关系管理模型，财务域标准模型等。
IT现状调研
IT现状包括现有的IT应用系统现状和功能架构，IT基础设施架构现状，IT系统对业务现状的支撑情况分析等。重点的是理清业务和IT的关系，IT对业务的支撑度。现状分析的目的是为提出后续业务目标和IT系统规划建设目标打基础，明确了建设目标才能够真正为业务服务，体现业务价值。
调研完成后的输出内容覆盖四个方面
在调研完成后的输出如上图包括了业务流程，业务数据，系统功能，接口集成和部署四大方面的内容。而这四个方面的内容刚好是我们做后续四大架构规划的基础。
差距和目标匹配分析
有了以上现状分析和调研，才谈得上差距分析。
差距分析包括了当前目标和当前现状间的问题和差距分析；业界参考目标/最佳实践和当前现状下的差距分析；IT现状对当前目标支撑的差距分析；IT现状对参考目标和业绩标准的差距分析。
差距分析清楚后得到双方认可的最终业务战略目标和业务子目标，由业务目标传递到对应的IT规划和建设目标，而后续的IT规划即解决两个问题。
- IT建设解决当前业务和IT间的差距（无新业务战略下你如何更好支撑）
- IT建设解决后续战略目标和IT间的差距的问题（新战略下你如何扩展支撑）
对于目标提出而言，有两个途径。
其一直接提出业务目标和IT建设目标；
其二是通过差距进一步细化目标和有针对性的目标，特别是IT建设目标的提出，必须进行差距分析，因为IT建设重点就是支持业务目标，那么所有现存的IT建设和应用架构中无法支撑的部分都是差距，IT规划建设就是要解决这些差距。
改进也同样的道理，有些是不需要业务改进直接进行IT建设和改进，有些则是业务优化和改进先进行，IT配合业务优化改进措施的落地。从这个思路基本也就清楚BPR的考虑和定位，并不是所有场景都一定要让用户进行BPR。
通过差距分析得出的目标是多个子目标，是一个目标群，正如我们面临的问题是一个问题集一样，多个子目标的分阶段，分步骤实现最终才可能完成一个大的业务目标。
目标分解，问题分解，目标和问题映射最终形成一个完整的解决方案。这也是为何我们说，在大的IT规划中一定会涉及到组合管理，项目群管理方面的内容，目标分解到子目标，子目标最终落实到具体的项目，通过项目规划和建设的方式推动实现。
这个本身我和前面文章谈到的咨询类方案成为的思路完全一致。
第一阶段：问题分解和基础素材对应
在这个阶段重点就是将目标分解为子问题，然后将论据映射到对应的子问题上。
在这个过程中你已有知识库积累可能不足够，这个不要紧，那么需要你进一步学习，进一步上网搜索资料，对资料进行分析，同时将没有的素材论据全部要清理掉。
最后留下的就是能够完全支撑目标的有用论据材料。
第二阶段：粗粒度对应，进一步排序和整合
到了第二阶段做什么？简单来说就是要做抽象和归纳的事情了，即进一步对你的材料进行整合和归纳，形成大块的解决模块，然后将解决模块对应到子问题域。
在解决模块形成过程中，我们还需要对素材论据进行优先级排序，确定材料的重要性，哪些在最终呈现的时候应该放在前面，哪些应该放在后面等。
第三阶段：进一步归纳并从归纳到演绎反转
前面三个论据形成了，但是仍然比较散。因此我们需要进一步进行归纳，将其形成一个完整的整体，不论是静态的金字塔结构，还是动态的流程结构都需要看到，你最终的解决方案中各模块必须首先是一个整体，不能散。
从流程分析到业务架构和数据架构
经常看企业架构输出的可能会注意到，对于完整的业务架构输出而言可能并看不到具体的流程图。这是因为实际上业务架构中的每一个小方框都可以是一个完整业务流程。
比如你在一个完整的业务架构图里面会看到有合同签订，采购需求的小方框。而这些本来就是独立的业务流程，你完全还可以自己画Level3到Level4级的流程图进行描述。
03 类似上面的业务规划图如何构图出来
大部分人实际上缺的正是如何形成上面的业务架构完整构图。在整个业务架构和数据架构规划里面我们看到，核心仍然是从最顶层核心价值链开始驱动，逐层分解的端到端流程分析，跨业务域流程分析。
可以看到，虽然不同类型的企业核心业务流程都存在差异，比如类似电信运营商，电网公司和实际的传统制造型企业，那么核心业务上肯定有差异。但是核心价值链思想无差异。
核心价值链思想一句话描述就是：
接收市场和用户的需求，将最终的需求转变产品或服务并交付给客户的过程。
你可以是重资产企业也可以是轻资产企业，可以是服务类也可以是制造类企业，可以是传统企业也可以是当前的互联网运营企业，但是最终价值核心思想不变。
那么我们可以看一个我多年前画的一个电网类企业的价值链模型图：
这种价值链模型就可以理解为企业的核心顶层流程视图。通过该视图你再去分析企业核心的端到端业务流程，去分析跨业务域的一些流程。比如：
- 工程项目建设的端到端流程（最长的一个流程）
- 供应链跨域流程
- 财务的概预核决流程
- 客户全生命周期服务流程
为什么要去梳理这些端到端和跨域流程？
我前面已经谈到一个重要观点，即对于你熟知的行业领域你可以直接拿出结果，类似上面的业务架构图，但是对于你未知领域，你必须通过详细流程分析得出结果。
流程分析后，你会发现里面有流程图里面有业务活动，而这些业务活动就是最终会体现到业务架构图里面的业务功能单元。流程分析中可以识别出关键的业务对象和数据对象，而这些就是体现到你后续数据架构里面的关键内容。
这也是我经常强调的一个点。
从顶向下的流程分析是找到关键业务单元和数据单元的过程，而业务架构规划和数据架构规划是对单元进行归类，汇总，朝上进行聚合和抽象的过程。
只有这样才才能够真正解释清楚你的业务架构是如何得来的。
比如我们基于价值链已经看到供应链跨越流程，那么我们可以对供应链流程进行梳理。
梳理完后你会发现，输出的职能带流程图中的大阶段刚好就是你业务架构里面的业务域或业务单元。或者流程图中的业务活动刚好就是你业务架构分解到最底层的业务功能模块。
即当我们流程分析到最底层后，我们就可以抽象输出一个最底层的业务架构图。比如对应供应链和采购管理，我们可以输出到最底层的业务架构图或业务组件图。
04 流程梳理和分析究竟应该到多细粒度
流程梳理从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。
第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来，如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。
因此高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。
从业务架构到数据架构
流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。即我们谈到的业务流程分析和梳理还会识别和产出另外一个关键内容，即业务实体和数据单元。
流程中的业务活动可以是产生数据单元，也可以是对数据单元属性状态进行变更。
比如采购订单制作和提交业务活动，自然这个业务功能就会产生采购订单这个关键数据单元。而对应采购订单审批这个业务活动，则仅仅是对订单审批流状态进行变更。
数据架构贯穿业务和IT两个层面的规划
对于企业架构里面的数据架构规划，大家可能会有一个疑问，即数据架构究竟是偏业务层面的内容还是偏IT规划层面的内容，今天在此进一步说下我的看法。
即数据架构规划是一个贯穿业务和IT两部分规划的内容。即在业务阶段你可能只做到数据域划分，核心的数据概念模型和主数据识别。而到了应用架构规划阶段，你就需要进一步对数据进行逻辑模型和物理模型的设计。
在业务层面数据架构规划做到识别关键的业务对象即可。而到了技术层面数据架构规划必须细化到具体的数据库表和表里面的核心字段定义。
数据域-》数据概念模型-》数据逻辑和物理模型
数据域和数据分类是数据规划的顶层，这个时候如何确定数据域？
简单来讲如果你所在的行业有标准的数据模型标准，那么参考业界标准来做，比如电信行业的SID数据模型分类。如果没有标准，那么业务架构规划里面核心价值链模型的业务域即是数据域。
从这个图我们可以看到大的数据域实际和我业务域是完全对应的。
数据域出来后，我们可以对单个数据域再进行细化分析，这个时候就到了单个数据域里面所有和业务相关的业务对象和数据对象的识别，数据的概念模型定义。
比如对于供应链数据域，我们在完整梳理了供应链业务后即可识别出所有的业务对象，然后对这些业务对象单独拿出来进行数据建模，并分析数据对象之间的关联和依赖关系。
因此数据架构规划需要关注数据分域，数据对象和主数据识别，跨业务模块的核心业务单据数据。数据的问题最终都将对应到应用架构和信息架构，SOA解决的是业务集成和协同，而数据集成是有其它系统解决方案，包括BI，数据中心，MDM系统等。流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。
应用架构和集成架构规划
IT蓝图规划包括了业务架构，信息架构，应用架构，集成架构，技术架构和 IT基础设施架构等方面的内容。特别的是，IT规划蓝图包括了业务架构，业务和IT是密不可分的。所有的蓝图规划都自顶向下，逐层分解，相互融合和协同。业务架构重点是在流程，信息架构的重点是在数据。
而对于IT方面则包括了应用架构，集成架构，技术架构和IT基础设施架构。应用架构在最上层，而集成和技术架构在平台层，IT基础架构在基础设施和物理资源层。从现有的云和集中化趋势来看，更加需要考虑基础设施和平台层的集中化建设，上层的应用架构重点集中在应用和功能层面，体现业务组件化和能力化，体现业务组件本身的独立性和可集成性。
业务架构和信息架构最终要落地到应用架构中
- 业务架构体现到具体的业务组件和功能
- 而信息架构落地到具体的数据模型和数据库设计
如果再落地到具体的系统分析和设计，即演进到应用系统中的高端架构设计，包括用例模型和逻辑模型，用例模型体现业务和流程，逻辑模型体现信息和数据。
以上分析后，将推进到应用架构规划领域。很可惜的是，在大多数的规划项目当中，业务架构和应用架构出现了严重脱节，两阶段之间出现断层，没有通过科学的分析方法在两者之间平滑的进行映射。这里进行着重的强调，在应用架构规划时，首先进行总体应用规划，应用架构和业务架构对应，但不一样的地方是，流程优化分析和业务架构不会考虑太多应用平台层面的内容，而应用架构必须考虑。
其中两大核心就是集中化和协同，两大技术就是云计算和SOA。
这些内容需要引入到IT总体应用架构规划中。谈到传统IT建设呈现竖井式，相互之间协同难的现象，在引入SOA思想后并不是没有竖井现象了，一个个核心的业务组件和能力提供单元还是独立的，但是应用层中共性的内容完全下沉到最底部，并提供互相集成的机制。
应用架构规划需要体现逐层展开的核心思路，总体应用架构清楚后将细化到第二个层次：功能架构和集成架构。这个时候细化相当重要，真正解决业务目标和业务功能的落地问题。功能架构包括功能模块和具体核心功能点，这些梳理出来后我们需要明确当初提到的业务架构和业务需求在功能架构中如何落地。其次，以某个应用为核心，来观察该应用和外部应用间的集成关系以及集成后如何协同。前者为功能性需求，后者为接口需求。
应用架构如何形成？
可以看到应用架构基本是和业务架构对应的，只是有两点差异
- 其一是增加了非业务相关的技术平台内容和上层类似门户集成等内容
- 其二是对业务架构中的业务域可能出现拆分和合并的过程
我们先拿一个应用架构规划做说明：
从图里面可以看到底层增加了类似门户，SOA集成平台等非业务内容。但是整体应用划分仍然和业务架构规划对应和匹配。在这个时候的差异点往往体现在业务到系统建设的合并和拆分。
比如对应供应链业务域，我们是建设一个供应链系统，还是建设类似招投标，采购管理，物流平台等多个子系统。而这点实际和企业本身的业务组织架构关系很大。但是到了当前微服务架构思想下你可以看到，一定是安装业务架构底层最小业务域单元进行微服务模块拆分。
应用架构规划仍然会体现分层，到了最底层即回归到我们单个系统的功能架构设计。比如对于供应链管理，我们最底层就是系统的功能架构图，如下：
05 为何如此强调CRUD分析？
不论是在业务规划阶段，还是到了应用架构规划阶段，随时都存在CRUD矩阵分析。
信息架构与业务、应用的映射涉及几个矩阵分析，在业务架构阶段重点的是业务对象和业务流程、业务组件、业务功能间的类CRUD矩阵分析。
而在应用架构阶段重点则会是逻辑或物理模型对象和具体的应用模块或应用功能间的矩阵分析。两者关注层面不同，前者重点是主数据的识别和业务组件的分析，而后者的重点是应用功能模块的划分和模块间集成接口的初步分析。
在应用架构阶段的CRUD分析有两个关键点。
- 其一，某个业务功能究竟划分到哪个系统更能够实现松耦合
- 其二，某个数据对象其Owner究竟属于哪个系统能够实现松耦合
当前我们经常看到企业实施微服务后，微服务模块间大量的接口网状调用，导致各个模块间耦合更紧，这就是典型的微服务模块拆分时候没有做好类似CRUD等分析导致。
06 继承架构规划-接口服务从何而来？
这个也是大部分做IT规划咨询的人没能搞清楚的问题。
即知道有这些接口，但是这些接口和集成点是如何一步步的分析和识别出来的不清楚。
我们先思考下为何会出现系统间集成？
简单来说就是企业的业务流程本身是端到端和连贯的，但是我在应用架构规划设计的时候，为了降低系统构建复杂度，将应用拆分为了多个系统进行实现，每个系统实现业务流程中的某一部分内容。
即业务连贯，但是业务实现在多个系统中导致了割裂。因此因此业务系统必须高效协同起来才能够完成一个端到端的业务流程。
有了这个理解，基本就清楚了集成架构规划的重点，即：用你规划好的应用架构各系统功能提供来重新验证你前期梳理出来的端到端业务流程。即去回答和自己演算用各个系统功能的协同如何来完成完整的业务流程。
即原有的流程梳理图-》跨系统业务交互流程图
所有跨系统交互流程图中的竖线和红色三角形点即是潜在的系统集成点。在这个分析中，你就详细完成了业务系统间究竟有哪些集成点，集成点如何协同来完成完整业务的分析，如下：
当然上面的分析方法可能会遗留类似数据服务接口，技术服务接口等。而实际上要做一个完整的服务架构规划又有详细的指导方法。其核心仍然是从企业架构的业务，数据，技术各类架构输出入手，去分析和识别类似业务服务，数据服务，技术服务等各种类型的服务，最终形成完整的服务目录库。
具体如下图：
在把单个跨越业务流程的集成点全部梳理和识别清楚后。我们接着进行接口的分析和归纳等工作，在这里不再展开。最终所有接口都识别出来后，可以进一步朝上聚合完整的集成架构规划视图。
技术架构规划
技术架构描述了企业开发、实施和管理应用系统和数据所需的IT技术体系和IT基础设施。技术体系定义企业IT的科技管理和技术标准，从最高层次的政策、原则、指导纲要到技术领域的技术标准化、技术选择和技术组件。
基础设施是企业整个IT系统的基础，包括硬件、软件操作系统、数据库系统、网络系统等企业数据和应用程序可以运行的环境。
在整个基础设施架构规划中，高可用性规划和设计又是一个重要内容。
技术架构在业务架构、应用架构的基础上提供了一个框架，这个框架为发展和开发一个交互不同的业务部门和业务领域的、在技术层面上的、与业务相一致的解决方案提供了一个基础。重要的是它保持了企业的技术标准、技术选型、应用设计、系统产品选型、系统技术架构、系统部署、整个企业的技术部署等一切技术层面的组合和组件，与企业的战略规划、业务架构和应用架构的实际需求保持了一致性。
传统的技术架构规划，由于较少融入云计算和SOA思想，内容上偏向IT基础设施架构设计。虽然在TOGAF的技术架构规划中也谈到了技术和应用平台，但是却没有具体的落地方式。
而实际上我们可以理解为基于SOA和云计算思想的技术平台都可以划归到技术架构规划里面。比如我在前面给出了企业私有云PaaS平台规划，就可以属于技术架构规划内容。如下图：
而对于我最近在整理的云原生解决方案中的平台层能力提供，也完全可以纳入到技术规划的内容。这部分能力既包括了IaaS资源层能，也包括了PaaS服务层能力提供。如下：
实施规划和演进路线
实施规划直接影响到IT蓝图规划的可落地性，影响到IT建设投资是否真正体现业务价值，为业务目标服务。实施规划重点方法论主要为组合管理和项目群管理。可以从成本投入，建设难易程度，对业务价值实现的贡献，推广实施难度等多个方面来评估建设内容的优先级。预算和成本投入，在实施规划中同时也要考虑到。
实施规划按照组合管理的目标来说，就是要用最少的IT资源投入创造最大的业务价值。
我们要建设哪些IT系统，如何分阶段建设，如何来支撑业务流程，IT系统建设的协同关系，如何加强项目管理和管控，如何推进系统的建设，如何减少重复建设，这些关键信息在实施规划时都必须要考虑到。
