您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
     
   
 订阅
  捐助
Togaf的四大架构——信息架构理解分享
 
2794 次浏览     评价:  
2019-8-21
 
编辑推荐:
本文作者Heavin,文章介绍了信息架构的目标、组成,以及信息架构和业务应用架构的区别等相关内容,希望对您能有所帮助。

信息应用架构更多是继承前面的业务应用架构,分解成更具体地信息系统建模,也可以理解成让业务语言转换成大家都理解技术语言建模,当然也是把技术语言转换成业务语言的表现方式之一;同时注意在信息架构时的架构愿景的体现和采纳,并如何展开服务能力的转换,而相对于业务应用架构的区别主要如下:

1、信息应用架构面向的核心干系人已经不是对战略决策层、业务高层等的支持与共识;而是更关注的具体如何展开,采纳架构原则,为实施行动提供指导作用。

2、主要面向的核心为研发实现和业务数据生命周期,而业务数据生命周期主要由系统推广模式和用户模式所决定;所以很多是关注数据流、UI交互、展示等方面;而研发更多是系统间的服务、对象依赖关系

3、业务架构的时候已经创建架构目录集合;在信息应用架构则是更新和添加新的架构内容目录集合。

4、较于敏捷开发模式的参考、IPD等集成,实际研发中,因利弊经验积累,没有那家公司采用瀑布模式,即在信息应用架构的时候全部的系统分析清楚后,再进入研发实施;这个是比较与其他研发体系混合应用重要体现。如全部的UI设计,即不建议在这时候,把全部的UI全部设计、全部的数据建模、流程刻画设计的绝对完成,而是进入小型的迭代模式,一边构建UI、流程模型、一边实施的并行敏捷方式。以提高产品快速响应能力。

因此在很多研发同学中,总是感觉项目好像没有分析清楚,完毕就进入了研发编码设计实施。其实是没有真正的经历过瀑布模式带来的时间成本浪费,还有无论如何分析,总会难免有不完整的一点点,而导致的后面设计缺陷,引起整个系统的信息应用架构重新设计的风险。

5、针对核心平台的研发过程,则相对要谨慎,稳定平滑、兼容等非功能性的属性需求要求,可适当的加强信息系统应用架构。也可以结合项目特点采纳必要的活动环节。

详细如下:

1、当随着系统、服务的增多,造成的复杂;出现增功能、改需求A、B系统,服务就出错;并且是恶性循环;这种跟本性的问题肯定是缺乏系统应用分析;

2、不信各项活动回顾打开这些建模分析。肯定要么是没有;要么是设计的恶性闭环循环造成

   
2794 次浏览  评价: 差  订阅 捐助
 
相关文章

UML概览
UML图解:用例图(Use case diagram )
UML图解:活动图(activity diagram )
UML图解:类图(class diagram )
 
相关文档

UML统一建模语言参考手册
网上商城UML图
UML建模示例:JPetStor
UML序列图编写规范
 
相关课程

UML与面向对象分析设计
UML + 嵌入式系统分析设计
业务建模与业务分析
基于UML和EA进行系统分析设计