解决企业 IT 问题的基本途径
如果你找到这本书，说明你很有可能需要解决一个具体的企业信息化问题，要为自己的公司或者客户设计一个企业应用，服务目标用户。解决企业信息化问题有几个完全不同的途径，并非每个途径都需要从头开始设计企业应用，使用一些现成的、实用的方案会让你事半功倍，减少无谓的设计和开发工作，提升交付的质量;有一些场景则可能需要从零开始，独立建立架构，进行设计开发;还有一些需求场景可以混合使用多种方案，搭建合适的桥梁，从而满足需求。
我们可以把满足企业 IT 需求的基本途径概括为如下几种:
· 按需原生开发
· 使用和对接 SaaS 产品
· 基于开源软件和平台开发
· 混合和实用模式
按需原生开发
按需原生开发是指企业不得不根据应用要解决的问题，进行完整的产品架构设计和应用设计，利用某一种集成开发环境和编程语言完成所有的业务前后端开发。当然，在这种情况下，企业也需要独立管理软件运行所需要的 IT 基础设施。
这种途径代价很高，需要依赖拥有多种技能的设计开发人员，交付周期长，而且需要建立专门的团队来跟进应用的长期迭代。虽然应用在开发完成后会逐步完善和稳定下来，但这个过程通常需要几个月甚至几年的时间。在实践中，如果没有稳定的设计研发团队长期跟进某套 IT 系统，它的可用性便会随着时间的推移而降低，因为在实际环境中，很少有业务是一成不变的。另外，随着应用设计水平的提升，客户的要求也会在无形中提升，因此这也对应用的迭代升级提出了要求。就像我们现在使用五年前设计开发的产品，总是觉得不够好用，哪怕这套系统在当时已经达到了很高的水平。
企业在决定是否需要进行原生开发时，可以根据以下条件判断。
1)应用本身解决了企业核心业务流程的高价值问题，而不是周边性质的小问题，否则带来的产出很可能抵不过投入。比如一个金融服务企业可能需要原生开发客户账务处理和风险控制应用，但对于一般的招聘和人事管理业务可能更适合选择既有的产品方案或者基于平台开发产品方案。
2)应用要解决的问题和所采用的问题解决模式有明显的独特性，
而不是那种很多企业已经解决了的问题，为后者进行原生开发很可能是在重复造轮子。
3)除了以上两个明显特征，对于特定的问题来说，还可以检验市场上是否有主流的软件产品已经可以很好地解决之。通常，使用已有的产品方案必然会牺牲一定的灵活性和个性，这时就需要权衡利弊，做出合理的决策。如果利弊相当，则一般应该优先从已有的产品方案开始，通过实际的使用进行评估。即便将来依然需要自建应用，使用已有产品的过程也可以帮我们降低试错成本。
按需原生开发的最小化人员组合
要开发出高质量的企业应用，每个环节都很重要。尽管也有极少数的全能型人才，但我们依然青睐专业化的分工，因为专注聚焦能够提高工作的质量和效率。
一个完善的企业应用设计团队应该尽量包含以下专业成员和角色。
业务分析师:负责从产品设计的角度搜集、分析和归纳业务需求，将其撰写为业务需求文档(BRD)，并保证其始终反映了需求的变更。业务需求文档不需要过于技术化，也必不涉及实现细节，但它要将 IT 应用待解决的业务问题、背景、价值和风险描述得非常清晰。它是业务需求方和应用开发方之间的桥梁。
产品经理:负责将业务需求文档转换为产品需求文档(PRD)，将需求按照某种逻辑进行横向的模块拆分，并按照实现步骤进行纵向拆分(通过多个迭代版本依次实现)。PRD 有更加规范的组成部分和格式要求，在本书后面的章节中会提供更多的 PRD局部范例。
架构师:如果涉及非常复杂的数据结构，应当由专门的软件架构 师来负责数据结构和业务逻辑的设计。他要负责设计应用所对应的数据实体关系图(Entity Relationship Diagram)和流程图。因为数据结构涉及更多的软件技术背景，所以在实际分工中，也可能是开发团队成员来承担架构师的工作。
前端(交互)设计师:根据定义好的 PRD(产品需求文档)绘制产品前端界面设计稿，并在其中填充范例数据。根据实际需要，设计稿可能是框线图，也可能是高保真的静态稿，甚至有时需要用专门的软件制作可以交互的演示稿。企业应用通常比较复杂，交互环节众多，所以在很多情况下，产品团队会选择投入产出比较高的框线图模式。如果设计团队拥有完备的交互范式库，那么这个设计环节将会顺利很多。
因为本书聚焦于企业应用的设计过程，所以不便对开发、测试和运维流程展开介绍。但是我们应该对自建一个完整企业应用的复杂度有所预估。即使完成了独立的产品设计，后面还要有后端工程师、前端工程师、测试工程师、运维工程师等多个专业岗位来保证它的高质量交付。一个完全自建、按需原生开发的企业应用是非常昂贵的，因此在选择这个途径之前需要慎重衡量投入成本和产出。
使用和对接 SaaS 产品
解决企业 IT 问题的第二个途径是使用现有元的软件产品，尤其是按需使用的 SaaS 模式软件。对于年营收在五亿元人民币以内，人数在 1 000 人以下的中小型企业，选择现有软件产品是主流方案。
为了找到满意的 SaaS 产品，企业首先需要明确自己的问题所对应的门类，这就是为什么本书的第 1 章是从企业应用的门类开始介绍的。如果你需要满足一个具体的企业信息化需求，不妨再翻阅一下第 1 章，看看是否有完美匹配的市场化的成熟产品。
比如，某企业希望解决采购过程中供应商管理的分级流程问题、货物验收和付款流程的有序性问题、报价搜集规范化问题以及招标过程自动化问题，与第 1 章的内容对照，会发现这些问题几乎都对应了现代企业管理软件的某个门类，属于运营和财务管理领域的交集。
现成的 SaaS 软件产品有显而易见的好处，那就是开箱即用。客户无须进行烦冗的定制开发和 IT 部署，也不需要详细撰写自己的需求说明书，直接开通云端账号就能够开始使用(对于复杂的企业应用，用户培训可能是必不可少的)。但是它也有显而易见的缺点——作为通用软件，它无法迎合每个客户的需求。这时就需要用户企业做出权衡，SaaS 软件产品无法满足的那些需求是不是必不可少的?如果无法回避，是否可以通过 API 来进行局部的扩展开发，而不是完全重新设计?一般而言，SaaS 软件产品都可以提供完善的 API，而且 SaaS 软件自身的特性组合也会根据客户的实际需求进行增加。所以，理论上来说，用户企业的共同需求很快会得到厂商的重视，并被加入升级版本的开发计划中。
基于开源软件和平台开发
基于某个比较成熟的开源软件进行定制开发(行业俗称“二次开发”)是一种比较折中的方式，它在保持灵活度的同时控制了开发成本。除了传统意义上的开源软件，中间件和云计算时代出现的PaaS 模式也都能起到类似的作用。它们旨在帮助企业应用开发者降低开发成本，提高交付速度。
在企业应用领域，比较知名的开源产品如下表所示。
企业应用领域的开源商业模式和其他领域的开源经典模式略有不同，并非所有的开源厂商都会免费提供产品，也就是说，开源不等于免费，商业用户在获得可修改的源代码的同时依然有义务支付授权费用。
虽然开源软件能够节省设计和开发的时间，但选择任何一个开源平台都需要设计与开发人员对这个平台充分熟悉。而且，任何一个开发平台都不可能提供完全自由的设计空间，应用的实现受制于开源软件的框架和特性基础。这也是为什么大部分开源产品构筑的应用都具有雷同的界面和功能。对于部分追求效率和可靠性的企业应用开发者来说，这未尝不是好事。
在某些企业应用领域，比如 BPM(业务流程管理)和 BI(商业智能)，基于某个平台进行开发恐怕是不可避免的，因为很少有企业愿意从头构筑这些应用的基础数据结构和逻辑，它们实在是过于复杂了。而且，随着商业自动化、智能化的要求越来越高，几乎所有的复杂企业应用门类都有专业化分工的需求。在商业软件世界里，虽然厂 商不提供源代码，也不能通过修改源代码进行二次开发，但客户依然可以通过自定义数据、自定义流程和自定义规则等用户数据来搭建满足自己需求的具体应用。所以，在选择企业应用产品的时候，到底是选择一个应用，还是选择一个应用开发平台，有时候界限是模糊的。
混合和实用模式
除了以上介绍的这三种途径，企业也可以综合使用这三种方式来满足自己的 IT 需求，这是一种非常务实的做法。即便像阿里巴巴这样的巨型企业，也不可能完全独立开发所有的应用，当然更不可能通过购买现有的软件产品来满足自己的全部需求。
在使用混合模式时，企业集成门户(EA)和单点登录(SSO)是最常使用的 IT 框架，因为用户当然不愿意在使用混合解决方案的过程中出现混乱，员工也不可能通过多个孤立的账号来使用多个系统。而且，企业希望这些组合起来的应用最终能够被准确地分发、授权和收回。当然，在选择这些起到整合 IT 应用作用的系统时，也要决定是进行独立开发还是使用现有平台。
上文节选自《现代企业应用设计指南》（作者/明道创始人任向晖），点击即可购买
