对于SOA架构咨询，其核心还是在于组件化和服务化，然后才是服务管控和治理，基于服务化思想对传统软件开发生命周期过程的改进。SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构，或者更多的人仅仅是将SOA理解为service服务接口，这些都是对SOA方法论很大的误解。
SOA咨询一个重点就是业务驱动IT，而非单纯的IT架构咨询，SOA咨询一般都会结合企业架构和云的思想，结合组件化架构和领域服务的思想，高层结合BPM端到端流程整合目标，并对这些内容进行有效的融合。在整个过程中包括服务全生命周期治理和管控的内容。
对于传统企业信息化应用和架构的诊断，需要的还是从企业的业务流程或业务域出发，整理出企业当前的业务架构，转换为组件化业务模型，然后结合当前已有的应用架构进行差距和匹配分析。在技术方面的诊断最关心的点主要还是在当前的应用架构是否是一种完全的松耦合架构模式。即当前的业务系统组件化的实施情况，当前的业务系统组件提供的服务接口的实施和集成情况。在和很多企业的架构咨询和交流中，一个普遍的情况还是在企业信息化建设初期没太注意总体规划的事情，没太注意平台层建设，后期增加新的业务系统或新的功能组件都相当随意，这些都直接导致了后续一个业务系统越做越庞大而且无法拆分，或者说企业内的多个业务系统间关联依赖关系相当复杂，接口也千差万别，但是无法解耦。这些都直接导致了后续整个IT运维和管控相当困难。即使有些企业用了ESB服务总线，但是也没有解决上述的问题，ESB总线仅仅是服务管理和中介的平台，关键的问题还是在于组件划分的是否合理，服务的识别粒度和复用性是否合适。
一个企业的信息化建设后期，由于系统越建越多，都会想到一个问题就是打破系统边界，然后能否按照组件开发，组件后续组装和集成方式来构建企业内部IT。这样的好处就是SOA思想和组件化思想已经进入到系统内的架构设计，同时解决掉原有的业务系统内多个模块紧耦合无法拆解的问题。但是这种做法有一个前提，即首先是要有云和平台化的思想，即构建公共的可复用的技术平台层，将原有业务系统中和业务不相关的内容全部下沉到技术平台层，形成可共享的技术服务能力。只有这样做了，上层的业务系统才能够转变为一个个相当干净，并且只关注业务的多个业务组件。
业务系统或组件间的集成模式是我们在SOA架构诊断中经常发现问题的地方，即在多个上层业务系统或业务组件间，当发生依赖和交互的时候，应该是调用组件暴露的业务服务和数据服务能力，这些服务能力本身是属于领域服务的范畴，同时有效的屏蔽了底层数据库的实现逻辑。而当前我们看到比较多的情况还是数据库通过dblink等方式的直接访问或开放，这直接导致了多个业务系统或组件间发生了更强的细粒度层面的关系和依赖，加大了系统间的耦合程度。这样在做的过程中确实方便了，但是跨过了逻辑层或领域服务逻辑，直接导致了后续运维和管控相当困难。一个典型现象就是对于自己是owner的应用的，其数据库信息发生了变动都无法有效追溯，而且也无法快速查询自己的数据库究竟外围有多少业务系统或功能模块在调用，是哪些业务场景导致了这些调用。
数据问题是我们在SOA规划咨询中发现的另外一个主要问题，即由于为了满足系统间集成的需求，出现大量的数据交换和集成，同样一份数据多点落地导致的数据及时性和数据不一致问题。这个问题的本质还是没有对共享数据或主数据进行统一的规划和考虑，还有就是思维仍然停留在数据交换上而不是数据服务能力提供上。而数据服务能力提供本身数据是不会导致数据多点落地的，这个在架构层面很多企业都没有很好的解决这个问题。
在一个企业复杂的IT应用架构下，特别是到了运维和变更处理阶段，我们需要的就是对于企业内部运行的业务系统，接口和相互依赖关系了解的相当清楚，组件之间本身也处于松耦合的一种状态。对于新来的任何一个需求变更我能够快速的分析出来究竟应该实现到哪个组件里面？是否存在接口的变更，是否会影响到其它的业务组件或功能，整个变更如何多个组件配合变化后统一集成和发布。这些都是实实在在管控阶段的关键，如果没有一个清晰的SOA组件化架构，组件集成架构和服务接口清单，那么就很难快速的分析这些内容，而导致每次都由于变更影响分析不足而导致的发布故障或版本回退。
SOA技术架构不要考虑的太复杂，其本质仍然是组件化和领域服务设计思想下，可复用组件设计，服务接口的设计这些传统软件架构设计的内容。目的就是首先要解耦，其次才是解耦后的组件能够快速的装配。这些思想没有理解而一下进入到单个服务识别或接口的设计，那就很难从全局来掌握整个SOA架构的合理性。
青春就应该这样绽放 游戏测试：三国时期谁是你最好的兄弟！！ 你不得不信的星座秘密 