前面谈了业务架构和数据架构,接着谈下应用架构,对于应用架构的描述将参考togaf信息系统架构部分的内容,但是不完全相同,总体思路是围绕在IT架构层面来谈应用架构包括的内容。为了区分高层架构(包括多个应用的总体架构)和底层架构(针对单个业务系统的架构),前者采用企业架构中的应用架构这个词,后者采用系统架构这个词以进行区分。
首先说下应用架构中静态的部分,包括了应用功能架构和应用数据架构两个部分的内容,应用功能架构由业务架构中的业务组件架构转化过来,应用数据架构由业务架构中的业务对象数据架构或全局ER模型转化过来。中间会体现出映射关系。
对于应用功能架构可以比较明细的看到和业务架构之间的映射关系,但是要强调的是高层应用架构图中已经会明确的体现出了具体的业务系统,因此业务架构中的业务域业务组件和应用系统间往往不是一对一的关系,其中既存在合并也存在拆分,比如对于采购可能是独立的业务域或业务组件,但是在构建应用系统的时候可能是构建一个大的供应链系统;而财务是一个大的业务域,但是又可能拆分为报账,预算,成本管理等多个业务系统。这个一方面是结合企业实际情况,一方面仍然是考虑系统分解的粒度和耦合度。第二点应用架构和业务架构的不同体现在应用架构重点已经是在实现层面,需要实现业务架构朝IT架构层面的抽象和转化,最明细的就是底层可能会抽象相应的基础平台和技术平台,而上层或抽象相应的门户等,这些在业务架构中是绝对不会关心的内容。
业务架构阶段的数据架构重点是业务和领域对象,数据域的划分,主数据的分析和识别,重点是数据的概念模型。而到了应用架构则需要将业务对象转换为数据对象或具体的数据库表对象,应用架构的重点则已经是逻辑模型和物理模型。同时在应用架构阶段已经在分析数据对象和应用系统和应用功能之间的CRUD矩阵,以明确功能边界划分的合理性,以做到更好的系统划分和高内聚。
其次,在业务架构中有流程建模的动态建模部分,在业务架构中往往会从高端流程-》流程分解-》一直在具体的业务用例建模。而到了应用架构中要注意仍然存在动态建模部分,即业务用例-》系统用例-》用例实现,这个可以理解为应用架构中更加细化的动态建模,这个动态建模完全是实现层面的事情了,和本身应用系统的技术架构和分层也密切相关。但是这个过程却相当重要,特别是核心业务用例的用例实现,在这个动态建模过程中会分析和识别出一些细粒度的服务交互。在单个业务系统的架构设计中往往应用到类似序列图的方式来进行用例实现的交互,重心是在分层模型上面,而在应用架构中往往也用到序列图的交互,重心不是在分层上而是在不同的技术组件上的交互,这一点需要明确。
再次,应用架构设计中一个重要内容就是集成架构,集成包括了数据集成和业务集成两种,需要区别对待。数据集成架构重点是参考BI架构方式,而业务集成重点则是SOA参考架构模式进行。集成架构的分析可以在进行了业务系统划分后识别出业务系统之间所有核心的交互点和接口,作为数据集成或SOA服务的输入信息,也可以进一步对业务系统划分是否合理,是否满足松耦合的条件进行修正。集成和共享是两个层面的内容,集成往往数据落地,而共享往往数据不落地只是提供能力,当你在进行集成分析的时候发现了多点集成和交互的时候,往往都需要考虑能力抽取和下沉到平台,进行能力共享。
最后,应用架构中包括技术架构的内容,在这里分为多个方面的内容,首先是涉及到支撑企业内所有应用的技术平台层架构方面的内容;其次是整个应用架构中基于SOA参考架构的服务架构的内容;还有就是针对单个应用的类似java的ssh分层架构的内容,对于基础设施架构暂时先不纳入应用架构中的技术架构来考虑。
前面有两篇文章再谈这个内容可以参考:
应用架构构图:
http://blog.sina.com.cn/s/blog_493a84550101ayag.html
基于SOA应用架构:
http://blog.sina.com.cn/s/blog_493a845501013flt.html
对于SOA组件化业务架构是对类似ssh分层技术架构的一个加强,而不是互斥的两个东西,再引入soa参考架构会会进一步强调业务组件,服务组件和技术组件,强调服务能力的抽象,强调服务能力的共享,强调了各个组件之间真正意义上的松耦合,强调部分业务是可以通过服务组合和编排来实现的。
在应用架构的构建中我们引入了云平台和云化的思路,即各个应用系统不是简单的烟囱式的结构,而是从底层基础设施层面开始逐层向上考虑哪些是应用系统共享的技术能力,哪些是可以集中化建设和共享的,对于基础设施层则抽象到iaas层能力,对于技术平台层则抽象到paas层能力。由底层集中化建设的iaas+paas平台来支撑上层松散耦合的多个业务系统或应用模块,这是一种应用架构中体现云计算思路的重点。
在这里可以用下面这张图来做个理解,如下:
青春就应该这样绽放 游戏测试:三国时期谁是你最好的兄弟!! 你不得不信的星座秘密