今天晚上临时挤出点儿时间，说个重要问题，就是“业务架构”的定义，到底什么是业务架构。
对我而言，这是个搞不懂也不耽误啥的东西，这么说没有玩世不恭的意思，毕竟我之前的实践就是这么过来的，了解我职业经历的朋友都知道，我入行业务架构是挺偶然的，属于单位的工作分配，让我做我就做了。
说实话，作为一个执行力很强的银行人，我真的没管这东西是什么，而且它的全局化、结构化思维方式本就是我喜欢的，所以在不知道它到底是什么的情况下，开开心心的干了好几年。你会觉得这有些反逻辑，不过，工作就是工作，何况还是个挺让人喜欢的工作。我们被告知了要做什么，做的东西要用来干什么，自己再琢磨琢磨怎么干好，就行了，没在意它到底姓甚名谁，是谁家的孩子，在手里就养着了，养了当然也要尽力养好，与其学究式地研究它是啥，到底有没有用，不如走起来，斜不斜，走走就知道了。
所以我确实没太在意过它到底是啥，就这么干的也不错，上上下下都挺认可的。直到有一天这种率直的幸福感开始有变化了，那就是我写书了。自己干不在意它是个啥其实问题不大，但是写书不行，写本书连个定义都没给出来，这说不过去啊，所以挺认真地思考了半天，我在业务架构那本书中第一次给出了我自己的定义，在聚合架构那本书中又发展了一次。经典理论的定义也都不错，只不过跟我自己的感觉还有些差异，所以自己搞了一个，感兴趣的话，大家可以到书上看，今天虽然话题是什么是业务架构，但是我不打算按常理出牌，我认为对于业务架构的定义，来自于你对它运转方式的理解，而不只是你落笔的那些话是怎么写的。
对于业务架构的运转方式，我觉得，其核心首先是结构化地分解事物，这是认识事物的基本方法，业务架构也不会例外，那么它采取的方式就是把过程和对象都持续向下分解，来找到基本组成单位，这就是流程建模和数据建模干的事情，这种拆分将复杂的业务变成了一地碎片，将业务拆成拼图，但是拼图是一块一块拼起来的，不是拼两张图再试图压成一张，这就是流程和数据为啥要结合在一起分析，合在一起，才是一块一块的拼图，而不是搞两张图再压到一起，这也是为啥我要在聚合架构中把任务和数据实体合起来称为业务构件的原因。
基于这种运转方式，业务架构先拆后拼来分析所有业务，所以就方法来讲，它可以分析局部业务，也可以分析全局业务，后者效果会更好，因为你看到了更多，才有不一样的风景，管中窥豹就只能略见一斑，威力发挥的差了些。
既然基本原理如此，就不要把业务架构理解的、写的太复杂，那样就遮掩了“底层逻辑”，现在企业架构有些火，这方面的文章多了，但是企业架构自古有着大体量的传统印象，所以介绍文章往往写的范围广阔，容易让读者“迷失”，提醒一句，千万不要想复杂了，那样就把最基础的东西忽略了，我的架构文章和书籍始终坚持，业务架构是简单的方法，业务可以是复杂的，但是分析方法不因该，因为，复杂的业务对上复杂的方法，做错的概率远大于做对。系统设计也是一样，如果你放松一点儿看面向对象，也如是如此。最近看了一本厚厚的软件工程书籍，然后忽然发现，全书的图基本都是一个风格，都是基于对象关系描述的，无论是需求还是服务还是硬件描述，都是一个风格，“底层逻辑”很统一。
业务架构运转方式的第二个关键点就是目标导向。“为啥干”比“怎么干”重要，因为不搞明白为啥干，干着干着发现不用干，或者打偏了，就悲催了。业务架构的导向是啥，就是企业战略、企业目标呗，拉大旗做虎皮，这是必须的，不然没有啥理由值得你千辛万苦去干一件打地基的事情，做业务架构就是打地基，为企业寻找实现目标的路径打分析方法的地基，企业越大、越复杂，筑基时间就越长，反之就会短。干啥都需要方法，除了少数军事天才是在战场上直接练，古代的统帅、军师们往往要自我修炼一阵子乃至拜师学艺，现代的很多要军事院校科班毕业了，无论自学还是上学，学的都是作战指挥套路，以套路为基础再去临时发挥。这就是基础，军事学习的特点就是，学过的战例基本不会再出现，很多战例考古可能都有问题，所以，战例无法直接使用，看看而已，作战的时候还是要先清空脑袋，呼唤战神附体。企业往往只有在真心需要企业架构的时候才能较好地落地这一方法，因为，你愿意做，就会克服困难做，而不是见硬就回。真心需要，才能最后见到效果，做架构，从心出发。
基于这两个点，全局化、结构化地分解事物，目标导向，你可以自己定义和理解业务架构，以及对你而言它该包括什么。
我喜欢用架构思维去看其他东西，并不是因为自己只会这个，就拿着锤子到处找钉子，因为它本质上是个认知方法，所以也就是通用方法，可以作为基础分析逻辑广泛使用。好了，这篇文章就到这里，自己找自己的定义吧，如果大家碰巧一致更好。
