。

本文通过一系列随笔#xff0c;探讨了业务架构的价值、从通用架构到场景架构的转变、恰如其分的架构设计以及如何避免盲目低效等问题。

通过对多个实际案例的分析#xff0c;笔者揭示了架构设…

在当今复杂多变的商业环境中企业架构的设计与优化成为了一个关键议题。

本文通过一系列随笔探讨了业务架构的价值、从通用架构到场景架构的转变、恰如其分的架构设计以及如何避免盲目低效等问题。

通过对多个实际案例的分析笔者揭示了架构设计不仅仅是技术问题更是对企业现状和未来发展的深度理解与把握。

本文适合希望深入了解业务架构及其实践意义的读者阅读。

当我们需要了解一个人时需要“察其言观其行”不过也难免“误判”。

企业的发展与管理最重要的还是要了解企业自身知道在做哪些事情有哪些能力。

如果企业都不知道自身的能力和发展情况那么管理层就容易“纸上谈兵”、“朝令夕改”或选择“无为而治”。

因为不了解一线情况就会提出不合时宜、不够长期的个人主张下面的人也会“晕头转向”企业长期也可能“原地踏步”。

企业黑盒盲目低效

业务架构其实是为了“塑造一面镜子”让企业看清自己。

下面是本人之前梳理的一个整体逻辑图。

从顶层的商业模式到中间的业务能力、业务流程再到具体的系统实现与资源消耗是一个抽象层面的认知结构。

业务架构大图

说白了我们需要一个能够承上启下的模型能够让企业外的人或者上层的管理者在比较抽象的角度理解经营活动同时让具体的干活的执行者能够知道“我在做什么”、“能够产生怎么价值”“应该往什么方向演进”。

也就是把一件事抽象地讲清楚。

这个常用的语言就是业务架构大图中价值流和业务能力的部分。

下面是一个讲清楚实现“招聘员工”这个事情的案例就是采用了“价值流映射到业务能力”的方法。

价值流映射到业务能力案例来自《TOGAF

价值流的定义价值流表现为【一系列】端到端的【增值活动】能够为客户、利益相关者或最终用户【创造整体效益】。

价值流阶段的定义价值流中的【增值活动】被称为价值流阶段价值流每步入一个新的阶段就会为利益相关者【创造并增加增量价值】。

业务能力的定义业务能力是企业为实现特定【目的】或【成效】而可能【拥有】或【置换】的一种特殊【能力】或【产能】。

道理大家都懂但是该怎么做呢复杂系统下我们该如何实践关于这个问题说到了很多事情的痛点我们缺少最佳实践也就是一些优秀的模版。

如果没有这些模版我们很容易“走歪”变成“东施效颦”、“照猫画虎”、“画蛇添足”等各种辛苦但又无奈迷茫的局面。

此时我们应该去看一下业界实践和行业观点多了解大家的实践。

当我们见过好东西就知道差在哪里了也可能原本方向就是对的缺的可能就是“信念”。

2010年的一个流程整理版本是一个相对抽象的角度讲清楚了中国电信的客户管理系统要干什么。

CRM

再进一步上面是具体的一个价值流阶段展开下面是抽象出来的功能架构。

CRM

继续进一步将价值流阶段纵和一些功能主题横组合在一起的时候就从一个比较高的层次描述了企业要做哪些阶段的事每个阶段需要哪些能力支撑下面就是一本书中对上面电信系统的描述。

CRM

回过头来我们好像一直在讲如何理解企业要做什么事情需要具备哪些能力并没有具体讲如何避免盲目低效。

但是我们从日常的经验知道掌握企业方向的都是少部分高层让这部分高层理解企业的现状是他们决策的起点上面的理解实际上是一份“沟通语言”、“顶层类目”、“业务模块”的抽象呈现是“指令”、“反馈”的中间桥梁也就是打开的企业黑盒。

在这样的基础上我们可以进一步去做增量思考相关能力是否不够完善能力成熟度多部门之间的能力是否有重叠重复建设与成本新的战略要补充什么能力能力规划与组织招聘等。

做事情之前要把事情想清楚想清楚之前首先得能够有渠道和视角看到东西。

看不到看不明白也就无法思考更没法做出有效决策那么只能随波逐流听天由命。

在知识与信息爆炸的情况下传统的营销策略已经很难生效因为大家会主观上过滤各种投放的广告。

现在要想进一步促进销售就需要进入特定场景融入到不同用户的体验过程中可以称之为场景营销。

知识爆炸

回到架构场景上在相对成熟的公司中由于基础的建设相对完善我们现在很难通过一个相对简单和通用的方法解决一大类类似的问题进而需要进入特定的场景一步一步地进行场景分析和架构设计个人认为可以是进入了“场景架构”的时代。

放弃一劳永逸的幻想在这样的情况下我们很难在不打开研究对象的时候在外部进行一个切面研究就获得显著的改善效果。

一个切面就能解决的往往称为基础技术。

需要进行归类与分级在打开特定场景的情况下意味着场景的发散需要解决的问题很多在有限的时间内我们需要进行场景归类和类型优先级的排序针对不同的价值和收益提供不同的解决策略。

更加需要基础架构理论因为场景的发散我们会发现很多特殊的情况或者与原先判断相左的案例从而产生疑惑。

为此我们在解决场景问题前需要不断完善横向理论让理论更具包容性和策略性。

在多种策略背后我们需要对目标更加确认和清醒让目标真正的可持续和符合实际情况。

业务内容为先理解场景意味着理解业务这意味着我们需要跨进业务域明白生产关系各方诉求也需要增加访谈的能力了解业务背景。

同时这样意味着我们需要投入更多的精力会经历更多的反复。

不再期待架构中有“神灯”

“场景架构”的地位提升往往发生在业务发展到比较成熟的阶段是业务进入深水区时的认知改变。

如果业务本身还没有很复杂基础建设也还有空间那也还有很多的通用策略去解决问题但是这一部分往往属于技术架构、数据架构、应用架构等方面而业务架构则没有银弹。

深水区需要精耕细作

不需要架构活动有人认为完全不需要独立的架构活动架构应该回归到日常研发过程中软件开发者会在迭代中自我思考和解决架构活动基于首要位置有人认为开始就需要进行整体的架构设计这是后续工作能够不返工的关键。

在《恰如其分的软件架构》一书中提到不同的场景下需要的架构活动比例是不一样的并不是绝对的0和1的事情如果要进一步去认知比例的多少应该转向“风险驱动的原则”软件复杂风险较大的业务架构活动的比例就需要提高反之则可以控制在较低比例甚至没有。

再进一步看实际上很多软件设计或多或少都需要结构和方案的设计会考虑后续的扩展性、可维护性、可读性等方面这个架构活动的比例是天然存在的。

不过很多的问题是需不需要独立出来一个“架构(师)”的角色来承担各问题域的兼职角色。

如果这样看的话问题变得更加复杂了软件工作中架构的“恰如其分”不仅仅是架构活动的比例更需要考虑这个比例在人员上的分摊情况。

最近在架构书籍的序中看到一个观点是说到最后要忘掉自己画的圈不破不立。

这让我很触动我们身边的架构活动一直都在试图建立规则维护规则甚至想方设法植入到生产中让物理现实和逻辑空间保持强一致性然后陷入到日常管理的“权利”快感中。

回顾我们的行动本身当我们看到复杂的规则之后尝试去设计和建立新的规则时是不是想过我们是将复杂变得简化还是在复杂上增加复杂。

思考不能偷懒

数学中一个很好的例子就是过拟合。

当我们拟合的不错的时候往往我们还会乐忠于不断调整进行进一步的拟合因为这样的增量对我们来说比较轻松也容易看到结果。

当看着拟合的曲线几乎完全覆盖所有的点时往往会兴奋地欣赏着自己的杰作。

可再来一个新的点时候我们却会陷入深深的茫然才发现自己对过去发生的事情过于在意进一步拟合的快感虽省去了找新思路的的苦恼但同时也让我们忽略了我们的职责是保持一定的适应性是对未来的点进行预测。

如何忘记自己给自己的画的圈如何不固守自己的一亩三分地如何跳出自己煮出来的“温水”我想更好的办法还是要牵引不停地奔向远方去看大海看到更多的世界和想法。

当我们遇到一些问题的时候我们往往可以找到一些基本的策略可以不假思索地去执行与推进因为以前就是这么做的这样也很好做前人可能把阻力磨平了你只需要在上面做新的调整。

但是时间与阶段发生了变化我们面对的问题和环境也不一样还是用前人的思想讲述当今的故事往往是思想上的偷懒逻辑经不起深度推敲。

事情不能模糊化

可能大家潜意识里面都触碰到过这样的抉择是继续思考下去把问题想清楚还是拿着当前看似可通的逻辑去赶快拿结果。

前者会面对思维的反复充满痛苦后者却可以快速地进入操作让身体变累头脑却变得轻松。

但是思想的大海一定是要经历蜿蜿蜒蜒的曲径才能最终看到。

让你兴奋的也许是大海的波澜壮阔也许只是你为了看大海而一直前行走过的漫长道路。

忘记“圈”其实还是让我们不要做思想上的懒惰者不要享受“一招半式”唬人的快感还是要踏踏实实地踏上思考苦旅。

大话西游中可通过“月光宝盒”回到过去重新演绎历史甚至能够进行走向的影响但是总是只能改变细节很难改变大结局因为实物运行的规律是多方作用的结果。

如果很难改变如果只是重复演绎那么这又有什么意义呢

工作中如果在一个相对成熟的公司站在领导的层面可能会有这样的疑问为什么还是那么些产品却仍需要那么多人同样站在一线的人也会有这样的疑问好几年前就有的产品怎么一直要做到底是什么原因。

如果我们细细去看这些工作内容往往不是同一个团队的持续工作而是历史的多次重演

无线再到各种智能设备同样的产品在不同交互阵地上需要重新建设。

自建or共享每个业务线都可以选择自建因为共享的产品内容往往因为人员有限支持粒度有限不够高效所以不同业务可能也需要重复昨天的建设。

范围变了原来大家都是管好自己产品内的逻辑即可因为大盘的增量本身会带动各个产品的增量但是当增量有限大家就需要扩大产品的覆盖范围就需要从考虑大盘变成考虑各个其它产品场景走入了各种叠加下产品逻辑设计的长尾工作中。

维护人变了即使什么都没有变化但是人还是可能离开那么新进来的人势必需要时间学习通过各种资料去调查历史的故事了解各个模块的设计和具体实现。

在一些团队“老人”的眼中他们能够看到之前的一些故事能够看到一些差异点知道”重演“的原因。

但是在团队新人的眼中并不会感知之前的历史只能看到自己在改写新的历史但是如果被问到“为什么这个产品好几年了为什么还在做”时可能并无法理解。

我觉得工作中“重复”的事情之所以那么多因为我们工作的那层还是过于靠近业务同时建设成本其实也并不高。

只要有团队能够想出差异点只要这个热度比较高就很容易走向自建或者各种设计的漩涡中。

就好比一个街道上开了个奶茶店很快就会有一堆奶茶店只要有赚头就会有新店。

我们很容易回答要做什么因为做了可能就有机会能找到各种逻辑而且往往不用考虑成本公司兜底。

这个问题很类似的就是经典电视剧可能每个几年就会重新拍一下。

观众变了演员变了拍摄技术变了即使故事情节也没有变还是会有消费的群体以前看过老的版本的人可能也不在目标客户中。

回过头来如果工作中我们在反复建设以前的产品同时老板又会疑问为什么还需要那么多人时其实还是要回到我们的业务业务在反复打开月光宝盒期望引入各种变化能够将原来特定结局演绎成多个版本为了他们的不同策略这些策略可能是为了不同人群可能是为了不同行业可能是为了不同交互等。

但是是否真的”重复“的关键还是在于他们的策略或者目的是否在反复还是在不断细化完善。

这有着截然不同的感受的一个是产品的重复建设or返工一个是产品的逐渐完备

很幸运的是我们的工作时间有限很难经历一个产品的多次反复总会有新的人演绎新的故事是否重复并不重要有人消费可能就够了。

此外好比电视剧虽然各种支持人员可以减少但是演绎的人员的确要那么多并不可能一个人演了全部的角色。

那么工作中可能只有减少产品新的各种功能才可能减少特定的人员。

认知有限我们不如专业人士擅长

近期参加了儿子幼儿园的家长开放日期间看到老师教小朋友唱歌很有感触这里分享一下。

北风北风呼呼呼

抛出一个问题冬天那么冷做哪些事情可以暖和有很多回答洗热水澡多穿衣服。

继续递进问题能不能不通过外物保持暖和也有很多回答做运动搓搓手等。

然后问大家可以听听音乐中有哪些活动开始播放音乐。

听完后大家补充回答可以搓手、跺脚、拍球。

老师将提到的东西做成卡片贴在小黑板上。

然后问哪些歌词出现了3次大家回答北风北风呼呼呼、雪花雪花飘飘飘、天天锻炼身体好。

然后通过播放音乐大家按照黑版提示唱了几遍。

然后分2组让大家依此进行了表演。

我发现通过这样一轮操作下来小朋友们很快能够记住歌词内容并唱出来。

这对于思维比较简单的小孩来说的确很不容易。

这让我遐想万千因为我们作为程序员工作中很关注逻辑、结构、复用等。

但是我们却没有很多好的实践无论是大家对于一套架构的理解还是说对于团队系统的认知。

但学歌这个过程让我觉得大道至简很多事都是相通的甚至于说我们陷入于软件世界中缺少了最为广泛的生活视角思考的源动力有限。

生活是最好的老师也是智慧最多的地方。

提出一个关注点问题将这个问题进一步细化描述形成一定的目标将需要了解的内容呈现出来带着问题去观察了解大家可以一起探讨互相补充理解尝试发现规律比如什么经常重复有哪些重要动作形成自己的串联理解尝试描述出来进行实践大家展示交流。

我不知道按照我们日常工作中的一些理论或者逻辑能否实现快速教会小朋友们这样的事情。

或许说我们日常的工作中的事情本没有什么深层次的逻辑只是将砖头从A点搬到B点有时也会再从B点搬回来。

并没有思考如何搬如何搬的更好也很难教会拌水泥、扭钢丝这样的工作。

事实上我们可能得承认我们的认知有限。

最后分享一句最近看到的话“好的设计的重要目标之一就是让系统一目了然”可能也是大道至简。

拓展阅读