Risks involvesd in Creating Value Added Functionality and Applications Through Mashups

When implementing mashups, four areas of risk should be considered:

Dependency on services

One of the major risks in creating enterprise mashups is when you create a dependency on services that are external to your company (such as the “services in the cloud”). The terms of the service agreements should be investigated before the dependency is created. For example, some services require that the software using the service be a public facing Internet site; this might occur when the service has an ad-based revenue model. The terms of service may also be subject to change in some cases in ways that could be detrimental to your use of that service. To mitigate this concern, look for service providers that have a model that fits your usage.

Loss of data fidelity

Loss of fidelity in the data being displayed is another key risk. As data is visualized, there is a tendency to make the data fit the confines of the presentation surface. There will be a natural tendency to not visualize small amounts of data or to group data into larger collections in order to conserve space on the presentation surface. This has the potential to “warp” the end user’s view of the data.

Politics

Politics can also be a hurdle when creating mashups. If you didn’t create the service, then it might or might not do exactly what you wanted and it takes too long to get the originator of the service to change it to your needs. This Not-Invented-Here (NIH) mentality is fatal to mashups. This also manifests itself in trust. If you don’t trust the provider of the service, then you will not rely on that service in your mission-critical application.

Uncontrolled consumerization

Consumer technologies are increasingly being used inside the enterprise without the awareness or governance or corporate IT, according to a recent report from Gartner, Inc. Consumer-facing tools are tightly focused on the creation of a mashup and the visualization, so it can be very easy to create the initial mashup, but longer term maintenance of the mashup is not taken into account. Also consider how dangerous would it be to have an end user upload corporate data into a public mashup tool like Pipes or Popfly.

There are several ways to mitigate these risks. First, for internal or external services, put into place a Service Level Agreement (SLA) that clearly describes responsibilities of both parties, response time for change requests, uptime requirements, bandwidth restrictions, and all other relevant details. Second, lay out the possible fall back requirements in your application when there is a failure calling a given service. For some services, it might be acceptable to just not show that data; with other services, you could cache data that you can fall back on anytime there’s a failure. You might need a secondary service lined up as a backup to call in case something goes horribly wrong.

Finally, you will need to address the consumerization issues and the politics. Unlike increasing the reliability and redundancy of services, this requires a governance process. If your organization has a mature process for governing the use of services, then you should leverage that process for mashup creation and consumption as well.

Risks

When implementing mashups, four areas of risk should be considered:

Dependency on services

One of the major risks in creating enterprise mashups is when you create a dependency on services that are external to your company (such as the “services in the cloud”). The terms of the service agreements should be investigated before the dependency is created. For example, some services require that the software using the service be a public facing Internet site; this might occur when the service has an ad-based revenue model. The terms of service may also be subject to change in some cases in ways that could be detrimental to your use of that service. To mitigate this concern, look for service providers that have a model that fits your usage.

Loss of data fidelity

Loss of fidelity in the data being displayed is another key risk. As data is visualized, there is a tendency to make the data fit the confines of the presentation surface. There will be a natural tendency to not visualize small amounts of data or to group data into larger collections in order to conserve space on the presentation surface. This has the potential to “warp” the end user’s view of the data.

Figure 5: Mashups deliver ROI for IDV Solutions (Click on the picture for a larger image)

Politics

Politics can also be a hurdle when creating mashups. If you didn’t create the service, then it might or might not do exactly what you wanted and it takes too long to get the originator of the service to change it to your needs. This Not-Invented-Here (NIH) mentality is fatal to mashups. This also manifests itself in trust. If you don’t trust the provider of the service, then you will not rely on that service in your mission-critical application.

Uncontrolled consumerization

Consumer technologies are increasingly being used inside the enterprise without the awareness or governance or corporate IT, according to a recent report from Gartner, Inc. Consumer-facing tools are tightly focused on the creation of a mashup and the visualization, so it can be very easy to create the initial mashup, but longer term maintenance of the mashup is not taken into account. Also consider how dangerous would it be to have an end user upload corporate data into a public mashup tool like Pipes or Popfly.

There are several ways to mitigate these risks. First, for internal or external services, put into place a Service Level Agreement (SLA) that clearly describes responsibilities of both parties, response time for change requests, uptime requirements, bandwidth restrictions, and all other relevant details. Second, lay out the possible fall back requirements in your application when there is a failure calling a given service. For some services, it might be acceptable to just not show that data; with other services, you could cache data that you can fall back on anytime there’s a failure. You might need a secondary service lined up as a backup to call in case something goes horribly wrong.

Finally, you will need to address the consumerization issues and the politics. Unlike increasing the reliability and redundancy of services, this requires a governance process. If your organization has a mature process for governing the use of services, then you should leverage that process for mashup creation and consumption as well.

Wow, thanks for the detailed response and generous offer! EPA Staff have invited me to listen in on some of the Data.gov PMO's SemWeb / Linked Data team calls and I have, as well as participate in EPA's Strategic Data Action Plan and Data Publishing Project. The result of that is my Build Data Catalogs in the Cloud in Support of Data.gov and EPA's Strategic Data Action Plan at http://semanticommunity.net/ as well as my Build EPA’s Synaptica in the Cloud: An Enterprise Vocabulary Catalog for Data.gov/semantic at http://semanticommunity.info/EPA/EPA_Synaptica. I have co-lead the Federal Semantic Interoperability Community of Practice (SICoP) from 2002-2007 and now participate regularly in OASIS, W3C, RPI Data Science and Semantic eScience and Harvard Leadership in a Networked World Graduate Classes, and other groups. Mills Davis and I are restarting (by popular demand) the SICoP with the launch of Semanticommunity.info: Community Infrastructure Sandbox for 2011-Getting to 'the 5 stars of Linked Open Data' and we would welcome your participation again at http://semanticommunity.info/.

My email is bniemann@cox.net and I welcome the opportunity to participate. I have submitted 10 suggestions to the Data.gov Open Data Forum and sent emails recently to Jeanne Holm and Sonny Bhagowalia offering to help.

See http://semanticommunity.info/White_House_Visitor_Records_Online,_June_25..., http://semanticommunity.info/Whitehouse_Visitor_Records_Online,_October_..., and http://semanticommunity.info/EPA/EPA_CASTNET. Plus many more at http://semanticommunity.net and My Data Science Library in the Cloud at http://ondemand.spotfire.com/public/library.aspx?folder=Users/FAMIEVL-91...

P.S. I have suggested that URL's in these comments be executable links so you don't have to cut and past all of these URLs.