因为存在上述所说的困难，企业移动数字市场经过多年的发展，出现了不同的方式来解决企业上述的困境。从大致上来说，分为以下几个模式
1. 模式一：使用钉钉或企业微信IM（即时通讯）平台
2. 模式二：使用OA类的平台系统
3. 模式三：开发工具类平台
4. 模式四：私有化部署解决方案
5. 模式五：小孩子才做选择题，全局思维的CIO“都要”！
我们接下来逐一分析这些模式的优劣及适应情况
2.1 使用钉钉或企业微信的IM（即时通讯）平台
在国内，以阿里及腾讯为主的互联网企业，一开始触角并未伸向TO B的行业，它们也基本以专注互联网及TO C服务为主。随着TO C业务模式的成熟，而TO B的服务业务仍处于早期阶段，这些互联网企业开始把触角伸向TO B的企业。
大约在2014年12月底，钉钉发布了1.0.0版本，迅速成了抢占这块市场的头部互联网企业；企业微信则在2016年4月才发布企业微信1.0版本，虽然时间上晚了近2年，但凭借微信强大的用户基础及生态，迅速成为这个市场的引领者。
优点：
1. 免费。互联网企业不按TO B常规套路出牌，仍然沿袭TO C的模式，也就是免费模式。期望以免费快速抢占企业，再通过企业来做大生态，通过生态圈来创造额外的价值。
2. 功能丰富，产品稳定。由于是TO C出身，很多功能包括邮件、视频、IM语音等，在TO C的市场上磨练已久，其技术实力与产品稳定性都具备优势。
3. 方便连接C端。由于微信加持，企业微信自然就有快速体验、大流量方便获客和维系的优势。
4. 生态丰富。一大群ISV供应商围绕着钉钉和企业微信做客户化的落地实施。
缺点：
1. 安全可控不足。所有IM即时通讯数据均在互联网企业中，这对很多企业来说，特别是对数据安全有要求的企业来说，是个难以接受的点。
2. 产品定制不足。SaaS产品的特征就决定了，某些需要产品本身去配合的功能，SaaS端难以支持和适配。SaaS优点更多的表现在“有什么”，而不是能“做什么”，所以从定制到扩展能力，方方面面都受限制。企业把自己的业务搬到上述平台并不是非常顺心顺意。
3. 不了解B端业务。SaaS离C端用户更近，不了解B端、E端（员工端）的需求和痛点。
4. 卡脖子。SaaS平台的数据和用户信息都在大厂，对于中小企业可以享受大厂带来的流量红利，适合积累和导入初期用户。但免费是有代价的，很多大企业为了不被卡脖子，而选择自建移动平台和私域流量池。SaaS平台在互联网1.0时代要了企业的用户，现在又想全面地侵入企业的生态，作为首席信息官，需要权衡此中风险。
适用：
小微企业、初创公司、或者当前IT预算有限的组织。我们建议先尝试用钉钉、企业微信IM（即时通讯）。如，面向C端用户多的中小企业，可以利用微信流量给企业微信导流，做用户运营。
小结：
企业微信和钉钉IM（即时通讯）平台的应用对象和应用场景更多的是适合小微企业的简单管理逻辑，并且企业微信和钉钉在伴随企业成长过程中，自身很难向更精细化、个性化靠拢，所以企业微信和钉钉更多的是扮演陪伴企业成长发育期的“学步车”角色；而面向中大型企业，企业微信和钉钉几乎无法抗衡专业的移动办公产品。
2.2 OA类平台系统
在移动平台出现之前，多数企业用OA系统解决内部协同，用OA系统提供的移动端做企业的移动门户。他们做企业OA起家，专注OA十多年，在垂直的OA业务上优势明显。
优点：
1. 解决具体问题。OA类系统或平台，有一个比较明显的特点：他们提供了一套成熟的工作流解决方案，基本包含流程管理、HR管理等企业内部协同需要的方方面面功能。
缺点：
1. 优点即缺点：平台能力强，扩展性弱。专注解决垂直领域业务问题的OA类产品，本身相对来说比较封闭，扩展性弱。他考虑了OA层面的方方面面，但是如果需要对接OA或者要求OA做一些开放能力建设，就比较吃力。
2. 移动端能力偏弱：术业有专攻。OA类产品的移动端能力，包括IM及时性、IM到达率、IM稳定性有待进一步提升。这一点OA厂商自身也意识到了，他们几乎弱化了自己的移动端，转而投靠企业微信、钉钉这类强IM移动端基座。
适用：
上OA要看公司的管理目标和需求。如果公司寄希望于通过业务流程合理化来促进管理指标的提升，可以上OA类产品。
小结：
目前OA类产品也推出了移动平台。但是，打个比方，OA移动端像小诊所，能看伤风感冒，解决部分问题，但如果要更加专业的诊疗方案还得去三甲医院。
产品的“出生”决定了“生长”。业务系统厂商，解决其业务系统功能在移动端的展现是主要需求，其他系统的对接管理是非必要的。业务需求的重点不同决定了其产品的侧重领域不同，也使得产品最终的形态定位成业务系统移动端而非企业移动平台。企业选型的第一步，就需要确定选择平台型还是业务系统移动端型产品，这决定了企业未来移动信息化建设的结果。

-

当Exchange损坏时，一个平常的日子可以很快变成你生命中最差的一天。花费几个小时在一个Exchange服务器修复上，有可能彻夜难眠，还可能会被每五分钟警告一次而身心疲惫。

Exchange后端数据库故障，一般都会是比较严重的紧急故障，因为这会直接影响到大面积用户的正常使用，而且涉及到用户数据。一旦遇到这种级别的故障，管理员往往都需要在非常紧张、压力非常大的状态下进行恢复操作，需要在高压状态下迅速做出决策，下一步应该如何做。

作为从业者， 我很好奇，想去探究为啥exchange这么脆弱？我想已经找到答案，以下是我的思考和体会。

Exchange经过20年的发展， 架构上从合到分再到合的过程。在 exchange 2010 中，exchange 包含五个服务器角色，分别为邮箱服务器，客户端访问服务器，集线传输服务器，统一消息服务器，边缘传输服务器。

在后来的 exchange 2013 中服务器被精简为 3 个：邮箱服务器，客户端访问服务器，边缘传输服务器

exchange 2016 和 2019 中则只有邮箱服务器和边缘传输服务器了。 到Exchange Server 2019，这个版本和Exchange Server 2016这个版本的架构基本没有变化，仍旧只有MBX和EDGE，但EDGE一直是一个可选角色，大部分企业都不用，被邮件网关所代替。这个架构其实越来越和金笛邮件系统+邮件网关的架构接近。

在存储方面，exchange一直采用数据库edb格式，把所有的邮件存放到数据库中。这种方式虽然查询检索备份比较便利， 但是有一个致命缺陷，那就是随着邮件越来越多， 数据库文件越来越大， 一旦出现突然断电或者硬盘出现坏道， 哪怕出现几个字节损坏，整个数据库文件会出现脏关机状态。 当数据库处于“脏关机”状态时，它将防止Microsoft Exchange数据库挂载，从而导致电子邮件服务中断。

此时，Exchange服务器数据库无法挂载并显示错误消息，例如“失败的错误：无法挂载您指定的数据库”。 解决方案是从更新的备份还原Exchange数据库或应用有效的Exchange EDB修复技术。

当Exchange服务器崩溃时，管理员可以使用setup / m：RecoverServer switch命令来重建新的Exchange服务器。 但是，根据故障的性质，数据库恢复是一项更具挑战性的任务。您从崩溃的Exchange服务器的.edb文件中恢复邮箱，尤其是当ESEUtil失败，日志丢失或删除且备份不可用时。

EDB文件存放了所有邮箱项目，包括电子邮件，附件，联系人，日历，便笺，任务，日记和公用文件夹。修复大型EDB文件是一个容易造成数据丢失的风险操作。

有很多第三方厂商专门开发了修复exchange的软件竟然是个不错的生意， 可见exchange崩溃是个3-5年内会出现的大概率事件。究其原因， 邮件收发是个频繁的硬盘IO操作，硬盘读写特别频繁， 一个机械硬盘频繁读写3、5年出现坏道是大概率事件。Exchange把所有邮件放到一个EDB文件中， 显然是设计上的致命缺陷。这个大文件只要有几个字节错误， 格式就发生变化，变得不可读， 导致无法加载。 国内大硬盘存储基本上还都是机械硬盘，用几年后，不可避免地出现坏道。这是exchange如此脆弱的根本原因。

其实在linux系统上，很多年前，单一的邮件的存储格式mailbox已经被抛弃， 而采用更先进的Maildir格式至今。这种存储格式， 是非常科学非常先进的。硬盘出现部分坏道，只影响个别或者部分邮件，整体上不会受影响，更不会影响邮件系统的基本服务。可靠性比单一文件存储不是几百倍的提高，二是数量级指数上万倍的提高。

微软在操作系统领域实力确实可以，但他不是什么都能做得好。比如IE被全面抛弃和替代就是明证。Exchange由于先天的设计缺陷，经过了20年发展，也没有在中大型企业推广开来，更逞论政府、部队、公安等要害部门。

Exchange在国内卖的价格很高，但有致命缺陷，依赖于代理商提供的服务。越来越多的企业已经意识到，且已经醒悟，不再交这个智商税。