A smarter water app development ecosystem

In previous blog posts I have detailed how enterprise apps can be developed today using the IBM Smarter Water Platform. From this a whole enterprise based app development ecosystem can be built up to help address real worlds problems for the water industry such as water conservation and non revenue water (NRW). These apps follow a pattern of; leveraging information from various sources such as the citizen as a sensor and the Internet of Things (IoT) of smart water sensors and meters, analyzing the information with advance analytics, and visualizing the information and analysis in a contextual and situational aware environment. This pattern can yield powerful insights into the water network. In this blog i want to examine this ecosystem more with a story about how multiple players can collaborate around this smarter water ecosystem.

Below is the diagram outlining the development of a smarter water app development ecosystem. The App Store in the diagram below can be realized by our IBM Cloud try and buy offering. We will now look at a non revenue water story that could be realized by this ecosystem.

A Non Revenue Water story (A Smarter Cities ecosystem)

1. A Water Balance App is  developed on the Platform by a App Developer in collaboration with a Domain Expert (an example of a water domain expert would be a water engineering consultancy company). The Water Balance App could then be published to a Smarter Cities App Store (such as IBM Water Usage Analysis app at the IBM’s try and buy site). A domain expert can then consult with the Water Balance App and use it to help find leaking zones in a water system
2. A Domain Expert can then consult with a Pressure Management App (from the Smarter Cities App Store) to help reduce the pressure in the water network and therefore reduce the amount of leaks. The domain expert can extend the app with their domain knowledge (KPI, regulatory reports, SOPs). The Domain Expert can use the Water Balance App to quantify how effective the Pressure Management App has been in terms of leaks reduction in the water network. 
3. An Asset Vendor (an example would be a sonic sensor manufacturer ) can then work with an App Developer to create a Sonic Leak Detection App for their sonic sensors. This app would again be published in the Smarter Cities App Store. A Domain Expert would then consult with the Sonic Leak Detection App to detect a leak down to a particular pipe. The Domain Expert can again use the Water Balance App to quantify how effective the Sonic Leak Detection App has been in terms of leak reduction in the water network.

Here the roles are defined more clearly

• Platform Provider - IBM would be the smarter water platform provider 
• App developer - An app developer would use the platform services and programming model (SDK) to develop apps on the platform, these apps could then be deployed to the Smarter Cities App Store. 
• Domain expert - Domain experts will use the platform as well at the apps from the Smarter Cities App store in their consultancy to give them a competitive advantage. They will typically augment these app with domain specific content (e.g KPI, reports, SoPs).
• Asset Vendor/Content Expert - Asset Vendors provide hardware solutions such as sensor and meter vendors. As cloud hosted solutions become more common, our platform and SDK will become an attractive solution of developing apps to access their hardware that are connected. 

This ecosystem will enable multiple parties to collaborate together to allow them consume and use water resources smarter. The  IBM Smarter Water Platform therefore allows us to build advance analytics based apps with data consumed from the enterprise, the Internet of Things, and the citizen as a sensor thereby opening up a new ecosystems for collaborative smarter planet app development: an enterprise app store. This combined with the latest announcement of a joint collaboration between IBM and Apple makes this a very exciting time.

http://lnkd.in/d_-6WZF

View Eoin Lane's profile

Smarter Water Application Development Lifecycle

So far we have looked at a number of concepts around the IBM Smarter Water Platform. We have looked at the water information hub (the WIH provides a systems view of the water network), the Smarter Water SDK which is built on-top of the WIH (the SDK provides the tools that an application developer needs to build water related applications), and the content packs ( the content pack provides supporting content for the application) used to support applications. Now we will put all this together and show how an water related application can be developed, installed, configured, and extended in IBM Smarter Water Platform.

The following diagram shows the end to end lifecycle of a water application developed, and deployed into IBM Smarter Water Platform

IOW app development concepts dependencies

1. An application developer develops an water related application (app) to address a water related business need
2. The application is supported with a content pack
3. When developing the application, the application developer also creates app meta data such as UI extensions points which allow the application to be hooked up to the platform UI
4. This application is categorized by vertical, role and business responsibility or component (conceptually we can think of this as the app being installed into an app store).
5. The application can then be installed into IOW to help solve a particular business need.
6. Based on the categorization and the UI extension points the app is customized into IOW
7. Extend the application content pack with domain knowledge and expertise

Let us now look at each of these steps in a bit more detail. We will expose each of the step in more detail using a example pressure management application.

0. Identify the business need

Within a pressure zone, the water pressure in usually kept high to ensure that there is adequate positive pressure on the tap side. Keeping the water network at high pressure all the time has a detrimental effect on the pipe network, particularly in an aging pipe network, which is the case in most western european cities. The constant high pressure tends to corrode the pipes and also exasperates any existing leaks.

1. Develop an application to address the business problem

An application developer develops a water related app to deal with the problem. The app exposes a service to deal with the business problem. In the case of high pressure problem, a pressure management app would be developed and it would expose a business service to manage the pressure’

A pressure management application, built using SDK, will read off the pipe network and then iterate through the pipe network and read off the pressure reading at pressure critical point and then take that data and process it through an optimization algorithm. The output of the optimization algorithm will then give the optimized pressure readings for that pressure zone. The application could then write out to the optimized pressure reading to the pressure reducing valves in the water network. This pressure management app then exposes a service called ’Manage Pressure’. Once this application is deployed into IBM Smarter Water Platform (IOW) this service becomes available to be called either standalone or part other application as part of a business process or collaboration.

2. Support the application with a content pack

An application developer will also need to develop a content pack to support the app. There is a minimum amount of content to make the application functional and these content needs to be developed at this time. Note that the content in a content needs to be both multi-tenant and high availability aware. Here is the typical types of content that an app needs in order to function

Data sources - Understand the external systems (e.g. work equipment: devices, sensors, meters, etc). Identify the external system that the app needs to pull data from, or interface to, in order to function. This data is ingested over and industrial strength enterprise service bus.

For the pressure management app those type of data sources would be pipe network categorized by pressure zone, the pressure reading from the pressure critical points, and the pressure reducing values in the network.



Events - The enterprise service bus and the mediations are also responsible for handling and dealing with events. These events can be external event such as a weather event, or events from the meters and sensor devices, such as a no read. These events can also be generated by the application.

The pressure management app is interested in events such as leaks, bursts, pumps request to be serviced and also event correlations such as unknown or ’no data’ status reads from the sensors on the network.

Database extensions - Create the corresponding application specific IOW persistence stores. Based on the format of the data from the external systems, such as the measurements and measurement values from sensor or meters, the corresponding database stores need to be created within the Smarter Water Platform (IOW).

For the pressure management application, the corresponding data stores to store the measurement values for the pressure critical points and the data from the pipe network and pressure zone boundaries must be created.

Water information hub/Semantic model - Extend the IOW Semantic Model to support the clients water model. Based on the application requirements and the types of external systems the semantic model, at the heart of the Smarter Water Platform (IOW), can be extended to model these systems to provide a overall view of the water network.

Extend the IOW semantic model to understand EPANET hydraulics model (pipe network)

3. Application meta data

When developing the app, the application developer also creates meta data about the application. This app meta meta is stored as part of the content pack. Examples of the kind of meta data associated with applications would be

• The UI extension points for the application. When an application is being installed into IOW, these UI extension points are exposed to the application installer to allow the application to be connected to the platform viewer.
• The applications classification by vertical, role and business component or responsibility (see section 4. Application Classification below) .
• A list of the services that the application consumes and exposes (see section 1. Develop a business application above)
• Role based authentication and authorization access information for application services.



4. Application Classification

The application now needs to be classified and categorized by vertical, role and business component or responsibility. Conceptually we can think about this as installing the application into an app store where the application is verified and classified. This classification will help intended audience to find the application and it corresponding service(s). This classification will provide guidance as to how and where the application will be installed into IBM Smarter Water Platform (IOW).

The pressure management application would classified as follows:

Classification of the pressure management application

Vertical	Water sourcing and distribution
Role	Water Planner
Business component/responsibility	Infrastructure monitoring and optimization
Business service	Optimize pressure (the application provides a realization of this service)

This classification information is then added to application’s meta data. Also note that a pump energy optimization application would be classified the same way.

5/6. Application installation and configuration

The application installer/configurator can now install the application into IBM Smarter Water Platform (IOW). Conceptually this can be thought of as a user installing an application on their iPhone/iPad. Based on the classification of the application, the installer takes into account the application’s domain vertical, the role, the business component/responsibility and the business service being exposed. The applications configurator also configures the application extension points such as the UI extension point, localize the application, and configures time and date formats.

Based on its application classification the pressure management application would installed into a water sourcing and distribution planner page or tab and would be categorized in that page/tab under infrastructure monitoring and optimization. The pressure management application extension points would also be configured to localized the application and to hook up the UI extension points.

7. Extend the application content back with domain knowledge

App content packs can also be extended by a content pack extender, typically this is an typically a entity with domain knowledge expertise. An example of a domain knowledge expert would be water engineering company who understand the local domain (e.g. USA, Europe, South Africa, etc) and regulatory compliance (e.g. EPA regulations in the USA) that the apps needs to operate in. Again the content in the content needs to be both multi-tenant and high availability aware.

An application with a basic content pack can be extended multiple times with difference content depending on the domain that the app is deployed in. For example the pressure management app could be used by a water pump company who have pumps all over the world. The water pump company or a water engineering company that sell these pumps, can then take the pressure management app and provide difference extension to this content pack when they are using this app in Denmark and using it in the USA.

Role based security access to the content may also be added by the content pack extender to application meta data section as the content pack is extended.

Here is the typical types of content that an app can be extended with:

Key Performance Indicators (KPIs) - Create application specific KPIs

Discover, specify and implement the KPIs that the application needs to report on. Key performance indicators (KPIs) are quantifiable measurements employed by organizations to monitor and assess performance. See Allen Smiths dW article Part 1 and 2 on KPIs

Custom business reports - Gain insight from historical data with reporting, scorecards, clustering etc. Custom business reports, also know as descriptive analytics, provides summaries and reports about the sample and about the observations that have been made.

For example, the asset maintenance history of a water pipe is a descriptive statistic that summarizes the quality of a water pipe.

Standard operating procedures - Standard operating procedures (SOPs) can also be launched by an application via the underlying eventing mechanism. SOPs are essential to an organization’s ability to deliver consistent, measured, high-quality responses to complex events.

An SOP might be related to automatically detecting a failure in a sensor and opening a work order to have it repaired, or to dealing with approaching severe weather. Regardless of the reason for the standard operating procedure, if an organization develops a planned, understood (and rehearsed) response to various events it can better respond to that incident quickly, and consistently. See Bob Patten dW article on SOPs.