从支撑业务需求来解读业务架构与技术架构

服务化，业务架构，技术架构是比较关注的几个架构术语，也是我一直比较感兴趣并且深度挖掘的，工作中也有相应的开发经验和架构实践。这篇文章中简单谈谈一点体会。

对于系统服务化的实现路径会有以下的一句话

通用功能模块和业务组件重新分配和组织，通过业务架构和技术架构，实现通用模块化和业务组件化，最终实现服务化。

这句话咋一看很有道理，但是足够抽象，并且没有实践参考性，光是功能模块如何划分便是是一个技术团队内部容易争吵的敏感点，更不用说重新分配和组织。

充分的理解技术架构和业务架构，有助于推动组织内部实现服务化。

在我看来，技术架构中技术性因素占比较重，也就是说，技术人员在做架构决策时，会把技术因素放到第一位。比如，考虑设计是是否充分体现了面向对象的设计思想，模块内部是否足够的高内聚，低耦合，或者说对冗余设计极度排斥。

业务架构要求实施者对技术和业务有很深的掌控能力，业务熟悉和全局把控正式技术人员，或者说技术架构师欠缺的。

以下是从服务中心的建设中来体现技术架构和业务架构的作用和适用场景

在《企业IT架构转型之道》第四章共享中心建设原则中，专门提到服务中心的划分原则。

架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术，成本，资源，性能，团队等各方面进行平衡，以最效的解决主要问题。服务中心建设要考虑，运营，设计，和工程单个重要方面。

我对上边的观点进行一下解读，第一方面：技术是架构中考虑的主要方面，但不是唯一方面，甚至不是考虑的最要维度。架构是逐渐演变优化的，是一个动态的过程。返回头说，服务中心本身是一个业务领域的概念，所以服务服务中心的建设，更多的是技术架构和业务架构的有机结合。

第二方面：我们要不要忘记系统总是以解决一定的业务问题为最终目的，开发的输出系统功能能够有效的支撑业务部门的运营活动，便是考量系统价值的重要因素，我们不能过度沉浸在技术设计的思维中。

实际的开发经验中中的教训，过度的追求技术架构，必然会忽略业务架构在系统中应有的价值。换一种思路考虑问题，思考系统在现有的技术架构下【是否能够有效的支撑业务需求，符合复杂的业务场景】 ，如果能，则技术架构是合理有效的，否则架构需要演化，调整和更新。

用【现有系统的支撑业务需求能力】作为系统服务化转型的一个量化标准即业务架构和技术架构孰重孰轻，以及判断现有技术架构是否合理的。