现在让我们转向后SOA方案。在同样的状况下，管理者可以通过公司门户站点应用政策管理工具。这种工具利用构成SOA治理框架的服务，但是管理者并不了解具体细节，他们只知道通过公司访问门户更改某些公司制度，例如，管理者可以在访问门户调整服务层面协议(SLA)，以便公司制表能够包含全部所需的报告，为公司数据调整转向时间，从“一个星期”到“一天”。

　　现在IT所面临的问题是，我们为蝴蝶效应付出了极高的代价，IT机构能够自动对管理者做出的调整有所回应吗，或者会要求IT人员进人工干预。IT是不是无法满足新的SLA？，甚至是，如果不同的管理者在同一时间更改了不同的制度，会发生什么样的事呢？IT首先要解决的是什么呢？在前SOA时代，自动化的匮乏借助人力改善受到影响的IT， 所以当遇到突发事件时，人为因素很可能在业务更改方面起了很大的作用。由于SOA治理指向了更多的自动化制度管理，但是许多公司却在铤而走险，将人为判断智能化。

　　元策略解决方案

　　幸运的是，当一个公司注意到蝴蝶效应时，解决方案就简单的多了。很明显，业务要实施的制度改变和要求手动解决的IT之间是有一定的差别的。换句话说，SOA治理不仅要求管理策略，还要求管理策略的策略——你也可以称之为元策略，这样的元策略可能对策略改变是有边界条件限制的。例如，SOA策略不仅要求被授权管理人员可以得到IT的同意就可以改变策略，这种策略的改变最多可以达到10%，但是，任何超过10%的策略改变都需要经过特定经理的批准。

　　事实上，没有所谓额度全自动治理框架。从某种程度上来说，人必须直接管理策略变更。但是这个条件并不代表策略是一个骗局，但是，由于高效的SOA治理工具能够为公司如何建立，通信管理策略，提供极大的自动化和充足的灵活性，但是和其它强大的工具一样，人们必须要清楚他们使用的是什么，而且要小心慎用。蝴蝶效应带给我们的另一个启示就是IT必须拥有一定的管理权，以确保可以调用策略做出决策，如果负责策略变更的管理者不了解这些变化的内涵，那么这个问题依然存在。

　　ZapThink采取的措施

　　当一个公司实施SOA后，负责批准策略变更额度IT管理人员就会架构实施的相互依赖性有了更为深刻的了解。在前面的SOA实施前的例子中，只有数据分析师需要了解数据查询所需的时间和成本。在SOA实施后，策略改变可能会影响更多额度应用，数据源，旧系统。因此，不管策略变化有没有什么意料之外的结果，分析师也不像是进行呼叫的人。这个进行呼叫的人必须对IT有着深刻的了解，也知道用业务术语描述一个复杂策略的成本和收益。因此，这个任务非架构设计师莫属。