业务架构图，相信大家并不陌生，但应该怎样画项目的业务架构图，相信很多人就不是很清晰了。接下来，我把近期画项目组的业务架构的经历分享给大家。
首先说下项目组的业务。我们项目组致力于服务第三方系统，主要负责消息发送，及数据可视化。通过模板的制定，发送渠道的选择，从而将可用，可靠，用户需要的数据发送到用户手中，帮助用户成长。三方系统可以调用我们系统的接口，自定义模板，发送数据。系统理念：无处不入口，无处不按钮，真正符合面向对象的原则，做到封装，高复用。
那么，要实现这样的系统，业务架构图应该如何来画呢？
1、业务架构图，要体现项目的整体业务，而不是具体业务。简言之，就是根据面向的对象不同，是展示具体的业务，还是做到业务的抽象。
2、业务架构图要分层，要形成一个闭环，不能上闭下开，左闭右开。
3、业务架构的颜色的选择，不能太鲜艳，要显得沉稳大气，尽量避免太亮或太暗的颜色。
4、业务架构图的间隙要始终，不能太大或太小
5、业务架构图的整体排列，要体现过程性，打个比方来说，从上往下的排列，最下层是数据源，中间是业务，上层是前端应用，左边和右边可以放基础服务或数据分析
6、业务架构图的业务的展示数量要均衡， 打个比方，渠道管理模块包括，微信，钉钉，短信。模板管理模块，只有一个自定义。这样在数量上不对等，是不允许的。也影响整体的美观性
下面，展示下我对于项目组的业务架构图的一个迭代过程
1.0版本
这个版本的业务架构图属于典型的上闭下开，不对称，业务太繁琐具体，没有体现全局性，且业务划分没有范围，太泛泛
V1.1版本
较第一版有了进步，至少增体上看起来是一个闭环，业务也划分了具体的范围，但基础服务数量不对称，印象整体美观性，数据源显示数量太多，不够抽象
V2.0版本
较上一版有了很大提升，整体看起来比较整洁，模块划分也清晰，从数据到接收方也能体现出过程性。但不足之处在于模板之间耦合过高，还能再次抽象，且颜色种类太多，不能凸显主体业务
V2.1版本
对比上一版又有了提升，从业务上再次进行封装，分类，进一步的减小耦合，从而达到职责单一，也加入了数据管理分析，使整个系统更加完善。不足之处在于，颜色过于鲜艳，基础服务中的安全控制与过程监控存在耦合，前端应用不够具体，可以进一步的优化完善
V3.0版本
这一版作为项目组的定稿版本，从颜色上由浅入深，体现层次性，整体颜色趋于一致，模块上划分清晰，将模块间的耦合度降到最低，尽可能的抽象，也对基础服务进行再次整合，力求完善。
总结：对于绘制业务架构图，是一名架构师的必备技能，从一次次的完善与迭代中，对系统的业务有了更深层次的认识。但对于业务架构图，永远没有最后一版，一直需要完善。