Yes. We are well-versed with both of those regulations. Specific details of compliance are often dependent on the nature of the application, but if your application needs to operate within those regulations, we have experience developing applications that do. If you give us a set of requirements that are not GDPR or CCPA compliant, and you’re okay with that, we’ll implement it that way. We’re not forcing you to be compliant. But if it’s necessary for you, we can and will accommodate that for you. We are not implying that we have some sort of “GDPR button” that we push and then we’re done. It requires custom work to make sure the application is compliant – there are fundamental things we have to take into account when designing an application – but we have done that and will do that when required. If you don’t take them into account and you don’t understand what you need to do to meet those requirements, then it can be very expensive to retrofit it later. If you do understand it and you want to be compliant, then we have the expertise. We know what to do to build it into the application from the ground-up.
Yes, although most of our customers don’t because they are looking for our expertise to accelerate their time to market. There is a learning curve to building an application with Prism, and we’re not really offering a drag-and-drop WYSIWYG tool here. It’s not meant for any developers to pick it up and have an IoT solution created in minutes. This was built for developers on the back-end and the UI/UX people on the front-end. So, if you have those resources on your staff, they could absolutely learn Prism, but the vast majority of our customers allow us to do it. One common trend is where customers will let us do the turn-key development of the initial product and then they will do their own ongoing maintenance and enhancement from there.
Yes and yes. We love a good, simple answer.
Yes, in fact we recommend it. There are usually unanswered questions at the start of a project, so this is the best way to start a project. Prism is designed to build large-scale, highly customized IoT applications. But it can also be used to do quick prototypes. And the way that you do that is you focus on the specific functionality that you’re trying to test – the questions you’re trying to answer – and you don’t worry about all the other stuff that goes into the solution. As an example, if what you need is quick data collection with some analytics, maybe some visualizations, then don’t waste your time building the entire end user provisioning system and the billing system and the user management system—don’t do any of that. That all has to come at some point, but focus on just the part that matters – the primary questions you have. In a PoC, you are not trying to make it look pretty. You’re just trying to get your questions answered quickly and easily. Prism is designed to be able to work like that.
Yes, including everything from cellular carriers to public LPWAN providers. We are already pre-integrated with all of the major carriers in this space (like AT&T, Sprint, T-Mobile, Public LPWANs, different regional LoRaWAN providers, etc).
Yes. Machine Learning is a subset of Artificial Intelligence, and Machine Learning is what people are usually talking about when they say AI. But we digress. Machine Learning has many different types of applications, and we will have a Machine Learning expert specific to your solution’s needs.
Yes. And for our customers that are bound by HIPAA, we regularly sign a Business Associate Agreement (BAA).
Well, it depends on the requirements of the project, but the overall answer is yes. They typically fall into two categories: 1) Progressive Web Application (PWA) – a web-based application that is designed to run on a phone. In some cases, this is the best solution for “mobile”. 2) A Native Application (for Android and iPhone) – this is a mobile application, proper. If a native application is required, we have that capability as well. When people think of a mobile app, they’re usually thinking of an app they can download from the App Store. But that might not always be the right answer.
Apps that run through the App Store require quite a bit of specialized programming, and the approval process can be time-consuming. If you need that, we can absolutely do that for you. If you’re not sure, we can show you the options and help you decide. Our modus operandi is not to immediately say yes just for the sake of the sale. We want to understand exactly what your business needs before we jump into development.
There absolutely are times where there are two or three companies working very closely together. This is different than when we have a point solution where we bring in outside companies with some specific expertise. This is where someone says, as an example, “I’ve already picked out my hardware design firm and they’re already halfway down the path of building the device. We need you, ObjectSpectrum, to come in and build the software and make sure the integration is going to work.” Then we are working alongside an outside company, but that’s because that is what the situation called for. So, yes. Sometimes we do, and yes – we are always open to this when that’s what is needed. And the same is true for UI stuff – where a customer was already working with a design firm that they already used for their corporate identity and they asked, “Hey, we want you to work with our design firm because they’re going to design the wireframes and do all the graphics and do all the assets – could you work with them to incorporate what they do into our solution?” and of course the answer to that is also “yes.”
Yes, we offer an industry-leading SLA and here’s a link to it.
Yes. If the customer wants to deploy our software (Prism) on their premises or in their self-managed cloud environment, then we operate in a traditional software licensing model (like deploying Oracle in your company’s environment, for example).
Nope, you’re on your own, sucka. Okay, okay – yes, of course we do. As part of us hosting your solution for you, support for you is included within that service contract. If you are licensing our software, support is also provided as part of that licensing contract. And while those options don’t include support to your end customers, end customer support is one of the optional services you can choose (as part of our IoT as a Service offering).
Yes. This is especially true for applications that have a specific geography. This could be on a farm or in a building or on a campus where the solution is well suited for a private network and the private networks can include things like LoRaWAN as well as private LTE or even in some cases, private WiFi or Bluetooth networks. Obviously, it depends on the application, but when it makes sense, we can and do provide the network and the management of a complete network solution. There have been prospects in the past that have assumed “if I am using a public network, I’ll have to pay for it, but if I’m using a private network, it should all be free, right?” Nope. Not right at all. Think of the network as one part of your overall solution. If we use a public network, then that public network needs to provide service to you, and they will charge you some type of recurring fee to do that. If we build a private network for you, we still have to provide that service, so there’s some kind of fee whether it’s built into our monthly rate, or the fee associated with the number of devices that you have, but it’s not free. Just because it’s private does not mean there’s no cost to it. Somebody has to actually operate it. Now, typically the cost will be less for a private network than a public network, but in some cases you have to use a public network because there is no other choice.
As part of a project, yes. We do not offer these as standalone services.
Yes. In fact, that is the most typical deployment model for most customer solutions.
Yes, we do. That’s really about the device itself. So, if we had an application that had sensors for a hazardous environment, we’d have to support devices with Hazardous Area certifications. But from our perspective, it doesn’t really matter that much because Prism is not in the hazardous environment. Your solution is almost always in the cloud. The exception would be on-premise deployments or certain edge computing hardware, and of course options generally exist for those that have Hazardous Area certifications, too.
Yes. We will integrate with any normal modern API that’s available for any other third-party services. There are two directions: 1) we provide a number of different options and industry-standard protocols and APIs to allow other systems to act as data and functionality within your application, and 2) we also will integrate with any normal modern API that is available for any other third-party services. One of the things that we’ve done is we’ve pre-integrated with a number of third-party services that make it faster and easier to build a solution, including things like weather data from the national weather service or satellite imagery for mapping applications or the ability to send and receive text messages. Those are third-party services that we’ve already pre-integrated to, but hose aren’t the only ones we can integrate to. We have a very open system that allows anyone to integrate with us and we can accommodate integrating any other third-party API on an as-needed basis. We’ve just pre-integrated a bunch of stuff that’s common.
Blockchain is not directly related to IoT. It’s a technology that – in some applications – can be used as part of an IoT solution. There are a number of different possible use cases, ranging from payment processing using cryptocurrencies to things like smart contracts, which use blockchain ledgers to exchange information securely between trading partners. Blockchain creates an unalterable record of something that has happened, which is why it is used for cryptocurrency. But in IoT, we might need an unalterable record of some sensor value and that doesn’t have to have anything to do with cryptocurrency. It’s a way for everyone to trust that the information is accurate. While not every IoT application has a need for blockchain, we have quite a bit of experience leveraging various blockchain technologies in different IoT solutions.
Yep. Bring it on. This is actually an advantage to Prism – it was designed for that type of scale, tested for that type of scale, solid and ready to roll for whatever load you put on it. And a lot of people can’t say that. Or they can say that and then your solution will pass the demo phases, then the next phase with 100 devices out there, then even that other phase with 1,000 devices – and then fail at scale. You need to make sure whatever solution you’re building has been built with that scale in mind, and in our case ALL of our solutions were (because they’re all sitting on Prism, which was intended to support massive scale).
No. There are cases where there is a cloud connection, but the cloud connection is primarily there to collect data for analysis, and the function for the application that it is performing is completely local. That might mean that the application is running entirely on the phone, or it might mean that there’s some local process, computer, or device that’s actually running the application, so it doesn’t need the cloud to operate. It can connect to the cloud if the cloud is available, but it doesn’t rely on the cloud to operate and do its job. It’s an application that can run self-contained if it doesn’t have connectivity to the cloud.
Prism – if you look at it in its three different parts – Edge, Core and View: Edge and Core are regular, typical software development environments. They’re not intended to be no-code, they’re intended to be used by an experienced software developer. The language that we use is JavaScript (because it is a common and accessible language), so if you’re using Core and Edge, you are writing JavaScript code (so not “no code”). In the case of View, the target user is an experienced UI/UX designer. There is no code in View (so technically “no code”, because View is declarative); instead, there are industry standard technologies that are well known by experienced UI/UX people (things like CSS, SVG, JSON, HTML, etc). To summarize, the different environments – Edge and Core are targeted at an experienced software developer with skills in JavaScript and View is targeted at an experienced UI/UX person with those skills.
Yes. Prism consists of the core services that implement things like the microservice environment that runs the application, and it also includes other services that are used to support the application (like message brokers, databases, and so on). The architecture for each of those different systems is designed for high availability using the particular high-availability approach that is suitable for that particular system. In the case of a database, this might be to have a cluster of three database servers that are all working together so that if you lose one, you haven’t lost anything. The high availability for a message broker might be that you have two different message brokers and either one can handle the expected message volume. For any given subsystem, there will be a way to implement that subsystem in a high-availability architecture, which we always do in our hosted environments. Another term for this is “fault tolerant.” It just means it can tolerate a fault without adversely impacting the application. High availability really means the same thing. You want the service to be highly available (24/7), so you architect the system with high-availability design rules. You want to make sure the service it provides is highly available even if parts of it fail.
Yes. When you talk about asset tracking, that’s a very generic term. One of the built-in capabilities of Prism is the underlying building blocks of asset tracking, which includes things like GPS coordinated math and mapping, visualizations, geofencing logic, etc. But the advantage of using Prism and ObjectSpectrum comes when you get past the basic idea of GPS locating and asset tracking. This is where your specific needs come into play – what exactly are you tracking? Is it outdoors, is it indoors, is it something that needs to go anywhere in the world? Is it something that only moves around in a campus or a factory? Are you keeping track of more than just its location? Do you want to know information from other sensor inputs on it with data that needs to be tracked and reported? When you get into the specifics of an asset tracking application, that’s usually where we have a big advantage that we can bring to the table, because we are certainly more than just an asset tracking solution.
Machine learning is a branch of artificial intelligence (AI) and computer science which focuses on the use of data and algorithms to imitate the way that humans learn, gradually improving its accuracy. AI, or artificial intelligence, is a term that defines a broad category of intelligence – much of which is still highly experimental, or even still solely theoretical. But one component of AI is ML, or machine learning, which is a mature technology that is already in use in thousands of applications across hundreds of industries. And is something that you would often find as part of an IoT solution. As to whether you should use it or not, the real answer is “it depends.” Machine Learning is not a magic bullet or ingredient. Machine learning is a technology like any other that, in certain applications, can add a tremendous amount of value to the solution. And in other cases, it has no place in the solution. We have experience using machine learning. We will look at machine learning as a possible element of your solution when it makes sense to do so. But we have no vested interest in whether we include ML in your solution or not.
There is some confusion around what people mean when they use the term “no-code” (and also “low-code”). The idea, theoretically, behind no-code is that you do not need to be a programmer to use it. The problem with that concept is that some of the things that you are doing within a no-code environment actually does involve defining logic. But you’re typically doing that through some kind of drag-and-drop interface. So instead of writing a piece of code that defines the logic, you’re drawing something like a diagram on the screen, and that’s what defines the logic. So, the question there is, “haven’t we just given you a programming tool that just gives you a different way of programming?” We liken this to a WYSIWYG HTML tool like Dreamweaver used to be. I still had to tell it I want this option field to be a radio button. I want it to have these values, I want these values to mean these things, and I want the submit button to go here and write this to the database. I didn’t have to code it myself with a programming language, per se, but I still was programming in a different way. That is typically what people mean when they call something “no-code.” They mean something you can program through a drag-and-drop interface. And it theoretically does not require any programming skills.
Low-code is kind of a hybrid, where it requires some programming skills, but much of it can theoretically be done by someone without programming skills. So, the problem is that different people in different companies will describe their tools as no-code or low-code without a consistent definition of those terms across different companies and even people within those companies. The bottom line is that – in both cases – this category of low-code and no-code, which typically go together in discussions (which reinforces the fact that there is a lot of confusion between the two terms), they tend to be very highly opinionated environments. Which means that – whatever you’re building – you are going to be operating under the limitations that someone thought you might need when they built their platform. So, if you want to put a chart on the page, then you pick a chart from one of their drop-down meus, they put a chart on the page and they give you three things you can change like the color and the title and that’s it. Highly opinionated just means there are a lot of constraints because the closer you get to no-code, the less flexible it becomes. The other limitation is that – if you want to do something that the tool has not anticipated that you want to do – you probably just can’t do it. You probably have to wait until the vendor of that tool provides it because you have no ability to extend it yourself. Now, some low-code environments will give you a way to extend it, but it’s kind of weird because – if you bought the thing to use it without being a programmer – how are you expected to be a programmer when you get to the things that require a programmer?
They tend to be more suitable for simpler applications and they tend to make for a nice demo. They’ll show you how quickly you can make a page with some charts and gauges on it, how to hook it up to a data source and have a running application. But it’s typically a rather simple application that doesn’t involve anything that’s too far outside of what the capabilities are of the tool and isn’t particularly complex when it comes to the logic that it encapsulates.
The potential benefit to those types of tools is that they can sometimes be used to quickly prototype something. These are often great for prototyping a demo to show your idea’s potential to an investor or your board, for example. So the advantage of it being highly opinionated is that they tend to automatically make a lot of assumptions for you. So you go in and define a data source and the data is coming from wherever and when you drop your chart on the page, it’s usually smart enough to assume that the data is coming from that data source that you specified and it automatically hooks it up for you. As a result of it making a lot of assumptions for you, for doing a quick prototype, it can be useful. But they tend to break down when you go too far beyond simple solutions and basic prototypes and they don’t provide much flexibility when it comes to look and feel and user experience.
Also, just because a no-code environment doesn’t require true programming skills does not mean it doesn’t have a learning curve. The people that do those videos that show them building an app in three minutes? Yeah, they’ve been doing it for years, on that specific platform. It looks super easy because the people who are showing you that have been doing it for a while. They may even be the same people that developed it.
Our standard cloud infrastructure provider is Amazon Web Services. We’ve used them since the beginning, we have experience with them since they started back in 2007, and we like them a lot. But – we are completely cloud-agnostic. If you wanted a dedicated cloud environment as opposed to running your solution in our shared tenant cloud environment on Amazon, we can run on any cloud infrastructure provider that offers Linux virtual machines. And that includes physical infrastructure providers, too.
Declarative means you are not writing “functional” or “procedural” code to do something. Instead, you are declaring what you want to happen.
The main example of a declarative approach within Prism is Prism View. For example, instead of writing code that tells the browser how to draw a bar graph, the UI/UX person that is developing the UI part of the solution declares how they want that bar graph to appear. They are saying, “I want a bar graph, I want it to be here, I want it to be this size, I want it to use these colors, I want it to have these labels, I want it to pull from this data.” That’s what declarative programming is. You are declaring what you want to happen, you are not writing software to make it happen. The advantage is that it’s faster to develop, it’s less error-prone, and it’s easier to maintain over the life-cycle of the application.
Another example is our Binary Schema module, used to decode packed binary data payloads, typically received from sensor nodes. While it runs in Prism Core and Edge, which are not declarative environments, the process of building a payload decoder with the Binary Schema module is itself declarative. So instead of writing code that procedurally extracts data from the binary payload (which can quickly turn into some real spaghetti code), the developer simply declares the desired result: data in the form of meaningful named properties. And as with Prism View, this approach is faster to develop, less error-prone, and much easier to maintain and modify.
LoRa stands for “long range,” so it the word literally means “long-range wide area network.” It is a low-power WAN modulation technique that uses license-free frequency bands to transmit small amounts of data – either over long distances (ten miles or more) or through obstructions like buildings, typically being able to penetrate several concrete walls. It’s used in a lot of applications, including agriculture, smart buildings, smart cities, where you need either the long-range or the deep building penetration capability to wirelessly collect data from sensors and/or wirelessly send commands to actuators. It is often used in applications that need to be very low power, like battery-powered devices that last five years or more on a battery, or energy-harvested devices, like devices that run on solar power virtually forever. It’s a wireless technology that can either be operated on a private network or on any one of a number of public networks that provide LoRaWAN connectivity for a monthly fee. LoRaWAN is one of the wireless technologies that we use at ObjectSpectrum, and often includes network management services for private LoRaWAN customer networks as part of the solution. We are also member of the LoRa Alliance, which certifies LoRaWAN devices.
In most cases, what we’re looking for from the customer is somebody that has expertise in the subject matter – someone with domain expertise in the area of whatever the solution is. If it’s a solution for ranchers, we need someone with deep ranching expertise.
ObjectSpectrum supports just about any third-party sensor and device. We have the ability to rapidly integrate new devices. We aren’t limited by any particular list or kind of sensor or device. We figure out what the best solution is for what you’re trying to do, and we are completely agnostic when it comes to the device or any other technology it uses. We can integrate devices from different manufacturers with different technologies so that we can use the best in class for your specific solution’s needs. As a general rule, we try to use off-the-shelf sensors and devices whenever possible, but will work with our partners to develop custom hardware when that’s needed.
All modern browsers and mobile devices.
Well, “best” for your solution is different than “best” for someone else’s. And ObjectSpectrum is not tied to any particular wireless or connectivity standard of any kind. We regularly use a number of different technologies, and that is part of the Design Phase of any solution – to determine what the right technologies are for a given solution. Of course, that’s true no matter what technology we’re talking about (not just the wireless standard). Tracking ships at sea will necessitate a very different wireless technology than something that needs to keep track of pallets in a warehouse. It just depends, but we are not tied to any particular technology.
There are two issues here:
It ultimately translates into speed, cost, and low risk. That’s really what this boils down to.
ObjectSpectrum is primarily a software engineering company, focused on creating IoT solutions. We are more like a traditional software outsourcing company than a SaaS provider. An IoT SaaS company is primarily looking for a customer that wants to do it themselves and is willing to operate within the constraints of their software. The closer you get to a tool that can be used by non-software engineers (i.e. application designers and developers), the more you will have to play by the rules they have created in their software. Their software will let you take your knowledge of your warehouse, for example, and combine that with their software to connect and monitor this thing and that thing, and that’s great. But by targeting that kind of a user, you are going to be putting constraints around what you can do. And for some people, this may be completely fine. That might be the best choice for them and their situation.
If you are an enterprise customer, and what you need is to collect data from a hundred different sensors in your factory, or GPS trackers on your hundred different pieces of heavy equipment, then an IoT SaaS company could be okay for you because it will let you build a functional application. But the problem is that you are still going to be working within those constraints. To be clear, we are not knocking the idea of you working with an IoT SaaS company. We are just stating what’s different about that type of company and ObjectSpectrum. It’s important for you to understand the differences so that you can make the best choice for your specific situation.
But the dirty little secret of any SaaS company is that if you need to go beyond the scope of capability that they deliver to you, you either a) have no choice because they didn’t provide you with a way to extend it, or b) you now need to bring in the hardcore developers that are necessary to go beyond that set of functionality provided with the software. If you’re trying to build an application that is going to be offered for sale, either as a standalone service or as part of something that you’re selling, you want something that is a lot closer to from-scratch software development. You want something that doesn’t have those constraints; you need something that isn’t designed for a non-technical user. Because you’re going to run into issues with the SaaS products where they simply don’t meet your needs, and then what do you do? So the target audience for this is typically someone who is using it internally and they’ll tell you, “oh no, you can white label it, put your logo on it and offer it to your customers,” and that’s all great. If what you actually need is what they thought you needed, you’re in good shape. But as soon as you cross that line, you’re now into having to bring in the technical people to actually get the job done.
The bottom line is that an IoT SaaS company is not in the business of IoT solutions engineering. It is in the business of licensing a piece of software. ObjectSpectrum is in the business of solutions engineering. Tools like an IoT SaaS company can be a great prototyping tool. Because once you learn how to use their tool, it can be very quick and easy to set up, “okay, we need to monitor these five sensors and we need to test this thing over the next two weeks” and that type of stuff. It can be a great prototyping tool. Unfortunately, with most IoT SaaS companies, it comes with a pretty high price tag just to license it. So that makes it kind of an expensive prototyping tool. That’s not the case for every single one of them (IoT SaaS companies), but it is with a lot of them.