集成可以简化应用程序架构吗
【IT168 专稿】
在本文中，我们将讨论一个怎么样的一个架构的客观是重要的——简化你应用程序的贡功能——能够通过应用重要的原则来促进。
你可能尝试着来使用业务用例来简化你应用程序的功能。但是你预想的更多的应用程序在“退休”的行列，看起来所花费的努力就更多，你知道正确的决定是使得大数量的陈旧的应用程序退休。如果复杂的架构包围着老的应用程序，常常引得大的业务从日益增加的产品开发时间、减少的销售量和很高的维护成本中蒙受损失（你用多少钱来持续支持你大型的应用程序的维护清单开销？）。因而这些增加了应用程序开发、维护等的IT开销。但是，这些损失很难去分离和量化，虽然越来越难展示在商业效益和IT架构投资方面的联系。
一．花费的简化
如果你像大多数管理者一样，你可能会构建你的用例来单独的简化你的架构在当前的IT功能中的改变。你估计减少陈旧的应用程序的开销，或者简单的将这些东西去掉（这就是说，为了额外的特征、扩展和修改没有做新的开发），并且接着将改变集成到架构中去。这些业务用例常常看起来是不起眼的，带有消极的呈现价值或者很长的回收周期，因为用来重建联系或者那些在不清晰的应用程序中构建的功能性花费了大量的的高档的投资。
一个更好的方法是将应用程序估价与全面的集成策略联系起来——这点能够保持在一个最小限度上重建相互之间的联系。毕竟，集成最后将简化了应用程序的30%到60%的花费。就像你找到了战略性的方式来集成你所有的计划的应用程序改变，你的花费遍布所有的这些相互联系中，并且他们相应的减少了。更好的是，你能够将较少的花费与降低商业风险、增强基于商业目标相互协作以及更少地花费资源联系起来。并且，业务用例突然变得明朗起来。你终于有了一个强制的需要做的活动。
摆在眼前的一个障碍物就是在使得在业务增涨方面简化应用程序架构的可选值常常很难量化和验证，因此在IT实践中应用得并不广。
这里有一个窍门就是尝试用一种更加宽阔的方法来简化你的应用程序架构，而不应该是开始于切开你的IT应用程序功能，以及对哪些功能你在应用程序中你可以舍弃的估计，而应该起始于集成策略。决定有多少努力将会用在联系这些应用程序上，并且通过一个简洁的集成方法来减低这些花费（例如，为了应用程序到应用程序进行连接的集成服务器）。接着，通过使用新的集成策略来再次简化你的应用程序。在三年内计划一个阶段性的方法。最后，将这些这些商业价值的因素包括进去：减少商业风险、使用业务策略重新分配、减少IT支持和增加IT风险的可见性。
既然应用程序的相互联系能够为简化架构的60%的花费做出贡献，所以为了减少花费这样做是很自然的。减少相互间联系的花费的关键是预先映射一个集成策略，接着决定哪些应用程序是最不耗费钱的，将它们从链中剔除。
二．映射你的集成策略
你将会需要通过一个策略将你的交互作用类型与集成工具匹配起来。例如，你的应用程序主要是在做系统到系统的事务处理上吗？典型地，这些系统通过点到点的接口联系，没有遵守软件工程原则。这些架构包括业务逻辑，这些业务逻辑常常没有在一个定义得很好的集成接口中得以包括或呈现；数据库没有很好的与接口隔离；数据映射一次都没做或者重新做了很多次。作为结果的接口常常在一个没有图形用户界面、调试或者测试工具的的语言中。做任何的改变需要主要的IT项目。这些应用程序的类型需要一个EAI工具来驱动使用集成服务器的基于应用程序的集成。
从另一方面来说，你需要为那些不是系统到系统的事务的应用程序来提供另外的工具。最终用户的应用程序需要有直觉的接口，并且因此趋向于通过使用基于工作流的集成工具来实现更好的集成。这些应用程序典型的没有参加处理事务或者过程，它们在多线程的数据提取系统之上，这些多线程系统对于建立互相联系来进行操作性等的数据存储是非常完美的。最后，对于带有强壮的基于Web的架构的环境，考虑基于Web Service的集成。
一旦你有一个集成映射来显示主要的集成类型和工具，你就能够通过在你的映射中定义的机制来估计每一个没有带策略的应用程序的花费。
识别有策略和没有策略的应用程序。简化应用程序功能的第一步在于分离应用程序（这些应用程序将会被使用作为先进的系统而不是那些不需要的系统）。这个估计将会基于业务和IT标准的混合，包括他们是如何很好的使得你们公司、卖方产品计划和重要的限制（如果有的话）的业务策略提供所需要的业务功能。
接着你必须精炼基于额外的因素（例如退却的时间周期、在一个中间时期提供需要的能力的减轻、代替在功能上克服限制的应用程序的可用性、在当前的业务程序功能中，重复的或者冗余的应用程序以及一个IT技能集的可用性等）的分类。
决定哪些应用程序是应该舍弃或者暂时不用的。一旦决定了这个，这些应用程序将会有两种选择，暂不实现这些应用程序或干脆不实现这些功能。当要舍弃这些应用程序的时候，额外的特征、开发、扩展和修改变得不合适。如果暂时不实现的，考虑的主要因素是是否花费超出限制。
三．业务用例的简化
现在你准备开发你的业务用例。首先通过考虑如下三种主要的开支来计算花费：为了一个选择的工具的实现花费（这个指的是，为了购买一个软件license，硬件，培训和改造开发所花的钱）、构建没有的系统功能的花费以及迁移数据的花费。
接着，在你计算收益的时候，不要忘记还需要包括在项目的开发过程中所做的减少花费的集成努力和在服务和维护需要所做的支持所带来的收益。整体上来说，你能够通过包括复杂的系统到系统的事务系统来即刻减少支持费用，因为EAI编写者是可用的，并且还是可重用的。为了一个新项目所做的集成努力的潜在花费的减少将会因为你当前应用程序功能的复杂性和业务情况而有所不同。例如，一个公司完成了一个合并，并且在寻找一个通用的架构的配合的话，将会发觉集成策略的利益是有实质意义的。
将花费和利益放在一起，你能够为了减少一些不必要的应用程序来构建你的业务用例，而不是在你发展一个业务策略之前。用来舍弃的比较小的外围应用程序（它们的功能已经在新的容易制成的应用程序中包括，因为它们不需要主要的数据的迁移和额外功能的构建）的业务用例。从另一方面来说，对于已经深入人们所习惯的、已经很自定义化的、并且有一大批重要数据的大的核心的进程系统，业务用例的典型的结果是带来负面结果的POI。在这些情况下，暂时不实现这些功能可能已成了一个唯一可行的方案。你仍然有机会通过自己做或者到外面去采购来管理这些应用程序的维护费用。
就像你通过为集成制作一个业务用例的第一个方案的方式一样，不要忘记将业务用户包括在其中。虽然，对其进行监视并且为企业架构实现计划是你的工作，但与这些最终的应用程序功能打交道的还是这些业务用户。这里可能还会有一些隐含的业务花费，这些花费能够动态的改变公司的整体的业务用例。
例如，虽然暂时不实现一个遗留下来的定制的应用程序，可能按照IT支持和维护费用是一个最好的决定，但是业务用户可能发现他们不能提出用新的架构策略来维护他们的竞争优势。在这种情况下，进一步的加强以便采用应用程序以便限制业务危急的进程的缩短可以减少业务的开支。
因此，你需要提前想想你们的第二个方案——与业务管理者合作——就像你建立架构时时的视点一样。你的新的视点将会在复杂的企业架构中得以不断的分解，而变成一个从IT中创建一个具有真正价值的物体。虽然开发业务用例是很耗时的，但是在严厉的量化花费、利益和关联风险以及最后提高对已存在的架构的限制的嵌入的透明度等都具有真正的价值。
0
相关文章
关注我们
