- Sustained competitive advantage will increasingly depend on enabling self-reliant employees to create their own software solutions to meet their business needs.
- These solutions are increasingly grouped under the term “situational applications” (SAs)[1].
- SAs are solutions aimed at solving immediate business challenges in a cost-effective way by specifically addressing the situation at hand.
- SAs are often applications that have generally been inaccessible in the past because software has been too difficult to write, too costly to implement, and too brittle to customize and maintain once deployed[3].
- Cloud computing has spawned a new wave of tools that effectively address these problems. These tools empower business users closest to the problems being solved to quickly build full-featured collaborative business applications online and immediately deploy those applications to the appropriate people both inside and outside their organization.
- SAs significantly reduce or even eliminate the need to hire professional software developers, purchase or build a new software application, or throw together a suboptimal, inefficient and incomplete solution using tools like Excel and email.
- Far removed from the traditional controlled environment of corporate applications, SA’s address areas that were previously unaffordable or of low priority to the IT department. This will lead to new opportunities for improving efficiency, effectiveness and innovation.
- SAs are growing in importance as a result of the need to increase agility and reduce costs at a time when increasing revenues is hard to do.
- This guide provides an introduction to the concept of situational applications and how they can be used to harness the power of knowledge workers in any organization.
Target audience
- Executive Management. How will SAs reduce time to market for new solutions, improve the organizations overall productivity, and increase return on IT investment?
- Departmental Managers. How will SAs help me improve my department’s productivity and effectiveness?
- Business Professionals. How will SAs provide me with better tools to do my job more effectively?
- IT Management. How will SAs reduce the amount of effort and risk required to build solutions, and how will it allow me to service my user base more effectively?
- IT Professionals. How will SAs make me a more productive and therefore more valuable member of the organization?
- Business consultants. How can SAs help me improve my client’s organizations, and allow me to expand my service offerings?
- Systems Integrators. How can I take advantage of SAs to help my clients and increase my revenue?
- Entrepreneurs. How can SAs help me build my new business, and what opportunities do they offer to create new business opportunities?
SAs vs traditional applications
Situational applications differ significantly from traditional software:| | Traditional IT development | Situational Applications |
| Stakeholders | · LOBs' executives · Corporate IT | · Individual users/self-organizing small team · User community that's formed around the application |
| Targeted users | · Large, generic group | · A known individual or a small team · Attracts unintended users |
| Governance | · Centralized · Formal | · Grassroots · Community based |
| Evolution | · Top-down controlled · Centrally driven · Depends on available funding | · Organic · Based on user feedback and participation |
| Time-to-value (life cycle length) | · Many months or years | · Days or weeks |
| Development phases | · Well defined, following agreed-to schedule (although with frequent schedule overruns) | · No defined phases, milestones, or schedules · Focus on a good-enough solution to address an immediate need |
| Functional requirements | · Defined by limited number of users · IT needs to "freeze" requirements to move to development · Requirement creep often caused by changing business needs | · As requirements change, usually changes to accommodate business changes · Encourages unintended uses |
| Nonfunctional requirements | · Resources allocated to address concerns for performance, availability, and security · Focus on these and other nonfunctional requirements (such as scalability and maintainability) often results in robust but costly solutions. | · Little or no focus on scalability, maintainability, availability, etc., significantly reducing cost. |
| Testing | · By IT with some user involvement | · By users through actual use |
| Funding | · Often coincides with annual IT planning · Requires approved budgets | · No formal budget · Developed and run under the radar of corporate IT |
(Adapted from IBM[2])
SAs in the application landscape
The Long tail
SAs represent the “long tail” of software applications – applications that before are too costly to build the traditional way, or have a lower priority for IT.
Dynamic Solutions
Traditional applications address anticipated situations with planned responses:
Source: Igniting the Phoenix: A New Vision for IT[4]
Knowledge workers, however, live in a world beyond the bottom left quadrant, buffeted by unanticipated events requiring unplanned responses. Traditional applications are not well suited to the flexibility and responsiveness needed. Today, employees address these quadrants with a combination of email, spreadsheets, and word processing tools to help them coordinate their work and maintain focus on the tasks at hand. SA’s promise to take these solutions to the next level.
SAs and Mashups
A “mashup” is built by taking multiple, disparate data sources and creating a something new. Typical mashups allow users to take maps, charts, videos and data and mash them together into a visually interesting experience for the user.
Mashups are a subset of situational applications[6]. There are mashup tools that are designed to only produce mashups, and there are SA Web application tools that include mashup capability. There is a good chance that the overlap will become blurred over time as SA development tools evolve.
Why SAs are now feasible
Situational applications have become feasible as a result of a number of factors:
| Factor | How it contributes to the rise of Situational Applications |
| Introduction of new development environments | Users with a lower skill base can rapidly create highly interactive applications |
| Introduction of technologies such as REST, Atom, and RSS feeds | It has become much easier to access existing data in a standard, simple, easily consumable format. |
| Overall computer literacy | A larger population of users can "program." |
| Acceptance of community-based computing and collaboration | Developers and users readily share consumables and improve on each others' work. |
| Proliferation of APIs and Web components | SA builders have a richer palette for selecting consumables. |
| Availability of numerous services and SAs in the public domain | Novice SA builders learn by viewing applications written by others. |
| Lower infrastructure costs | SAs don't need to be deployed by IT; Platform-as-a-Service (PaaS) solutions take infrastructure out of the equation. |
(Adapted from IBM[2])
What benefits can be expected from SAs
Situational applications can facilitate the following benefits
| Benefit | Type of Situational Application |
| Better decision making
| Increase the speed by which knowledge workers receive information; deliver the right information at the right time; provide shared, common access to the latest information at all times; automatically consolidate information from multiple sources. |
| Fewer errors
| Reduce re-keying of information by providing single data entry facilities for multiple systems; provide a central shared database to ensure everyone is working off the same data at all times; eliminate paperwork by providing online forms; prevent things from falling through the cracks through automated notification of missed deadlines; deal with problems earlier by automating red-flag reporting through monitoring. |
| Faster processing
| Improve visibility of commitments so decisions aren’t delayed due to missed commitments or poor coordination; reduce miscommunication by keeping the right data, making it always available, and by making changes immediately visible; reduce lag time by automatically notifying the next person in a workflow to start a process. |
| Greater customer satisfaction
| Build highly customized solutions for each client; respond faster to customer queries by making information easy to find; offer customers self-service; automatically keep the customer informed through automated notifications; identify problem trends earlier through tracking and threshold reporting. |
| Increased innovation | Gain insight by unlocking and re-mixing information in new ways; make it easier and less costly to try new ideas; free up more time for users to use for innovation. |
| Increased agility | Dynamically assemble new applications and bring them to market quickly. |
| Improved attention allocation | Reduce the need to do constant followup by using automated notifications; reduce the need to search for information – make the information come directly to the user when they need it; reduce the amount of clutter the user needs to push through to get the exact information they need. |
| Automated compliance | Automate logging for compliance purposes. |
| Faster time to market | Bypass traditional development methodology for certain types of applications. |
| Increased employee satisfaction | Reduce stress through automation; provide software that is better suited to each users needs; provide users with the ability to create their own solutions; provide easier access to enterprise and Web data for use in their jobs; better coordinated teamwork. |
| Increased competitiveness and market share | Through greater customer satisfaction; more innovative solutions; made-to-fit services. |
The SA mindset
Situational applications require a different mindset to traditional application. Without this, it is easy to limit what can be achieved. This section explores what the situational mind set looks like.
|
| Traditional applications | Situational applications |
| Focus on “good enough” | The formal methodology of traditional applications favors a “big bang” approach – getting all the requirements, then programming, etc. | The goal is to produce something “good enough” of value as soon as possible and refine it later if needed. |
| Embrace incrementalism | Because the overhead of starting up an IT project is so great, it only makes sense to tackle large projects with a significant payback. | A situational application is never going to have the impact of a single application, like ERP. But the incremental impact of a multitude of small situational applications can result in geometric growth in productivity. |
| Embrace messiness | Messiness is the scourge of IT.
| Highly adaptable systems look sloppy. There is no point in wasting resources and energy trying to make something look beautiful if it’s not going to be around for very long or is going to change all the time. |
| Use simplifying assumptions | Because of the time and cost involved, there is a need to try anticipate the needs of “any” user and anticipate every contingency. | Because a SA is aimed at a very specific target audience, assumptions that simplify the application can be made e.g. building applications without a lot of security, authentication, etc. because it will be used by a small user community who know and trust each other. |
| Get personal, don’t personalize | A significant amount of time and effort is put into both making a system generic as well as providing a way to “personalize” it. This makes the application much more complex than if it were written for a specific use. | A SA doesn't need to be personalized - it is personal from its inception. The application's lack of generality or completeness, communicates that “this was built this for you". |
| Re-evaluate triviality | Many applications can be built that before would have been considered “too trivial” to automate (for example, the cost of automating was too expensive, it only affected a small number of people, it only happened a few times a month, the process changed too often, or the window of opportunity was too small). | Many applications previously considered too trivial to build now become feasible. Their relative value is enhanced by the significantly lower cost to build the solution. |
| Re-think ROI | Because of the significant cost involved, calculating ROI is essential. | The cost of justifying the return on investment for developing small services will, in many cases, be more costly than developing the service in the first place. For example, no one would do an ROI for a spreadsheet. |
| Embrace change | Change is the enemy of traditional applications. Requirements are frozen in time, and are only changed with great reluctance, because change creates a cascading affect across the various roles involved in the process (QA, documentation, etc.). | Solutions are recognized from the start to be temporary and are treated as such. The system can be made to respond to any situation. There are few negatives to implementing change |
| Underprescribe | The tendency in traditional development is to overprescribe – to think of all the possible exceptions and variations that might occur and cater for them when the system is written. This is important for applications where efficiency is key. | Most business processes involving knowledge workers are fluid and adaptable, so they cannot be too restrictive. This would also likely encourage rigidity due to a lack of desire to change the things needed to deal with exceptions. So the goal is to keep SAs “elegantly minimal”—to create “elbow room” for local interpretations and innovations. |
| Be specific | To help justify the cost and to try reduce the chance of changes later, every conceivable scenario needs to be considered. | Build for a very specific set of users and features. |
| Seek success | Traditional applications by their nature are focused on seeking to avoid failure and are concerned about keeping things status quo. | By being able to easily adapt, SA’s are focused on seeking success and finding new, better ways to perform tasks. |
SA methodology
Ideally, SAs should be developed by the users themselves.
But while this is feasible some of the time, there are many times when building the application is beyond the interest, time available, or ability of the user.
In these cases, it makes no sense to revert back to the traditional development methodology. What’s needed is a methodology that takes advantage of the strengths of SA’s and builds on them.
The limits of end user development
- Many users are simply not interested in building their own applications.
- Even those that are interested often won’t do it because they would rather spend time building their chosen career.
- There is a big gulf between users building spreadsheets and being able to write meaningful applications.
- Users who try to build their own applications may never be able to get to the aha! moment that often needs to take place when building a software solution. This may be because they are too deeply involved in their subject to be able to abstract it or they may not be capable of clearly expressing what they do – at least in clear enough terms that can be used to build an application. But the most common reason is that understanding database relationships is hard to do.
The Situational Application Analyst (SAA)
A solution to this problem is to create a role of Situational Application Analyst (SAA). The SAA would help translate a users requirement into system terms, model the data needed to support the application, and help translate complex business logic. The SAA could also work with IT on behalf of users to secure access to corporate data as needed.
A SAA could be a power user, an analyst, or high-level developer. But the role of SAA could become more defined in its own right as SA’s start to take hold.
The SER model
- The SAA would also basically “seed” the application with the user. They would help the user put the first version in play.
- The user(s) would then evolve the application any way they like.
- There may be a point during this evolution where the SAA needs to get involved once more to “reseed” the application. Reseeding is necessary when evolutionary growth no longer proceeds smoothly. It is also an opportunity to organize, formalize, and generalize information and application functionality created during the evolutionary growth phase so that it can be found and shared with others. [5]
Further Reading
General
Long Tail Software
- The long tail of software. Millions of markets of dozens.
- The forces of long tail software and services
- The Long Tail of Software
IBM and Situational Applications
- SOA meets situational applications Part 1: Changing computing in the enterprise
- SOA meets situational applications Part 2: Building the IBM Situational Applications Environment
- SOA meets situational applications Part 3: Examples and Lessons Learned
- Changing the corporate IT development model: Tapping the power of grassroots computing
- Changing the corporate IT development model: Tapping the power of grassroots computing - References
References
- The term “situated software” was coined by Clay Shirky in an article of the same name. He described situated software as software designed in and for a particular social situation or context. The term has morphed into “situational” applications.
http://www.shirky.com/writings/situated_ software.html - http://www.ibm.com/d
eveloperworks/webser vices/library/ws-soa -situational1/?S_TAC T=105AGX04&S_CMP=ART - http://bnoopy.typepa
d.com/bnoopy/2005/03 /the_long_tail_o.htm l - J. Sapir, Igniting the Phoenix: A New Vision for IT, Xlibris Corporation, Philadelphia, PA (2004).
http://www.amazon.com/Igniting-Phoenix-V ision-Jonathan-Sapir /dp/1413436994 - http://l3d.cs.colora
do.edu/calendar/atta chments/2008.02.13-f ischer.pdf - http://www.ibm.com/d
eveloperworks/lotus/ library/mashups-web/ index.html - http://blogs.zdnet.c
om/Hinchcliffe/?p=45
Dave
Invite as author
Coghead Applications