精华内容
下载资源
问答
  • 企业应用架构是指一整套软件系统的...本文将通过一个线下小型门店成长为多元化集团的发展历程,逐步向读者展示企业应用架构的演变和设计的理念。完整的企业架构(EA,EnterpriseArchitecture)分析构建,包括业务架构
  • 企业应用架构是指一整套软件系统的构建,通过合理的划分和设计组合在一起,支持企业方方面面的经营运作。不论是传统企业,还是互联网公司,发展到一定阶段,都需要一整套体系化的应用架构来支撑其运转。良好的、合理...
  • 浅谈企业应用架构

    千次阅读 2014-04-09 14:09:44
    在牛津高阶词典(第7版)中,架构(architecture)一词的解释是:the design an structure of a computer system,而架构师(architect)一词的解释是:a person who is responsible for planning ...针对于企业应用

     

    一、什么是架构

    在牛津高阶词典(第7版)中,架构(architecture)一词的解释是:the design an structure of a computer system,而架构师(architect)一词的解释是:a person who is responsible for planning or creating an idea, an event or a situation。

    针对于企业应用,依据不同的关注点,架构可以分为如下几类:

    业务架构(Business Architecture):关注于业务及其流程;

    应用架构(Application Architecture):关注于应用系统设计;

    基础架构(Infrastructure Architecture):关注于基础技术;

    数据架构(Data Architecture):关注于数据存储及其规划;

    这里所说的企业应用架构,即属于应用架构,包括如下几个部分:

    1.目标和愿景。即应用系统所面临的问题域。

    2.评价指标。从哪些纬度和指标来评价和度量解决方案。

    3.原则和方法论。为解决这些问题,所采用的原则及其方法论。

    4.技术架构。架构的技术层面,给出相应的设计以及结构,描述应用系统。

    5.组织因素。架构的组织层面,组织的各个部分如何参与。

    二、架构的目标和愿景

    1. 架构的问题来源

    1. 外部,客户要求包括了业务和技术上。

    2. 内部,组织管理、项目管理和技术发展上。

    特别的,架构需要解决的非业务问题包括如下:

    A.系统目标:系统性能,稳定性等。

    B.项目目标:开发成本,项目质量等

    C.项目过程:需求的不确定性和开发过程的团队协作性,即所谓的开发管理。

    2. 架构的核心问题

    问题可分解为两种类型,业务上和技术上。

    1. 业务上。问题域分解为,逻辑的纵向抽象层次,以及逻辑的横向模块分解和集成。

    2. 技术上。问题域分解为,纵向的技术主题,以及横向的技术职责的分解和集成。

    A.领域化

    传统的架构模式是三层或者四层模式,虽然从技术上有效的横向分解系统结构,但对业务模型如何建立,如何进行层次间传递,模型间关联关系,以及与服务逻辑耦合等问题没有给出进一步的细化,也带来了很多问题。

    此外,在传统设计方法下,分析模型和设计模型的转换也是一个大的问题。

    B.组件化

    实施组件化或者说模块化,其需求分为两个层面。

    1.内部管理,可以帮助开发过程中进行业务切分,帮助控制进度,降低风险,以及财务分析;对于大型复杂的项目,也有利于知识的传递和积累。

    2.销售需要,All in one的系统因不符合发展趋势而不利于销售;组件化有助于产品销售,可以针对客户,将若干组件打包销售,同时减少集成的风险。

    C.产品化

    C.1 定制化问题

    定制化问题的由来:1.面向行业的应用通常没有标准,或者完备的标准;2.通常产品的开发是针对于通用或者公共需求,不针对于特定客户;3.而一个确定的客户,其自身的业务差异和管理差异导致需求的差异性。

    这种现象尤其在缺乏标准的行业应用中,以及系统的产品化过程中。

    传统的简单的解决方式是为每个客户单独维护一个系统分支,在此情况下提供维护和升级,则维护成本巨大;因此如何解决领域的定制化就成为一个重大问题。

    C.2 升级问题

    领域需求每次进一步的挖掘和实现,都意味着领域的升级。但升级面临的诸多问题:数据迁移,旧版本的兼容问题,依赖关联等等,在组件化和定制化情况下,还面临定制化兼容和冲突检测。

    C.3 国际化问题

    1.文本消息国际化

    国际化消息没有直接呈现,而是中间存储后呈现;

    2.布局国际化

    阿拉伯人是从右到左;

    3.业务时间,跨时区;

    4.计量单位,多币种;

    D.平台化

    应用系统可以分为两个内容:应用程序和基础设施。应用程序处理业务问题,而基础设施处理技术问题。

    来自客户的要求是包含业务和技术两个方面。其中技术上包括两种“定型和定性”,其所需的知识和技能是不同于业务上的;

    此外,内部管理也提出相应的要求。由于技术的发展和业务发展之间的不同步,对于一个产品而言,同时存在技术升级和业务升级两个需求。而同时升级存在较大的成本和风险。

    同时对于一个产品来说,技术方面需要较强的适应性,能够低成本上的适应客户的特别要求。

    因此有效解藕技术和业务两个部分成为必然。

    3. 架构的应用问题

    A.事务管理

    数据一致性问题出现的原因通常是开发过程中,由于错误的并发和事务控制导致的;而在业务过程中也存在错误的业务操作情况。

    B.并发处理

    不同的业务应用存在不同的并发场景(并发度以及存在的业务依赖),因此业务上需要明确原则和方案;而不同平台所支持的并发方式和能力也不相同,则采用一定框架支持有助于简化问题。

    C.集成能力

    业务应用所面临的集成问题不同,包括不同的集成环境:外部系统,内部系统,遗留系统等;不同的集成模式:基于文件,基于数据库表,基于消息等,导致所需的集成方法及其能力也不同。

    4. 架构的设计问题

    分析设计和开发实现存在着一定的差异性:分析设计属于知识级,而开发实现属于操作级的。

    分析设计是需求和实现的中间桥梁,因而设计必须解决系统边界的合法性,内部逻辑解藕的合理性和实现的可达性(设计的类方法为实现的30%-70%)。而开发实现需不断重构代码,采用约定和框架能力等技术手段解决开发的实际问题,解决程序级别的健壮性,可读性,可维护性以及可测试性。

    传统的方式,分析设计存在于文档中,而开发实现存在于代码中。两者的割裂导致沟通的困难,也导致了开发工程中具大的风险——分析设计和最终开发实现的不一致性。

    三、架构的评价指标

    1. 财务角度

    在传统的财务核算机制中,系统或者产品的开发通常属于成本中心,对于IT企业来说,电脑设备,办公室等属于沉没成本,而IT人员的工资属于可变成本,是成本的核心部分,为了控制成本,就需要减少项目的开发时间。

    因此架构一个重要的关注点在于控制开发成本和维护成本,通常讲维护成本是开发成本的3倍。降低开发成本核心,在于提高效率、提高适应需求变化的能力。

    2. 技术角度

    技术角度评估架构很难说一?%

    五、架构的技术层面

    (一)基础手段

    提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点,好处不用说了,可以并发的工作,每个人面对的问题都简单而容易操作。而与分解对应的集成,只有提供了好的集成能力,分解才成为现实,而只有分解了,才能清晰的提供业务更多适应性。

    分解和集成的手段分为编程语言和技术框架两个层面。所谓语言就是强框架,而框架就是弱语言。

    A. 开发语言

    现代面向对象的语言提供如下能力:抽象和派生能力,以及接口隔离能力。实际提供两种分解和集成能力:

    1. 把逻辑分解在两个层次中,而通过继承的方式把两个部分集成在一起。

    2. 把逻辑的外观和实现分解在两个地方,而通过接口实现的方式把两部分集成在一起。

    另一种语言AspectJ或者C#语言2.0之后提供的特性:把流程逻辑,分解在不同的地方,而通过签名匹配,利用代码生成的方式来把几部分集成在一起。

    B. 应用框架

    然而语言提供的集成能力,毕竟底层,而且有限,扩展起来也格外小心。因而技术框架提供另外的集成能力就格外重要:

    1. 对象关联关系的分解和集成,如Spring提供容器管理能力

    依赖注入对于依赖关系是适合的,对于服务间,技术层次间都是适合的(因为无状态);但对于聚合(整体和部分)的关系——主要是领域模型(有状态的)——则不合适;

    2. 模块间关联关系的分解和集成,如OSGi,ESB等

    3. 流程逻辑的分解和集成,如Spring Web Flow以及jBPM。

    4. 不同系统的类型分解和集成,如Spring利用动态代理提供的Exporter模式。

    5. 模式的封装集成,设计应当是面向服务的设计,但是服务的暴露方式以及模式可以有很多种,比如API,Web Service,RMI,以及Command模式,Event模式等,框架应该利用动态代理等技术对于这些服务暴露方式,模式进行封装。

    C. 分析设计

    设计中涉及到的组合方式,包括类(接口)组合,继承组合以及产生组合三种。三种组合各有优缺点,设计时适应不同场合。这就涉及到现有面向对象的设计粒度:类(第一公民)和方法(二等公民)。

    类(接口)组合实际上复用的是类一级粒度的设计,而继承组合本质上是一种有方向的组合,复用的方法一级粒度的设计,提供与或非的逻辑操作。而产生组合,例如AspectJ,也是在方法一级粒度的设计复用。

    因为继承组合复用在方法一级的粒度上,因而其更适合存在嵌入式,最低粒度的差异性的设计中,借助于虚拟机的支持,无需额外工作。而类(接口)在类一级上,更适合在更高一级的逻辑复用上;其实不一定需要接口,普通的类也可以,但是在这一级粒度的差异性替换,采用接口优于类,因此称为类(接口)组合;接口是类(接口)组合的编码需要;对于接口一级,需要通过框架的集成和适配来提供差异性的设计。产生组合其实也是在方法一级,不过更关注于广泛的横切面,同时由于现有的语言对它的支持不同,Java需要额外的编译器,而.Net则是在内置编译器上支持。

    更高一级的组合是组件组合。对于组件边界的设计,遵从两点:严格把关设计和代码优先。接口优先的设计通常导致成本太高,实践中会导致开发人员在项目的进度压力下把代码写在不合适的地方。

    D. 开发方式

    常见的开发方式可以归结为3类:开发式编程(Programmatic programming),声明式编程(Declarative programming)和产生式编程(Generative programming)。

    E. 小结

    通常语言作为架构的基础,语言的设计带来的好处远远高于框架和模式,但其引入和更换也是有巨大风险的;而通过提供强大的框架能力,框架尽可能多的完成技术问题,并通过元数据,模式以及约定降低业务和框架的耦合。避免因为框架升级带来不必要的成本。

    Meta Programming的最高层次是语言级别直接解决,比如,Smalltalk, Ruby, Python, 还有其他Reflection支持的非常好的语言。甚至STL等template技术,也可以算作语言级别。 Code Generation 是最低级别的Meta Programming解决方案,技术含量也最低。这个级别必须超越,才能够真正达到质变,完全跳出概念炒作的层次。

    从技术手段上,提高开发效率的另外两个手段是代码生成和类库引用。但代码生成和类库引用,都只解决了逻辑的分解能力,没有提供集成能力,所以一般情况下需要提供框架集成,尤其代码生成需要在系统的最外层,避免集成带来的问题。

    代码生成也没有那么坏,关键在于生成什么,如果是生成结构性的代码,由于往往不是最终的产物,就存在同步维护问题;同时这种代码是大都可以用template完成的。

    但如果生成的是功能性代码,这类代码是最终执行代码,那么通常就把用于设计的代码看作是最终产物,最明显的例子是DSL。

    (二)核心问题

    1. 领域化

    领域化,即领域建模。通常而言,领域模型设计中,模块分解,抽象分层和职责分层都是重要手段。问题域为:流程,领域模型和领域服务(包括规则)。

    a. 对象的抽象分解和集成

    b. 对象的依赖分解和集成(模块内和模块外)

    c. 流程的分解和集成(页面流,工作流以及计算流程)

    d. 进程边界:用户请求重定向,以及业务数据持久化等。

    对于中等项目来说,系统中应该有50-100个领域对象代表了业务抽象;

    2. 组件化

    面向对象语言本身没有提供的组件级别的依赖关系集成能力。语言不提供,因为领域组件的粒度太大,超越了语言的范畴。但我们可以通过框架提供,在Java体系中,目前已经有两个较好的解决方案:OSGi(JSR291)和SCA。可以很好的解决组件服务依赖关系管理,包括热替换。

    同时另一个问题——逻辑分层的问题:如保险产品面临的核心层,国家层以及公司层三个逻辑层次分解和集成能力。这点的解决方案可以通过OSGi + Spring来解决,包括了静态差异性替换和动态差异性替换。

    还有组件边界保护问题,我们希望限制别的组件访问本组件内部实现,有两种手段可以完成,1是提交/部署时,通过在代码提交时的代码检查工具,或者发布时编译工具完成;2是通过OSGi的边界限制能力。

    3. 产品化

    A. 定制化支持

    领域定制化涉及到逻辑替换问题。逻辑的替换根据开发方式不同,有两种类型:基于接口和基于继承;

    A. 基于接口(包括了静态替换和动态替换)

    1. 静态替换是Override,在OSGi中只要停止原有服务,启用新服务即可,而在Spring中更改相应配置文件即可;

    2. 动态替换,其实是指运行时Condition Service Locator,在OSGi中可以利用Extension Point(Plug-in)解决,而Spring中只要提供一个类似Service Locator就可以。

    B. 基于继承(或者静态类)

    1.开发时,直接修改源代码编译;

    2.编译时,采用AspectJ,在编译时提供替换;

    3.加载时,开发一个新逻辑的同名类,但其加载路径优先于原有类;

    B. 升级支持

    主要是增量升级支持,以及有限的降级支持。同时要考虑到对于定制化产品的升级支持。

    4. 平台化

    A.基础设施

    基础设施包括:类库和框架。基础设施可以自己开发,或者应用第三方(开源商业)实现。

    A1. 基础设施的选型

    应考虑几点:1. 商业角度的可维护性和可升级性;2. 组织的学习和管理能力;3. 基础设施自身功能以及所支持的开发效率。以下是详细要求:

    A2. 基础设施的集成

    基础设施独立后,出现平台化的发展趋势,这个趋势有两个方向:通用化和专业化。通用化意味着基础设施和应用的距离加大,易用性减低;而专业化意味着适应性的减少。这是一个矛盾体。在基础设施选型后,再进行一定集成工作,可以结合当前情况,平衡易用性和适应性;同时合适的集成也有助于隔离技术和业务两个方面。

    从维护升级角度看集成的合适性:对于没有标准的,不要做不必要的封装,封装等于是建立一个标准,而这是不现实的;应当尽可能采用框架方式,屏蔽基础设施对于应用程序的侵入性。如果是标准,就更没有必要封装,画蛇添足。

    B.业务支持

    B1. 基本原则和手段

    基本原则是:应用程序POJO化。减少技术对于业务侵入性。主要手段是:容器上下文;依赖注入;AOP技术;元数据支持;事件机制;开发工具和代码生成;

    依赖注入+AOP+元数据构成了简单对象(POJO)的支撑技术。基于此三位一体的技术可以有效的隔离业务问题和技术问题,更为甚者它可以支撑简单对象体系,每个对象做且只做一件事。

    B2. 开发模式与最佳实践

    基础平台应该提供业务相关的模式封装。

    B3. 关于元数据

    元数据有多种:语言级别为Annotation(微软.NET为Customer Attribute);框架级别可以是XML文件或者其它配置文件。

    元数据可以通过以下几个视角观察

    1. 应用层次:元数据代表了业务含义和技术含义;

    2. 技术分析:文档类型(开发管理型);编译类型(类加载型);运行期行为。

    3. 物理分析,包括Annotation和接口,XML文件,甚至是EL和类。

    元数据系统的建立其实是代表了认知过程。

    以运行期的元数据为例,代表了系统通过反射获取相关元数据来自适应系统,其实际意义在于将软件设计开发人员对于系统的认知通过技术手段固化下来。

    元数据系统的开发目的有两个:

    1. 业务应用上,提供业务动态能力;

    2. 技术应用上,简化开发减低成本;

    这里面有一个误区是:为了技术应用而过分地开发元数据系统,而随着业务的演化导致为技术应用的元数据迅速被抛弃,导致投入的浪费。实践中要避免。

    (三)应用问题

    1.事务管理

    A. 成熟的事务技术:如数据库;

    B. 合理的并发设计控制;

    C. 完整的业务日志;这也是解决业务回退的主要手段;

    D. 辅助的数据校验能力;

    并发设计控制和完整的业务日志,是架构设计中保障数据一致性主要着力点。并发设计控制,需要结合业务,通过悲观锁定来保障。

    而业务日志的获取则面临着诸多困难,主要是业务事务和物理事务的不一致性(即一个业务事务可能横跨多个物理事务,也可能一个物理事务包括多个业务事务);业务日志控制层面有两个:应用系统或基础设计;通过应用系统编码控制,则不可避免的提高了应用系统开发和测试的成本;通过基础设施控制,有助于减低成本,但提高基础设施的设计成本;

    2.并发处理

    分析业务所涉及的并发场景,制定相应的原则和方法,并合理选用现有的并发处理框架,进行一定程度的剪裁,通过框架支持和简化这些原则和方法的实践。

    3.系统分解

    基于应用的层面的分解,有多个纬度,包括:业务抽象度,业务任务,业务产品线,以及业务领域等等。

    4.集成能力

    软件开发的适应性在于分解粒度的大小,而分解粒度大小取决于集成能力。

    1)依赖管理

    在技术的角度看,软件系统是一个存在大量依赖关系的对象系统。其中包括了两种依赖:

    1.业务代码的对象依赖;比如调用一个工厂类创建一个对象。

    2.业务代码的环境依赖;它可能依赖于一个Web环境(读写Request和Response流),数据库系统(读写数据记录),文件系统和网络系统等。

    不幸的事是这种代码量占据了大量的开发工作。重复的开发工作(对象或者数据的依赖关系维护工作)减低了开发效率和系统适应变化的能力。

    而这样复杂依赖关系也给软件的测试带来了相当大的困难需要搭建足够的依赖环境(如一台Web服务器和数据库服务器),甚至是硬调试。

    于是就有了采用第三方代码来完成依赖关系维护工作的思路,所谓的依赖注入。业务对象出现Spring等著名框架

    动态代理技术则解决了提供支撑环境封装的问题。比如提供网络访问能力(如RMI,URL和Web Services),文件访问能力(如xml、property文件读写)。

    由于企业开发中数据库技术的应用不可避免,因而ORM框架的出现还有特别的意义,在它的支撑下,核心业务西可以严格区别领域逻辑和业务逻辑,而这在以前是做不到的。

    AOP开发的出现解决了面向对象下的横向组织关系。从一定程度上看,AOP可以看作是另一种依赖关系,可以另外依赖注入来实现。当然也可以采用编程实现。

    2)数据对象

    说起集成,就不得不提到一种类型的对象存在——VO对象。

    VO对象是为了集成而存在的;其意义是:1. 保护系统的信息边界,提供一种结构可以使其它系统或者组件通过编码方式获取系统内信息的方式;2. 保护系统的事务边界,领域对象技术上携带着持久化信息,通过VO可以屏蔽得以屏蔽。常见的VO对象存在于Web层和Domain层。

    因此,VO对象的存在只是为了集成而存在,其是否存在的取决于两个方面1. 集成的设计结构;2. 框架的两个能力——对象路径访问能力以及事务边界管理。

    Domain层VO对象,通常是用于不同领域组件间的交互,但随着架构的改进,集成代码独立存在而不再嵌入到组件内部,组件的边界问题保护不复存在;更进一步的是,框架提供自动化的接口适配映射能力的增强。因而VO对象失去存在的意义。

    Web层VO对象,以SWF为例,早在SWF 1.x时代,框架就提供了丰富的对象路径访问能力,但其Web交互是典型的MVC2方式,事务边界在view的render前关闭,因而导致需要特定的VO对象来避免持久化信息问题;而SWF 2.x时代,view的render是在事务边界内,VO不再需要。

    系统设计是一种结构化过程,逻辑和数据被分解和集成到系统的各个部分;在运行期,真正重要的是结构化路径访问能力,换句话说重要的是结构化后的路径,而实际用何种数据结构其实不重要。

    可以使用数据树Data Tree形式,提供扁平化的数据访问能力,是一种较好的开发方式,极大的提升了开发效率。Spring Web Flow以及其它框架广泛的运用EL提供统一的表达式访问数据,也大大降低了开发成本。

    3)事件机制

    事件机制应用非常广泛,是很重要的集成手段。事件机制的优势在于其提供了松散耦合而带来的扩展能力。基于传统事件模式,可以扩展提供同步/异步,事务隔离等额外控制能力。

    4)组件设计

    一个组件包括了API和SPI,其中API是用于客户方编程,SPI用于服务方编程(属于框架回调)。无论是API和SPI都是该组件所有,体现了一个组件自身的完备性。其与其它组件依赖通过集成模块完成,依赖解藕。

    组件的设计还分层次,上层组件的逻辑依赖下层组件,上层组件直接访问下层组件的服务和模型,保持单向依赖有助于降低开发和维护成本。而平级组件,由于组件的替换可能性大,因而保障组件边界完整性尤为重要。

    接口的实现是关键。面临的问题是,在开发初期需求不确定和经验不足的情况下,接口的设计不尽合理,导致需求变动后,所进行的修改将影响三个方面,接口、接口实现对象和测试用例。工作量将可能很大。特别是在并行开发过程中,一个通讯接口的变化将可能引起很大连锁反应,导致其他成员不得不停下手上的工作。

    因而在实际开发中需要做个权衡。不同模块的通讯接口应该由团队成员共同负责,一旦接口变化,接口实现成员应该提供相应的假实现。而模块内部可以由开发人员自行设计,可以在初期不提供接口和简单的测试用例,在项目具有一定稳定性后,利用重构实现接口和完整的测试用例。

    有效定位系统错误。尤其在组件化和分层化,以及其它开发手段混合运用情况下。例如,A,B,C。由于C引起的错误导致A错误是很难查的。代价很高。

    5)胶水层

    胶水层代码属于集成范畴。它是系统开发中不可避免的。胶水层代码的存在增加了设计、开发和测试的成本。因尽量减少胶水层代码的人工开发。

    胶水层代码有两种类型:一是适配器,二是开发模式。

    适配器对于集成来说并不陌生。适配器从用途上分可以分为两种:业务适配和技术适配。业务适配是指处理应用程序接口的适配调用,消除应用程序的耦合度;技术适配是指处理应用程序和技术框架上,消除技术框架的耦合度。

    开发模式是指基础平台对于应用开发的支持减少无效代码,例如采用ORM系统(如Hibernate)以及有状态的Web层框架(如Seam和SWF)可以有效减少应用系统处理数据(对象)状态;以及各种元数据的识别和增强。

    6)集成阶段

    根据阶段分为:设计时, 编译(加载)时和运行时。设计时是由人工编码,通常就是一些特定业务代码,完成集成工作;编译时集成工作通常指配置文件,由程序员提供,但不需要编码工作;而运行时指通过指定元数据,由框架运行时解析;

    5.部署方式

    部署有两种:本地部署和分布式部署。

    分布式部署会带来额外的问题。如果支持分布式部署,有两种方案:

    1. 前后端分离方案

    传统EJB方案就是此种。面临的问题和风险:

    a) 部署成本,即分布部署带来开发成本;

    包括:分布式调用;分布式事务管理;开发模式(即上下文的传递)。

    b) 运行成本,即分布式数据传输性能问题;

    2. 采用Portal或类似技术

    (四)设计问题

    设计文档依然有用,采用Color UML有助于阅读。

    面向对象提供各种关系的表达能力:关联,依赖,集成,组合等;类似于数据库表关系,但是更强烈。在设计时需要注意表现。

    新的开发方式,应该可以通过代码记录分析设计的成果,形成系统中一个稳定的可发展的抽象层次代码,而开发实现则继承或者适配该抽象层次,最终保证系统可运行性。

    这样知识层面的分析设计可以有效贯彻发展,而操作层面的开发实现可以关注于实现过程的工具和手段。这样就可以确保设计是做正确的事,而开发过程提供各种框架工具则把事做更有效率。

    六、架构的展示

    1.两个要素

    架构要展示的两个基本要素是:业务和技术组件。而业务又可分为组件和功能两个层次,技术又可分为基础平台与组件所需提供工件两个部分。

    后续所有展示都围绕此二要素。

    2.核心视图

    由RUP贡献的四个视图是架构展示的核心视图。

    逻辑视图(静态类图)

    关注功能,不仅包括用户可见的功能,还包括为实现用户功能而必须提供的"辅助功能模块";它们可能是逻辑层、功能模块等。

    应映射为业务组件、功能包以及技术工件(分层),以及它们之间关联依赖关系;

    开发视图(静态类图)

    关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件。

    开发视图和逻辑视图之间可能存在一定的映射关系:比如逻辑层一般会映射到多个程序包等。

    应映射为具体的SDK和框架等,以及关联依赖关系;注:开发视图应尽可能和逻辑视图一一对应;

    处理视图(动态类图)

    关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。

    处理视图和开发视图的关系:开发视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,处理视图比较关注的正是这些运行时单元的交互问题。

    可映射为状态图和活动图(高层和详细);

    物理视图(部署视图)

    关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器,以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

    物理视图和处理视图的关系:处理视图特别关注目标程序的动态执行情况,而物理视图重视目标程序的静态位置问题;物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

    可映射为组件图,部署说明图;

    3.扩展视图

    在核心视图,针对于不同受众,还需要提供三个扩展视图。

    非功能视图

    展示非功能性指标的支持能力。通常针对于技术人员。

    基础设施视图

    展示架构所采用基础设施,以及它们之间的关系。通常针对于技术人员。

    数据视图

    关注于数据组织和存储形式。通常针对于DBA,或者需对数据进行定期维护的用户。

    4.原则和约束

    架构因明确说明本架构采用原则、方法论以及相关约束。

    5.技术选型分析

    由于架构涉及众多底层技术,也应给出相应的选型分析。

     

    展开全文
  • 系统架构师-基础到企业应用架构-索引系统架构师-基础到企业应用架构系列会从,系统架构的起源、发展、架构师必备的基础知识与技能、如何把架构应用到企业应用中去。整个系列计划30篇左右,每一篇都是自己在系统架构...
    
    

    系统架构师-基础到企业应用架构-索引

    系统架构师-基础到企业应用架构系列会从,系统架构的起源、发展、架构师必备的基础知识与技能、如何把架构应用到企业应用中去。整个系列计划30篇左右,每

    一篇都是自己在系统架构过程中的总结和经验,每一篇我都会抱着认真的态度去完成,宁缺毋滥的原则。希望本系列看完之后不但能够帮助看过这个系列的人对系统架

    构有深刻的认识,并且能够掌握系统架构中的必备知识,应用到自己的工作中去,更可以共同提高大家的个人能力。本系列希望能够抛砖引玉,希望大家能够多提出宝

    贵意见。

    前篇

          1、系统架构师-基础到企业应用架构系列之--开卷有益

          2、系统架构师-基础到企业应用架构-系统建模[上篇]

          3、系统架构师-基础到企业应用架构-系统建模[中篇](上)

          4、系统架构师-基础到企业应用架构-系统建模[中篇](下)

          5、系统架构师-基础到企业应用架构-系统建模[下篇]

          6、系统架构师-基础到企业应用架构-系统设计规范与原则[上篇]

          7、系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]

          8、系统架构师-基础到企业应用架构-设计模式[上篇]

          9、系统架构师-基础到企业应用架构-设计模式[中篇]

          10、系统架构师-基础到企业应用架构-设计模式[下篇]

    中篇

          11、系统架构师-基础到企业应用架构-企业应用架构

          12、系统架构师-基础到企业应用架构-分层[上篇]

          13、系统架构师-基础到企业应用架构-分层[中篇]

          14、系统架构师-基础到企业应用架构-分层[下篇]

          15、系统架构师-基础到企业应用架构-表现层

          16、系统架构师-基础到企业应用架构-服务层

          17、系统架构师-基础到企业应用架构-业务逻辑层

          18、系统架构师-基础到企业应用架构-数据访问层

          19、系统架构师-基础到企业应用架构-组件服务

          20、系统架构师-基础到企业应用架构-安全机制

    后篇

          21、单机应用、客户端/服务器、多服务、企业数据总线全解析

          22、系统架构师-基础到企业应用架构-单机应用(实例及demo)

          23、系统架构师-基础到企业应用架构-客户端/服务器(实例及demo)

          24、系统架构师-基础到企业应用架构-多服务(实例及demo)

          25、系统架构师-基础到企业应用架构-企业数据总线(实例及demo)

          26、系统架构师-基础到企业应用架构-性能优化(架构瓶颈)

          27、系统架构师-基础到企业应用架构-完整的架构方案实例[上篇]

          28、系统架构师-基础到企业应用架构-完整的架构方案实例[中篇]

          29、系统架构师-基础到企业应用架构-完整的架构方案实例[下篇]

          30、系统架构师-基础到企业应用架构-总结及后续

          最后何戈洲 会尽心尽力写好这个系列,同时由于是自己对这些技术的使用总结和心得体会,错误之处在所难免,怀着技术交流的心态,在CSDN上发表出来,所

    以希望大家能够多多指点,这样在使一部分人受益的同时也能纠正我的错误观点,以便和各位共同提高,后续文章敬请关注!

    展开全文
  • 应用架构、业务架构、技术架构和业务流程图详解

    万次阅读 多人点赞 2018-10-09 18:48:32
    企业级的应用架构企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略发展方向和业务模式,向下规划和指导企业各个IT系统的定位和功能。在企业架构中,应用架构是最重要和工作量最大的部分,他...

    应用架构

    应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次:

    企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略发展方向和业务模式,向下规划和指导企业各个IT系统的定位和功能。在企业架构中,应用架构是最重要和工作量最大的部分,他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

    单个系统的应用架构:在开发或设计单一IT系统时,设计系统的主要模块和功能点,系统技术实现是从前端展示到业务处理逻辑,到后台数据是如何架构的。这方面的工作一般属于项目组,而不是企业架构的范畴,不过各个系统的架构设计需要遵循企业总体应用架构原则。

    应用架构主要以架构图的方式描述系统的组成和框架,一般从系统功能和系统技术层次两个架构视角进行设计:

    1. 系统功能视角的应用架构图

    ​​​​​

    2. 系统技术层次视角的应用架构图 

    业务架构

    ----摘自《自主变革的基石 制造企业管理技术及SOA实践》

        主要考虑部署,例如你不同的应用如何分别部署,如何支持灵活扩展、大并发量、安全性等,需要画出物理网络部署图。按照应用进行划分的话,还需要考虑是否支持分布式SOA

        每一个典型业务,都可以把它想象为一台运行中的机器,而其中的每个业务组件便是构成这台机器的功能模块。之所以要利用组件来进行业务架构的搭建,正是因为组件具有上述特性,这些特性能确保搭建的典型业务架构图,既完整有效、又无功能冗余,而且有利于今后展开系统架构的组件分析和设计。这样的架构能告诉我们:是由哪些内容相对独立的业务模块构成了这项典型业务。如对其中的每一个业务组件之间的作业关联关系、相互沟通的方式进行研究,就能掌握整个业务架构的协同作业水平;如果对每一个业务组件都采用前述外特性定义的方法加以描述,就能掌握这些组件当前能完成哪些独立的业务内容以及能达成哪些业务目标。本节重点介绍利用业务架构图分析典型业务的分析方法,分析的对象就是业务架构在功能构成方面的完整性和合理性。

       首先,需要表达出当前的典型业务是由哪些业务组件构成的。基本可以断言,大家在开始按上述三个层次描述某个典型业务的构成时,一定会对应该如何定义管理层和决策层的业务组件感到困惑,这是非常自然的反应。因为,至今以来,大家总是在研究执行层的作业方式,不会去、也不敢去研究管理层和决策层的作业能力。但在不远的将来,我们的企业注定要进入业务协同和系统整合的时代,所以,大家现在应该开始学习如何定义和建立管理层和决策层业务组件的具体方法了。

    典型的整车生产企业产品开发业务的业务架构示意图

     

       如典型的整车生产企业产品开发业务的业务架构示意图所示:当我们对于某项典型业务的业务组件的构成进行初步的归纳后,能够得到该项业务的一个整体的框架结构,我们可以称之为“业务架构图”,以及在这个框架内,企业中三个层级的员工在该项业务上分别从事着哪些作业内容。分析执行层的业务作业方式和作业规律,你觉得很正常,但如果让你去分析作为你上司的管理层、甚至决策层的作业方式和作业规律时,你也许会感到有所不安。这种心理反应,实际上正好反映出目前很多企业中的一种能力倒置现象的产生原因。很多人都了解这样的事实,那就是,企业中的很多升职后的中高层领导,在就位后的很长时间内,不能进入应有的管理角色中,这绝对不只是个人能力的差异问题,而主要是因为我们的中高层领导总是习惯地认为:研究执行层的作业方式和规律才是他们的主要职责,而没有注意到自己的作业内容和作业方式在整个作业链条中的重要作用,其结果,自然是管理层和决策层领导们的业绩,只好取决于执行层作业人员的努力程度,这种习惯也导致我们的中高层领导们不会去研究影响自己判断能力和决策能力的技术瓶颈是什么。而很多新出现的现代管理模式,实际上就是为了解决中高层领导们的作业能力问题,或是为了解决三个业务层级之间的信息沟通能力的问题,这也就是为什么业务架构分析人员还必须分析战略层和管理层作业形态的原因。下面将分别说明上述三个不同层次作业组件的特点:

    (1)战略层业务组件

       战略层业务组件自然是用于定义和规范战略层决策人员的业务行为的。那么,哪些人员可以归类于战略决策层之中呢?一般说来,在典型的制造企业中,部长以上的领导应被理解为企业战略决策人员,因为,他们通常已脱离具体的、单一的业务管理,他们通常会被要求在某个综合业务的专业领域提出战略性规划,并按规划进行部署和指挥。但在很多企业中,还设置有经营管理课或战略策划部等机构,其中的一些专门从事为决策层领导进行战略数据分析和提出具体方案的高级管理人员,也应该被认为是战略层业务组件中的业务人员。

     战略层业务组件通常应按如下的作业基准进行设计:

    - 对于特定的典型业务,是否具备有效的战略规划编制和调控能力。

    这里提到的调控能力,是指当企业经营发生重大的内部或外部环境变化时,企业内部是否具备能对既定规划及经营目标做出及时分析和调整的响应机制和具体的作业标准。

    - 制定、发布以及变更经营战略规划的流程和作业规则是否明确。

    这只是一个规范作业流程的问题,在很多企业内部,通常具有手工审批,进行传递的流程,有时存在指令重复、重要度不明、不易追溯等管理问题。

    - 是否能及时、准确地获取相关战略指标的动态统计数据(用于决策)。

    这是直接影响战略层决策能力的重要条件。这里提到的及时和准确,往往可以作为衡量一个企业管理技术水平的标尺。

    - 战略指标数据是否能明确指向具体部门或具体业务组件(用于能力评价)。

    这同样是一项检验企业管理技术水准的重要课题,在此后的第七和第八章中,将对此课题展开详细的讨论。

    - 是否具有根据设置的危机监控标准,及时触发决策机制的系统反应能力(确保决策的及时性)。

    这是一个技术含量最高的课题,任何企业都很难达到这样的水准,只有在管理方法和技术手段方面同时达到很高水准的企业,才能有效展开这一类课题的研究活动。但这一课题显然是所有企业都需要瞄准的目标。

       当然,上述的作业基准未必一定完整和精准,只是按照对一般指挥机构职能的理解来考虑的。例如,企业每年需要设置生产成本控制的战略目标,如经营层的业务人员(实际上是一些领导们)能按图2的成本控制图谱获取所有部门和所有组件的目标达成数据的话,自然就能及时做出相应的评价、指导和决策调整。关于如何实时采集和展现业务状态数据、以及如何设计战略决策信息舱的详细情况,请参见第八章《商业智能和可视化管理》的内容。

    单车成本构成示意图

    (2)管理层业务组件

    由于管理层处于决策层和执行层之间,从信息沟通的角度来说,具有上情下达、下情上报的职责,一般情况下,上情下达比较容易实现,但下情上达则相对困难,存在诸多的管理和技术问题。管理层业务组件应以提升管理层控制业务过程的能力、以及提高管理层和执行层及战略层之间的信息沟通能力为主线进行设计。管理层作业的重点应按如下思路设置:

    - 对于某个典型业务的企业战略,是否具有明确的计划编制、监督实施等作业标准。

    如部门接受了达成企业某个战略,或实现某个企业年度指标的任务时,应该按照既定的作业标准,进行自身业务能力的分析、指标的分解、作业分工以及过程控制方法的确定等作业,以确保该项战略目标或年度绩效指标能按计划展开,并确保其实施过程能得到有效的监控。

    - 相关的典型业务的过程状态是否能有效掌控。

    这一条可以认为是管理层的主要业务方向之一,如一个中层管理人员对如何监控业务过程缺乏最起码的研究,那就基本可以断言,他肯定是一个缺乏最起码业务过程控制能力的管理人员。

    - 对于某些典型业务或某些关键的作业节点,能否实时、有效地评价员工的执行力。

    管理人员之所以需要掌握员工或团队的执行力,不仅仅有利于达成业务目标的正确预测,更重要的是将有利于管理人员发现团队中意愿不足和能力不足的员工,以便及时加以指导。另外,如能实现员工执行力的数据统计,还将有利于事后的正确评价。

    - 对于部门重点业务以及管理改进目标,能否掌握员工知识贡献度的不同。

    能设置符合这一方向的业务组件,其先决条件是必须已经实现了基本有效的知识管理,否则,这样的要求就偏高了一点。作为一个以创新为主的业务部门的管理人员,必须研究如何做才能达成这样的目的,关于这一点,将在第八章中进行详细的介绍。

    - 对于所承担的企业战略指标部分,是否具有实时采集、分析和上报的机制。

    如果管理层职员基本具备这样的意识,就基本上能够得到他们上司的认可,至少能够保持住当前的官帽。如果能够建立这样的机制,具备这样的能力,那就完全不用担心自己的升迁问题了,因为,能够实现及时、准确地“下情上报”的管理人员,已经充分具备了能随时取悦上司的资本。

       总之,从信息沟通的功能来说,设置中层管理业务组件的目的,一是能够掌握企业战略动态,及时编制、和实施部门业务计划;二是要能够实时掌握执行层业务的作业状态(进度、执行力、作业量、知识贡献等)、并能够及时处理、分析执行层的业务统计数据,以便及时对员工进行指导、督促和评价,以及顺利履行按规定向上通报的职责。根据以上思路设置管理层业务组件,从表面来看,似乎主要关注的是中层管理者们处理信息的能力,但大家必须清醒地认识到这样一个事实,那就是:没有充分有效的反映执行层作业状态的信息,管理层就不可能进行有效的控制、指导和评价,作为管理者的能力,也就不可能得到充分地展现。

    (3)执行层业务组件

        执行层业务组件的设计重点,当然首先要关注组件的设置是否有利于实现所属典型业务的目标,其次是希望它能以最少的资源投入来确保业务目标的实现。如果企业单一系统的建设卓有成效,则基本可以认为该企业的执行层业务组件应该是处于一种良好的状态。但在当前加强目标管理、绩效管理的企业,所有执行层组件应该还要考虑是否需要设置向管理层提供信息服务的功能。归纳起来,应考虑以下要素:

    - 是否能确保实现典型业务的业务目标。

    要回答上述问题,必须对典型业务有完整的认识,所以,必须尽量把有利于实现业务目标的业务活动、操作方法以及技术手段都纳入研讨的范围。也许,在考虑如何才能实现典型业务的业务目标时,暂时可以不要过多地去推敲效率的好坏。

    - 实现业务目标的效率如何。

    如果企业对于作业效率有很高的要求,则在设计业务组件时,或许要更多地考虑组件的合并、组件业务流程的连通方式的改进、执行力的监控等有利于提高作业效率的问题。

    - 业务过程失控的危险是否已完全消除。

    企业中的有些业务,如必须需要通过设置控制基准值,并通过逻辑条件或数学运算规则来发现业务过程失控、指标达成失败等现象时、则需要考虑追加自动监控组件,如果没有自动监控的条件,也应明确人工监控的具体方法。

    - 业务状态数据是否可实时采集、统计和发布。

    对于必须控制进程的业务,则通常需要考虑追加进度监控组件,至少应明确关键节点的进度监控方法。

    - 业务组件之间的协同是否顺畅。

     这一条要求是指业务组件之间的流程连通方式、信息共享方式是否符合业务目标的要求,如果不能达到要求,则要追加某种提升协同能力的辅助组件。

        总之,执行层业务组件是实现典型业务目标的骨干部分,而管理层业务组件的合理设置可确保执行层业务过程得到实时的控制,而战略层业务组件则应起到目标调整、资源调整的决策作用。

    在进行上述三个层面的业务组件设置时,如果已经掌握了相对先进的、行业内的最佳实践模式,并对该典型业务进行过组件构成合理性的分析,或者根据日常的业务不良投诉记录,已经掌握了某些组件的问题,那么,在分析和描述该项典型业务时,可明确地表达出该典型业务在构成上的缺失或冗余项,以及当前这些业务组件的业务能力的总体状态。在分析中,最容易发现的是业务组件的缺失项,即一些目前我们还没有开展的业务,而这些业务的开展恰恰有利于企业最新战略的实现。但发现所谓冗余项,则通常是一个不容易完成的任务,因为,大多数员工不会斗胆挑战现有业务存在的合理性,因为大家已经习惯于把时间打发在这些日常业务上了。但作为业务分析人员,建议大家必须时常保持高度的怀疑态度,因为任何业务组件的存在都要消耗资源,为此,任何业务组件都存在压缩、分解乃至取消的可能,如果能通过业务的重组或优化,凸现出某些业务的冗余功能,并最终取消之。这才是分析人员应该加以重点研讨的方向,才是大家更值得骄傲的地方。真所谓“居人之所恶,故几于道”,我们业务分析人员,没有必要对自己始终保持对现实的批判态度而心怀歉疚,反倒应该随时提醒自己,要始终保持对现有业务合理性的怀疑态度,在这方面,做“恶人”比做“好人”,更能体现业务分析人员的职业价值。对于上述的分析结果,自然应在业务架构图中表达出来,具体的表达方式可参见图2-4。在图中,采用的是用色彩区分来表达组件业务能力状态的方法,虽然这种表达方法比较直观,但肯定不是唯一的表达方法,在此建议大家不必拘泥于形式,只要能容易理解即可。

    和最佳实践模式对标或完成调查和分析后的业务热点分析图

        不过,有一点,希望大家注意,上述的架构图是一张企业级的典型业务架构概略图,所以,对于每一个典型业务,都包含了所有相关部门的业务组件。但实际上,我们的很多具体分析,往往只须针对一个部门的业务展开即可。在这种情况下,也可以按照上述的方法编制部门级业务架构图,只是这种架构图在大多数情况下,不需要考虑战略层的组件设计,所以,只采用两层的架构图也是没有问题的。另外,根据需要,对于部门级的业务,还可以编制一种横向按时间顺序展开的架构图,但这种架构图不利于展开全局性的分析,所以,通常不采用,这里就不作详细说明了。

       根据以上两个图例,读者是否不再介意使用‘业务架构’这样的表达方法了呢?为此可以认为,即使是相对抽象的业务也是可以用相对直观的架构形式来表达的。这样的表达方式不仅仅只是为了直观地进行业务的归纳,更重要的是为了直观地表达出现有业务架构的缺陷。图3中,红色的组件表示缺失、冗余或存在严重缺陷的组件,此类组件我们通常称之为“热点组件”(这样的架构图也可称之为热点组件示意图)。红色组件通常是表示尚未实施改进对策的热点组件。粉红色的组件则表示该组件虽有问题,但目前正在对策中。黄色的组件表示存在当前可以默许的缺陷,但随着企业的发展也许需要加以关注的组件,通常其评价的平均得分低于3分。绿色则表明该模块当前运行正常,暂时不需要特别关注的业务。当面对如此直观明了的业务架构图。没有理由不对缺失的和有缺陷的模块部分进行进一步的问题定位分析、并制定改进方案。但怎样才能知道A组件是缺失,应该考虑增设,或B组件有缺陷,需要改进呢?这便是后面的章节中将要重点介绍的核心内容。

    下面这张就是画的比较细的业务架构图

    ​​​​​

    技术架构

    从技术层面描述,主要是分层模型,例如持久层、数据层、逻辑层、应用层、表现层等,然后每层使用什么技术框架,例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等,分别说明,要求这些技术能够将整个系统的主要实现概括。

    技术框架(technological Framework)是整个或部分技术系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一种定义认为,技术框架是可被技术开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

    实例图:

    业务流程

    业务流程,是为达到特定的价值目标而由不同的人分别共同完成的一系列活动。活动之间不仅有严格的先后顺序限定,而且活动的内容、方式、责任等也都必须有明确的安排和界定,以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。而狭义的业务流程,则认为它仅仅是与客户价值的满足相联系的一系列活动。

    流程图

    竖式业务流程图就是要业务流从上到下,看起来一目了然。

    竖式业务流程图可以划制成矩阵式流程图,就可以同时说明业务、工作的流程,还可以在流程中明确各自的分工和职责,关键的控制点等。业务流程要重点注意可靠性、资源利用率、反应性、灵活性、较低的管理成本五方面问题。

    综述

    良好的业务流程设计是保证企业灵活运行的关键。清晰的定义业务流程之间的接口,可以降低业务之间的耦合度,使得对局部业务流程的改变不会对全局的流程产生灾难性的后果。

    对整个企业的业务流程进行建模是一个相当复杂而有挑战性的工作,但是并不代表没有方法可循。一般来说,建模需要处理好以下几个方面:

    建立流程

    主要的业务流程是由直接存在于企业的价值链条上的一系列活动及其之间的关系构成的。一般来说包含了采购、生产、销售等活动。 辅助的业务流程是由为主要业务流程提供服务的一系列活动及其之间的关系构成的。一般来说包含了管理、后勤保障、财务等等活动。

    层次关系

    业务流程之间的层次关系反应业务建模由总体到部分、由宏观到微观的逻辑关系。这样一个层次关系也符合人类的思维习惯,有利于企业业务模型的建立。一般来说,我们可以先建立主要业务流程的总体运行过程,然后对其中的每项活动进行细化,建立相对独立的子业务流程以及为其服务的辅助业务流程

    业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。为使得所建立的业务流程能够更顺畅的运行,业务流程的改进与企业组织结构的优化是一个相互制约、相互促进的过程。

    合作关系

    企业不同的业务流程之间以及构成总体的业务流程的各个子流程之间往往存在着形式多样的合作关系。一个业务流程可以为其它的一个或多个并行的业务流程服务,也可能以其它的业务流程的执行为前提。可能某个业务流程是必须经过的,也可能在特定条件下是不必经过的。在组织结构上,同级的多个部门往往会构成业务流程上的合作关系。

    进QQ群(779809018)免费领取学习资源,欢迎大家,加入我的微信公众号:代码帮 ,免费分享资源。

    本公众号将秉持活到老学到老学习无休止的交流分享开源精神,汇聚于互联网和个人学习工作的精华干货知识,一切来于互联网,反馈回互联网。
    目前研究领域:大数据、机器学习、深度学习、人工智能、数据挖掘、数据分析。 语言涉及:Java、Scala、Python、Shell、Linux等 。同时还涉及平常所使用的手机、电脑和互联网上的使用技巧、问题和实用软件。 只要你一直关注和呆在群里,每天必须有收获,讨论和答疑QQ群:大数据和人工智能总群(779809018)微信公众号(代码帮)每天分享最新IT、大数据和人工智能新技术。

    展开全文
  • 企业应用架构演变之路

    千次阅读 2017-05-06 16:08:36
    企业应用架构是指一整套软件系统的构建,通过合理的划分和设计组合在一起,支持企业方方面面的经营运作。不论是传统企业,还是互联网公司,发展到一定阶段,都需要一整套体系化的应用架构来支撑其运转。良好的、合理...
    作者|杨堃编辑|Gary 
    

    企业应用架构是指一整套软件系统的构建,通过合理的划分和设计组合在一起,支持企业方方面面的经营运作。不论是传统企业,还是互联网公司,发展到一定阶段,都需要一整套体系化的应用架构来支撑其运转。良好的、合理的应用架构可以支持企业高效开展业务,控制经营风险,而混乱的、不合理的应用架构则会限制企业的快速发展,成为企业增长与变革的瓶颈。

    企业信息化建设已经发展了几十年,传统企业和成熟互联网企业的应用架构并没有本质的区别。本文将通过一个线下小型门店成长为多元化集团的发展历程,逐步向读者展示企业应用架构的演变和设计的理念。

    完整的企业架构(EA,Enterprise Architecture)分析构建,包括业务架构、应用架构、技术架构、数据架构,本文聚焦应用架构,更加关注软件系统设计与公司经营管理的关系。不论是C端产品经理或者B端产品经理,理解应用架构的建设思路,能够帮助你更轻松的理解公司的业务运转,以及各个系统存在的目的与你所负责工作在整体团队中的定位和价值。

    传统企业的应用架构演变 1. 小门店的Excel管理之路

    我们将从一个最简单的案例入手,来展开故事。假设你是一名个体经营者,在小区中开了一家小门店,售卖居民常用的生活用品。门店不大,只有十几平米,平常由你一个人负责经营管理,包括采购,摆货,销售。为了更准确、科学的打理你的生意,你设计了一个Excel文件来管理你的商品与销售数据。实际上你只需要做三张表格,第一张表格存储了你的货品信息,第二张表格存储了你的采购记录,第三张表格存储了你的销售记录。这三张标的结构和关系如下图所示。下图采用了ER模型来描述三张表的逻辑结构,*和1的含义是表和表之间的关联关系,例如采购记录和商品信息是多对一关系,即采购记录表中的每条数据只能对应商品信息表中的一条数据,商品信息表中的一条数据可以对应采购记录表中的多条数据。

    因为你采用了科学的数据表格管理,记录了门店的所有采购入库和销售数据,这让你的经营变得井井有条,通过这些原始数据,你可以准确的管理库存,计算利润,掌握畅销品和滞销品,还能通过数据透视表制作销售日报和月报。实际上你通过以上三张表格管理自己的生意,已经是一个管理软件的雏形了。所有的软件系统无非都是对数据的增删改查操作,可以说,如果使用得当,Excel也可以做出一套小型的软件系统。

    2. 小超市的轻量级ERP之路

    因为你善于使用信息技术来协助你做生意,你的买卖发展迅速,很快,你将小门店升级成为一家小型超市,并且雇佣了几个店员来帮你。作为店长,你兴奋的绘制出自己的第一张组织架构图,梦想着事业会继续壮大。

    因为经营的货品更加丰富,日交易量成倍增长,并且有好几名员工需要做数据录入分析工作,这时Excel已经难以满足经营管理的需要。因此明智的你在开店之前,就决定采购一套ERP软件来协助你管理超市。因为你还处于创业期,资金有限,通过仔细挑选,你选择了一套轻量级的ERP,并且只购买了其中的几个核心模块,这样既可以控制成本,又可以让你经营的软件设备升级。现在,我们可以绘制公司的第一张应用架构图,公司拥有一套系统,包含三个模块。

    3. 通过CRM拉近与客户的距离

    为了更加准确的理解、认识你的客户,同时也为了能够拉近你和客户的距离,你打算通过CRM软件进行更加科学的客户管理。你设计了一套会员积分制度,所有的客户都能免费办理会员,这样你就可以记录下关键的客户信息,而且你的小伙伴建议你开通一个微信公众号,让客户能够通过微信来查询自己的积分,这个主意太棒了!你追加购买了几个ERP的模块,虽然ERP中也包含了CRM模块,但是研究后你认为内置的CRM模块功能有限,不支持对接微信,营销功能也不够强大,因此你新购买了一套CRM软件,和ERP进行了一定程度的对接,同时申请了微信公众号,找外包公司做了一些定制化开发。这样上述想法就都实现了!我们绘制出公司的第二张应用架构图。

    可以看到,核心的客户信息资产模块都在CRM中实现,其中内置了营销模块、消息推送服务Msg模块,包括SMS、EDM(Email Direct Marketing)和微信消息推送, CRM主要聚焦客户资料的管理和营销服务,主要用户为店长和运营人员;ERP主要聚焦于超市的进销存以及财务业务,主要用户为营业员、出纳、采购、库管和会计。请注意,这里已经产生了应用架构设计的概念,公共号,ERP和CRM每个系统都为了解决某一大类的业务问题而存在,有各自清晰地定位、分工和目标用户,每个系统相对独立又互有关联,内置若干模块,每个模块都是为了解决某一大类业务问题下的某一小类问题而设计。在这张图中我们使用了分层描述,靠近C端用户的微信公众号在最上层,支持业务运转的ERP放在中间层,偏底层的客户信息集成CRM放在最下层,这样可以清晰地看出几个系统的层次关系,同时也在一定程度反映了系统和业务之间的逻辑对应关系。

    4. 中型连锁超市的架构之路

    业务进展很顺利,你已经开了五家中型连锁超市了,员工数量达到了几百人。公司走上了正轨,标准化的管理分工已经成型,不同职能单元各司其职。为了有效管理团队,并且让内部流程更加顺畅,你邀请专业的IT咨询公司帮你重新梳理了公司的业务目标,组织架构,运营流程,通过引入OA,HRM以及重构ERP等手段,对不合理的制度,低效的流程进行了改造。公司成立了信息技术部,其中项目部配合咨询公司以及软件外包公司进行系统改造或实施新系统,运维部负责保证服务器、网络的稳定。

    你理解数据对公司发展的重要性,所有的管理决策都应该基于对数据的分析和判断,因此你邀请咨询公司帮你强化公司的数据分析能力。咨询顾问建议你实施数据仓库(Data Warehouse)和BI(Business Intelligence)项目,原因有几点:1. ERP系统和CRM系统都有报表模块,但两个系统的数据相互孤立,不利于整合分析。2. 业务系统的底层数据结构并不适合做复杂的数据分析,常见的多维分析更需要一套数据仓库常用的星形数据结构和雪花型数据结构。3.成熟的BI软件套件可以让你的报表分析与多维数据探查更轻松,其中的仪表盘更能够让你轻松掌控公司全局的核心指标变化。4. 企业经营中很常见的一个问题就是经营分析指标统计口径太多,造成管理混乱和沟通障碍,除了在管理上规范公司级指标的定义,也需要一套底层数据架构,消除上游各个异构系统的孤岛和屏障,统一管理汇总数据和指标计算。

    咨询顾问建议,虽然目前公司的业务系统还没有到非常复杂的阶段,但数据仓库可以帮助企业更快速高效准确的理解、捕获、使用数据,做好基础建设工作,培养员工的数据分析意识和方法,通过数据来进行决策。随着业务的拓展和系统复杂性的提升,数据仓库的存在价值将越来越明显。

    在数据仓库项目中,同时构建了数据集市(Data Mart)。数据集市介于BI展现层和DW数据底层之间,是数据仓库的数据子集。数据仓库的服务对象通常为全公司或全集团,但是不同部门可能有自己的数据分析诉求与指标管理诉求,这时候通过统一的数据底层,封装出针对某个部门使用的小型数据集市,可以保证数据流的合理性、可追溯性,同时研发部门可以完全复用DW和BI的技术能力,轻松地设计实施DM。

    如果希望数据仓库在企业中真正发挥作用,不仅仅是软件系统实施问题,更重要的是公司层面的经营分析思路体系化,指标管理规范化,以及数据部门组织架构、与业务部门合作流程设计问题,同时还需要提升全员数据化管理运营的概念和意识。软件本身并不能解决企业的问题,只有配套的架构、流程、制度与意识,才能发挥软件的功效。

    5. 应用架构跟随业务而变

    由于公司经营良好,很多商品可以从供应商处拿到很好的价格,经过供应商授权,公司决定开展2B业务,成立了大客户销售部,公司将作为供应商的B端渠道,挖掘企业客户。为了让销售工作高效展开,对销售人员进行严格的过程管理,同时也为了保留客户资料,避免销售独占客户资源,根据CTO建议,公司决定实施操作型OCRM(Operating CRM)项目。同时由于各部门经常出现个性化的软件开发诉求,软件外包维护的成本高,效率低,公司决定招聘研发团队,用自己的队伍进行软件的二次开发。

    在设计OCRM系统时。CTO面临两个选择:

    方案一:新做一套独立于现有CRM的OCRM

    优点:OCRM系统已有成熟的软件可以选择,无需从头开发;两个系统边界清晰,分工明确,便于未来各自的发展与演变。

    缺点:应用架构会略有复杂,需要将原有的CRM和OCRM做数据打通,对原有的客户模型做升级。

    方案二:在原有的CRM基础上开发新模块

    优点:新开发的模块完全基于公司业务流程和模式设计,适配程度高。

    缺点:新开发模块成本高速度慢,系统边界模糊,导致以后维护升级时模块管理的混乱。

    综合评估两套方案实现的成本和速度,考虑到对未来业务变化的灵活支持,同时为了避免影响核心CRM业务的稳定性,CTO决定采用方案一,让两个系统各自聚焦,互相独立,边界清晰,虽然无形中增加了公司应用架构的复杂性,但可以快速实施支持当前的紧迫业务,并灵活应对未来公司的销售业务变化。

    一般来讲B端客户的数据模型和C端客户差异非常大,B端客户模型关注组织架构和人员角色的描述,C端客户模型关注客户本身个人信息的描述,即便应用系统中将客户模型和操作型系统分开建设,客户模型一定会做成两套以支持不同的上下游业务系统。上图为了简化表述,只绘制了一个模块“客户信息”,但读者应该认识到该模块应该包含B端、C端两套客户模型。实际上有的公司会明确将两套客户模型在应用架构中分开设计并且分别建设,以便更加准确的体现应用架构中的业务概念。

    另外读者需要注意的是,广义上来讲,CRM代表一种企业对待核心客户资源的管理理念和运营方法,CRM是一种概念而非某一个独立的应用系统。大型的企业涉及多条业务线,不同的业务线有不同的客户群体,企业需要有统一的客户视图和管理理念,以及强大的IT系统支持,来实现准确的客户接触点管理,充分挖掘客户群体实现精准销售,积极有效的维护企业和客户的关系。CRM体系化的系统建设中包含了客户建模,会员积分管理,营销中心,销售线索和过程管理,小型数据仓库或数据集市,统一客户视图,客户画像和数据挖掘,电话销售中心等等。不同的企业对系统的划分和团队的管理各不相同,但所有CTO都应该明白CRM是一套应用体系,而不仅仅是某个单一的独立应用系统。

    至此,我们已经绘制出一套一般企业的简化版应用架构图,以及一张常见的组织架构图。可以看到,应用系统的建设,是根据业务的发展变化逐步完成的,每个系统都有独立存在的意义和价值。

    6. 传统企业如何管理软件开发

    在上一节的组织架构图中,CTO引入了需求管理部的子部门。传统企业内部的软件升级开发,一般会由业务部门将需求提交给需求管理部受理,需求管理部常设BA岗位(Business Analyst),负责受理、评估业务方需求,形成软件方案设计,输出需求文档,提交给开发人员开发。BA非常像互联网企业的PM岗位,区别是互联网企业的PM决策权更高,更加深度的参与、影响业务。BA以及IT部门的的权责范围取决于企业对信息化建设重要性的认知程度,以及团队负责人在企业的决策权和影响力。一般来讲传统企业的CTO或CIO汇报对象为COO,很少进入公司最高决策层,而在互联网企业CTO或产品VP都属于最高决策层。

    传统企业更加倾向于瀑布式软件开发,对研发、运维流程的管理更加严谨,因为传统企业业务变化慢,对系统的每一次调整改造都非常慎重,而互联网公司业务变化调整快,必然要求软件开发时效性高,对软件设计的严谨性做出一些让步,因为很有可能发生的情况是,软件还没有开发完毕,业务或流程已经再次发生变化。

    企业的信息化管理有很多标准的管理模型,例如COBIT,ITIL,CMMI,ISO27001,覆盖了开发管理,服务管理,数据管理等方方面面的规范和标准。很多成熟的互联网企业也会执行使用这些标准来提升IT能力对企业管理效率的提升和经营风险的控制。

    多元化业务带来的应用架构演变 1.    在线商城业务带来了互联网化管理

    公司的零售业务发展进入了瓶颈期,CEO需要寻找新的增长点。经过评估,决定开展电商业务,新成立了电商部,从市场上聘来了某电商平台VP作为部门负责人,直接给CEO汇报。为了学习互联网公司,以技术力量推动业务创新,电商部组织结构参考了一般互联网公司组织结构,有自己独立的研发团队,设置了产品岗位,产品技术总监给电商部负责人汇报。电商部受到CEO极度重视,给与极高自治权和最高资源支持,同时CEO还将之前线下的客服团队升级为公司一级部门,直接给CEO汇报,统一处理线上线下的客服与售后业务。

    新业务开展,大家干劲十足,因为电商部产品技术总监和公司CTO之间不存在汇报关系,产品技术总监为了快速推进项目,所有决策基本只是告知CTO。产品技术总监作为纯互联网背景专家,认为购买现成软件套件不利于系统的二次开发和自主维护,长远来看会限制公司业务发展,希望整套系统实现自主研发。虽然CTO极力反对,但经过电商部负责人和产品技术总监的游说,CEO听取了总监的建议,并且总监承诺自己的研发团队效率极高,一定会在承诺之日交付系统。

    产品技术总监设计的应用架构体系,包括PC和移动版的前端应用,以及完整的后端系统,包括订单、售后、客户信息、会员、营销、账号、CMS。此外,仓储、财务系统会接入现有ERP的服务,配送模块直接与第三方配送服务商系统对接。对于这个架构设计,CTO比较不满,认为客户信息和账号管理不应该重复建设,而应该统一规划管理,但产品技术总监一心快速推进实施,对于信息技术部开发效率低的情况他早有耳闻,他可不希望被一些不可控力影响导致自己的项目延期,因此CTO的抗议他不予理会。

    升级后的客服部门,新建了20人坐席的电销中心,以支持主要来自于线上的电话客服诉求。新成立的客服团队需要CallCenter系统开展业务,虽然CallCenter的主要服务群体是线上业务的客服话务员,但CEO为了在一定程度上安抚CTO的不满情绪,将CallCenter项目安排给CTO负责。CTO采购了一套成熟CallCenter来支持400热线业务,对此安排电商部的产品技术总监没有什么异议,但在CallCenter的实施中却出现了问题。因为CallCenter系统只负责电话作业,其中的客户资料一般由上游系统提供。但是公司现有两套客户资料,一套是保存在CRM的线下业务客户资料库,一套是在线商城的客户资料库。为此只能在CallCenter中新增一套客户库,将另外两套客户库数据同步过来,这样客服人员才能在CallCenter中查到公司级别的完整客户信息。

    2.    信息孤岛与主数据管理

    电商系统如期上线,业务发展迅速,电商团队的运营和产品人员年轻,聪明,充满活力,思维活跃,玩法众多,电商技术团队响应迅速,产品经理和技术团队的无缝配合,让技术力量真正推动了业务的增长。公司赚钱了,老板很开心。但很多问题也同时暴露了出来。我们先来看看之前的应用架构。

    之前为了快速上线,有一些应用架构遗留问题没有解决。现在公司有三套客户资料库,线下客户通过微信公共号访问CRM系统中的客户信息,在线商城的客户通过线上商城访问e-Store系统的客户信息。当客户致电400时,电销业务员(TSR)访问的是从e-Store和CRM同步过来的客户信息。

    线上客户关注公共号后,查不到自己的资料,这让客户感觉很诡异。

    线下客户想在线上商城下单,发现之前登记的账号不能使用,需要重新注册完善资料,客户很烦躁。

    数据同步30分钟一次,有时候客户刚修改完资料再致电400,客服查到的客户信息不是最新的,让客户很生气,客服很苦恼。

    有的客户喜欢打电话让客服改资料,因为客户资料是单向同步,客服无法协助客户修改资料,客户很气愤,为什么你们连这点服务都做不好!

    很多客户在线上线下都消费,但由于在数据仓库中冗余出了两个客户对象,不论是线上团队还是线下团队,都无法做更准确的客户画像和跨渠道消费行为分析。

    CEO很生气,找到CTO和电商产品技术总监,质问怎么回事。CTO回答,我们遇到了严重的信息孤岛问题!由于CRM和商城后台数据互相孤立,导致核心客户资源不同步,不统一,让公司无法得到一个完整准确的客户视图。如果要解决这个问题,必须对应用架构进行改造,并且改造比较耗时。CEO很郁闷,没想到应用架构不合理会影响到业务发展,也没有想到组织架构的设计会导致应用架构出问题。为此,CEO做了一些调整,产品技术总监实线向电商部经理汇报,虚线向CTO汇报;总体来讲产品技术总监对电商业务销售端负责,CTO对全公司IT架构管理和其他所有系统负责。经过善意的沟通,CTO和产品技术总监的矛盾消除了,大家决定合力解决问题。

    解决数据信息孤岛的方法很简单,那就是只保留一份客户信息库,这份客户信息库保存最核心的,与业务单元无关的客户属性和资料。至于积分、会员等扩展属性依然由各个应用系统维护管理。调整后的应用架构图如下:

    将客户信息库独立,商城、CallCenter、CRM和微信公共号通过统一接口调用Customer Profile存储的核心客户档案,不论客户或业务员从哪个端口查看或修改信息,变化对其他端口都是透明、实时的。实际上这就是客户主数据管理(Customer MDM)的设计理念。

    在企业应用系统建设中,不可避免的会遇到信息孤岛问题,信息孤岛是指因为各种原因,每个应用系统独立建设时,没有和外界系统做良好的打通,导致应用系统之间存在流程或数据的孤立性,最终给业务带来严重影响。解决数据信息孤岛的经典方法就是主数据管理(MDM)的思想,主数据管理通过应用架构的拓扑设计,配合相应的管理手段,帮助企业存储、识别唯一的关键数据,避免企业内部关键数据的冗余和不一致问题。常见的主数据有客户主数据,商品主数据等。

    主数据管理的设计理念应该自始至终贯穿企业应用架构的设计过程,需要注意的是,企业应该在合适的阶段实施主数据管理和治理。主数据将应用架构变得更复杂,在初期阶段实施时需要投入更多时间和资源,而在企业发展的某些阶段,快速迭代上线意味着对商机的捕获和市场变化的迅速跟进,一个合格的架构师应该在应用架构设计和公司业务发展之间做出合理权衡,要根据现实的情况和资源,敢于在应用架构的和理性上做出妥协和让步。

    主数据经常作为底层数据应用来管理,因此在架构图中我们将它和DW并列画在最底层。

    3.    抽离共性模块全面服务化建设

    公司业务发展稳定,各个系统底层做过几次技术重构,性能更强健。为了让各个应用系统更加聚焦,提升稳定性,节约开发成本,避免重复劳动,CTO和产品技术总监讨论后决定对一些公有服务从各自应用系统中剥离,统一进行服务化改造升级,为以后公司新业务的开展打好基础。例如,将CRM和商城后台的消息模块功能合并,将商城支付模块单独剥离,设计实施了集成化的权限管理系统Auth,给全公司多个应用提供统一的权限管理服务,控制公司运营风险。

    CTO和产品技术总监合作加强了数据团队建设,设立了数据挖掘团队,丰富了客户画像,加强了经营分析能力,产生了更多的策略输出。数据策略输出不仅给在线商城提供了更强劲的推荐策略,也为CRM,运营人员提供了更丰富的策略运营、精准定向活动推送支持。

    4.    强健的底层架构快速支持新业务开展

    公司在寻找新的增长点,计划开展个人理财业务。公司的组织架构有了新的调整,管理模式也有了新的提升,形成了集团化治理模式,成立了财务共享中心,人力资源共享中心。新设立的理财事业部,和零售事业部、电商事业部一起,调整为独立核算事业部编制,事业部聚焦经营和销售,集团层面给事业部提供基础运作支持。信息技术部也与时俱进,将之前的需求管理部调整为产品部,信息技术部主要负责CRM、CallCenter、ERP、OA、HRM、DW、BI等应用系统,保证集团职能部门运作,为事业部的应用系统提供基础架构和底层服务支持。

    因为集团IT应用架构已经非常强健,理财业务的系统构建可以迅速展开,CTO和理财事业部的产品总监沟通后绘制了集团应用架构图,理财业务只需要建设一套C端APP和一套基本的管理后台,而类似于客户数据,支付,Push服务,DW和BI都直接使用集团现有系统,无需重新开发。


    CTO和产品总监讨论后,认为上述架构图还存在一点问题,账号管理不应该单独创建,集团已经有着很成熟的统一客户管理理念,多套账号管理模块会再次造成信息孤岛问题。因此决定将现有的账号管理模块也进行平台化、服务化升级,给理财业务提供支持。集团层面的Passport系统诞生了。更新后的架构图如下。


    这里顺便解释一下,为什么本文对所有软件系统都称为系统,而互联网公司则习惯称其为产品。

    互联网的发展催生了产品经理的岗位。产品经理常分为C端产品经理,B端产品经理(包括商家端和运营管理中后台)等。B端产品线中,有CRM产品经理,供应链产品经理等。在互联网公司似乎不太在意区分产品和系统的叫法,到底两者有何区别?

    实际上,所谓产品是指企业提供的商品或服务,给企业带来利润。早期的互联网公司多为虚拟经济形态,面向用户的软件系统就是公司给消费者提供的商品或服务,因此聚焦软件功能设计的人员被称为产品经理。而互联网公司是一类高度依赖信息技术能力驱动业务的公司,对各类软件系统都倾向于自主建设,因此不论是面向客户的系统,或面向企业内部的系统,软件设计人员都统一叫做产品经理,其职责定位就是负责软件的设计和实现,软件系统习惯被称为产品;而在传统企业,负责软件设计的人员一般都叫做需求分析师或系统分析员,软件系统习惯被称为系统。

    其实怎么称呼都无所谓,本文统一叫做系统。

    企业通用应用架构设计 1.    通用企业应用架构图

    对上文的应用架构图做一些简化和调整,以便更加准确的体现应用架构的共性以及与业务的对应关系,得到一张更加清晰简洁的企业级应用架构图。


    第一层是对外系统。所有给企业外部客户使用的系统都在这一层,包括官网,普通用户或客户使用的C端。如果是类似于美团,天猫这种平台性质的业务,还会包括给商家使用的商家端。这类系统站在与客户接触的最前线,是公司实现商业模式的桥头堡。

    第二层是对应C端系统的管理后台。常见的管理后台都会包含订单、CMS、商品等模块。每个C端业务形态都会对应一个管理后台,有些管理后台的模块可能会被抽离出来集中维护,例如风控,消息服务,客户主数据。

    第三层是业务单元支持系统。绝大多数企业业务的开展,必然不能单纯靠线上的运作来实现经营,而可能包含电话销售,客服,地推,仓配等一系列业务单元共同运作。业务单元的运作需要强大的系统支撑。

    第四层是职能单元支持系统。企业发展到一定规模后,必然会有完善的职能单元作为后勤部门支持业务单元的运转和企业的正常运作,例如法务、财务、人力、客服,每个部门的正常运转都需要相应系统的支持。

    第五层是基础架构支持系统。信息化建设到达一定程度后,企业有必要将通用功能服务化,平台化,以保证应用架构的合理性,提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。

    第六层是数据底层,和第五层类似,这一层主要集中在数据层面的统一和封装,对各个下游系统提供数据服务。

    以上六层划分涵盖了企业所有的应用系统建设,每一个应用系统的存在都将定位在六层中的某一层。上图示例的系统涵盖了绝大多数正常企业经营运转常见的应用系统,在现实世界中,应用系统数量会远远多于上图所示,例如商业银行可能会有成百上千个系统存在。但是理解一个常见企业的组织结构,部门定位,以及上述应用架构图形成的原因,可以让你更准确快速的理解、掌握、设计任意一个应用系统。

    2.    不同类型企业的应用架构图示例

    因为一般企业的组织架构设计,职能单元的设计基本没有太大区别,而以上简化版的应用架构图映射了一个标准化企业的各个常规业务单元,且涵盖了绝大多数企业中标准的应用系统,所以我们可以将不同互联网企业的应用架构图映射到上图中。下面我们用三个例子,向读者演示不同业务形态、发展阶段的公司,其应用架构的可能形态。作者并未在以下公司任职,或与相关内部人员探讨过其公司应用架构,以下示意图均为作者根据几个公司的业务特点和发展阶段,所做的推测。

    首先以美团点评为例。美团的业务模式主要为供需平台建设,帮助消费者和服务提供方撮合交易。外部系统包括了C端系统和商家端系统,C端系统为消费者常用APP,商家端系统为商家提供商品管理,交易管理,推广管理,经营分析等功能。C端或商家端都对应后端管理系统,方便企业内部对整个平台进行管理、营销、风控等。平台需要发掘更多的商户资源入驻,因此会有销售过程管理的OCRM系统;平台需要对C端客户提供客服与售后支持服务,相信美团点评的业务量,一套专业的CallCenter系统必不可少;美团提供了自营的配送服务,TMS系统必然成为标配(也有可能是SCM中的模块)。由于美团业务不涉及自营的实物货物买卖服务,没有仓储体系,因此推测没有WMS系统(或者ERP中包含了WMS模块但是没有启用)。O2O业务需要管理大量线下门店,因此GIS(Geography Information System)系统不可或缺,对于实力较强的公司,可能还会开发独立的POI(Point of Information)管理系统(也有可能是GIS中的模块)。至于财务、OA、Passport、Auth、BI、DW、MDM等,必然都是公司标配。

    接下来再以今日头条为例。今日头条构建了信息流资讯类C端,吸引网民使用,这类产品最常见的盈利方式为广告变现。在公司经营之初,可能采取了市面上的DSP平台来完成APP的广告管理(当然也可能从来没有采用过),为了更好的设计广告产品,相信现在一定有自己的广告投放管理平台,因此公司会有给广告主使用的B端广告投放管理系统。(当然也有可能还没有这类平台,作者在百度工作时很多商业变现产品投放管理都是PM和广告主线下沟通后通过内部平台操作的)。因为业务模式以广告投放为变现手段,因此后端系统可能没有交易类后端复杂,但基本的CMS和风控(反垃圾、反作弊、合法合规)必然是有的。

    公司需要盈利,就需要售卖产品,售卖产品永远不可能只在线上运作,必然会有BD团队支持,因此今日头条也会有CRM系统,管理对象为广告主而不是网民。但是WMS、TMS系统这类系统估计就不需要了。至于CallCenter,笔者查询了官网,没有找到相关的客服热线,猜测还没有建设。今日头条的早已度过创业期,标准的管理软件应该配备齐全,例如OA,HRM;不同的基础架构支持系统,在当前阶段有可能有,也有可能没有,例如Auth,Pay,MDM等。作为一个纯技术公司,BI,DW当然是标配。

    最后的例子,我们挑一个相对规模小,产品形态单一的例子,例如墨迹天气,万年历这类工具类应用的公司。这类公司在创业初期,不考虑变现的情况下,团队小,产品简单,应用架构图也会非常简单,在产品发布时,只需要实现官网、C端、后台管理、账号和会员管理就足够了。当然随着公司的发展,常见的变现手段之一就是广告投放,可能会继续演变到类似于今日头条的应用架构。

    以上举了三个例子,让读者更好的理解应用架构演变和公司业务模式以及发展阶段的关系。在实际工作中,应用架构的建设与面临的情况会复杂得多,只要理解了以上简化版的例子,可以更容易理解实际工作中的场景。

    3.    企业应用架构设计的一些建议

    最后,我们来谈一谈如何合理的设计企业应用架构。不论是架构师,产品条线负责人,或某个系统的产品负责人,都要有架构设计的理念和知识,尤其是后端产品经理,必须充分理解企业应用架构的基本概念。这里给出一些应用架构设计的建议。

    系统定位和边界要清晰,对应的业务定位和边界要清晰

    一套应用系统的存在,都是为了解决某一类业务问题,对应某一个业务板块。如果业务板块或业务单元定义模糊,也会导致对应的应用系统定位混乱。

    系统要实现松耦合,高内聚

    系统要对外界透明,简单,易理解,与外部系统的接口要简明,扼要,灵活。内部模块高度聚合,粒度越细越不可拆解。

    易变的,尝试中的新业务要避免影响现有业务的稳定性对新业务的支持,可以考虑新建独立微小型应用系统,以便避免改造成熟核心系统,影响其稳定性和健壮性。

    系统之间数据要实现单向流转

    系统之间尽量保证单向数据流转,确保数据流可回溯,数据的一致性和可追溯性。混乱的数据流转管理会造成应用架构管理的灾难。

    架构设计核心目标是支持业务,有些时候不合理的存在是合理的

    应用架构存在的首要目标是支持业务,很多成长性企业或初创公司面对生存的压力,不能为了保证架构的合理性而拖延系统实施速度导致企业错过发展时机。这种情况在互联网型企业更为常见。业务还在试错期,系统需要尽快保证支持业务试错,如果一上来就谈论整体架构的合理性,很可能花费巨大成本实现了合理架构后,新业务已经取消或失败。优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。

    对于CTO或公司架构师,要保证整体企业应用架构的合理性,只要大框架合理,局部的偏差可以忽略,修正的成本也比较小,如果大框架有偏差,修正的代价会非常高。对于产品条线负责人,要保证局部框架的合理性,避免出现设计不合理造成的返工和补救工作。很多时候架构师或条线负责人要做出判断,是做一套新系统,还是修改老系统,新系统如何定位,老系统如何调整定位;数据如何流转,系统之间如何关联,底层数据如何打通;是否要复用其他系统模块,是否要将某些模块抽象化,服务化,平台化。对于产品经理,要在系统级别的粒度做出类似问题的判断,能够识别出可能存在的系统演变风险,及时升级控制不了的问题,避免做出错误决策。

    企业架构是一套庞大复杂的体系,本文是对其中应用架构部分,结合作者实际工作经验的浅薄理解,业界有着众多的企业架构建设规范和指引,例如Zachman,EAP,TOGAF,这些框架涵盖了信息技术和企业战略结合实施的方方面面,感兴趣的读者可以做更深入的学习。

    展开全文
  • 企业应用架构之分层 - 总结

    千次阅读 2015-04-14 21:35:42
    总结了3中企业应用架构分层中常见的3种分层。
  • 企业架构发展过程概述

    千次阅读 2018-04-19 21:37:34
    这篇文章主要是给大家介绍下企业架构发展过程,这十多年我处在中国一线互联网公司,基本见证了整个中国互联网企业架构变迁的历史。一.简单的单体应用在这个阶段企业主要的需求是线下的内容线上化,对于技术部门...
  • Java企业应用架构

    千次阅读 2010-09-14 21:43:00
    Java企业应用架构设计中的分布式结构大致可以分为单级结构、2级结构、3级结构和N级结构。充分理解和应用分布式结构可以更好的理解当代网络计算的现状,设计出更优的企业级应用程序。 <br /> 长久以来...
  • 出现这种问题的根源就在于原有架构设计不合理,扩展性极差,出现了新的解决方案,只是在原有架构上增加新的解决方案,而没有及时的对原有的代码进行重构和改造,随着时间的推移整个项目就是铁板一块,为后期的项目...
  • 企业IT架构发展历程

    千次阅读 多人点赞 2019-04-17 09:58:52
    提起IT架构每个人都不陌生,有人说...无论怎样,IT架构都是企业IT信息化建设的基础,它能够有效指导信息化项目的开展与执行,今天笔者就来谈谈企业IT架构发展过程。 最早期没有IT架构一说,信息化基础设施与应用...
  • J2EE WEB应用架构发展分析

    千次阅读 热门讨论 2012-02-22 19:32:25
    J2EE体系使用多层的...Web项目的架构从成型到基本稳定也经历了几个版本的发展。   一、 直接基于JSP的开发结构  JSP是J2EE中很重要的一部分,JSP功能强大,既可以作为页面来浏览,也可以处理业务;基于传统的
  • 企业应用通用架构

    千次阅读 2015-01-06 09:42:31
    晚上把应用架构结合之前研究的东西梳理了下,整理了一张架构规划图,贴在这里备份 下面是个人理解的做架构的几个要点: 1、系统安全 这是首要考虑的,以这张图为例,网络划分为3个区: a) DMZ区可以直接公网...
  • 企业多层分布式应用架构

    千次阅读 2009-02-12 17:39:00
    企业多层分布式应用架构 2000-07-19· anony·yesky 在信息产业高速发展的今天,企业间的竞争将更加激烈。随着规模的不断扩大和业务的不断更新,企业迫切需求完整的分布式解决方案,用于管理复杂的异构环境,实现...
  • Java企业应用架构设计中的分布式结构  2010-12-24 13:54:12| 分类:默认分类 | 标签:|字号大中小 订阅 Java企业应用架构设计是每个Java开发者不必学的知识,本文将对Java EE应用的架构与...
  • 式的起源及发展的过程进行讲述,并且分析目前MVC模式在不同UI层中的应用设计,由于本人的水平有限,加之实际的项目中可能应用的理解和经验水平不足,可能在 某些分析的地方不对,还请大家提出。我们之前的写作...
  • .NET企业应用架构设计系列

    千次阅读 2011-01-24 23:47:00
    一、.NET企业应用架构设计系列之技术选型这里说的技术选型实际上是指技术方向的选择,或者叫平台方案的选择,也或者叫技术路线等,总之是大方向的把握。假定项目背景是要做一个中型WEB系统,公司组建新的技术团队...
  • 以秒杀为例浅谈企业应用软件架构设计过程

    千次阅读 多人点赞 2015-01-27 17:19:18
    1、引言 本文不是学术性文章,也不是某些标准化理论的阐述,而是根据所从事J2EE应用软件架构设计工作的经验,谈谈自己对软件架构设计过程的理解,希望能让一些徘徊于门口的同学能对企业应用软件架构设计的目标、...
  • 企业架构是自上个世纪七、八十年代发展起来的一套理论,在这几十年的发展过程中已经衍生出很多种不同的企业架构方面的理论体系,而且很多国际大型企业和政府已经在反复摸索中创建了符合各自特点...
  • 一方面是工作上比较忙,同时生活上也步入正轨,事情比较繁多,目前总算是趋于稳定,可以有时间来完善以前没有写完的系列,也算是对自己这段时间工作和生活上总结,同时也加深下自己对架构和 设计方面的理解,由于...
  • 基于企业服务架构的新一代企业管理应用软件 --在2007年中国开发者精英论坛上的演讲IT168耿英英: 企业发展离不开信息化,而信息化的关键是企业管理的信息化,新一代的企业管理软件,使得现代的企业可以达到一个更高...
  • 企业发展呼唤企业架构

    千次阅读 2007-01-14 18:39:00
    近年来,SAP的中国用户从传统制造业迅速扩展到各行各业,从单纯ERP应用到CRM、SCM、SRM、PLM等各类企业应用,从纯粹后台应用到前后台有机结合,从简单的交易处理到综合业务分析和企业决策支持,从孤立的应用系统到...
  • 首席架构师眼里的应用架构设计

    千次阅读 2018-05-11 15:13:04
    无架构,不系统,架构是...架构可细分为业务架构、应用架构、技术架构,业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。 如何针对当前...
  • 郝振明 EAII企业架构创新研究院 转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号:“加群 姓名 公司 职位 微信号”。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 211,400
精华内容 84,560
热门标签
关键字:

企业应用架构的发展