| 编辑推荐: |
| 本文作者Heavin，文章介绍了信息架构的目标、组成，以及信息架构和业务应用架构的区别等相关内容，希望对您能有所帮助。 |
|
信息应用架构更多是继承前面的业务应用架构，分解成更具体地信息系统建模，也可以理解成让业务语言转换成大家都理解技术语言建模，当然也是把技术语言转换成业务语言的表现方式之一；同时注意在信息架构时的架构愿景的体现和采纳，并如何展开服务能力的转换，而相对于业务应用架构的区别主要如下：
1、信息应用架构面向的核心干系人已经不是对战略决策层、业务高层等的支持与共识；而是更关注的具体如何展开，采纳架构原则，为实施行动提供指导作用。
2、主要面向的核心为研发实现和业务数据生命周期，而业务数据生命周期主要由系统推广模式和用户模式所决定；所以很多是关注数据流、UI交互、展示等方面；而研发更多是系统间的服务、对象依赖关系
3、业务架构的时候已经创建架构目录集合；在信息应用架构则是更新和添加新的架构内容目录集合。
4、较于敏捷开发模式的参考、IPD等集成，实际研发中，因利弊经验积累，没有那家公司采用瀑布模式，即在信息应用架构的时候全部的系统分析清楚后，再进入研发实施；这个是比较与其他研发体系混合应用重要体现。如全部的UI设计，即不建议在这时候，把全部的UI全部设计、全部的数据建模、流程刻画设计的绝对完成，而是进入小型的迭代模式，一边构建UI、流程模型、一边实施的并行敏捷方式。以提高产品快速响应能力。
因此在很多研发同学中，总是感觉项目好像没有分析清楚，完毕就进入了研发编码设计实施。其实是没有真正的经历过瀑布模式带来的时间成本浪费，还有无论如何分析，总会难免有不完整的一点点，而导致的后面设计缺陷，引起整个系统的信息应用架构重新设计的风险。
5、针对核心平台的研发过程，则相对要谨慎，稳定平滑、兼容等非功能性的属性需求要求，可适当的加强信息系统应用架构。也可以结合项目特点采纳必要的活动环节。
详细如下：
1、当随着系统、服务的增多，造成的复杂；出现增功能、改需求A、B系统，服务就出错；并且是恶性循环；这种跟本性的问题肯定是缺乏系统应用分析；
2、不信各项活动回顾打开这些建模分析。肯定要么是没有；要么是设计的恶性闭环循环造成
|
