企业业务架构设计方法论及实践(二)

前言

        前面提到了业务架构作为企业战略与技术实现的桥梁,那本文具体讲讲企业战略如何与技术实现进行互通。

 

一 业务架构决定技术架构

        优秀的架构师需要具备体系化的架构设计思维能力,加以架构设计方法论的沉淀和实践的操练,久而久之架构设计指导和设计哲学必定了然于心。不管是业务架构还是技术架构其核心还是以实现企业战略目标,降低系统复杂性,隔离业务与技术的耦合,提升研发效能,降低研发、运营、维护成本作为架构分析的出发点。相对于需求分析或产品设计,业务架构的首要责任在于实现业务与技术架构的深度融合,打造能够让企业整体业务与技术之间进行有效的沟通和协作。在面对不确定性的复杂业务体系中,能够通过特定的方法(领域驱动设计)对业务领域、业务流程、组织架构、数据模型进行有效的建模和表达;能够通过把具象化的业务提升思维维度及层次,以中台建设方法论进行抽象和沉淀;能够通过中台架构和基础设施,以业务架构为桥梁连接企业战略和技术实现,通过某种机制(中台)做到业务域技术的隔离,到达业务回归业务,技术回归技术。

 

二 业务架构师商业价值交付的灵魂
      业务架构是企业战略、企业业务流程、企业组织结构等业务元素的结构化表达,是凌驾于技术架构之上的需求原动力,可以说业务架构是商业价值交付的灵魂。作为架构从业者做到“知线”和“行线”两个维度的统一还是非常具有挑战性的。其一,很多高层管理者并没有意识到打破业务与技术人员壁垒的重要性,要打破这种壁垒靠自顶向下的改革是不够的,必须从企业战略的高度认识到业务对软件开发的重要性,并提供一套可以实施和落地的方法论即本文的核心--业务架构。业务架构需要解决各种形态的业务问题、理清业务本质、抽象业务流程、提升业务复用性。在目前数字化转型的关键期,企业需要较强业务背景和技术背景的复合型人才,以数字化为基础打通IT系统,实现组织协同,从而提升端到端闭环的效率,这样才能够在激烈竞争的背景下快速进行产品创新和模式创新。如何面对业务的不确定性,适应业务的多变性,提供满足业务需求、可靠健壮、易于扩展的企业架构,还需要进一步的探索。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
付晓岩:虽然做了六年的企业业务架构,但是总觉得业务架构不是个好讲的东西,业务架构离不开业务模型,所以讲它就会搬出一堆枯燥的模型来,甚至会让人觉得业务架构就是建模。但建模只是个手段,建模的目的是把现象总结成模式,再从模式中找到结构,将业务上看到的结构传递给技术,如果者能够基于同一结构思考,沟通上将产生最大的便利,这就是通用语言的基础,其实说通用语言,还不如说通用结构,因为说语言,经常会把人带到语法层面,纠结于规则、概念、标准之类似是而非的东西。所以,我总结建模的原则无非是把握整体、穿透现象、保证落地,建模即不能死守规则、冥顽不化,也不能脑洞大开、信马由缰,必须从一开始就关注如何落地。建模不是建个自圆其说的乌托邦,而是传给后续过程的设计图纸。业务建模可以有前瞻性,但是所谓的前瞻性是能够看清分阶段实施路径的前瞻性。 业务架构是不断演进和迭代的,它有生命力,可以成长,如果架构管理工具本身支持历史记录和模式比对,你也可以看到企业架构的演进历史,而不是只看得到现在,只能听别人讲讲过去,过去是可以看见的。这种可视化的历史是一种宝贵的学习资源,人是从历史中学习未来的,毕竟有很多行业还是需要积淀的。 但是,业务架构的形成过程的确是在一种看起来科学的方法论下,不完全科学地操作的,这点我曾经也很纠结,后来软件架构的书看多了,再加上到项目中的观察,也逐渐释然了。软件架构其实很羡慕建筑架构,觉得建筑架构有力学基础做支持,有很多可以计算的东西,但是软件架构却没多少能算出来的。在开源思想时兴之前,行业内部交流分享较差,都比较愿意看别人的架构,而不想亮出自己的,很多研究者都抱怨这个非常需要标准的行业反倒是很隔离的。开源为架构和软件带来新的成长方式,共享让思维发展更快、普及更快,但是,软件架构本身却只是增加了大量的案例,依旧难以标准化,哪怕是同一个行业的企业,给这家做的软件也不一定能直接搬到另一家去,很多商用化了的系统软件也还是离不开个性的本地化改造过程。云计算带来的 SaaS 虽然让软件应用省去了许多部署过程,但是,依然难以改变这个行业个性化程度严重的局面。软件架构尚且如此,业务架构也就不需要纠结了。 业务架构设计可以很快,也可能很慢。快无非是两种情况,一是架构师自身炉火纯青、天生慧眼,设计能力超强;是原有业务模型已经很清晰,可以快速分析业务变化,形成架构设计,我们可以追求的是第种,这也意味这首次建模,尤其是首次建设企业级模型,不要过快,对模型设计方法、业务流程分析、标准化过程,都要细致点儿,基本功扎实了,才有后边的“敏捷”。企业级转型没有轻松的,不少企业是把转型仅当成一个项目,而忽视了对自身的调整。一个普通士兵变成一个特种战士,不是因为给了他一身价值 10 万的装备,而是经过了地狱般的训练。上至最高管理者,下至普通员工,人的思维不转变,哪来的企业转变呢? 为了推动企业真正的数字化转型,业务架构设计人员永远不要忘记,业务架构最重要的职责不是传递需求,而是藉由自身的努力,推动业务和技术的深度融合,桥梁作用才是业务架构最重要的职责,如果不能实现这一目标,也就不能真正实现一个快速响应内外部变化的企业业务系统。 其实中台并非万能,客观地讲,一个优秀的架构设计人员是不会“迷信”于任何一种架构设计方式的,也不会执着甚至偏执于方法间的争论,没有哪种设计方式是完美无缺的,软件行业没有“银弹”,任何一种方法都需要坚持与灵活的结合,都需要通过长期的实践不断总结和改良,如果一个方法没有被坚持数年以上,可能连入门都谈不上吧。我对中台认识更多还只能算个一般观察者,论述中难免有失,感谢读者朋友们能够宽容地看我一路“叨叨”下来。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

天秤座的架构师

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值