The rising value of linked information

Mark Noworolski

Mark Noworolski is the CTO of Streetline. He has been working with low-power sensing technology for more than 15 years, and he co-founded Streetline to leverage low-power sensor design, mesh networking, and web technology to deliver valuable applications to cities.

Peter Leiser is vice president of engineering, platforms, and applications at Streetline.

Mark Noworolski and Peter Leiser of Streetline detail how they are transforming the parking ecosystem with cloud, mobility, and analytics technologies using RESTful APIs.

Interview conducted by Vinod Baya, Bo Parker, and Bud Mathaisel

PwC: Mark, can you tell us about your company?

MN: Sure. Streetline was founded about six years ago with the vision of applying wireless sensor technology to compelling problems. We were very excited about low-power mesh networking and all the applications it makes possible with region-wide connectivity and sensors. We explored many applications and chose to transform parking first. What excited us about parking was that it’s an activity that occurs in a dense urban environment and with a large number of transactions. We often asked ourselves, “Where can I derive some value from the bits of information that I’m able to squeeze through a wireless mesh network?” We were looking for something where we can assign a value to each one of those bits of information.

At a high level, parking raises many challenges in almost every city. A one-year study of a 15-block area in Los Angeles found that about 30 percent of the traffic in the city is people looking for parking. That’s almost 1 million miles of driving and about 50,000 gallons of wasted fuel.

“We often asked ourselves, ‘Where can I derive some value from the bits of information that I’m able to squeeze through a wireless mesh network?’ We were looking for something where we can assign a value to each one of those bits of information.”
—Mark Noworolski

We have digitized the process of parking and created new value for consumers, parking garage operators, and local governments concerned about parking enforcement and the impact that parking-seekers have on the quality of life in cities. We get two pieces of information from the field in real time: occupancy and payment information. We use this information to transform the parking process and create a smart parking ecosystem. [See Figure 1.]

Figure 1
Smart parking ecosystem enabled from Streetline’s technologies and solutions

PwC: What’s possible now that was not possible before?

MN: In our system, we address several use cases. The first innovation is to guide consumers to available parking spots. Parker is our consumer guidance application, available on iPhone and Android platforms. Parker takes the parking availability, policy, and pricing data, and displays it to drivers in real time so they can find parking quickly. We also have a mobile payment capability inside the Parker app, so you can set reminders for yourself to add new payment before the parking meter expires, thereby avoiding a fine. You can even take a picture of where you parked, and that picture will be marked with GPS. Then when you’re done shopping, for example, and need to find your car, just pop up the picture and it will show you where to go.

One of our other solutions is ParkEdge, which is a parking management platform that is a self-service solution for private garage operators. Now a parking garage operator who has excess inventory in the middle of the day can access parking-seekers in real time with messages such as, “I have a special on parking right now near your location.” There’s also the ability to offer reserved parking. For example, if OpenTable1 is integrated with the ParkEdge platform, a restaurant could offer a reserved parking space with dinner reservations. Similarly, if you’re a merchant, you could validate parking for consumers shopping at your store. Many such use cases are now possible.

PwC: How does the system work?

PL: On the street, we have sensors in each parking spot and meter monitors, as well as wide area network gateway devices on lampposts. Everything is connected to everything. Information flows from the field and is posted to our data center. Our detection engine generates arrival and departure information in real time. This information is published onto a messaging queue to update the appropriate systems. We also aggregate information about payments from meters. We have a meter payment API [application programming interface] to aggregate information from different meter vendors that all have their own data semantics.

MN: Also, through our ParkEdge product, garage operators can enter their inventory into our system and indicate that some amount of capacity could be reserved. They can handle it any way they want: publish their charges, change pricing dynamically, offer valet parking, and so on.

PwC: So you instrumented parking spaces, surfaced new information, and digitized the parking process so that it can be transformed with cloud, mobile, and analytics technologies?

MN: Indeed, that is what we have done. The key for us, as I said before, has been to find information that we could assign value to. It was clear to us that real-time information about occupancy and payments is valuable to lots of constituents. You can probably appreciate that there’s a lot of value to the real-time aspect of the data, but there’s also a lot of value to the historical aspect of the data. This is where analytics comes in. It turns out that occupancy varies from day to day. The advantage of having sensors and real-time meter information is that you can then feed that into a back end that will allow you to look at historical trends over time. You can compare one city street to another, and if you have a true global reach to that data, then you can also compare how your city is doing to other cities.

PwC: You are using RESTful [representational state transfer] APIs to publish and share data. What is the strategy behind that?

MN: We’ve had an open business strategy from the beginning, and we’ve come to see RESTful APIs as a key enabler of that. We use them in our internal development as well as in how we interface externally. The openness applies to the sources from which we will consume data and to the way we share data via robust APIs. From relatively early in our company’s history, we’ve taken the position that we don’t need to limit ourselves to using only our own sensors. It does not matter where the data comes from; the value comes from how you aggregate and link data together.

PwC: What are some benefits you are seeing with an API-driven approach?

MN: One of the interesting things about our APIs is that the core data is the same. What changes is how the data gets used. Different use cases want parking data presented in different ways. For example, in Parker, if you’re trying to do real-time guidance to empty parking spaces, you’re not after historical data; you’re after what’s happening right now or what’s likely to be happening by the time you get there.

Whereas if you’re sitting in the parking department office and need to see what’s going on out on the streets, that’s a different API on the same data. In Los Angeles, we will cover close to a third of the city’s entire metered parking spaces. A parking control officer now has a global view that shows how many violations there are in each individual city block and can be guided by that information to specific blocks. The officer can zoom in, and it shows where the parking violations are on that individual block. As the officer gets out and writes that ticket, it sends information back to the server, and that information then gets republished to all the other officers in the city.

PwC: Are there benefits outside of parking to what you are doing?

MN: Indeed, a key benefit we plan for is the extensibility of our platform. An example that we’ve considered that’s not directly related to parking is to open up our sensor mesh network to collect other types of information from the environment. The idea being that you could then spur open development of different sensors.

Consider pollution sensors, for example. Let’s say we weren’t sure whether there was a market for those, but we opened up the APIs and we allowed somebody to build hardware that could use our already-deployed mesh network infrastructure to move pollution data from highly distributed sensors back to pollution control officers. Or because the APIs are open, we could get information from some other infrastructure entirely. That data can be published to our servers, and then it can be mashed up or brought into the Parker app. Anybody could use the open APIs to extend the parking experience to include pollution information or other environmental information.

PwC: How has the transition to RESTful APIs affected your software engineering practices, enterprise architecture consideration, and that side of things?

MN: If you think of everything you code as a module that has an API, it’s much easier to run development. As a small startup company you have a few people who know the full software stack and all the interdependencies in that stack. Inevitably as you grow, fewer people know the entire stack and understand all the interdependencies. Just because of that, you need to do something like this. You need to become more API driven, because if you don’t, you’re going to have intricate dependencies.

PL: In the past, we ended up with big pieces of software. When you looked at it, you could determine what was shared and what had been added specifically for another application, but it’s all one big soup. That becomes a maintenance nightmare, because there’s always this problem where you change one thing over here and you’ve just broken something over there.

“If you use this loosely coupled RESTful API approach, you accumulate less technical debt for every new piece of functionality created.”
—Peter Leiser

Now we have multi-tenant, system-of-record APIs. There are APIs for each use case: a parking status API, a meter payment API, a payment status API, and so on. It makes it much easier to organize and run engineering development and much, much easier to integrate with external code bases. We think API first now. We think, “What is the API contract based on the use cases?” and that helps us establish clear boundaries. Even with an internal application, the question is, “What data does that application need?” So you drive that through this API framing, which has the added benefit of not constraining other potential use cases.

PwC: Based on your experience, what would be your advice to CIOs considering a move to more openness and more focus on linking to other sources of value both internally and externally?

PL: Internally, we talk about our older practices as having created “technical debt.” The longer you’re in business and the more things you’ve built, the more technical debt you have. That technical debt is really like financial debt, where sometimes just servicing it ends up eating all your time and capital. I would advise CIOs to not be afraid to start over. If you use this loosely coupled RESTful API approach, you accumulate less technical debt for every new piece of functionality created.

With loose coupling, it’s a lot easier to replace modules one by one, piece by piece. When you have an API contract, those systems that talk to your API don’t need to worry about what goes on under the hood. What is important is to keep the API stable, so it needs to be managed like a product that would be maintained, supported, and evolved with good change management practices.

“If I were starting a company now, or doing an application that had a mobile and web component at any enterprise, I can’t think of any way to do it other than focusing on the platform that provides the RESTful APIs that the mobile and web client consumes from.”
—Mark Noworolski
 

MN: Strategically, you need to take an educated guess about what information and APIs will add to business value. Technically, if I were starting a company now, or doing an application that had a mobile and web component at any enterprise, I can’t think of any way to do it other than focusing on the platform that provides the RESTful APIs that the mobile and web client consumes from. This way, you can actually get to market fastest because you can have one built in parallel with the other.