Situational applications and social networks
A social network is a model of the relationships in a group of individuals that are tied together by a specific common trait. An individual can also belong to more than one social network. For example, Joe Soap belongs to a social network of graduates from the University of Texas, a social network of individuals who enjoy mountain biking in Austin, a social network of individuals who shop for groceries exclusively at Whole Foods, and the list goes on. Joe Soap belongs to a wide variety of social networks.
Knowledge of the traits of a specific social network is a valuable tool that application developers can use to intimately examine the needs and requirements of the social network and tailor the application appropriately. For example, you can add features that are useful and remove features that aren't. This makes the application more engaging to the specific community for which it's targeted. In addition, you can work closely with the same community by soliciting and incorporating feedback over multiple revisions of the application. This exhibits the tight feedback loop with the community mentioned in the first article. This approach is in contrast with designing software for a broader audience, which requires you to add various features that may or may not be used.
An article by Clay Shirky (see Resources for a link) has several compelling examples of how students at New York University designed useful and popular applications by crafting them for a specific (if not niche) target audience. He goes on to say how these applications would have lost their value and popularity had they been positioned for a wider audience. So, to sum up, a situational application is an application that has been created for a specific situational need, designed for and developed in collaboration with a specific social network.
Another interesting factor to be aware of is that, due to rapidly changing market dynamics, a significant amount of business collaborations tend to last less than 12 months. With the average application integration effort taking from three to six months, there's little room left for a return on investment (ROI). The industry needs solutions that can be built rapidly and cost effectively (in lieu of the total time frame of the collaboration) to solve immediate and specific business problems, yet be considered disposable (when the market moves on). Because situational needs often necessitate that the application be short lived, situational applications have another trait -- that the end result can be informal and just good enough, as they don't need to exhibit features and traits that give them product-level quality.
How do you create situated software?
If SOAs can evolve and be improved to empower users by freeing up information and making it more accessible, a mashup ecosystem can be put into place that leverages these SOAs to let users rapidly create situational software. While this is very interesting, these are indeed difficult goals to achieve. The following sections explain this approach in more detail.
Evolving the SOA
The IT industry has made great strides decomposing IT infrastructures into modular, reusable services. While this has provided value in other areas, it still takes the skill of a developer to be able to integrate and build applications with these services. Because IT exists to fulfill the needs of the business, it stands to reason that the next evolution of the SOA will be to put these services in the hands of the users (nondevelopers) so they can build solutions in a manner that can overcome the issues with ROI that were described in the previous section.
Furthermore, to achieve the requirements of a situational application, development needs to become significantly more affordable and expedient. You need a new way of accessing and leveraging the current services in the SOA and empowering the end or business user to quickly integrate the services together. This approach would allow them to rapidly create applications that meet their situational needs.
To effect such a model, the services need to have a visual element to them. A face, or visual representation, for each service can provide access to the properties and features of the service as well as the ability to reflect relationships (wiring) between services. After this has been achieved, a service catalog can be created to contain visual representations of services and content that can be dragged from a palette and used on a canvas. If the properties of the services can be made visually accessible, then the wiring phase can be completed without programmatic intervention. Considering the fact that business users are already familiar with the capabilities of the services and content, this allows for extremely rapid application creation.
If business users are the ones using the services, they can provide useful feedback on the granularity of the information provided by the service. Previously, the granularity of information provided in services has often been decided by factors such as performance and maintaining the status quo of the old legacy interface. If business users are able to build applications using these services, they can provide valuable feedback on information granularity based on how they were actually using the information in their applications.
Figure 1 lays out the framework for how SOA is used as the infrastructure of a situational application.
Figure 1. The face on the SOA
A more broad example of a social network than those found in Shirky's paper is the social network of the modern business end user or power user. This particular network of individuals is categorized by their good understanding of the Web, the technologies used within it, and basic programming skills (such as the ability to create Microsoft® PowerPoint® automations and Microsoft Excel® macros). These users know their audience intimately (usually a much smaller social network) and can use this knowledge to avoid spending time adding features they know not to be intrinsic. To empower these users, these skills need to be put to use to leverage their knowledge of content sources (inside the enterprise and on the Web), tools, products, and services to enable them to build situational applications that can drive their parts of the business. This can be achieved by the adoption of the mashup ecosystem, illustrated in Figure 2.
Figure 2. The goal of enabling users to build situational applications
The mashup ecosystem
The diagram in Figure 3 displays the mashup ecosystem vertical stack. Each element builds on the one below it until the end result is that a mashup can be created. The mashup is at the top of the ecosystem but is only attainable if the other elements of the ecosystem are in place.
Figure 3. The vertical mashup ecosystem stack
A mashup is a type of situational application that's comprised of two or more disparate components that have been connected to create a new integrated experience. An example of this is zillow.com (see Resources for a link), which integrates county tax information on real estate for a given location (component A) with a map for the same location (component B) to allow you to view the assessed tax value for all real estate within a particular vicinity on a map (the new integrated experience). The original situational applications were mainly shell and Perl scripts, which, as a situational need arose, were used by developers to quickly and cheaply address them. Unfortunately, these technologies require the skill of a developer and are not amenable to leveraging the skills of business users. However, now that there's an approach to evolving the SOA and enabling services to have a facade, the foundation has been laid to employ a mashup ecosystem that will allow users to visually develop situational applications in the form of mashups. A mashup is just one form of a situation application much like a SOAP Web service is just one way an SOA can be implemented. Mashups are by far the most popular approach to creating situational applications as dictated by their prevalence on the Web today.
A mashup maker is an assembly environment for running and creating mashups. It gives users an efficient way to visually assemble mashups by blending publicly available information and services with a company's internal private information and services. The user can then visually manipulate and integrate that content, whether it's static content, such as a Web page, with dynamic content, such as a SOAP or Representational State Transfer (REST) service, or RSS feed. QEDWiki is a mashup maker contained within the IBM Mashup Starter Kit.
A mashup maker allows rapid visual assembly of mashups, because it provides a collection of widgets, which are software components that provide access (normally coarse grained) to one or more services or content (in this article, content is synonymous with information). Widgets tend to be designed with a focus on consumption and customization to ensure they are extremely flexible, as one of the basic tenets of Web 2.0 is that you can't anticipate how your content will be used. Widgets can be both visual (in that they render visual content, such as a chart) or nonvisual (in that they provide some form of discrete function or access to a service). Via the mashup maker, a widget can be dragged from a palette onto a canvas, where the widget properties can be visually accessed and used to connect the inputs and outputs between various widgets, with the end result being the creation of a mashup.
Build situational applications within the mashup ecosystem
After the mashup ecosystem is in place, you can use the model of assemble, wire, and share to build situational applications via a mashup maker. Let's break this down into each action:
- Assemble: An enterprise can create a widget catalog that's accessible to the mashup maker. This catalog contains all the internally created widgets and externally available widgets that might be used in a given area of the business. This provides a way for users to quickly find and employ the services and content they need in the process of a building a mashup.
- Wire: The assembler employs the services made available in the service catalog and connects them together via the mashup maker to rapidly, visually build mashups. For example, a form widget can be placed on a page, allowing a user to enter data. This data entered can be connected to the input of a widget that provides a Web service invocation, and the output of the Web service response can be connected to a widget that renders a visual display.
- Share: The assembler then shares the mashup to make it publicly accessible so it can be used by the knowledge worker, and the community mechanisms can be employed.
There are three distinct roles in this process:
- Mashup enabler: The mashup enabler writes the widgets and adds them to the catalog. They dialogue with the assemblers to anticipate their needs and add the appropriate services both retroactively and proactively. This is usually an individual from the IT department or someone with sufficient technical skills to write software.
- Mashup assembler: This is typically a nonprogrammer that's a line-of-business user or subject matter expert. The mashup assembler builds mashups by wiring together the mashup consumables that have been created by the mashup enabler.
- Knowledge workers: This is the community that uses the application for its intended purpose and employs community mechanisms on the application, such as ratings and comments, to provide feedback so the application can be improved on the next iteration.
The responsibilities of the roles in the various phases of the model are displayed in the diagram below.
Figure 4. The assemble, wire, and share model
What makes the mashup ecosystem so effective?
First, because of the strides the industry has made in standardizing key technologies, such as SOAP, REST, and Ajax, we've seen an explosion in the adoption of SOAs, both on the Web and inside the enterprise. This has led to the technologies reaching a critical mass whereby there is a proliferation of reusable Web-based APIs and mashups that are just a URL away. In this, there's an unparalleled ever expanding set of content, data, and services available for people who wish to develop applications using this model. The time is ripe.
Second, this is an extremely approachable programming model. It has a very low barrier to entry due to the broad base of business and power users that are familiar with Internet-based applications (and simple scripting languages like PHP) and can do tasks, such as write Excel macros.
Last, the collaborative mechanisms that are already popular on the Internet today serve to facilitate faster application development using this model.
In this article, you learned that using existing application development processes and methods leads to a low ROI due to the situational nature of business collaborations. Furthermore, you saw that the domain-specific and technology-related skills of business and power users can be leveraged within the context of a mashup ecosystem to let users rapidly, visually assemble situational applications, providing a better ROI. The next article in this series covers the IBM Mashup Starter Kit and how it you can use it to build mashups.
My thanks go out to Stew Nickolas and Dan Gisolfi for reviewing and contributing to this article.
- Check out video demos of IBM mashup technology on YouTube.
- Learn more about these concepts at Mashboards.net.
- Find content and services at The Programmable Web.
- Learn more about situational applications on Wikipedia.
- Read Clay Shirky's paper on "Situated Software."
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
- Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Check out a quick Web services on demand demo.