带你读《企业级业务架构设计: 方法论与实践》之二:业务架构的作用及与IT架构的关系

简介: 本书主要通过两条并行展开的线介绍了完整的企业级业务架构实践,一条为“行线”,一条为“知线”。“行线”是读者在日常工作中通常会比较关注的,其覆盖了企业级业务架构设计、实现及后期管理的完整过程;而“知线”则常常容易被忽视,尤其是在架构师或其团队之外。架构师有责任和义务持续改进、宣传架构设计方法,推动架构理念在企业以及社会范围内的磨砺、传播,实现架构工作的“知行合一”。

点击查看第一章
点击查看第三章
|第2章|

业务架构的作用及与IT架构的关系

2.1 业务架构的作用

业务架构的作用通常被认为是连接业务与IT的纽带,用于实现业务需求到IT的顺利传导,对于TOGAF等企业架构理论来说,业务架构也承担着将企业战略落地的职责。任何方法其实都有一定的时代性,除了上述一般意义上的作用之外,在通向“数字化”时代的进程中,业务架构的独特性在于帮助企业完成了深刻的“数字化”转型,使企业通过信息技术将内部、业务与IT深刻地连接起来,成为高效的“数字化”企业。
1.传统行业中的先行者已经实现了“数字化”
有人说,未来的企业都是科技公司,虽然就目前来讲还为时尚早,但是,科技已经极大地改变了很多传统行业。读者都知道BATJ(百度、阿里巴巴、腾讯、京东)是科技公司,其实星巴克也可以算是科技公司了。美国的星巴克门店,将近16%的收入是来自于其手机客户端;星巴克自己的App有近1300万的活跃用户,星巴克内部已经将网页、手机、社交媒体、网络营销、StarbucksCard、电子商务、Wi-Fi、星巴克数字网络和新兴的店内消费技术等,统一作为数字业务战略。
近年颇受大众关注的滴滴,在2016年就已经实现日产生数据超过50TB(相当于5万部电影),每天规划90亿次路径;据称2017年全年累计提供出行服务74.3亿次。
美团也是人工智能的“玩家”,其开发了服务快递骑手的语音助手,支持骑手全程通过语音与系统进行沟通、确认,免除了手动操作,提高了效率和安全性。以派单操作为例,语音系统会提示:“派单,从哪里到哪里,收到回复”,骑手只需回复:“收到”,系统即可确认派单。到了目的地附近时,骑手亦可以通过语音关键词回复,直接拨打电话,从而省去了掏出手机这个动作。在电量过低的时候,系统会提醒骑手注意电量,骑行速度过快的时候也会提醒骑手放慢速度,到达顾客附近时还会自动提示顾客的地址。美团的语音助手不仅方便了快递骑手,也使得快递过程更加安全,减少了事故发生的几率。
倒回十几年前,恐怕没有多少人真的相信零售、餐饮、出租车、外卖这些行业会与科技如此紧密相关,甚至会直接成为科技企业,而他们所用的技术也已经是大多数普通业务人员无法理解的了。这不仅仅是指技术原理无法理解,就连应用方式也都无法理解了,这是一个真实的“数字鸿沟”,其赋予了先行者“降维打击”的能力。
2.后觉者如何启动自身的“数字化”
很多人都清楚地认识到了科技的力量,心里也明白要应对技术推动的跨界竞争,那么后觉者应该怎么做呢?是简单重复先行者的“套路”吗?或者是高薪聘请一些技术人员?还是购买大厂的科技产品?这些虽然都是很有必要的,但正如交给你一把狙击枪,不代表你已经成为一名合格的狙击手一样,你还需要内因的转变,这种转变才是最终促成自身数字化转型的关键。
转变当然不是让所有人都去跨领域学习IT技术,全去当“技术能手”,而是转变思维方式,架起一道跨越“数字鸿沟”的桥梁,这就是业务架构的核心作用。业务架构可以帮助业务人员整体化、结构化地思考问题,从业务和系统的整体视角,附带一些对技术的基础了解,如分层理念、服务化、微服务化等,去理解业务和技术;同时还能够帮助技术人员理解、归纳业务人员的想法和目标,从而让业务和技术能够处于同一个语境之下,使用同一种“语言”工作。业务架构能够让“后觉者”从认知自身开始完成一场深刻的“数字化”转型。
3.业务架构带动深度融合
曾经的业务不用管技术怎么实现、技术能听懂需求就足够的时代已经过去了,现在是深度融合的时代。深度融合代表互相深入理解,而这种理解首先需要从思维方式的转变开始,通过建立业务架构,业务和技术都能向对方的领域多迈出一步。当然,这一步对业务人员的挑战更大,但信息技术是这个时代的特征,在一个信息化的时代,就得具备这个时代的思维方式和基本技能,这是任何人都无法回避的问题,就如同从农业时代的战车到工业时代的坦克的变化一样,无论是其战术还是对操作者的技能要求,都发生了翻天覆地的变化。
在构建业务架构的过程中,业务人员需要技术人员的大力协助来共同掌握这个方法,这不仅是一个通向理解的过程,更是一个达成信任的过程。此外,我们无法忽视的一点是,如果业务本身不能被很好地结构化、模块化,那么技术人员也很难做出一个具有良好架构的系统,就算你是中台的“铁粉”,也无法解决这个问题。所以,培养业务人员的逻辑思维、架构意识,对于系统开发而言,只有好处,没有坏处,要努力让业务“懂”技术。
有些技术人员会觉得应该让业务人员只专注业务,但是不妨想一想,业务人员和技术人员在现实中的比例,你会发现,要是业务人员也能对技术的思维方式有所了解,那将会对技术的合理应用乃至创新产生多么大的推动力。打个不恰当的比方,技术人员就好比是茶商,你可能想象不到,有多少现代人的喝茶习惯、茶叶知识都是拜茶商所赐,客户对茶叶了解地越多兴趣就会越浓,就更愿意尝试不同的茶叶、茶具以及泡茶技法。很多消费者最终在知识、兴趣上都远超一般的茶商,这就是人们常说的培养客户,与客户共同成长的案例吧。
4.来自银行的声音
大型商业银行业务种类繁多、组织结构庞杂,每年的IT投入也是不菲的,他们更需要进行合理的“企业级”规划以实现IT对业务发展的支持,应对来自互联网企业的跨界竞争。
2017年6月25日,中国建设银行宣布,该行完成历时6年的“新一代”核心系统建设,明确称其采用了企业级建模方法,形成了以“四个一(一套模型、一套IT架构、一套实施工艺和一套管理流程)”为特征的企业级工程实施方法,全面建立集团层面的流程模型、数据模型、产品模型和用户体验模型;2019年4月,中国工商银行金融科技部总经理在《中国金融电脑》杂志上撰文称,“中国工商银行整合构建企业级业务架构”,“重构了适应新时期发展需要的业务架构视图,重新规划整合了28个领域的业务架构,形成了2300余个任务组件”,“通过强化业务架构的顶层设计和跨条线的协同联动,为后续进一步打造更具新时代基因的智慧金融体系奠定基础”。
这些银行的应用能够为企业级业务架构方法提供了更多的有效性佐证和实现上的借鉴。
关于业务架构作用的讨论,读者可以进一步阅读本书的附录A,该篇附录是笔者在进行企业级业务架构设计工作期间,阅读马汉的名著—《海军战略》的读后感,也是对业务架构作用的一种思考。

2.2 业务架构与IT架构的关系

1.5节中提到过,TOGAF框架将业务架构视为IT战略的一部分,但事实上,业务架构应当是企业战略而非IT战略的一部分,它不同于通常意义上的业务需求,而是企业业务战略的实现方法。因此,业务架构范围是可以大于IT架构范围的,可以包含企业战略的非系统化部分,是企业业务的全景描述。IT架构则是用于企业信息化建设的,是企业战略的系统实现部分。二者之间的关系,用灵魂与容器来形容也许更为恰当。业务架构是灵魂,IT架构是容器,即灵魂的载体,没有灵魂,只有容器是没有生机的,所以,技术人员需要关注业务和业务架构。
业务架构与IT架构的关系可以用图2-1加以说明。
image.png
业务架构可从企业战略出发,按照企业战略设计业务及业务过程,业务过程是需要业务能力支撑的,从战略到业务再到对业务能力的需要,就形成了支持企业战略实现的能力布局,可以将这个布局理解为业务架构,它是企业为客户创造价值的设计过程。业务架构设计会尽可能地追求以更为集约的能力实现更为多变的业务或服务,这其实也是中台战略追求的目标,因而,中台战略实际上也可以归结为一种业务架构设计。
业务架构设计完成后,“灵魂”就诞生了,IT架构则是根据“灵魂”的需要来设计“容器”。IT架构的分类方式并没有统一的说法,通常会分为应用架构和技术架构,而近些年随着大数据的发展,数据架构的地位直线上升。此外,随着数据安全问题日益受到重视,许多企业的IT架构也将安全架构置于重要的位置上。
IT架构的4种架构的特点以及关系具体如下。
1)应用架构重点关注的是功能布局,与业务架构的关系非常紧密,可以称其为业务架构设计的“紧后工序”。
2)技术架构主要关注分层结构,对于大型业务系统来说,一个逻辑分层很可能要通过多种平台才能实现,因此还会在分层中加入平台规划。技术架构与业务架构的关系不像应用架构那么直接,主要是通过对业务特征、业务量等多种因素综合考虑分层的合理性和平台选型,通常业务架构设计不会涉及这部分工作,但业务架构人员应当了解本企业的技术架构及特点。
3)数据架构中有一个重要的组成部分是数据模型,数据模型与业务架构关系密切,甚至可以归类为业务架构的组成部分。
4)安全架构与业务架构的关系一般不是十分紧密,但是目前安全架构设计的一个发展趋势便是在向业务架构靠拢,或者说是向企业战略靠近,以使得安全架构设计更贴近实际业务需要,符合企业发展方向,而不再局限于传统的网络安全、信息安全等防护型工作,需要体现出更多的“规划”特征。
从上面的介绍可以看出,作为“灵魂”的“容器”,IT架构中的应用架构和数据架构与业务架构的关系是最为紧密的。从实践的角度来说,如果企业没有那么多的架构设计人员,那么应用架构与业务架构可以合并,毕竟业务能力规划清楚之后,向部署延伸一点就是应用架构。如果将业务架构与应用架构合并,那么让经验丰富的技术人员担任此项工作会更为合理,但要求相关人员必须具有或者培养良好的业务思维。数据架构中的数据建模工作更是可以合并在业务架构设计过程中。
将“灵魂”注入“容器”是技术人员的重要工作,而能否顺利注入,让“灵魂”有个适宜的居所,则有赖于对“灵魂”的充分认知;而引导这一认知过程,让原本朦胧神秘、纷繁复杂的“灵魂”清晰可见的,正是业务架构。

相关文章
|
14天前
|
监控 Java 持续交付
后端开发中的微服务架构实践与挑战####
在当今快速迭代的软件开发领域,微服务架构以其灵活性和可扩展性成为众多企业的首选。本文探讨了微服务架构的核心概念、实施策略及面临的主要挑战,旨在为后端开发者提供一个全面的指南。通过分析真实案例,揭示微服务在提升系统敏捷性的同时,如何有效应对分布式系统的复杂性问题。 ####
|
5天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
25 1
|
1天前
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
|
6天前
|
消息中间件 运维 开发者
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在后端开发中的应用,从其核心概念、设计原则到实际部署过程中面临的挑战进行了全面剖析。不同于传统的单体应用,微服务通过将复杂系统拆解为一系列小型、独立的服务,提高了系统的灵活性和可维护性。然而,这种架构的转变也伴随着服务间通信、数据一致性、部署复杂性等新问题。本文旨在为开发者提供一套应对这些挑战的策略,同时分享一些成功案例,以期促进微服务架构的有效实施。 ####
|
8天前
|
缓存 负载均衡 API
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的可扩展性、灵活性及易于维护的特点,成为众多企业后端开发的首选架构模式。本文将深入探讨微服务架构的核心理念,通过具体案例分析其在实际应用中的实践策略与面临的挑战,为读者提供一份详尽的微服务架构实施指南。 ####
|
10天前
|
消息中间件 负载均衡 测试技术
后端开发中的微服务架构实践与挑战####
本文旨在探讨微服务架构在后端开发中的应用实践,深入分析其带来的优势与面临的挑战。通过剖析真实案例,揭示微服务转型过程中的关键技术决策、服务拆分策略、以及如何有效应对分布式系统的复杂性问题。文章还将提供一套评估企业是否适合采用微服务架构的框架,帮助读者更好地理解这一架构模式,并为企业的技术选型提供参考。 ####
|
9天前
|
运维 监控 安全
深入理解微服务架构:设计原则、挑战与实践
深入理解微服务架构:设计原则、挑战与实践
|
13天前
|
Cloud Native Devops 持续交付
云原生架构的演进与实践
本文深入探讨了云原生架构的核心概念、技术组件及其在现代软件开发中的应用。通过分析容器化、微服务、持续集成/持续部署(CI/CD)等关键技术,揭示了这些技术如何共同促进应用程序的灵活性、可扩展性和高可用性。文章还讨论了云原生架构实施过程中面临的挑战和最佳实践,旨在为开发者和企业提供一套实用的指导方针,以便更有效地利用云计算资源,加速数字化转型的步伐。
31 5
|
15天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
42 5
|
19天前
|
监控 Go API
Go语言在微服务架构中的应用实践
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出,成为构建微服务的理想选择。本文将探讨Go语言在微服务架构中的应用实践,包括Go语言的特性如何适应微服务架构的需求,以及在实际开发中如何利用Go语言的特性来提高服务的性能和可维护性。我们将通过一个具体的案例分析,展示Go语言在微服务开发中的优势,并讨论在实际应用中可能遇到的挑战和解决方案。