信息化孤岛探讨及解决思路（二）孤岛及其解析
问题
在（一）中，我们理解了为什么要做解决方案和规划，那么要怎么做，就要进行分析了，我们知道应用是围绕着局部设计的，他们之间相互独立，好的地方是耦合度、复杂度相对可控，但是随着而来的是难以互相融合，也就形成了信息孤岛。而不管解决方案如何设计，它还是由应用组成的，怎么样让应用为全局服务？首先就要从应用的结构来进行分析，今天的问题是，应用从业务、使用者、系统管理员（运营、运维人员）的角度，由几部分组成的？分别是什么？
讨论
针对这些问题，小伙伴们循例进行了如下，有些发散但有益的讨论：
如果从使用普通用户使用的角度来看，那么我的理解是，他主要考虑的是前端，也就是他接收端、接触器，比如说他会考虑浏览器，或者客户端APP等，他的组成部分还有，UI界面设计、人机交互方面。还有应用程序的操作使用、输入输出、展现格式这些，也是它的组成部分。
从系统管理员来说，我觉得是更加关注的后端有哪些，比如说应用服务器硬件是什么？后台部署是什么架构啊？数据库、中间件有哪些等等。
界面-操作-安全-可溯（数据）。
业务角度：由用户需求、用户目标、产品功能、成本价值组成；
使用者角度：产品功能、美观度、交互流畅度、各种场景下使用是否方便组成；
运营角度：核心功能亮眼部分，品牌；
运维角度：功能，数据，平台规则。
使用者的角度：
- 清晰的目的，让使用者清晰了解应用的作用。
- 简单的逻辑，利用简单的步骤，实现使用者的目的。
- 友好的界面，让使用者觉得舒服即可。
业务的角度：
- 应用尽可能的模块化，最好可以做到即插即用。
- 与其他应用的交互不存在障碍，方便各种数据的交流使用。
如果我是一名运维人员：
我希望所运维的应用需要组成模块有：1.数据备份。2.容灾机制。3.清晰的问题定位机制，比如日志。4.最好是能自动化。
从业务的角度：
1、 实现哪些业务功能；
2、应用的性能和使用成本。
从使用者的角度：
1、这个应用是干什么的，有哪些功能；
2、这个应用在什么平台、客户端上打开使用；
3、应用的界面如何，是否使用便利。
运维:
数据可操作性高；
安全保障条件完善
使用者角度应用主要有以下几个组成部分：
功能、界面；
操作流程；
支持的使用方式；
业务的角度应用主要有以下几个组成部分：
做什么用；
安全性；
支撑能力。
用使用者角度，应用分为以下几个部分：普通使用者视角：
- 应用的载体是什么，即我要怎么去使用它，例如小程序，app，或者网页等；
- 应用能做什么，要解决用户什么需求，例如口罩预约；
- 用户需要输入什么以及怎么输入，例如提交地理位置信息，当前时间，个人健康状况;
- 应用输出什么及怎么输出，例如预约成功后的短信通知等；
职能部门用户视角：
- 使用规则制定，例如预约成功后10天才能继续预约；
- 与其他平台对接，例如订单信息与药店同步等；
运维视角：
负载能力，高可用，业务规则制定等，例如刚开始口罩都是抢购，导致瞬间负载过大，后来改成全天都可以申请，定时摇号；这些都是通过修改规则去降低负载的体现
运营：目标用户群体，及目前用户对应用的接受能力，应用产生的效益，成本的投入，配套制度的制定，广告宣传，市场（需求）分析等。
应用的业务角度：功能要求、性能要求。
使用者角度：使用体验是关键，这包括了UI的方便性、响应速度、完善的功能
运维的角度：安装配置方便性，应用安全、可靠性、容灾、备份、日志
管理者的角度：主要考虑成本、效益、同时也要保证安全、功能、性能的要求
观点
如图：如果我们把应用从用户层面、管理员、维护人员的角度分层的话，那么它的结构的可以分为图中的几层。
1，首先是用户层面，我们也可以称他为交付层，用户关心的包括通使用的终端设备，界面设计、操作、UI响应速度等等，都在这一层面。
2，然后一般情况下一套软件系统，都会有一个后台，跟我们刚才所说的ui层面（交付层面）交互，两者之间还有一层就是通讯层，通过这个网络的这一层完成信息的交互。
3，然后是业务（后台）层面，也就是我们常说的核心的功能。其实这些功能大致可以分成两类，一类是业务相关的功能，比如说我们大家有提到的，像需求、竞品分析相关功能，属于定制化的非标准的，或者是跟业务功能密切相关的，比如说考勤、制度、业务流程之类功能，这些是根据具体工作需要进行定制的，每一个企业用户都会根据它的实际情况进行定制的部分，各自都有不同的这一类功能，我们称为业务功能。
另外一类则称为标准功能，经常是一些通用性的功能。比如用户要设计一套软件系统，它有一些隐含的功能（不一定会明确提出来），但是又是整个系统必需的，像认证鉴权（用户管理）这一块，像文件的存储，有可能还有信息沟通、离线通知、短信通知、地图的展现等，还可能会有数据库、中间件，以及安全性、性能、容量、安装维护等等，这一类我们称为标准（通用）功能，标准模块。
也就是说，业务层面可以分成两类，一个是业务功能，一个是标准功能。业务功能一般是用户更熟悉的业务的软件实现，而标准功能属于IT专业的部分，每个应用可能都会包含的部分。
4，对一个系统管理管理员来说，他要让这一套软件系统运行起来，还需要有一个系统层面的考虑，比如说他拿到了后台安装包，需要准备什么环境？包括考虑后台装载在什么操作系统上面，是Windows呢？还是Linux？是redhat还是centos？需不需要装一些中间件，比如说Java的中间件、运行环境等，还有数据库装mysql还是Oracle，还是其他什么数据库？还有需要多大的硬盘空间？这些都是系统层面的东西。
5，另外还需要考虑要准备几台机，几个网口，需要什么存储设备，这些硬件层面的东西。因此，对于传统应用开发建设，至少就要考虑这五个层面的内容。
大家的讨论中，涵盖了各类使用者需要考虑的点。这里进行了一个不甚严格的层面区分，而大家讨论的这些点也分布在这几个层面之中。通过层面划分，我们就可以看到整一个业务应用，如果把它的解构后简化，就会是在上图右边部分的简化模型。
通过以上模型来看，如果一个单位、企业，内部存在几十个在这样的软件应用，如果产生了孤岛的话，那么孤岛在哪里呢？其实孤岛就产生在这几个层面中。因此，对于信息孤岛，我们会分为四种，包括交付层面的孤岛：交付孤岛，业务上产生业务孤岛和数据孤岛，还有一个叫资源孤岛（通讯层、硬件层、业务层面的标准类功能），为什么这样划分？我们在下一章节继续进行探讨。