Paul Collins, CTO, and Ben Williams, Chief engineer, break through the jargon to explain some of the common terms used when delivering workspace technology and the buzzwords we frequently encounter.
API
PC: An API is the way that two computer systems talk to each other without knowing how they work under the covers.
Edge to Enterprise
PC: This is a phrase that is supposed to mean getting data from the edge of the network, so in our case a device, to the enterprise, which is a computer system that’s normally in an organisation’s datacenter.
BW: Yes, it’s collecting all your data into, usually a single place, where you can process it all together.
Gateway
PC: A gateway is a piece of hardware and its job is to transfer all of the data from little sensors, to those enterprise systems.
BW: Usually those little sensors are battery powered and the gateway has to be plugged in.
APs
PC: Access points, so an access point is a bit like a gateway but its main job is to make a local network for IoT devices bigger.
BW: Yeah, it’s effectively a way of extending the range of the gateway, by putting extra antennas in.
Digital Transformation
PC: Is a terrible term that should never be used.
BW: Yep, next.
Iterative Development
BW: The concept behind iterative delivery is you want to deliver the smallest thing possible that’s useful, as early as possible. So you can discover more things about the problem that you might not have been expecting. Then you can solve those things during the rest of the time, rather than waiting to the end and discovering them when it’s too late.
Sprints
BW: As part of iterative development, delivery is split into small time chunks which are fixed length, usually two or three weeks. And you deliver something you can actually use at the end of those three weeks.
Alpha/ Beta Test Groups
PC: In iterative delivery sometimes the earlier releases that you produce might be called alpha releases, that might be used by a group of people, who understand that it isn’t the whole solution but just a little bit of the solution, and you want their feedback on that little bit of the solution. The same would go for a beta release and a beta test group.
BW: In an Alpha maybe you’re proving the technology, for example, proving that one or two or three or 10 systems are talking to each other. But you might not actually have any functionality that’s really useful, you’ve just done it to make sure technology works. Then in a beta, this is nearer to something that is the completed app, and people can take value out of it, you’d usually have a bigger user group too. Alpha is more technical feedback and beta is more user feedback.
Pilot/ Production
PC: I think that’s just a way of customers trying the end solution with enough of a group of people to work out if it’s the thing for them without paying for using it everywhere.
BW: Yeah, unlike traditional software projects the cost involved of rolling out in production with IoT, assuming there’s lots of hardware to install, is relatively high. So people might try the finished product in one building, or in just a floor or two of a building before they decided to roll it out to their full estate.
