集成可以简化应用程序架构吗
三．业务用例的简化
现在你准备开发你的业务用例。首先通过考虑如下三种主要的开支来计算花费：为了一个选择的工具的实现花费（这个指的是，为了购买一个软件license，硬件，培训和改造开发所花的钱）、构建没有的系统功能的花费以及迁移数据的花费。
接着，在你计算收益的时候，不要忘记还需要包括在项目的开发过程中所做的减少花费的集成努力和在服务和维护需要所做的支持所带来的收益。整体上来说，你能够通过包括复杂的系统到系统的事务系统来即刻减少支持费用，因为EAI编写者是可用的，并且还是可重用的。为了一个新项目所做的集成努力的潜在花费的减少将会因为你当前应用程序功能的复杂性和业务情况而有所不同。例如，一个公司完成了一个合并，并且在寻找一个通用的架构的配合的话，将会发觉集成策略的利益是有实质意义的。
将花费和利益放在一起，你能够为了减少一些不必要的应用程序来构建你的业务用例，而不是在你发展一个业务策略之前。用来舍弃的比较小的外围应用程序（它们的功能已经在新的容易制成的应用程序中包括，因为它们不需要主要的数据的迁移和额外功能的构建）的业务用例。从另一方面来说，对于已经深入人们所习惯的、已经很自定义化的、并且有一大批重要数据的大的核心的进程系统，业务用例的典型的结果是带来负面结果的POI。在这些情况下，暂时不实现这些功能可能已成了一个唯一可行的方案。你仍然有机会通过自己做或者到外面去采购来管理这些应用程序的维护费用。
就像你通过为集成制作一个业务用例的第一个方案的方式一样，不要忘记将业务用户包括在其中。虽然，对其进行监视并且为企业架构实现计划是你的工作，但与这些最终的应用程序功能打交道的还是这些业务用户。这里可能还会有一些隐含的业务花费，这些花费能够动态的改变公司的整体的业务用例。
例如，虽然暂时不实现一个遗留下来的定制的应用程序，可能按照IT支持和维护费用是一个最好的决定，但是业务用户可能发现他们不能提出用新的架构策略来维护他们的竞争优势。在这种情况下，进一步的加强以便采用应用程序以便限制业务危急的进程的缩短可以减少业务的开支。
因此，你需要提前想想你们的第二个方案——与业务管理者合作——就像你建立架构时时的视点一样。你的新的视点将会在复杂的企业架构中得以不断的分解，而变成一个从IT中创建一个具有真正价值的物体。虽然开发业务用例是很耗时的，但是在严厉的量化花费、利益和关联风险以及最后提高对已存在的架构的限制的嵌入的透明度等都具有真正的价值。
0
相关文章
关注我们
