新闻中心

Chris Forde

The Open Group是一个供应商和技术中立的组织。经认证符合ArchiMate®3.0.1版规范或ArchiMate®3.1版规范的工具登记册在此链接:

https://certification.opengroup.org/register/archimate-tool。

经认证符合TOGAF®9.1版规范或TOGAF®9.2版规范的工具登记册在此链接:

https://certification.opengroup.org/register/togaf-tool

The Open Group is a vendor and technology neutral organization. The register of tools certified for conformance to the ArchiMate® Version 3.0.1 Specification or ArchiMate® Version 3.1 where advised is here 

https://certification.opengroup.org/register/archimate-tool. 

The register of tools certified for conformance to the TOGAF® Version 9.1 Specification or TOGAF® Version 9.2 Specification where advised is here https://certification.opengroup.org/register/togaf-tool

Q：业务与技术深度融合的具体措施有哪些？对于业务来说，技术起保障作用还是引领作用？

付晓岩

Xiaoyan Fu

深度融合在我个人看是要基于日常工作机制，而非项目的。像摩根大通那种把合适的技术人员直接安排到业务部门进行工作，或者轮岗。所以，深度融合是建立在日常工作机制的基础上的。这方面目前国内很难说有特别好的实践，因为多数传统银行都没那么多的技术人员可以派驻到部门中去。

In my personal opinion, deep integration is based on daily work mechanisms, instead of projects. Like JP Morgan Chase, appropriate technical personnel are directly assigned to the business department for work, or rotated. Therefore, deep integration is based on the daily work mechanism. At present, it is difficult to say that there are particularly good practices in China, because most traditional banks do not have so many technical personnel to be stationed in the departments.

Q：业务架构需要针对公司的愿景，使命，目标进行分解，想请教付老师，建行在这个架构活动开展过程中有什么难点和成功的经验？

付晓岩

Xiaoyan Fu

难点首先是大家对做企业级的意义达成共识，这样部门之间在落实企业整体目标时才能接受更多的合作。企业在做企业级时，很多部门其实还是把自己的需求放在第一位的。经常也会出现由于需求进行企业级汇总时，提出需求的部门没到位，导致覆盖不完整的问题，但是这些也都属于正常现象，不要太纠结，本来也难以一步到位。做企业级画出整体蓝图，其实是为了尽可能了解全貌，而不是要僵化地执行蓝图，蓝图随时可以调整，这是很多人看待企业级时存在的误区。能够正确看待企业级时，做战略、愿景才能保持合理心态。观念调整好了，再分解战略就是要充分发挥集体智慧，分解的细致，这时需要对业务具备一定前瞻性，由于现在技术的重要性，所以，这一过程中要引入技术人员共同讨论，尤其是架构师。最后，这种机会都是培养业务架构师的好机会，不能忽视利用这种机会对业务架构师的培养。

The first difficulty is that how to have everyone reach a consensus on the meaning of being an enterprise, so that departments can be more cooperative when implementing the overall goals of the enterprise. When an enterprise focuses on the need at an enterprise level, many departments actually put their own needs first. Often, when the requirements are summarized at the enterprise level, the result from departments is in in-complete coverage. However, these are also normal phenomena, and it is difficult to achieve the goal in one step. To draw the overall blueprint at the enterprise level, in fact is to understand the whole picture as much as possible, rather than rigidly execute the blueprint. The blueprint can be adjusted at any time. This is a misunderstanding that many people think about the term of "enterprise level". When you can correctly view the enterprise level, you can maintain a reasonable mindset by making strategy and vision. After the concept is adjusted, the re-decomposition strategy is to give full play to collective wisdom and decompose meticulously. At this time, it needs to be forward-looking for the business. Due to the importance of current technology, it is necessary to involve technical personnel to discuss together in this process, especially the engagement of architect. Finally, this is a good opportunity to train business architects, and we cannot ignore the use of this opportunity to train business architects.

Q：您在企业安全架构执行过程中遇到过哪些典型的问题？

杨喜龙

Xilong Yang

IT安全，OT安全，云安全由不同的部门负责，但并没有部门对企业整体安全能力建设持续跟进；IT与业务缺乏沟通，对业务不够理解，在数据安全能力建设过程中问题格外明显。

Different departments are responsible for IT security, OT security and cloud security, but none is keeping up with the overall security capacity building of the enterprise. Lack of communication between IT and business, which results in lack of understanding of business. That becomes an obvious problem in the data security capacity building process.

Q：在实际工作中，如何运用企业架构方法加强项目管理水平?

林海龙

Hailong Lin

项目立项前，用高阶的架构交付物与项目发起者和利益干系人达成共识，并评估预计投入和项目里程碑；项目实施过程中，用不断对架构交付物进行具体化，确保在需求分析和系统设计阶段，遵循和实现项目预期的架构蓝图；在项目运营期间，基于架构进行沟通和交流，持续根据需求进行迭代。

Before the project is approved, use high-level architecture deliverables to reach a consensus with the project sponsor and stakeholders, and evaluate the estimated investment and project milestones; during the project implementation process, the architecture deliverables are continuously specified to ensure that the requirements analysis and In the system design phase, follow and implement the project’s expected architecture blueprint; during project operation, communicate based on the architecture, and continue to iterate according to requirements.

Q：目前敏捷开发流行，与企业架构是什么关系，如何互为补充？

林海龙

Hailong Lin

企业架构是一种为了实现业务目的到IT落地的方法，也可以应用到敏捷开发中，只是区别于传统瀑布式开发，敏捷开发要求快速的迭代，如果不运用企业架构方法，敏捷开发会陷入业务的迷区，就是被各种用户不同的需求所牵引，缺少方向性和总体性的愿景指导和创新牵引，解决方案是学会架构思考模式，在短迭代周期中应用。

Enterprise architecture is a method to land IT in order to achieve business purposes. It can also be applied to agile development, but it is different from traditional waterfall development. Agile development requires rapid iteration. If enterprise architecture methods are not used, agile development will fall into business puzzle area, driven by the different needs of various users, lacking directional and overall vision guidance and innovation traction. The solution is to learn to structure thinking mode and apply it in a short iterative cycle.

Jianmin Li

项目管理PMBOK的知识领域采用的是“输入、工具技术和方法、输出”，TOGAF®的ADM采用的是“目标、做法、输入、步骤、输出”，两者在方法和结构上非常类似，都是采用了“输入、输出、步骤”的形式。而TOGAF是各领域知识的集成者，项目管理是其中的一个领域，TOGAF涉及到的项目管理均需要参考PMBOK体系执行，而项目管理中涉及到的架构，无论是业务架构、应用架构、数据架构、技术架构，还是继承与发扬的开发架构、部署架构、集成架构等，均需要遵循TOGAF体系执行，两者互为倚重。

企业架构与项目管理一样都与企业的变革管理密切相关，如果企业不谋求变革而是按照常规进行运营，那就不会产生项目和项目群，也就不需要进行企业架构管理。换而言之，企业架构用于识别变革、定义变革，项目管理用来实施变革。企业架构对项目管理的实施进行约束并提供管控手段，做好企业架构规划，就如同做好“五年规划”，在实际项目管理过程中都能有据可依、有迹可循、有方向可指引。

The knowledge field of project management PMBOK adopts "input, tool technology and method, output", and the ADM of TOGAF® adopts "objective, approach, input, step, output". Both are very similar in method and structure. The form of "input, output, step" is adopted. TOGAF® is an integrator of knowledge in various fields, and project management is one of them. The project management involved in TOGAF® needs to refer to the implementation of the PMBOK system, and the architecture involved in project management, whether it is business architecture, application architecture, or data architecture , Technical architecture, or inherited and promoted development architecture, deployment architecture, integration architecture, etc., all need to follow the TOGAF® system implementation, and the two rely on each other.

Both of enterprise architecture and project management are close related to enterprise change management. If the enterprise does not seek change but operates in accordance with the routine, there will be no projects and program groups, and enterprise structure management is not required. In other words, enterprise architecture is used to identify and define changes, and project management is used to implement changes. Enterprise architecture restricts the implementation of project management and provides management and control methods. Doing a good job of enterprise architecture planning is like doing a "five-year plan". In the actual project management process, there is evidence to follow, traces to track, and direction to go.

Manzhou Xu

理清组织内架构管控的业务场景。EA角度来说，EA开发的成果有些应作为项目管理的输入以及项目实施过程中的参考与遵循内容。

项目管理中应该充分利用架构资产所能带来的价值——high level概念的输入、架构（项目相关）参考、标准规范的遵从等。

Clarify the business scenarios of structure control within the organization. From the perspective of EA, some of the results of EA development should be used as input for project management and reference and compliance during project implementation.

Project management should make full use of the value that architecture assets can bring input of high level concepts, architecture (project-related) references, compliance with standards and specifications, etc.

付晓岩

Xiaoyan Fu

架构的演进其实是在有了第一版蓝图之后的演进，所以，无论怎么看待架构是演进的这个观点，没有起点其实无从谈演进，尤其是对于转型而言，没有蓝图其实也无从谈转型。有了第一版的企业架构之后，演进实际上就是基于已有架构的管控，包括业务和技术两部分，业务就是根据业务需求判断架构调整，技术则是根据技术发展决定技术架构的调整，以及根据需求的实现判断应用架构的一些改动等。总体而言，所谓的演进是对已有架构，根据环境和需求对架构的调整，不必把演进这个词看的太重。

The evolution of the architecture is actually the evolution after the first version of the blueprint. Therefore, no matter how you view that the architecture is evolution, no starting point then no evolution. Especially for transformation, there is no way to talk about transformation without a blueprint. With the first version of the enterprise architecture, the evolution is actually based on the management and control of the existing architecture, including two parts: business and technology. Business is to determine the adjustment of the architecture based on business needs, and technology is to determine the adjustment of the technical architecture based on technological development, and adjustment of some changes in the application architecture based on the realization of requirements. Generally speaking, the so-called evolution refers to the adjustment of the existing architecture according to the environment and requirements, and it is not necessary to over interpret the term "evolution".

Q：目前敏捷开发流行，与企业架构是什么关系，如何互为补充？

林海龙

Hailong Lin

企业架构是一种为了实现业务目的到IT落地的方法，也可以应用到敏捷开发中，只是区别于传统瀑布式开发，敏捷开发要求快速的迭代，如果不运用企业架构方法，敏捷开发会陷入业务的迷区，就是被各种用户不同的需求所牵引，缺少方向性和总体性的愿景指导和创新牵引，解决方案是学会架构思考模式，在短迭代周期中应用。

Enterprise architecture is a method to land IT in order to achieve business purposes. It can also be applied to agile development, but it is different from traditional waterfall development. Agile development requires rapid iteration. If enterprise architecture methods are not used, agile development will fall into business puzzle area, driven by the different needs of various users, lacking directional and overall vision guidance and innovation traction. The solution is to learn structure thinking mode and apply it in a short iterative cycle.

Q：如何做领域划分和建模？如何通过建模来指导实践？

庄鹏

Peng Zhuang

如果是银行领域，可以参考业务能力模型BIAN，如果是其他行业，也可以参考BIAN的基本原理进行领域划分和能力建模。我后面会具体介绍BIAN标准和相关实践。

If it is in the banking field, you can refer to the business capability model BIAN, if it is in other industries, you can also refer to the basic principles of BIAN for domain division and capability modeling. I will introduce the BIAN standard and related practices in detail later.

Q：企业应该如何选择那些基于模型的管理工具？你们使用的管理平台是什么？

程燕

Yan Cheng

基于模型的管理方式国外已经有了相对成熟的实践和方法标准，国内企业在转型中选择相关工具时，一方面最好深入研究模型标准本身，或者采购那些支持国际成熟架构与流程建模标准的工具，使得相关工作的技术基础保持稳定，并且可以随着国际实践知识的积累不断演进。二是不要为了模型而模型，应该选择那些本身有实施方法论，建模便捷而又直接支持一些业务应用的工具，第三是应具备多样的仿真能力，如果基于模型却不能仿真，将无法真正实现基于模型带来的分析、优化与一次实施成功的优势价值。

There have already been relatively mature practices and standards regarding to model-based management method, when local enterprises choose relevant tools in transformation, on one hand, it would be better for them to deeply research the standard itself, or purchase those tools supporting international mature architecture and process modeling standard to ensure a stable and continuously evolving technological basis. Secondly, choose tools that have implementation methodologies, that are easy to model and directly supported some business. Thirdly, it is necessary to have diversified simulation capabilities. If model-based, but unable to simulate, the advantages of model-based analysis, optimization and successful implementation will not be realized.