应用集成框架之逻辑架构的价值

[2014年2月13日,陕西西安]考虑逻辑架构的一种方式是把他看作一种帮助我们尽可能快把需求变为可以用代码实现的物理(和特定技术)架构的简单有效的方法。在这种方法中,逻辑架构本质上是可抛弃的。另一种方法是您也可以把逻辑架构本身看作是战略性的资源从而进行积极地维护。在这种方法中,如果想用心的技术重新设计您的系统,逻辑架构可以提供一个系统的极好的抽象。在许多项目中采用的方法介于这两种方法之间,只有部门项目创建并维护逻辑架构。

1、使逻辑架构最小化

如果逻辑架构不仅仅是一种能够尽快到达物理架构的方法,您只需要产生足够的逻辑架构来证明您理解了当前的需求且这些需求已经适当地分配到解决方案中。

在极端情况下,根本不需要逻辑架构。在某些情况下这是有可能的——例如,当系统的需求和那些已经存在的系统类似的时候。在这些情况下,您可以通过查看现有的系统来得到架构的主要元素。另一个例子是包含一个封装的应用或现有的系统集成,需要的东西已经存在,因此可以把逻辑架构的需要最小化。

另一个因素是系统的复杂性。例如,当您预见到系统非常分散且在逻辑层考虑部署将有助于您在物理层理解部署元素时,您可以选择开发一个逻辑部署模型。

2、把逻辑架构作为一项投资

除了把逻辑架构作为从需求到物理架构的有价值的垫脚石之外,在预见到技术变革的时候,逻辑架构还可以维护以提供一个良好的开端。您能够使用当初的逻辑架构(假设系统需求没有改变),不会因为技术变革而必须重新发明创造,因为总体来讲,逻辑架构是独立于技术的。

与不强调逻辑架构相对的是逻辑架构看作是对技术变更有免疫力的投资。由此,从投资的角度来看,在预见到未来能够支撑系统重新设计的技术变革时,维护逻辑架构是有意义的。

在决定是否把逻辑架构看作是对技术变革有免疫力的投资。由此,从投资的角度来看,在预见到未来能够支撑系统重新设计的技术变革时,维护逻辑架构是有意义的。

在决定是否把逻辑架构看作是需要不断维护的东西时,请考虑下列问题:

系统大且复杂吗?它的开发可能会持续很长时间吗?周期长的项目更有可能从逻辑架构的投入中得到回报。

系统需要好几个版本来发展并在它的生命周期中可能需要适应技术上的变革吗?在进行技术上的变革时,参考独立于技术的架构描述经常是有用的。

有开发和维护逻辑架构的能力吗?主要由开发人员或程序员组成的组织可能没有从架构上进行思考的人。如果由于没有能力而不能开发或维护逻辑架构,最初的投资成本(培训或雇用的)将很难证明是恰当的,构建这样的一个架构简直是不可能的。

3、可追溯性的重要性

无论您采用哪种方法,理解如何从一个产品得到另一个工作产品很重要,这种知识能够让您对改变一个需求或架构元素所造成的影响进行分析。在开发过程中把可追溯性描述到什么程度,还要考虑可追溯性是显示的(例如添加特定的支持科追溯性的建模元素,例如需求实现。)。

本文来源:时光·协同
更多
相关文章
关注我们
媒介联系

Email:marketing@cicro.com

TEL:(8629)87579521

FAX:(8629)87579518