【IT168 专稿】
在本文中，我们将讨论一个怎么样的一个架构的客观是重要的——简化你应用程序的贡功能——能够通过应用重要的原则来促进。
你可能尝试着来使用业务用例来简化你应用程序的功能。但是你预想的更多的应用程序在“退休”的行列，看起来所花费的努力就更多，你知道正确的决定是使得大数量的陈旧的应用程序退休。如果复杂的架构包围着老的应用程序，常常引得大的业务从日益增加的产品开发时间、减少的销售量和很高的维护成本中蒙受损失（你用多少钱来持续支持你大型的应用程序的维护清单开销？）。因而这些增加了应用程序开发、维护等的IT开销。但是，这些损失很难去分离和量化，虽然越来越难展示在商业效益和IT架构投资方面的联系。
一．花费的简化
如果你像大多数管理者一样，你可能会构建你的用例来单独的简化你的架构在当前的IT功能中的改变。你估计减少陈旧的应用程序的开销，或者简单的将这些东西去掉（这就是说，为了额外的特征、扩展和修改没有做新的开发），并且接着将改变集成到架构中去。这些业务用例常常看起来是不起眼的，带有消极的呈现价值或者很长的回收周期，因为用来重建联系或者那些在不清晰的应用程序中构建的功能性花费了大量的的高档的投资。
一个更好的方法是将应用程序估价与全面的集成策略联系起来——这点能够保持在一个最小限度上重建相互之间的联系。毕竟，集成最后将简化了应用程序的30%到60%的花费。就像你找到了战略性的方式来集成你所有的计划的应用程序改变，你的花费遍布所有的这些相互联系中，并且他们相应的减少了。更好的是，你能够将较少的花费与降低商业风险、增强基于商业目标相互协作以及更少地花费资源联系起来。并且，业务用例突然变得明朗起来。你终于有了一个强制的需要做的活动。
摆在眼前的一个障碍物就是在使得在业务增涨方面简化应用程序架构的可选值常常很难量化和验证，因此在IT实践中应用得并不广。
这里有一个窍门就是尝试用一种更加宽阔的方法来简化你的应用程序架构，而不应该是开始于切开你的IT应用程序功能，以及对哪些功能你在应用程序中你可以舍弃的估计，而应该起始于集成策略。决定有多少努力将会用在联系这些应用程序上，并且通过一个简洁的集成方法来减低这些花费（例如，为了应用程序到应用程序进行连接的集成服务器）。接着，通过使用新的集成策略来再次简化你的应用程序。在三年内计划一个阶段性的方法。最后，将这些这些商业价值的因素包括进去：减少商业风险、使用业务策略重新分配、减少IT支持和增加IT风险的可见性。
既然应用程序的相互联系能够为简化架构的60%的花费做出贡献，所以为了减少花费这样做是很自然的。减少相互间联系的花费的关键是预先映射一个集成策略，接着决定哪些应用程序是最不耗费钱的，将它们从链中剔除。
