Smart cities in particular epitomize the concept of an ecosystem; buildings connecting, machines talking to each other, the right data flowing to continually improve services. But, such ecosystems are complex, fragile and need to be built and managed carefully with the right tools and planning.
Adam Pucher, currently Chief Information Officer (CIO) at smart city app NaviParking and IT Director at app innovator EkinnoLab, knows a little (a lot) about this. After years of working in the world of corporate telecommunications as a software engineer, and being involved in noteworthy product launches such as the Voice over IP (VoIP), DigitalTV (DTV) and Video on Demand (VoD) in the Central and Eastern Europe (CEE) region, around three years ago, Pucher made the move to the exciting world of smart city startups. Digital ecosystems are of course prevalent across both industries and even intertwined through partnerships, so Pucher was able to give us his perspective from both sides of the coin.
In our interview, Pucher covers how standardization, CurateFX and synchronicity across the value fabric have helped him, and can help firms, coordinate their efforts to pioneer strategically.
AM: A good working digital ecosystem is something that a lot of companies are working hard to finesse. Drawing from your combined experience, how important is this?
AP: I’ll start with the challenge: telecommunication companies are generally grown by acquiring smaller companies. This, of course, happens everywhere, but in the telecoms world, it’s been happening for many, many years. These businesses then need to be consolidated and if we look back to 15 years ago, there weren’t many standards or common approaches, making every such acquisition rather painful.
Managing the ecosystems here well is important because it saves a lot of time, cost and helps with the risk of mistakes and miscommunication, especially as they are getting more complex. I do think that it’s getting easier because the leading companies are using, or starting to use, ecosystem management tools, architectural guidance, good practices and so on. They make it easier to work together to, for example, integrate two systems from merging companies.
AM: So you’ve gained a great deal of insight in being a part of managing these ecosystems over the years, particularly smart cities in recent times, what changes have you seen in digital ecosystems?
AP: From the cities perspective, I see that there is a lot of maturity in how it’s done. I observed that cities are starting to see benefit from exposing their data to the wider ecosystem.
If I looked at the same thing two, three years ago, there were many situations where cities just selected the external vendors at low prices for smart city project projects such as city transportation apps and the like. These vendors would gather data for themselves and the city would have to think about whether it’s better to pay more and own the data, or not. Where they don’t, it’s a lot more difficult for them to improve services for citizens, who will then become disillusioned and start to complain about the app. Because of these experiences, cities started searching for more of a partner relationship rather than a contract, where all partners were helping and involving each other to better their own businesses and to continuously help the app and go further.
Another such situation is where every city has its own special app built, but between cities, the apps (such as parking or bus apps) are wildly different. And, of course, the costs of creating these apps is still high. In the digital ecosystem, if all cities use the same standards for these apps, it will be easier for them to create similarly great solutions and even compete better with one another by adding their own twists to the standard design. This will in turn increase the quality of application used, in turn drawing in more users.
AM: So as more and more different types of partners become involved together in creating and innovating, the projects, and the technologies and networks involved before far more complex as time goes by. How much has CurateFX helped in your work of managing these kinds of ecosystems?
AP: Since the beginning of last year, I’ve been involved in the API architectural and monetization stream where we mapped the business requirements. We used CurateFX to define and map how we were going to work together.
We’re now working on making the architecture more understandable on a business level; the CurateFX city as a platform module has helped me to visualize and to analyze the impact of the relationship between the business requirements and the APIs that can serve them. Here, we were also able to define the role of each stakeholder (e.g. integrator, end user), describing each role, agree on common terminology and define our needs to help focus us on the end goal through the same lens.
In the smart city world, there are not that many management tools or standards/common languages in place for smart cities. If this is adopted by the cities, it’ll be much easier for them to scale the applications/solutions through having a clear-cut way of communicating and managing what they need to do.
AM: What are some of these guidelines and standards you’ve used as well as CurateFX?
AP: There’s TM Forum Frameworx which I was using together with the architects for the integration process for a billing and provisioning system. It helps me to reduce the cost of designing the system as less time is spent trying to brainstorm and plan the design. It’s also reduced the risk; there’s always the risk in an architectural implementation that the design will be changed. When we’re using a model that’s already been used by other companies, the concept has already been tested, which means it’s workable, and that reduces the risk of having some part of the system redone after the implementation. From my perspective, these standards really make the projects much smoother.
We can also provide more accurate cost estimations whenever there are discussions about changing some system components. For example, if you’re thinking about the upgrading the billing system, you can better assess the cost of such operations based on the eTOM compatibility of the system.