架构如何为业务和技术“服务”（1）

前言
为提升架构对于项目，产品的贡献度，更好的服务于业务和技术，本文将探讨架构的现状和规划未来架构的目标。

在讨论架构、业务、技术的问题前，请耐心的阅读完本文有关架构、企业架构、软件架构、架构师的概念性定义，很多时候我们阅读文章都是“秒杀”风格的，只看自己感兴趣的部分，不看长篇大论，只有明确了这些概念定义，才能明白我们现在讨论的主旨。

 

1，架构定义
1.1，架构
架构是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案，架构往往是对复杂形态的一种共性的体系抽象。

 

一个架构是系统的基本结构，它由多个组件以及它们彼此间的关系而组成，并且在一定环境和原则下进行设计和演变。

 

复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。

 

1.2，企业架构
企业架构(EA：Enterprise Architecture)是指企业体系结构或企业总体架构。按照Meta Group的定义，企业架构是一个自顶向下、业务战略驱动的过程，它是一个整合了业务、信息和IT技术的企业解决方案架构。

企业架构可以分为两大部分：业务架构和IT架构，大部分企业架构方法都是从IT架构发展而来的。

企业架构的意图是确定组织如何能够最有效的实现其当前和未来的目的 (SEArchCIO.com)  。

1.2.1，业务架构
是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容

业务架构体系是针对企事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，比如业务架构体系认为一个信息系统必须由组织机构、业务流程、业务信息、业务功能、和业务语义等层次构成。

 

 

1.2.2，IT架构
指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。

 

 

1.2.3，IT架构与企业架构之间的关系
到底应如何看待IT架构与企业业务架构之间的关系? 众所周知，一个企业的架构规划应该是业务来驱动的，业务驱动则一般是由流程驱动的，而IT流程则正是流程驱动的动力引擎。因此，实现IT架构灵活性就成为企业架构的一个迫切需求。例如，企业的业务活动首先是由业务人员执行活动完成的，比如输入订单和客户资料、做出商务决策等，而IT系统则执行各种自动化活动，包括商业逻辑、业务规则、管理业务数据，提供IT界面连接等。

所以，IT系统是业务的一个重要组成部分，业务敏捷性不但需要一个灵活的业务模式，也需要IT系统的敏捷性。也就是说一个当业务改变时，IT系统也应该随业务的变化而变化，这种对IT的灵活性需求也就是对IT的所有方面都提出了挑战，如从架构、技术、产品，到过程控制、成熟度和管控等。

 

1.3，软件架构
软件架构（Software Architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

 

1.3.1，架构要素
软件系统的架构（Architecture）有两个要素

l  它是一个软件系统从整体到部分的最高层次的划分。

l  建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

 

1.3.2，架构目标
软件架构设计要达到如下的目标：

n  可靠性（Reliable）：软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

n  安全行（Secure）：软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

n  可扩展性（Scalable）：软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

n  可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

n  可伸缩 （Extensible）：在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

n  可维护性（Maintainable）：软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。

n  客户体验（Customer Experience）：软件系统必须易于使用。

n  市场时机（Time to Market）：软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

 

1.3.3，架构视图
1，逻辑架构：

逻辑架构关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块和类等

2，开发架构：

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

开发架构和逻辑架构之间可能存在一定的映射关系：比如逻辑架构中的逻辑层一般会映射到开发结构中的多个程序包；再比如开发架构中的源码文件可以包含逻辑架构中的一到多个类（在C++里一个源码文件可以包含多个类，即使在Java里一个源码文件也可以同时包含一个类和几个内部类）。

3，运行架构：

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

运行架构和开发架构的关系：开发架构一般偏重程序包在编译使其的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行架构比较关注的是这些运行时单元的交互问题

4，物理架构：

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

物理架构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标程序的静态位置问题：物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的

5，数据架构：

数据架构关注持久化数据的存储方案，不仅包括实体及实体关系的数据存储格式，还可能包括数据传递、数据复制和数据同步等策略。

数据架构和物理架构的关系：对于很多集成系统，数据需要在不同系统之间传递、复制和暂存，这往往要涉及到不同的物理机器；也就是说，如果需要，可以把数据放在物理架构之中考虑，以便体现集成系统的数据分布与传递特征。

 

1.3.4，架构设计方法

 

1.3.5，架构师
是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。

 

架构师的角色划分：

u  首席架构师：制定公司的长期技术路线图。是公司技术方向和技术组合的重要决策者。

u  技术架构师：关注整体网站系统架构。通过技术架构对业务架构提供支撑；（系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责）

u  业务架构师：关注业务架构。对公司战略、客户需求、内部需求进行抽象、组织、规划。关注业务的敏捷性，能够随着战略的变化而变化。

u  数据架构师：负责数据库相关的架构，数据相关的技术研究、规划、评估等。

 

2，现阶段的架构
2.1，NBF架构平台
业务发展中心在2010年3月，明确的提出了自己的架构平台-NBF，包括一些列的框架、服务、组件和规范，下面是该平台的架构图：

 

（有关NBF架构的详细介绍，请看高阳空间的文章：

http://www.hisun139.com/forum.php?mod=viewthread&tid=245

）

NBF的架构分为一下四个层次：

1，表现层：

1.1，基础技术

Windows--WinForm，WPF；

Web--HTML，Silverlight，Flash；

Mobile--WAP，Windows mobile；

1.2，用户界面接口适配层

 

2，业务层：

分为一些业务模块和业务组件，具体有

宏观诊断，基金诊断，基金管家，理财超市，理财资讯；

基金收益，基金易搜通，理财提醒，诊断报告，基金比较，数据对接... ...

 

3，系统框架&服务层：

3.1，系统框架

安全/权限，异常/日志，数据同步，系统更新，系统监控，通用服务；

3.2，系统服务

FT/MB数据服务，FT/MB对接服务，手基通应用服务，批量诊断应用服务，短信平台应用服务

 

4，数据层：

第三方数据库-》转换程序-》基础数据；

数据通讯服务--WCF/NOTES；

业务数据库；

PDF.NET数据开发框架--SQLMAP/ORM；

 

 

NBF架构强调的是“分层”的概念，跟一般的三层架构类似，我们增加了一个“系统框架&服务层”，这应该算是NBF的特色所在，它包含了一系列的技术框架和业务服务，而业务层是跟基金相关的业务处理组件。

 

2.2，对架构认识的误区
 

2.2.1，认为我们用的架构是PDF.NET
从NBF的层次图可以看出，PDF.NET仅仅是引入的第三方开源的数据开发框架，它是一个开发框架，而不是一个架构，而且，它专注的是数据开发，业务处理，界面呈现等还需要其它框架、服务或者组件的，大家常常说PDF.NET有问题就是邓太华的架构问题，这是完全不正确的，归根结底的原因，还是大家对于“框架”和“架构”的认识不清。

 

2.2.3，认为框架和架构是一回事
人们对软件架构存在非常多的误解，其中一个最为普遍的误解就是：将架构（Architecture）和框架（Framework）混为一谈。

 

框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。

一图胜千言，上图切中肯地点出了架构和框架的区别。一句话，框架是软件，架构不是软件。

 

软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。或许，人们常把架构和框架混为一谈的原因就在于此吧！

 

我们不能指着某些代码，说这就是软件架构，因为软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。

 

2.2.4，认为架构就是搭建一个VS解决方案
如果说架构是一个比代码更高一个层次的抽象概念，那么一个VS解决方案就是架构的实际落地。从某种程度上来说是如此，所以在每个项目开始的时候，大家都会叫我搭建一个具有三层架构骨架的VS解决方案，把必须的类库、框架都引入。也许正因为如此，大家都认为架构就是我的架构，架构出了问题就是我的问题。

 

根据前面的论述，架构远不是搭建VS解决方案这么简单，如果从VS解决方案来看，架构工作成果体现在解决方案中就是

•   解决方案项目的划分；
•   项目文件夹的划分；
•   文件的定义和组织；
•   类文件的组织；
•   资源文件的组织。

 

而要得到解决方案里面的这些东西，需要深入到项目的需求、开发、测试过程中去，抽象出项目要解决的问题场景，成员角色关系，模块关系等等。

 

2.2.5，认为架构的工作就是写代码
现实中，架构师都深入到项目中去做开发了，初看起来，他们也在写代码，做模块，跟一般的开发人员没有区别，所以会有人认为架构的工作就是代码开发工作，架构师就是高级程序员。

我们先看看架构师的六项潜质：

ü  每个好架构师都是一位出色的程序员（卓越的程序员）

ü  驾驭概念的技能是最高潜力（抽象思维）

ü  站在技术的山顶向前眺望（技术的前瞻性）

ü  透过问题看本质（问题解决大师）

ü  百科全书式的智者 (多领域知识)

ü  善于沟通的技术领袖（沟通能力）

 

而程序员不需要这么多潜质，我们看看高级程序员的职责：

会写代码，也会写一些项目的文档，如需求，详细设计，（系统整体方案设计）架构设计，用户手册，开发计划等；

 

可见，架构师除了写出优越的代码，还有更多的工作职责：

•   领导与协调整个项目中的技术活动（分析、设计和实施等）
•   推动主要的技术决策，并最终表达为软件构架
•   确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”
•   确定设计元素的分组以及这些主要分组之间的接口
•   为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻
•   理解、评价并接收系统需求
•   评价和确认软件架构的实现