Application Model
One of the issues related to open data is sustainability of the model. Too often cities and Governments invest into open data portal, publish several data sets, organize hackaton or two, and then nothing really happens, so the whole project basically shuts down.
Interestingly enough, we do understand right from the day one what we want to achieve: citizens and organizations that use services and applications to get better value from their city or their government.
Most of the efforts, after we build open data portal, goes into the creation of the applications that citizens will use to excersize some rights or access some information. To build apps we are using different scenarios: sometimes we build something from the scratch or we buy and customize products off the shelf. One of the most popular approaches so far is to organize a hackaton – to get together different people that think about the possibilities and then, during a day or two, they actually build prototype or application.
Well, that rarely works.
Even if it works, there is a lot of payload associated with it. Application code is left half finished, no one supports the code, there is no inherent interoperability, there is no … Actually it is very hard to reuse that code even if there is source code available or when the people that wrote the application wants to work with you.
So, can we do this little bit differently?
What if there is a way to build an application so that it is bascially write once run everywhere model? What if you just download the app or mark somewhere that you want to use it, and – it just works?
Welcome to the world of Application Models.
If we think trough the model, that means that we want to configure app so that it basically reads it setup dana at the runtime – when you start the app, it reads the configuration data, like what is the name of open data portal that it connects to or what type of colors or logos it have to use.
But also, it maps the needed data to available data – that way, when application “knows” what data it needs, it can basically check at the runtime is that data available. If yes – you can deploy the app. If not, at least you can say what data is missing.
But one thing is to Know what data you need – like “Address” and another thing it to translate that need to the data stored below. So, if we want to have truly portable and scalable app, we need to work with objects instead of data directly. So, what if App actually requests “ADDRESS” object instead of “Address” data? Underlying engine can map at the runtime those requests to the data available. Even more, if there is a mapper between an object and available data and you work at the App setup time at the maps between objects and data – you can actually really quicky map the App to any available data, as long as that data is actually what you are looking for. In Germany it will be “Adresse”, in Finish it will be “Osoite” and in Croatian it will be “Adresa”. But for an app – it is still the same object.
picture: That is how we enable multiple apps on different data objects 
Application Model and Services
For City as a Platform to be successful, platform need to enable various sets of business and citizen applications – the one that businesses and organizations are using to drive their core businesses every day, and those used by citizens to have better living. Applications are very core to the success of the City as a Platform / Smart City initiatives. If citizens have a mobile apps where they can access city services, submit proposals and issues and where city is communicating with them, that is for sure best way to move your smart city initiative forward. Same goes for businesses: spending less time with the government or city processes actually means that they can do more of productive work, and if they can do most of their processes online, that is a great productivity enhancer for a businesses that are operating inside the city borders.
1. Internal Applications and Back End Systems
These are two important elements of any City as a Platform, but they are fundamentally different in a way how system connects and uses them to perform specific function. Platform does not contains any software systems that is here categorized as a Back End system: we acknowledge that some processes and functions are too complex for a platform to support directly, like CRM or ERP functions.
Cities probably already have those systems in place, supported by some other vendor like SAP or Microsoft, and those systems are already performing their functions. Not that City as a Service is not integrating them or opening them to a wider audience (through the use of connectors) – we see that an end to end scenarios must incorporate back end systems. For example, if you want to submit an complaint to a city Complaint Management system, we believe that you should start with the citizen application, enter the complaint and then that data should end up in CM system, connected with CRM system. Some works for feedback or status that needs to flow backwards – city system will update the status of a complaint and then that info needs to travel back all the way back to the citizen’s application.
Also, there will be number of internal applications that are built on top of the City as a Service Application Model – so they are bound to the Data Model that is defined by City As a Services. That means that those applications can be transferrable to other cities and other cities can use them immediately. For example, Partner can develop and application for Transportation Management which connects and uses the data from the Big Data Store but also derives some patterns from DSS system. That application is internal to the city, have some connectors that enables its function, and have some connectors and data publishing mechanisms that connects any number of end user (citizen) applications that will help them have a better route, less crowded or faster, when they are traveling home.
Internal applications are very valuable to any city, since for most of them it take a significant resources to design, develop and maintain, and those applications all require infrastructure to function properly. If we have a platform behind and we operate by the model, we can drive those costs dramatically down, since we are sharing the apps and infrastructure – all toward OPEX cost model.
2. External Partner Applications for Cities
Of course, cities don’t use only internal applications to communicate and execute between different organizational units. There is an extensive communication that is happening between cities and external parties – and they need to have different approach to the internal processes. Most of those applications will be develop by external partners.
Platform must enable an interface where different application developed by external parties plug in nicely into the platform and act as a process element in larger end-to-end process that delivers something for the citizens or organizations. These applications can follow Data Model strictly (thus being scalable and portable to different cities) or they can be on their own (contained in some form of virtual environment), but are filling in the missing part the city probably have.
For example, city could subscribe to or buy an application for Air Quality Control, where obviously there will be a number of external sensors that feed in the data into the data store. Application will analyze the data and do some KPI or reporting and that info will flash at the Dashboard of the city official how is responsible for that element of the city performance. But, that info can also be feed into different other elements of the platform (like Open Data Store) so that other applications can use it and perform some additional activities.
3. External Partner Applications for Citizens
These are the most popular these days – cities, citizens and organizations are building an applications that citizens are using to communicate, to be informed or to act at a specific request or goal. Citizens would use different forms of applications depending on how and when they want to use them – sometimes they are sitting in front of the desktop computer and they want to fill in the complaint or read about the social or welfare possibilities they can use and then act upon the information that they have found. Sometimes they would report the issues immediately using the mobile application that is downloaded on their smart phone, but the result would be the same – request or information will end up into the back end system where city officials must act upon it. Feedback or status would be deliver back using the same channel as the one that initiate the process.
This is one of the main changes that we so in a last few years – citizens are moving away from their desks, they are more mobile and they want to act now and at the location where they spotted the issue. So, in order to follow the way how citizens want to use the app and work with the city administration – platform must support publishing of the mobile versions of the applications for all popular smartphone platforms. To support that behavior, partners will develop main desktop application that have more features and it is more configurable, but also for every single app it will develop mobile versions that citizens and organizations can download and use from a specific stores or marketplaces.
Mobile apps should support all known elements of how specific store works – for example – mobile versions should be upgradable and versioned through the standard mechanisms of the store. Also, all configuration elements should be developed so that application can be “localized” just in time – so that same application supports different cities or different locations / languages.
Social Connectors
Being connected to social networks and communicate through them is an important task for any city. But it is not just communication that is related to a citizen connecting city official and getting some information back and forth. One of the most interesting ways to use social connectors is to connect them with the automated agents or machine agents that are helping you to deliver specific functionality.
Also, social connectors are used to publish a specific information to a specific groups or citizens or organizations or to publish the change of the status of specific task – progress on some process that is important to a specific citizen. People are using social networks today as an equal mean of communication, just like telephone or email or sms, and platform should extend with developed connectors for any major social network that citizens and organizations are using today.
Back End Connectors
Back End connectors are used to connect a City as a Service platform to a back end applications and systems that city already have or could have in a future. We are using those connectors to connect to a systems that are supporting specific processes, like Citizen Relationship Management (CRM) or Enterprise Resource Planning (ERP) systems that are supporting everyday city activities.
Back End connectors are usually developed with the support of the specific vendor who is producing a specific back end system, or by their technology partners. Functionality or those connectors can vary dramatically – from simple data pump that is pushing the data through the connector toward a specific data consumer.
IoT Connectors
Internet of Things (IoT) is a next big thing in the area of specific data generation and delivery. Devices around us in the city are connected into a network of physical objects embedded with electronics, software, sensors and connectivity to enable objects to exchange the data with the data consumers or other connected devices based on specific standards. Also, city can control and sense those objects remotely across existing network infrastructure, and with the integration with the City as a Service platform this bring many opportunities to better control and manage the city needs.
Open Data Store platform develops number of different IoT connectors that are connecting to a different devices used in the city to perform different functions. They are mostly end points and data generators that deliver significant amounts of data into the Big Data Store, where they are processed, optimized and prepared for analysis. Those are the functions of external partner solutions, and they usually connect and correlate that data to the key performance indicators and decision support systems.
Get Connected