带你读《企业级业务架构设计: 方法论与实践》之二:业务架构的作用及与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架构中的应用架构和数据架构与业务架构的关系是最为紧密的。从实践的角度来说,如果企业没有那么多的架构设计人员,那么应用架构与业务架构可以合并,毕竟业务能力规划清楚之后,向部署延伸一点就是应用架构。如果将业务架构与应用架构合并,那么让经验丰富的技术人员担任此项工作会更为合理,但要求相关人员必须具有或者培养良好的业务思维。数据架构中的数据建模工作更是可以合并在业务架构设计过程中。
将“灵魂”注入“容器”是技术人员的重要工作,而能否顺利注入,让“灵魂”有个适宜的居所,则有赖于对“灵魂”的充分认知;而引导这一认知过程,让原本朦胧神秘、纷繁复杂的“灵魂”清晰可见的,正是业务架构。

相关文章
|
6天前
|
Kubernetes 负载均衡 Docker
构建高效后端服务:微服务架构的探索与实践
【10月更文挑战第20天】 在数字化时代,后端服务的构建对于任何在线业务的成功至关重要。本文将深入探讨微服务架构的概念、优势以及如何在实际项目中有效实施。我们将从微服务的基本理念出发,逐步解析其在提高系统可维护性、扩展性和敏捷性方面的作用。通过实际案例分析,揭示微服务架构在不同场景下的应用策略和最佳实践。无论你是后端开发新手还是经验丰富的工程师,本文都将为你提供宝贵的见解和实用的指导。
|
6天前
|
Kubernetes Cloud Native 持续交付
云端新纪元:云原生技术重塑IT架构####
【10月更文挑战第20天】 本文深入探讨了云原生技术的兴起背景、核心理念、关键技术组件以及它如何引领现代IT架构迈向更高效、灵活与可扩展的新阶段。通过剖析Kubernetes、微服务、Docker等核心技术,本文揭示了云原生架构如何优化资源利用、加速应用开发与部署流程,并促进企业数字化转型的深度实践。 ####
|
3天前
|
存储 安全 Java
系统安全架构的深度解析与实践:Java代码实现
【11月更文挑战第1天】系统安全架构是保护信息系统免受各种威胁和攻击的关键。作为系统架构师,设计一套完善的系统安全架构不仅需要对各种安全威胁有深入理解,还需要熟练掌握各种安全技术和工具。
27 10
|
4天前
|
监控 Cloud Native Java
云原生架构下微服务治理策略与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境下微服务架构的治理策略,通过分析当前技术趋势与挑战,提出了一系列高效、可扩展的微服务治理最佳实践方案。不同于传统摘要概述内容要点,本部分直接聚焦于治理核心——如何在动态多变的分布式系统中实现服务的自动发现、配置管理、流量控制及故障恢复,旨在为开发者提供一套系统性的方法论,助力企业在云端构建更加健壮、灵活的应用程序。 ####
44 10
|
3天前
|
缓存 运维 监控
后端开发中的微服务架构实践与挑战#### 一、
【10月更文挑战第22天】 本文探讨了微服务架构在后端开发中的应用实践,深入剖析了其核心优势、常见挑战及应对策略。传统后端架构难以满足快速迭代与高可用性需求,而微服务通过服务拆分与独立部署,显著提升了系统的灵活性和可维护性。文章指出,实施微服务需关注服务划分的合理性、通信机制的选择及数据一致性等问题。以电商系统为例,详细阐述了微服务改造过程,包括用户、订单、商品等服务的拆分与交互。最终强调,微服务虽优势明显,但落地需谨慎规划,持续优化。 #### 二、
|
4天前
|
运维 Cloud Native 持续交付
云原生架构下的微服务设计原则与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境中微服务设计的几大核心原则,包括服务的细粒度划分、无状态性、独立部署、自动化管理及容错机制。通过分析这些原则背后的技术逻辑与业务价值,结合具体案例,展示了如何在现代云平台上实现高效、灵活且可扩展的微服务架构,以应对快速变化的市场需求和技术挑战。 ####
23 7
|
6天前
|
消息中间件 Java API
微服务架构设计与实现:从理论到实践
微服务架构设计与实现:从理论到实践
27 7
|
3天前
|
监控 Cloud Native 测试技术
云原生架构下的性能优化与实践####
【10月更文挑战第21天】 本文深入探讨了在云原生环境下,如何通过一系列技术手段和最佳实践来提升应用性能。文章首先概述了云原生架构的基本原则与优势,随后详细分析了影响性能的关键因素,包括容器编排、微服务设计、持续集成/持续部署(CI/CD)流程以及监控与日志管理。针对这些因素,文中不仅介绍了具体的优化策略,如资源请求与限制的合理配置、服务间通信的高效实现、自动化测试与部署的优化,还结合案例分析,展示了如何在实际项目中有效实施这些策略以显著提升系统响应速度和处理能力。此外,文章还强调了性能测试的重要性,并提供了几种常用的性能测试工具和方法。最后,总结了云原生性能优化的未来趋势,为开发者和架构师
9 2
|
6天前
|
设计模式 API 持续交付
深入理解微服务架构:设计模式与实践
【10月更文挑战第19天】介绍了微服务架构的核心概念、设计模式及最佳实践。文章详细探讨了微服务的独立性、轻量级通信和业务能力,并介绍了聚合器、链式和发布/订阅等设计模式。同时,文章还分享了实施微服务的最佳实践,如定义清晰的服务边界、使用API网关和服务发现机制,以及面临的挑战和职业心得。
|
4天前
|
运维 Cloud Native API
云原生时代下的微服务架构实践
【10月更文挑战第22天】在数字化转型的浪潮中,云原生技术正以前所未有的速度重塑软件开发和运维的模式。微服务架构作为云原生的重要组成部分,其设计哲学、技术栈选择以及与传统单体应用的根本区别成为了现代软件工程讨论的焦点。本文将深入探讨微服务架构的核心概念,通过实际案例分析其在云平台下的应用,并分享在实施过程中的经验教训,旨在为读者提供一套清晰的微服务架构实践指南。

热门文章

最新文章