BPM平台与微服务架构天生契合

《K讲啦第九期直播》干货解读上期回顾

企业微服务架构选型的关键要素：随时、随地、随需、随人。在产品和技术选型中，企业可采用渐进式的建设方法，先专注其中某几个要素，分析业务需求并引入相应的技术，后期逐步完善其他要素，最终实现四要素兼具的效果。

本期将从传统企业信息化团队面临的挑战说起，解读引入微服务架构的必要性，以及微服务架构BPM平台的设计路径。

01

传统企业信息化团队面临的挑战

传统企业在触达到业务场景的过程中，为什么很难，为什么看起来互联网企业走的更快？

互联网企业天生就是轻资产，目前大部分都是直接触达C端的（国外已经有一些不是，比如SALESFORCE），而IT建设原本就是其直接生产力，也是核心资产，所以无论在团队组织、投资决策和需求反馈方面，它的很多逻辑都是最直接最顺理成章发生的。

对于传统企业信息化管理人员来说，除了团队人员、知识结构和思维习惯之外，还面临多方面的挑战：

01

组织结构

微服务架构从底层解耦到硬件再到运行环境，都需要含糊边界，没法一刀切。传统企业通常由业务部门提需求，架构师不触达业务和后台。这种内部职责分工和微服务架构提出的组织要求，天生存在不相容的地方。

02

架构的选择

企业原有信息化资产构成了企业运行的一部分，如何兼容原有信息化资产，还要确保未来的扩展性，是企业必须考虑的问题。

03

战场的选择

立项和前端业务需求是战术上最重要的两点，在抛出很多新技术和架构时，如何让决策层和业务层看到投资价值尤为重要。

04

产品的选择

寻找符合技术和框架概念的产品，确保产品能融入企业架构。微服务架构是以服务为主，以架构为核心融入的过程。一旦产品底层架构不符合整体原则，最后选择的产品无法拥有业务需要的敏捷、快速，不间断的能力。

05

合作伙伴的选择

无论是企业自身的开发团队，还是实施服务商。企业内部需要建设微服务架构、开发架构、开发规范等整套体系，以保证未来内外部开发人员介入时，利用企业要求的技术、架构和产品，快速理解组装出业务。

02

微服务架构引入的必要性和衡量标准

传统企业业务需求的专业性，和互联网轻资产企业有天壤之别。重资产带来的是专业知识的壁垒，IT人员无法通过简单的逻辑，学习理解整体的业务闭环，于是有了引入微服务架构的必要性，通过分层分块进一步解耦的架构，让更多人参与到应用建设中。这要求产品的完备性、强大的理论支撑、经验丰富的团队。

微服务是企业达成期望目标的核心要素之一，这不是简单通过一两个产品选型或者软件架构引入来做到的，而是要有框架、体系、工具、团队一起构成推进建设。

●衡量标准

微服务不仅仅是解耦、而是要看它解耦后是否能提供扩展性更强、运维能力更好的服务。

一定要能做到服务即软件、服务即产品的程度。

讲师金句分享

如何选择需要解耦的服务、工具和未来的方向都是要遵循一定的原则，而不能只是简单粗暴的来进行服务的“微小”化。

03

BPM平台与微服务架构天生契合

宏观上，BPM平台与微服务架构在企业信息化架构中，面临的核心挑战是一致的，因此两者诸多关键需求特性也是一致的：架构兼容性、扩展性、敏捷性、最终是对业务价值的沉淀和再赋能。微观上，BPM平台想融入到企业的微服务架构，打破烟囱式的平台概念，那么BPM平台本身也必须是微服务架构。

想要达成赋能企业架构、与企业架构完美融合的目标，不是依靠快速场景化、更不是业务化，这些虽然容易快速见到效果，但无法真正赋能整体架构。必须依靠自身架构的解耦、才能够快速融入整个平台找到切入场景、促进服务编制，找清楚定位。

两条设计路径：

一是轻应用、场景化、无所不包。触达场景，选择战场，利用BPM的场景触达性快速见效。

二是专业化、坚定边界、开放融入整体架构。融入架构通常是企业信息化部门难以深入的，但在新的架构下不能被撇开，因为企业无法通过完全引入外界服务获得能力。

以上两条路径必须全部打通，缺一不可。路径一往往更容易实践，但产品和架构选型不能忽略路径二，如果没有兼顾两种路径，未来架构会出现短板，造成推倒重来的风险。

Nebulogy 品牌介绍

Nebulogy致力于通过云原生理念，帮助企业构建PaaS平台，提高开发资源利用率，满足应用快速上线和迭代需求，助力企业实现真正应用云化、业务互联网化。