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

相关文章
|
数据采集 运维 监控
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
|
消息中间件 运维 监控
企业级短信验证码服务架构设计与最佳实践
随着移动互联网的发展,短信验证码成为用户身份验证的重要手段。本文从企业级应用角度出发,探讨如何构建高可用、高并发和安全可靠的短信验证码服务。通过多通道冗余、故障自动切换和服务降级保障高可用性;利用异步处理与消息队列应对高并发;借助多层防刷、内容审核和数据加密提升安全性。同时,提供了详细的架构设计、核心模块代码示例以及监控运维方案,帮助读者理解并实现一个完整的短信验证码系统。
863 2
|
存储 SQL 分布式计算
19章构建企业级大数据平台:从架构设计到数据治理的完整链路
开源社区: 贡献者路径:从提交Issue到成为Committer 会议演讲:通过DataWorks Summit提升影响力 标准制定: 白皮书撰写:通过DAMA数据治理框架认证 专利布局:通过架构设计专利构建技术壁垒
|
11月前
|
运维 Prometheus 监控
别再“亡羊补牢”了!——聊聊如何优化企业的IT运维监控架构
别再“亡羊补牢”了!——聊聊如何优化企业的IT运维监控架构
398 8
|
人工智能 监控 数据可视化
企业级LLMOps落地指南:蜂巢架构×可视化编排实战
本文将基础的单应用扩展成多应用,并实现工作流组件,包括:多应用模块设计、工作流模块设计、LangGraph实现图应用、前端Vue-Flow组件使用、工作流转LLM工具设计思路、关联工作流登技巧。
635 3
企业级LLMOps落地指南:蜂巢架构×可视化编排实战
|
12月前
|
存储 消息中间件 安全
企业级实时消息推送系统的架构设计,一文即懂!
如果你是技术负责人,该如何搭建一套能解决这些问题的企业级统一消息推送平台?今天我们就从核心挑战出发,拆解一套可落地的统一推送服务架构方案。
1681 0
|
缓存 监控 安全
301重定向进阶指南:从基础配置到企业级架构优化
本文深入探讨网站重定向的高级技巧与企业级实现,涵盖正则表达式重定向、权重无损迁移、分布式系统适配等核心内容。通过解析301/302状态码区别及应用场景,结合Nginx、Apache配置示例,帮助开发者优化大规模网站重定向逻辑。同时,文章介绍CDN边缘重定向、微服务架构下的规则管理以及容灾设计,确保高性能与安全性。最后提供全链路监控方案和经典案例分析,助你规避流量损失风险,提升SEO表现。
706 38
|
消息中间件 人工智能 安全
企业级AI应用需要系统工程支撑,如何通过MCP大模型架构实现全链路实战解构?
本文三桥君深入探讨了MCP大模型架构在企业级AI应用中的全链路实战解构。从事件驱动、统一中台、多端接入、API网关、AI Agent核心引擎等九个核心模块出发,系统阐述了该架构如何实现低耦合高弹性的智能系统构建。AI专家三桥君提出从技术、内容、业务三个维度构建评估体系,为企业级AI应用提供了从架构设计到落地优化的完整解决方案。
653 0
|
监控 应用服务中间件 区块链
301重定向的终极指南:从基础配置到企业级架构设计
本文全面解析301重定向技术,从基础配置到企业级架构设计。涵盖HTTP状态码语义、浏览器与爬虫处理差异,提供分层架构模型及高可用配置示例。深入探讨亿级URL处理策略、流量压力测试数据,结合HTTP/2优化与Core Web Vitals提升方案。同时关注隐私合规性、故障排查工具及前沿技术融合,如机器学习预测和区块链存证。最后通过实际案例分析,展示重定向工程的商业价值与未来趋势。
441 14
|
人工智能 自然语言处理 物联网
如何成为企业级大模型架构师?
企业级大模型架构师需要掌握从 底层算力、模型训练、微调优化、推理部署、企业集成 到 安全合规 的全栈能力。这里提供一个完整的 企业级大模型架构师成长体系。
1778 4