浅析信息系统架构的应用架构与数据架构

标签: 信息系统 架构 应用 | 发表时间:2015-08-18 07:40 | 作者:jsjbkshz031
分享到:
出处:http://www.iteye.com

信息系统架构


    信息系统架构包括了对于 应用架构和数据架构。这里不再介绍具体的方法论,而是考虑如何在设计信息系统架构时有效地避免复杂性。在应用系统层面将通过分层和配置的方式来简化应用系统,从而可以获得简单的架构。在数据架构层面将通过分层主数据的思想来考虑我们如何来管理主数据。


       应用架构


    来看一个业务应用场景。企业从生产/采购计划开始,到生产/采购管理,以及现场制造的执行。可以将应用系统划分为两种模式,如图6所示:

     图6 生产/采购应用系统划分 左:同一个系统,不同的模块;右:根据层次,分为两个系统

    图6 生产/采购应用系统划分

    左:同一个系统,不同的模块;右:根据层次,分为两个系统


    乍一看,好像统一的应用系统比较理想。但需要站在业务的角度重新思考:


    1)计划和管理的紧急度和执行不同。有些企业的计划是月度或者周间计划,有些是每日的计划。但是生产执行的系统其要求的程度是分钟级别。


    2)计算模式不同。生产/采购计划含有大量的批处理,主要利用的是计算处理能力。而生产/物流的执行涉及到大量的信息采集和信号控制,因此需要快速的交互能力。


    3)对于不同响应级别的系统,其系统需要的高可用和运维级别差异较大。如生产/物流执行系统需要实时热备,而计划和管理对于一般制造业而言,具备小时级别的恢复能力就可以了。


    而这里没有把计划和管理分开基于两个模块的交互信息多,而且其响应级别差异不大,因此将其放在同一系统中。在汽车行业内,计划/管理一般作为MRP系统,而执行一般作为MES系统。

谈完了系统的分层问题,下面再谈谈关于实现和配置的复杂性问题。图7是一个具体的例子,其中类型是应用的类型,实现指具体的系统实现,配置是指对应用系统配置完成具体的业务功能。图中上半部分指对于生产线的信息采集和发送类型的应用,经过多年的发展,形成了一个非常复杂的系统群。这导致了架构复杂,数据重复,管理运维困难,升级困难等问题。

 

     图7 信息采集应用系统

    图7 信息采集应用系统


    而经过分析,发现这些应用系统的基本功能有许多共同之处,发现系统的类型可以归结为信息收集和发送。通过设定不同设备接口的配置,可以实现配置实现对生产现场的信息采集以及控制。因此简化后的应用系统如图7中的下图所示。造成这种复杂性的原因是系统在建设时缺少统一的规划,尤其是缺少未来系统增多时的灵活扩展的考虑。最终造成了出现了大量的烟囱。


     数据架构


    在业务架构进行合理划分以及应用系统进行有效分层后,许多时候就将一些数据应该存在的范围定义下来了。但是企业内部存一些许多系统都会使用到的数据,这些数据称之为主数据。有的解决方案看起来很美,如下图:

     图8 主数据的管理和使用

    图8 主数据的管理和使用

但是,对于许多企业而言,这种做法不见得是最有效的,有时可能就是一个灾难。而且由于涉及到数据的管理流程更多,主数据管理又需要独立的系统,因此有必要考虑一种简单的主数据管理方式。首先考虑HR系统,真的有必要把HR系统的主数据独立于HR的应用系统放在主数据系统中吗?同样对于生产的车型信息放在主数据中管理也带来了较大的复杂性。因为这些系统只提供数据,而且它们的变化速度很慢,外部的系统也不会修改他们的数据。他们只要定期将变化点发送到相关系统即可。因此借助ESB的概念,利用ESB来定期更新其他系统的数据即可,如图9所示。

     图9 有效利用整合工具来管理主数据

    图9 有效利用整合工具来管理主数据


    此外的一种数据,比如对于银行或者汽车企业的顾客信息。由于其来源广,信息的真实性以及信息变化后的更新都有较高的要求,可以借鉴主数据管理的流程。但是需要说明的是,可以将同顾客信息紧密相连的应用进行改造,使得它们变成天然一体的应用系统。对于其他需要用到顾客信息的系统可以利用ESB获取顾客信息以及顾客信息的变化。


    《理想的数据架构的研究和实现》给出的层次模型我比较认可,见图10。但对于主数据而言,其实现模型值得商榷。从业务架构、 应用架构和数据架构综合考虑才能够确定是否需要集中的MDM。至少,对于许多已经具有许多系统的企业而言,根据业务和应用系统将主数据的管理分散在不同系统中是个明智的选择。当然也不能忘记,有些数据虽然不列为公司层次的主数据。但是它们在应用系统中仍然得到大量的使用,可以借鉴主数据的管理思路来有效地管理它们,实现在应用系统层面的集中管理。从而使得应用系统简单和高效。

     图10 理想的数据架构

    图10 理想的数据架构


    对于交易型系统而言,尽可能做到数据量最小化,这将使得交易系统的性能优良。此外,也使得运维便利。但是数据架构的这些内容最好最到对于用户透明,通过Portal可以让用户的体验就像在一个系统中一样。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [信息系统 架构 应用] 推荐:

浅析信息系统架构的应用架构与数据架构

- - 企业架构 - ITeye博客
    信息系统架构包括了对于 应用架构和数据架构. 这里不再介绍具体的方法论,而是考虑如何在设计信息系统架构时有效地避免复杂性. 在应用系统层面将通过分层和配置的方式来简化应用系统,从而可以获得简单的架构. 在数据架构层面将通过分层主数据的思想来考虑我们如何来管理主数据. 企业从生产/采购计划开始,到生产/采购管理,以及现场制造的执行.

企业架构-应用架构构图

- - 人月神话的BLOG
在这里要谈的是在传统的企业架构-应用架构的基础上进一步体现SOA和企业私有云平台的思想,而非传统意义上简单的原有企业各个业务系统功能架构的堆砌. 这个思想包括两个方面的内容,一个是集中化和平台化,一个是SOA服务化和业务能力组件化. 对于该构图模式考虑两种,首先第一种是充分考虑平台层独立和平台层能力的体现:.

应用架构和技术架构

- - 人月神话的BLOG
在这里再谈下应用架构和技术架构的关系和边界问题,这里的说明和标准的TOGAF会有一些区别,仅为个人理解的一些点滴记录. 首先再说下应用架构,应用架构是和业务架构有强烈的映射关系的一个架构,应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设,应用系统间的集成关系是如何的. 即我们常说的应用架构和应用集成架构.

再谈应用架构

- - 人月神话的BLOG
前面谈了业务架构和数据架构,接着谈下应用架构,对于应用架构的描述将参考togaf信息系统架构部分的内容,但是不完全相同,总体思路是围绕在IT架构层面来谈应用架构包括的内容. 为了区分高层架构(包括多个应用的总体架构)和底层架构(针对单个业务系统的架构),前者采用企业架构中的应用架构这个词,后者采用系统架构这个词以进行区分.

Java 应用一般架构

- - SegmentFault 最新的文章
原文地址: https://blog.coding.net/blog/General-architecture-for-Java-applications. 当我们架设一个系统的时候通常需要考虑到如何与其他系统交互,所以我们首先需要知道各种系统之间是如何交互的,使用何种技术实现. 现在我们常见的不同系统不同语言之间的交互使用WebService,Http请求.

iOS应用架构谈(一):架构设计的方法论

- - 博客园_知识库
  之前安居客iOS app的第二版架构大部分内容是我做的,期间有总结了一些经验. 在将近一年之后,前同事zzz在微信朋友圈上发了一个问题:假如问你一个iOS or Android app的架构,你会从哪些方面来说呢.   当时看到这个问题正好在乘公车回家的路上,闲来无聊就答了一把. 在zzz在微信朋友圈上追问了几个问题之后,我觉得有必要以文章形式专门来讲一些个人见解.

开源应用程序架构

- WCM - LinuxTOY
建筑师会在训练过程中学习并了解上千年来由不同大师所设计的建筑,而软件工程师却鲜有这样的机会去了解现实中的软件架构是什么样子. 该书列举了以下开源软件架构设计:. 该书依照 Creative Commons Attribution 3.0 Unported 发布,既可以在线阅读,也可以在 Lulu 上购买纸质印刷版本和 PDF 电子书版本(其他格式的电子书版本正在制作中).

莫要轻视应用架构

- - 灰色的灵魂
在管理大规模数据处理工作的时候,发现不少工程师,包括一些老工程师,某种程度上,都对工作有着某种程度上的轻视,常常的口头禅是“这个技术上没有什么难度”,但是我其实不太认同,所谓数据处理,在技术上没有什么难度这种说法. 的确,在这个MapReduce的基础架构已经被Google设计清楚,由Doug Cutting通过Hadoop完善实现了之后,似乎大数据处理变成了一份体力工作.

Mule应用架构:1、关于mule

- - CSDN博客推荐文章
本文介绍Mule结构上的特性,你可以使用它们构建你的Mule应用. l  关于Mule执行单元. Mule ESB提供综合的应用集成,既可服务于小型商业公司,也可用于大型企业. 企业服务总线(ESB)作为Mule的核心功能,即可利于组织内部的内网连接,也利于基于Web的API和其他云资源的外部连接.

[转]在HBase上查询地理信息系统(HBase in Action)

- - 小鸥的博客
本章我们将进入一个使用HBase的新领域:地理信息系统(Geographic Information Systems). GIS是个有趣的研究领域,因为它提出了两个重要的挑战:大规模数据处理的延迟和空间位置建模. 我们将以GIS作为透镜来演示如何让HBase适应这些挑战. 为了做到这些,你需要充分运用一些特有的行业知识.