经过多年的声称这是一种流行的时尚并且有 没有客户需求 对于SaaS,BigCos现在已经接受了 SaaS 是未来。
SaaS不是’未来SaaS是当前– the now.

正如“The New Economy” became 只是 “the economy”本世纪初,“软件作为服务” will soon become 只是  “software”. The fact that it’基于Web并作为服务交付的Web将成为必然。 SaaS一词将变得多余。

但是技术继续推动变革。软件开发和交付不是’不要停止发展。较小的公司’不要停止创新。和我’我要大胆宣称我知道它在哪里’我知道SaaS成为主流之后会发生什么。

在我做出预测并命名之前,让’s look at what’推动变革。

世界是’t “going mobile”

世界是’t 移动 – it’走向多平台。那里’这不是从台式机向智能手机和平板电脑的转变。智能手机和平板电脑以及台式机都在使用中。如今,大多数人都可以从智能手机,平板电脑和台式计算机访问电子邮件和其他服务,并且越来越多的人希望能够从碰巧使用的任何设备访问相同的数据和软件功能。

为此,供应商必须为不同的平台和设备构建多个应用程序。通常有4个或更多领域:桌面应用程序,平板电脑应用程序和移动应用程序–手机和平板电脑进一步细分为android,iOS甚至Blackberry(如果您’重新定位到十几岁的女孩)。 SaaS的巨大优势之一就是单一代码库。多平台破坏了这一点。最终客户感到失望– vendors can’不能将每个新功能添加到他们的每个应用程序中。所以–如果不是一开始就肯定会随着时间的流逝–非Web应用程序成为缺少功能的主要应用程序的近亲。“We’ve尚未将其添加到iOS应用”

生态系统越来越重要

正如本·凯普斯(Ben Kepes)最近写道: it’关于生态系统的一切: “该生态系统的基础构建块是一个开放且可访问的API,该API支持并鼓励开发人员和其他公司进行集成。”

发现。真正全面的API–一个可以让您做所有可以在应用程序中完成的任务–确实是一件罕见的事情。该API成为另一个需要维护的接口。与移动和平板电脑应用一样,新功能也不断涌现’在添加到主应用程序后又添加到API。对于开发团队来说,继续使用下一个新功能比花一些时间将刚刚创建的功能暴露给API更有意义。

这是一个越来越大的问题。您的集成合作伙伴需要能够访问您的所有功能– nit 只是 a limited subset of it.

速度问题

We’越来越不耐烦了。我们不’不想坐下来等待页面加载超过完全必要的时间不到一纳秒。对于大多数SaaS应用程序,在服务器端会解析对数据页面的请求,然后将完整的,完全呈现的HTML页面发送到客户端,这需要CSS,图像,javascript等附加的http请求。到数百kb。那’3G连接令人痛​​苦。当客户端真正需要的只是代表他们的数据的几千字节时,为什么我们要通过Web发送数百千字节的数据’ve requested?

解决方案

存在解决所有这些问题的技术。

响应式网页设计(RWD) 技术已经在网站上普遍存在。当您访问网站时,它会呈现针对屏幕尺寸优化的页面’重新使用,这是RWD在工作。如果使用这些技术构建Web应用程序,则它可以在所有设备上最佳工作。它’不是灵丹妙药。在应用程序开发中使用RWD会大大增加开发时间–特别是在为您的应用程序奠定基础时。但是男孩值得。返回一个代码库进行维护–好极了!当然,客户不再需要等待您到处将新功能添加到所有应用程序中。

“But that’s a web application!” I hear you shout – “那么本机应用程序呢?”. Well, let’用一块石头杀死两只愤怒的小鸟。使用javascript开发应用程序 单页应用程序(SPA) 您可以将其编译为 本机应用 在许多不同的设备上。不仅如此,您’ve也解决了速度问题。一键式将应用程序的gubbins下载到客户端。因此,现在当用户请求一页数据时,您需要做的就是返回所需的实际数据,如下所示: JSON格式。快速冈萨雷斯。

这使我很好地了解了拼图的最后一部分。 REST API。到目前为止,REST是最简单的API模式。使用Java可以轻松使用和使用架构。如果操作正确,它将提供一个非常直观,快速的解决方案,供其他人在自己的项目和商业集成中使用。

您的应用程序现在是API的使用者,它没有服务器端应用程序那样的直接访问后端的特殊访问权限。所以’您的应用无法执行任何可以’可以通过API完成。您’强制使您的API保持最新且完全全面。公开并观看您的生态系统开花。通过这种方法,您的API不再是事后考虑或访问系统的替代方法。它’实际上是其中的产品’s own right.

给它起个名字

We’我们已经在KFHQ内部进行了很多讨论,因此我们需要一种简短的方式来引用这种方法。 RWDSPAREST几乎不会滚开舌头。因此,我们采用了每种关键技术的首字母: R敏感的网页设计, Single页面应用程序, REST API– RSR, 发音为“Razor”.

建立未来

如果你’从今天开始从头开始构建新应用程序,为什么您不使用RSR方法并获得它带来的所有好处?

如果你’依靠具有合理规模的应用程序和大量用户的现有SaaS供应商,它’很难提出强有力的业务案例来重新架构整个应用程序并从头开始开发新的UI。 (在BigCos讨论如何过渡到SaaS的董事会对话之声?)。恭喜你’有遗留问题。

我写了第一行代码 卡什流  超过7年前我们甚至在创造术语SaaS之前就构建了SaaS会计应用程序。率先上市’的好处,但它也有缺点。您比其他人先显示年龄迹象。我们使用的某些技术已经过时。我们的UI和UX不是’就像我们一些较新出生的竞争对手一样精巧。我们需要添加精细的用户权限,无论如何,这需要触摸每一页代码。所以我们’重新将KashFlow架构为RSR应用程序。

It’没有听起来那么可怕,但确实没有’要求我们完全重写所有内容’在过去7年中做过–再犯同样的错误,再犯同样的错误。它’s “just”通过REST API公开我们现有的功能并构建SPA以使用它的问题。

再次突破技术界限并成为第一个为客户提供上述所有好处的人,这感觉很好。而且’令人兴奋–这种方法带来了许多其他可能性,您可以 ’与第一代SaaS在一起– stuff I’在这篇文章中甚至都没有提及。带来巨大客户利益的东西

该项目进展顺利,我们预计将成为第一个 测试版 在几天之内。

 

不要延迟免费kashflow试用

了解KashFlow如何与您的业务和书籍一起使用