集成可以简化应用程序架构吗
二．映射你的集成策略
你将会需要通过一个策略将你的交互作用类型与集成工具匹配起来。例如，你的应用程序主要是在做系统到系统的事务处理上吗？典型地，这些系统通过点到点的接口联系，没有遵守软件工程原则。这些架构包括业务逻辑，这些业务逻辑常常没有在一个定义得很好的集成接口中得以包括或呈现；数据库没有很好的与接口隔离；数据映射一次都没做或者重新做了很多次。作为结果的接口常常在一个没有图形用户界面、调试或者测试工具的的语言中。做任何的改变需要主要的IT项目。这些应用程序的类型需要一个EAI工具来驱动使用集成服务器的基于应用程序的集成。
从另一方面来说，你需要为那些不是系统到系统的事务的应用程序来提供另外的工具。最终用户的应用程序需要有直觉的接口，并且因此趋向于通过使用基于工作流的集成工具来实现更好的集成。这些应用程序典型的没有参加处理事务或者过程，它们在多线程的数据提取系统之上，这些多线程系统对于建立互相联系来进行操作性等的数据存储是非常完美的。最后，对于带有强壮的基于Web的架构的环境，考虑基于Web Service的集成。
一旦你有一个集成映射来显示主要的集成类型和工具，你就能够通过在你的映射中定义的机制来估计每一个没有带策略的应用程序的花费。
识别有策略和没有策略的应用程序。简化应用程序功能的第一步在于分离应用程序（这些应用程序将会被使用作为先进的系统而不是那些不需要的系统）。这个估计将会基于业务和IT标准的混合，包括他们是如何很好的使得你们公司、卖方产品计划和重要的限制（如果有的话）的业务策略提供所需要的业务功能。
接着你必须精炼基于额外的因素（例如退却的时间周期、在一个中间时期提供需要的能力的减轻、代替在功能上克服限制的应用程序的可用性、在当前的业务程序功能中，重复的或者冗余的应用程序以及一个IT技能集的可用性等）的分类。
决定哪些应用程序是应该舍弃或者暂时不用的。一旦决定了这个，这些应用程序将会有两种选择，暂不实现这些应用程序或干脆不实现这些功能。当要舍弃这些应用程序的时候，额外的特征、开发、扩展和修改变得不合适。如果暂时不实现的，考虑的主要因素是是否花费超出限制。
0
相关文章
关注我们
