Tibco may have nailed down the all-important edge of IoT
- Summary:
- By targeting the billions of IoT sensors with a `little scrap of code’ called Flogo, Tibco may well have given the edge of IoT just what it needs
That is why the little bit of software Tibco introduced at its recent Tibco Now conference in Las Vegas has a large amount of `potential’ now sitting on its shoulders. Project Flogo is, by modern standards, an insignificant little scrap of code just 3Mbytes in size. Yet it is being pitched at one of the largest volume markets so far seen.
This is the code that works with industrial, domestic (and any other work category you can think of) sensors so that they can provide both far richer levels of information to IoT management systems, and not only implement change commands from said management systems but control a range of obvious management functions independently.
Because this is a market with such huge potential, it may at first seem curious that Tibco has opted to follow the open source route with Project Flogo, but there is method in such apparent madness, as the company’s CTO, Matt Quinn, pointed out.
Actually, we wrestled with this question for many years. What to open source, what not to open source, and the answer ended up being incredibly simple. The switch happened when we started to go to a persona-informed development methodology - thinking about the people who are going to use the product upfront rather than building an engine and then working it out.
From a Flogo perspective we had an interesting problem to solve and believe we've got a really novel approach to solving it. But the people who are going to use it are developers. The answer is very simple - open source it. And I mean really open source it, not just half do it. Provide the openness, provide the community and then they will use it, because we want to solve the problem.
Now, from a business strategy point of view there are a lot of ways you can monetize those kinds of things, but you're not monetizing the developer relationship. That's not the goal. Our goal is not to ever sell to developers. We want developers to use it, absolutely, but monetization and the business model is different.
Show us the money
Quinn sees monetization coming from a variety of different places, such as partners porting Flogo to other devices and other environments, and from support, training and other services on the enterprise side. He sees a multitude of ways to monetize such relationships beyond the straight ‘use-pay-use-pay’ model.
Long term this is likely to include specific enterprise extensions and pre-packaged solutions, but according to Quinn Tibco is looking to avoid situations where, if an enterprise has a specific solution in mind then they have to pay the company `a bunch of money’.
Packaging it up into higher level solutions as part of a much broader play, does, however, form a long term part of the strategy. This would fit with the company’s increasing capabilities in providing both the integration and data manipulation services on a full, end-to-end basis. In that context, open sourcing Flogo as part of that package does then make it indirectly part of the monetizable `whole’.
You have to remember that some customers have lots of Tibco technology so this would be one more piece that they would have. So there is the halo effect of this type of technology.
For example, the conference demo of Flogo showed it working on connections to a memory data grid and messaging software, all of which are much more traditional proprietary software. But there are also other components for these tasks, some of which are also open source, and Flogo will work with them just as well. Not surprisingly, however, Quinn feels the Tibco tools are better.
The partnership angle is, therefore, the big one for the company, especially with the sensor device manufacturers. He sees Flogo pushing the smarts to the actual devices itself, which would be a real step forward from the current situation of dumb sensors. Now they can start to act and manage themselves.
Simple devices, such as light bulbs, can now carry their own processing power. So instead of change-of-state data needing to be sent to a central hub for every decision, the device itself can make some decisions – for example `change me, I’m busted’ – for itself. This cuts out a huge amount of network traffic and complexity by building intelligence into the device itself.
The hub approach, especially now they can be built on very lightweight Raspberry Pi devices, will still have a role, but distributing the intelligence in this way means those hubs will not need to be big, overly complex, or expensive. Quinn sees Flogo bridging that gap from the large corporate systems to these edge devices.
The 12 year-old newbie
Flogo is a fascinating piece of long term technology re-use, as it evolved from work Tibco did 12 years ago, when it an engine to power its big enterprise systems like BPM and Business Works. It was called Process Virtual Machine (PVM).
It was designed to take the cost out of us having to maintain lots of different process engines across the enterprise. The difference between BPM and integration processes is huge. One deals with people and humans and the other one deals with systems. However at the core it's still a processing machine and a state machine so moving from state a to state b to state c. So we built PVM as a way to make everything common at the lowest common denominator so we only had to focus on the differences.
The same team that built PVM recognised they could discard all the functions that weren’t required and evolve it for work in IOT. The one difference is that it is now written in Golang rather than the original Java. And rather than porting Java code to Golang, the development team re-envisioned the essential functionality into the new language in order to take advantage of Dev-Ops tool chains
One capability he thinks is particularly important here for development purposes is the ability to go backwards and forwards in a process, literally starting a process, running it through and then rewind or fast forward it, which with most engines is impossible.
And its key advantage is its size. At 3.3Mbytes of code Flogo compares very well with the 30 to 50Mbyte tools that are typical to date.
The first time that they showed it to me I was amazed. I thought it was some little tiny proxy that they'd built and the real engine was somewhere else.
That combination of small size, development flexibility and open source availability could just make Project Flogo one of the major`come-ons’ in moving IoT on to the next stage, where the billions of sensors and edge devices become far more activity players in the levels of management and service delivery that is possible.
That, in turn, could put Tibco into that enviable position of being first in line for the consequential benefits of having the right connections, as Quinn observed:
There are a lot of platforms out there, so I have no desire for Tibco to be another IOT platform. But we do have technology that can be used inside those platforms and obviously we are very good at connecting these platforms together. So a lot of IOT relationships and partnerships have been, and will be, about building those bridges between our technologies and other people's technologies.
My take
Sometimes it is the little things that are the most important, and while much is heard about the big management systems when it comes to IoT, this small bit of code targeting the very edge of IoT environments may prove to be the universal Godsend. And though it is an open source `freebie’ creators, Tibco, may well find it creates a well-trodden path to its door.