南昌网站空间,wordpress怎么备份,wordpress 添加微博话题墙,吉林做网站业务架构这个词大家时常听到#xff0c;但是能解释得清楚的却不多#xff0c;撩撩度娘#xff0c;你就会发现#xff0c;不少人问及业务架构和应用架构的关系#xff0c;聊天时#xff0c;也常有人问起业务架构师和产品经理什么区别#xff1f;业务架构分析和需求分析什…业务架构这个词大家时常听到但是能解释得清楚的却不多撩撩度娘你就会发现不少人问及业务架构和应用架构的关系聊天时也常有人问起业务架构师和产品经理什么区别业务架构分析和需求分析什么区别为了思考这个问题我把《软件工程》、《软件系统架构》、《系统分析与设计》都翻了这些经典教材确实没讲过业务架构这件事我把《聊聊架构》也翻了发现其中的讨论有解释到业务、架构和技术的关系但是也没有特别强调业务架构所以本文就先梳理下几个较为有名的业务架构理论。
Zachman模型
其实业务架构这个词并不新它隐藏在企业架构EA中。企业架构是上世纪80年代的产物其标志就是1987年Zachman提出的企业架构模型该模型按照“5W1H”即what数据、how功能、where网络、who角色、when时间、why动机六个维度结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统六个层次将企业架构分成36个组成部分描述了一个完整的企业架构要考虑的内容详图如下
资料来源网络
Zachman模型虽然没有明确提出业务架构这个概念但是已经包含了业务架构关注的一些主要内容如流程模型、数据、角色组织等既然没有提出业务架构概念自然也就没有包含构建方法所以Zachman模型应该算是业务架构的启蒙同时它也表明了这一工具或者技术的最佳使用场景——面向复杂系统构建企业架构。
TOGAF
1995年大名鼎鼎的TOGAF登场了这个在企业架构市场中据说2009年统计占了半壁江山的架构模型明确提出了业务架构的概念。TOGAF将企业定义为有着共同目标集合的组织的聚集。例如企业可能是政府部门、一个完整的公司、公司部门、单个处/科室或通过共同拥有权连接在一起的地理上疏远的组织链。TOGAF进一步认为企业架构分为两大部分业务架构和IT架构大部分企业架构方法都是从IT架构发展而来的。业务架构是把企业的业务战略转化为日常运作的渠道业务战略决定业务架构它包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统复杂系统集成的关键是基于架构或体系的集成而不是基于部件或组件的集成。TOGAF还提供了一个详细的架构工件模型资料来源百度
其中可以明确看到业务架构阶段的交付物。相信很多对架构有兴趣的朋友都认真学习过TOGAF模型此处不再赘述。
FEA和DODAF
TOGAF之后又先后诞生了FEA联邦企业架构和DODAF美国国防部体系架构框架。前者的体系由五个参考模型组成绩效参考模型PRM、业务参考模型BRM、服务构件参考模型FRM、数据参考模型DRM、技术参考模型TRM该方法应用于美国电子政务领域着眼于跨部门、跨机构提升业务效率解决重复建设、信息孤岛等问题很具有“企业级”理念虽然没有明确的业务架构定义但是很好地应用了业务架构的思维。后者体系挺复杂的8个视点52个模型但是实用性不错美国国防部和一些企业在用详细内容如下资料来源网络
其中能力视点和作战视点就是我们做企业时关注的业务部分。这两个模型网上有相关资料感兴趣的话可以自行查阅。
为何沉闷至今
通过寻根溯源可以发现即便从TOGAF算起业务架构这个词也有20多年的历史了但是在开发人员中业务架构显然没有需求分析的概念明确业务架构师也远不如产品经理常见。作者所在单位曾经实施了一个长达数年的企业级转型项目其中有明确的业务架构组织但是每每与技术人员讨论他们也常觉得业务架构有点儿“虚”。细究其原因可能有如下几点
用的少。原有的单体式或者竖井式开发依然是大家更经常采用的项目构建方法而这种开发基本上没有横向视角所以无需强调业务架构通常的产品分析或者需求分析足以满足开发需要难设计。业务架构特别是大型企业这种错综复杂的业务架构说起来容易做起来难业务架构对战略的分解、业务架构自身的整合与标准化、到IT设计的过渡都有不少坑业务越复杂越宽泛就越难驾驭因此即便做过业务架构设计的企业也有不少将业务架构设计保持在高阶状态有点儿“虚”易跑偏。施工期间由于客观因素可能导致实施对业务架构的偏离这种偏离如果没有及时纠正或者调整架构累积久了会造成业务架构的失真会变“虚”难维护。少数扛过了业务架构落地困难期的企业也会由于感受到维护架构的难度而心生放弃从而降低了对业务架构的评价。
其实业务架构从诞生之初就很清楚地定义了自己的使命面向复杂系统构建。也就是说业务架构同其他架构一样目的也是要降低复杂度更好地规划系统因此TOGAF是将业务架构归属于IT战略部分。但是从本人的实践经验看业务架构不仅具有上述作用其更突出的影响是对参加过业务架构设计工作的业务人员的影响他们的逻辑思维能力、结构化能力、企业级观念和意识都有明显的改变所以应当将业务架构从IT战略中独立出来更多面向业务人员以充当业务与技术之间的桥梁。当然业务架构真正要承担起这一职责还需要改进、简化业务架构设计方法对业务人员更友好并且坚持使用业务架构方法做企业级需求管控否则熵增一定会将已经建好架构秩序回归混沌状态。
中台说到底也是一种业务架构设计结果回顾软件设计的发展历程中台也不是石头中蹦出来的齐天大圣它并非一种超越了企业架构这个概念的存在因此想要深入理解中台设计方式多去学习下业务架构、软件架构的发展历程还是有帮助的。
架构伴侣业务模型
业务架构是战略、流程、组织等业务元素的结构化表达因此说起业务架构自然离不开业务模型所以本章我们讲讲架构的伴侣——业务模型。
模型与业务模型
业务模型也是模型的一种因此我们先从模型讲起。模型的概念大家可以查到很多种不过度娘上有一种是我觉得比较容易理解的这个解释中说模型是所研究的系统、过程、亊物或概念的一种表达形式也可指根据实验、图样放大或缩小而制作的样品。很多人一说起模型都喜欢说模型是抽象的东西模型最重要的是抽象这个说法对软件开发人员而言并无不妥但是对于理解模型这个概念而言还是有些狭窄了。模型可以是具象的可以是实物比如售楼处常见的楼盘模型我们的老祖宗修故宫、给皇帝家造亭台楼榭时也会先做出精巧的木制模型模型不仅可是真实事物也可以是虚拟的只要脑洞开的够大比如很流行的高达玩具模型、变形金刚等模型当然也可以是抽象的比如软件开发中常用的实体模型、时序图、状态图、用例图等等。例子参见下图
模型就是一种表达形式其实说出来的话也可以视为一种模型它是你头脑中的想法的表达说的过程也就是个建模过程还遵循了一定语法规则。所以模型不是个神秘的东西对于业务人员而言工作时候经常会画的业务流程图也是模型与软件开发中用的模型相比无非是个建模视角和抽象程度的差别。
理解了模型我们再来看看业务模型。套用上边的概念业务模型就是对业务的表达至于这个业务的范围就看你的需要了如果只是针对一个产品那业务模型可能就是对产品的生产、销售、使用、售后管理过程的描述其中还要包含所有参与方的目标、活动、角色、职责等等如果针对的是一个大型企业那业务模型的范围就可能包含多条产品线每条产品线都有不同的业务过程而涉及到的参与方也会更多、更复杂。所以业务模型最主要描述的就是组织及其运作过程。企业的业务模型有一个最高阶抽象的三角形如下这个三角形可以说是一切盈利性企业的基本行为企业为生产而投入成本产品或服务销售后取得收入而衡量企业业绩的最基本方法就是通过收入减去成本形成的利润。其实所有企业的行为都可以从这个三角形出发去分析比如一个企业基本流程就可以概括为
企业准备向哪些人销售自己的产品或服务这就体现了企业自身的价值定位企业准备组织那些人生产组织哪些人销售在什么样的渠道上销售为此投入什么样的资源这就是企业的生产和销售流程收入和成本都需要记账这就是财务会计的流程对利润实现情况的衡量、盈亏原因的分析等体现在管理会计中所有行为都会产生数据这些数据是我们做系统设计时的必要输入是结合业务流程做架构分析的基础。从这个最高阶的核心模型出发我们可以演化出整个企业的过程可以模型化地创造一个企业这就是“大道至简衍化致繁”吧。
建模原则与模型思维的应用
既然业务模型对业务架构、对系统设计如此重要那么建模是否有什么诀窍呢很遗憾没有。这不仅是我个人的理解不少关于建模的书中也都会提到建模看似有很多方法、标准可以遵守但是模型质量却十分依赖于建模者的经验是一个“熟练工种”“老司机”很重要。虽然没有捷径但还是有两个原则可以时刻注意的
整体性原则。做模型切忌快速上手不要快速被业务细节吸引更不要被立马解决问题的冲动左右一定要将问题域或者说建模对象放在一个更大的环境中观察要先找到建模对象的边界也就是上下文环境。搞不清边界就搞不清范围即不知道起止也不知道思虑是否周全甚至无从检验建模成果容易一叶障目不见森林。合适性原则。大家可能都听说过一个比方把世界上最美的五官凑在一起并不会成为世界上最美丽的脸这就是合适性原则美丽的脸通常是五官比例好、搭配好的脸也就是说模型中包含的各个部分、各类元素要有机结合在一起不能在设计时为了图新潮、赶时髦甚至为了建模者个人的“执念”生搬硬套强买强卖忽视了模型的平衡。
业务模型是为业务架构服务的所以细心的读者也一定注意到了这两条其实也是架构设计的重要原则。建模唯有不断练习不断参与项目实践以获得对建模成果的必要反馈才能有所提高设计上我们经常把不管实现的架构师比作“PPT架构师”其实建模也一样不能在生产环境中得到反馈建模者也会成“PPT模型师”所以“实践是理论之源”啊。
经历过的人都知道认认真真建模是项枯燥繁琐的事情而且我也提到业务架构设计可以帮助业务人员提升逻辑思维能力应该让业务人员多参加那么广大业务人员也会疑虑投入这么大精力参与这事儿做完了项目这技能还用得上吗肯定用得上啊虽然不会到处去建模但是重要模型思维可是非常有用的我个人总结有这么三点是在各类工作中都值得借鉴的
把握整体。这条不再赘述应用上我建议对于任何领导交办给你的工作尽可能不要第一时间就“Just do it”而是要挤出点时间考虑下来龙去脉前因后果这样你才能控制好工作的度过犹不及啊。穿透现象。浮在水面上的往往是冰山一角透过现象看本质是我们对建模人员的基本要求这种注意事物内在联系、本质差别的能力有助于你拨开现象的迷雾找到最佳的解决方案。保证落地。前一阵子曾经流行过一句话“一切不为业务目的服务的技术都是耍流氓”套用一下“一切不考虑落地的架构设计都是耍流氓”架构不能飘在天上印在纸上所以真正了解架构本质的人无论做的是“矮穷挫”的搬砖方案还是“高大上”的传奇方案都要以落地为前提对应到日常工作中就是我们无论何时何地提出的工作建议都不能是“空谈”。
中台的表达方式其实也是一种模型化表现方式毕竟当前的软件设计基本都是“模型驱动开发”无非是模型工具的差别。关于模型的一些基础性介绍先到此为止本文所讲的业务架构都是使用业务模型来构建的。\t相关文章中台之上一重视业务架构不要让“业务的归业务、技术的归技术”
作者介绍付晓岩原国有大行资深业务架构师负责业务架构设计、项目管理热衷新技术探索与实践具有丰富的银行业务经验和企业级项目业务架构设计经验曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号晓谈岩说。
