智慧建筑的破题立意心得

这半月进京被央企客户赶考两次，对于如何做好智慧楼宇的产品，丰富解决方案打法又有所体会。产品来自客户和项目需求，脱离了项目空谈产品，就如同缘木求鱼，白用功；而项目一样离不了产品，解决方案的好坏，能否打动客户，还在于做好标准产品的输出和定制化的方案调整。一个好的解决方案架构师如果不深入理解产品，就无法说服自己为何选择这套方案，更无法让客户相信你推荐的方案。而且优秀的解决方案架构师还会带着客户的问题反哺产品，引导产品团队的产品迭代方向，推动产品能更好地满足市场的需要。

作为智慧楼宇平台的产品设计师和解决方案架构师，我们重拾话题，继续聊聊楼宇智能化。往前看，十年前市场上并没有楼宇智能化平台这个说法，我们常听到的是霍尼韦尔的BPS、Webs、CCS系统，江森的MetaSys、JEM系统，这就涉及到一个平台化和标准系统的区别。

云计算技术为何落到商业服务模式上有IaaS/PaaS/SaaS三大类平台，因为这对应着硬件、操作系统、应用软件三个层面的平台化进程。

存储、CPU资源、网络带宽等硬件能力的弹性按需分配，带来了IaaS平台的大发展
软件应用研发的操作系统、部署环境、开发工具等基础设施平台化，衍生出PaaS平台。开发者只需要关注自己的业务逻辑，不需要关注底层，为生成、测试和部署软件应用程序提供一个环境，类似应用开发的middleware中间件
软件开箱即用的需求则激发了SaaS平台的发展

那对于做智慧建筑的从业者来说，一样回避不了这三类问题。

硬件（边缘）作为IaaS基础设施，是否可以做到按需调配
业务中枢是走平台化的方式还是集成系统的方式
应用软件在设计时如何平衡标准化和定制诉求

关键字：平台、系统、IBMS、运营中心、IBOS

感谢霍尼、Tridium、UTRC一起共事的同事和我一起无聊地讨论这些话题，给我提供素材:)

建筑智能化到底需不需要平台？

首先我们了解下何为平台。

“平台”泛指要开展某项工作所依据的基础条件。平台本身不做事，只是为其他做事的人或设备或系统提供一个环境或土壤。

平台也可以理解为一系列共性能力的集合。比如物联网平台提供了设备接入、设备管理等基础能力，大数据平台提供了数据管理、数据分析、可视化呈现等通用服务。

前面所述的平台并不直接解决具体的专业问题，但客户更感冒的往往是“开包即用”软件系统，比如企业资源管理的ERP系统、营销的CRM系统、生产管理的MES系统，这些专业类的系统就是为了专门为做一件事或一类事而开发的一套系统，都带有一定的业务目的性。

用户不会为平台买单，只会为具体的业务系统或应用买单。所以从软件公司来说，什么时候需要平台？这其中的道理其实非常简单——平台是可以复用的，而业务系统由于考虑了各条业务线的关联性，反而不够灵活，相对较僵化，复用性差。

当一个行业业务需求还有很大的未知空间时，平台化会有优势，而当一个行业需求已经很固定，比如物业FM运维管理、办公OA系统，这时再要做平台化重新基于平台重塑业务应用系统，其实就是一件很值得推敲的事儿。不是不能做，而是现有的行业巨头会评估是否值得推倒重来，当然有时候，外部压力也会倒逼这些垄断巨头加快做出战略调整。比如霍尼韦尔在HBS楼宇板块有EBI、Webs、BPS、CCS等多套系统软件产品，涵盖了BMS、IBMS、运营中心等多个客户需求，本来稳赚不赔，不过在最近几年互联网公司数字化的强势侵入下，也开始重视平台产品的建设，开始着力打造自己的Forge云平台。撇开互联网巨头为了推平台而不停地推数字化解决方案的动机，我个人觉得随着C端、B端产品的壁垒逐步打破，未来的楼宇应用会越来越往个性化、定制化发展，所以有一个平台级的支持底座还是很有必要。

不过对于这个平台来说，是做类似微软Azure IoT、阿里云IoT这样的通用物联网平台，还是带有业务赋能功能的系统平台。我觉得还是值得好好设计一番的。

现在很多在做数字化转型的互联网企业将IoT物联网平台当成自己的杀手锏武器，对外宣传自己提供了怎样怎样的数字化能力，材料看起来也很不错，不过这其实还是难以推敲的。设备接入、连接管理虽然很重要，但我们已经不再是5-10年前刚做物联网市场的时候，这些就如同00年的windows操作系统，10年的IOS，已成为一个大家都很认可、相对成熟的基础产品，比拼的无非是差异竞争力。如果无法提供更颠覆性的改变，比如IOS至于塞班，我们就需要在专业深度上下功夫。这就是我所说的智慧建筑需要平台，但更需要有专业Know-how能力的平台。

从这个角度来说，我们如果将智慧楼宇这个活儿按“端-边-云-应用”的四层架构来设计，云上提供的其实是两层平台，一层是IoT通用平台，再其上则是赋能业务系统的领域平台。

通过通用和领域两层平台，业务方不再需要自己去维护底层物联基础设施，也不需要过多的去关心业务引擎等相关的一些问题，业务方只需要专注于业务即可，这显然能够降低业务方的成本。

智慧建筑是否需要楼宇操作系统

现在的智慧楼宇和十年前的建筑智能化，区别并不在于应用场景的多样性，丰富的移动端玩法，两者的最大差别还是管理思维的变迁。就像15年之后自从阿里提出“中台”的概念，很多企业也一窝蜂的言必称建设中台，纷纷上马各种数据中台、技术中台……，可效果如何，好像并不咋样。不是中台不好，而是用错了地方。中台其实是一种组织方式、思维方式、创新方式的变革，而不仅仅是一个技术手段。当前的智慧楼宇、智慧园区也是一样的道理，并不是新瓶装旧酒，而更多代表的是一种运营模式、管理方式的创新。

传统的本地IBMS是什么？这是一种对子系统/设备的集成楼宇管理系统。其立意在“管”，为了管理的方便，所以就近提供了这样一套集中式的中控入口，以管理可靠、方便为要旨。不过这样一套集成管理系统是否适用现在这样一个需求多样、讯息万变的数字时代，还是需要去面对市场考验。就拿我当前面临的央企大楼智能项目来说，我们需要分三阶段来立项，分步骤、分应用给客户来做智能化设计。那IBMS这种面向固定用户群，注重流程和整体性考虑的系统软件设计方式就显得繁冗而不灵活。因为我需要更多考虑构件的重用性和彼此间的低耦合。另外数字化时代，强调边云协同，synergy不是一句空话，云和边如何协调一致，离不了楼宇大脑这样的操作系统调配。

操作系统，从狭义上来看，是管理和控制计算机硬件与软件资源的计算机系统软件。对楼宇来说，楼宇操作系统就是对端设备、边设备/系统的资源进行控制管理的一套系统平台。这套系统既可以安装在近场的边缘服务器，也可以部署在弹性更大的云端。通过云-边垂直联动，边-边水平联动，如臂使指，灵活地实现楼宇大脑中枢预期的效果。楼宇操作系统的价值在于能够把一个领域的能量（比如OA）传递到另外一个领域（比如IT），这里面涉及到业务、管理的知识，不仅仅是技术能力复用那么简单。

作为连接底层物理硬件的关键中枢，操作系统减少人工资源分配的工作强度，降低使用者对于计算的操作干预程度。一样的道理，楼宇操作系统，需要给上层的应用提供更多的开发便利，同时屏蔽现场设备硬件的操作、管理、调配的难度，这也是当前IBMS为何会跟不上的一个因素。我们需要的是一个足够标准化、介于设备与用户之间沟通、完成诸多基础管理能力的一个操作系统，而不是一个更侧重项目制、定制化的集成管理系统。

尾声：

ToB业务和ToC完全不一样，家用智能家居对可用性，掉线率容忍性都很高，君不见Google的Nest，苹果的Smart Home，经常可以看到各种安全新闻见诸报端。但企业端的客户产品ERP、SAP则无法接受这种情况，对于智慧楼宇尤其智慧园区这块，虽然我在“智慧建筑的几个常见误区”一文戏说过，属于ToN(‘Ni’or Need）行业，不过两权相利取其重，智慧楼宇对末端硬件、边缘网关、网络架构、云端平台的要求都远不同于C端产品，这块不是仅仅做软件高可用就可以，还涉及到供应商、集成SI、交付实施的资质门槛，有一整套产品质量检验要求。智慧建筑既对平台专业化有要求，又对操作系统有要求，我认为其更像是一个系统平台工程。只是当前还远达不到操作系统的级别，就如同真正做底层操作系统的微软、苹果。而亚马逊、FB、腾讯、阿里虽然也宣传各种OS系统，不过此系统非彼系统，仅属于应用级的优秀，离卓越还有一些距离。

结合最近热炒的社区团购，智慧楼宇、智慧产业无疑属于投入多，但收效慢的行业，这不符合一些投资资本追逐的目标，所以愿意在这块好好经营的人也不多。劣币驱逐良币，优秀的高校人才往往被热钱推动去一窝蜂忙着搞直播、团购等短期逐利项目。围绕流量跑，趋之若鹜，不过冷静下来想想，这块对社会和产品升级的好处会有多少，资本逐利，风险大、周期长的芯片、硬件投入无人问津，反倒一杯奶茶、奈雪、喜茶等排队上市，结合最近中央媒体对各大互联网巨头狂炒团购事件的冷处理，可以看出真该好好学习霍尼韦尔、江森、西门子这些企业是如何在DDC控制器、PLC可编程器件上大力投入的。想起三星当年从低端食品企业，勒紧腰几十年带搞芯片，才有了今天电子帝国的地位，牢牢把控上游话语权。

智慧产业的未来还离不开一代人甚至更多人的努力，洗去铅华,方显真谛。共勉。