信息化与企业能力

从企业职能分配的角度来看，企业能力包括企业产品开发与设计能力、市场与客户服务能力、产品与服务提供能力、生产与品质保障能力、供应与物流管理能力、人力资源开发与利用能力、成本管控能力、品牌策划与运作能力、后勤保障支撑能力等等基础能力。

图一 企业职能的分配

这是信息化规划中，应用架构的关键设计依据和指导方向，它给应用架构设计提供了业务架构与IT服务之间直接的对应要求。

应用架构与业务架构之间的支持关系

图二 三层系统的分层次结构

首先、我们知道业务层是一个系统中最核心的部分，业务层是实现系统业务功能的核心逻辑层。业务逻辑一般是通过分层结构来构建应用系统，在组织业务逻辑功能时大部分的情况下是使用业务层单独负责相应的业务逻辑来实现的。

其次、很多人认为业务逻辑层并不复杂，可以把问题简单化，引入一些框架性的东西即可。事实上这种认识与做法会提升系统的复杂度，架构师需要根据业务运转的逻辑本身来适应性的搭建应用框架。尤其是对规模较大的以及业务逻辑性较强的业务，事先展开周密的业务设计模式给整体企业架构带来的优越性就显而易见了。

再者、从单层技术视角来看，业务逻辑层是用来处理领域模型对象之间的逻辑关系。单从整体架构来看，业务层的数据最终是要沉淀到数据库中形成数据架构，我们在进行业务层设计时一般是在架构中的分层架构模式中出现，但不能忽略与其他几层架构之间的匹配关系。分层结构的一个优势是解耦后的灵活性，将领域模型与底层数据访问、表现层等进行分开组织，这样可以让系统结构上清晰，并降低他们之间的强耦合性带来的不便。

最后、很多架构设计都须最初在业务层完成，比如说用户的角色权限、数据验证、业务逻辑初设等一些基本的业务规则。

应用架构支持业务能力构建的关键要素

业务架构层面须构建的关键要素如下：

全面原则：全面考虑架构设计的专业性要求、业务的拓展性要求以及治理落实要求。以架构开发方法为基础并按照组织的需要和业务愿景来对架构开发方法所进行定制，并落实到架构治理流程层面。

共识原则：明确业务架构的各类术语，在组织中建立起关于这些内容的共识。

视角原则：明确所有架构实践所涉及到的企业、业务部门的视角，而针对这些内容的定义工作应由此前被识别出来的架构实践企业运营级主办方牵头业务与IT、供应商协同沟通、展开工作。

规范原则：明确阐述将会由架构实践所产生的各种架构交付物以及他们之间的交互关系、依赖关系、检验关系，同时要说明用于管理这些交付物的设计规则与维护指南。

权责原则：定义清楚架构实践所涉及到的各种角色，以及为这些角色所分配的关于架构交付物和流程的责任。

度量原则：管理学之父德鲁克曾经说过一句名言：“如果你不能测量它，你就不能管理它”。业务架构设计应明确和描述用于与架构实践愿景和目标进行比对和监督的各项架构实践性能指标。

治理原则：基于上述内容，系统展现整体架构的治理模式。

应用架构层面须构建的关键要素如下：

完整原则：定义应用架构用于立项、需求、开发、设计、维护、上线、维护以及业务支持可扩展性的各种功能。

分域原则：应用架构的构建须要考虑功能区域划分，一般而言，包括O域(运营域)、B域(业务域)、M域(管理域）,以更明确地指导应用系统的研发建设以及后期的维护方式。但这种区分并不是割裂的而是更为紧密的契合，譬如，恰恰是这种明确的分类使得企业运营活动与业务活动具备了紧密协同的识别基础，通过整合B域和O域的数据，能够提升信息共享能力，能够提升业务洞察能力，出乎意料地通过分域系统建设形成了有数据洞察力的跨域（B域/O域）统一系统架构平台。灵活原则：对于业务模式、生产模式较为稳定的企业可以考虑企业传统三层结构，解耦显示层、业务层、应用层；如果企业应用的复杂度较大，可以从散乱的具象类中明确可继承的抽象类，考虑在原有三层架构上探索面向企业级的分层架构，这种架构能很好的支持新的技术和代码上的最佳实践。

服务原则：应用层具备业务服务解析功能，可强化该层设置以直接隔离显示层来调用业务层。企业应用的灵活性与结构性平衡不可避免的在借鉴互联网式的架构解耦融合方式，对业务逻辑的访问可以不必须在进程内访问，也可跨越网络进行访问。应用层的强设置让原本显示层调用业务层的过程变得灵活很多，我们可以添加很多灵活性设置在里面，更为重要的是若显示层和业务层两个独立的层需要完全独立，那么必须要有一个层来辅助和协调层级之间互动，那就是被强化后的应用层。

接口原则：模块内部则可以由负责的开发人员自行设计，但不同模块的通讯接口应该由团队成员共同负责，一旦接口变化，接口实现成员应该提供相应的实现原型，并通过变更审批后方可执行变更。

对接原则：应用层不仅应包含业务服务定义，还应还包含IT服务的应用逻辑调用，比如：记录LOG，协调基础设施的接入等。应用层可负责整体的协调“业务层”和“数据层”甚至“基础设施层”。

图三 应用架构层面须构建的关键要素

“你的用户并不关心架构的问题，他们只关心你的应用是否好用”，所以架构师决不能忘记从企业运营视角以及业务视角共同检讨系统架构的设计，当这个时代的企业价值链条越来越迥异于以前的被动任务导向的价值链驱动时，应用架构支持业务能力的答案不在功能说明书里、不在闭门造车的标准化产品线里、不在强专业导向弱服务导向的专家式自负里，而在应用架构对业务的服务里，在我们对企业需要、业务需要的客户化服务里，在我们帮助客户承担成本、风险、思虑如何实现的烦恼里，当客户感觉不到架构的存在时，这才是对架构师最完美的评价！