Over the last few years, SOA has found increasingly broad acceptance and emerged as the dominant enterprise architecture to support business transformation by providing tighter linkage between business processes and enabling IT. Much has been written both about the successful SOA implementations and about the obstacles to the adoption and successful realization of SOA.
While enterprises were defining and undertaking their SOA initiatives, the recent rise of grassroots computing among both professional programmers and knowledge workers highlighted a different development approach. In this approach, those who best understand the business problem at hand develop rapid solutions without the overhead and formality of traditional IT methods. The new breed of situational applications (SAs), often developed by amateur programmers in an iterative and collaborative way, shortens the traditional edit-compile-test-run development life cycle. SAs have the potential to solve immediate business challenges in a cost-effective way, capturing the part of IT that directly impacts end users and addressing the areas that were previously unaffordable or of lower priority.
This series of articles about SAs covers the following topics:
Part 1:
- Learn about usage patterns and technologies that contributed to the current rise of community-driven SAs development in the enterprise, and compare and contrast it with more traditional, corporate-focused SOA initiatives.
- Examine life cycles, technologies, and social aspects of each.
- Discover how you can use SAs in an enterprise to improve the state of corporate computing.
- Learn about the IBM SAE, which was built to let individuals and small teams create ad hoc composite applications to address their immediate business needs.
- Explore enterprise changes required to build such an environment and the challenges you must address while building it, including access to enterprise data, and privacy and security concerns.
- Check out some lightweight development tools.
- Analyze several SAs selected to represent a wide variety of business challenges that SAs are leveraged to solve. Some of these commonly occur across lines of business (LOBs) and are of general interest. Others are LOB specific, yet with typical challenges that can be successfully addressed by an SA.
- Learn about obstacles the authors had to overcome for each of these applications, and get an architectural overview of the resulting solution and the enabling technologies, tools, and techniques used.
- Understand the tangible business results achieved, best practices, and lessons learned with each of the SAs.
The rise of Web-based situational applications
Clay Shirky's essay titled "Situated Software" (see Resources for a link) describes a type of software that "is designed for use by a specific social group, rather than for a generic set of 'users.'" He argues that "most software built for large numbers of users or designed to last indefinitely fails at both goals anyway."
The loosely accepted term situational applications describes applications built to address a particular situation, problem, or challenge. The development life cycle of these types of applications is quite different from the traditional IT-developed, SOA-based solution. SAs are usually built by casual programmers using short, iterative development life cycles that often are measured in days or weeks, not months or years. As the requirements of a small team using the application change, the SA often continues to evolve to accommodate these changes. Significant changes in requirements may lead to an abandonment of the used application altogether; in some cases it's just easier to develop a new one than to update the one in use.
The idea of end-user computing in the enterprise is not new. Development of applications by amateur programmers using IBM Lotus® Notes®, Microsoft® Excel spreadsheets in conjunction with Microsoft Access, or other tools is widespread. What's new in this mix is the impressive growth of community-based computing coupled with an overall increase in computer skills, the introduction of new technologies, and an increased need for business agility.
The emergence of Asynchronous JavaScript + XML (Ajax)—which leverages easy access to Web-based data and rich user interface (UI) controls—combined with the Representational State Transfer (REST) architectural style of Web services offers an accessible palette for the assembly of highly interactive browser-based applications.
Similar to SOA-based solutions, SAs are seldom developed from scratch, but rather assembled from existing building blocks (or consumables as we call them). Mashups are a (better known) subset of SAs. The abundance of simple application programming interfaces (APIs) and the enablement of Ajax-style Web components (for example, Yahoo Developer Network design patterns and APIs listed on ProgrammableWeb.com) have contributed to this development style's increased popularity. Even older Web technologies, such as JavaScript, have been reinvigorated as a result.
Factors contributing to the growth in popularity of Web-based SAs among knowledge workers and professional developers are summarized in Table 1.
Table 1. Contributing factors to the rise in popularity of Web-based SAs
| Factor | How it contributes to the rise of Web-based SAs |
|---|---|
| Introduction of technologies and techniques, such as Ajax, REST, Atom, and RSS feeds | Users with a lower skill base can rapidly create highly interactive applications and access data in a simple, consumable format. |
| Overall computer literacy | A larger population of users can "program." |
| SOA adoption | Users are more comfortable creating and using solutions from consumables created by others. The componentization of legacy application functionality into consumable services made it available to SAs. |
| 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 mashups 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 centrally deployed; you can use individual computers as servers. |
| Increased requirements for business agility | LOBs can't wait for long IT development and budget cycles; they need immediate solutions to their business challenges. |
Some people comment that the SOA-SA relationship is contrived. They observe that SOA is focused on providing robust enterprise-scale solutions, while SAs are do-it-yourself applications that can't scale up to address enterprise business needs.
Others see synergy between the two, as in one blog posting that describes Web 2.0 (which SAs are one aspect of) as "actually the most massive instance possible of service-oriented architecture" (see Resources for a link to this blog posting).
Our observations show that while SOA and SA have contrasting development life cycles and motivations, different usage patterns, and even dissimilar enabling technologies, they also have important aspects in common:
- Separation and exposure of legacy applications' functionality into reusable services
- Software as a service
- Composition or assembly of a new solution from distributed reusable and remixable parts
Whilst with SOA the focus of compositions is on the back end, many SAs are using the Web as a platform, often focused on composing at the consumer architectural layer, or on the glass.
Development life cycle and usage patterns
Unlike the SOA-based development that often takes many months and even years, developers of SAs expect benefits of improved productivity and functionality, and a much shorter time getting from needs identification to productive application use (time-to-value). These solutions can solve some immediate business challenges in a cost-effective way—capturing the part of IT that directly impacts knowledge workers—and addresses the areas that were previously unaffordable or lower priority for inclusion into a corporate SOA project, sometimes called The Long Tail, a term first coined and popularized by Chris Anderson (see Resources for a link). By embracing this development paradigm, IT can enable the automation of business areas that were considered too niche before.
In contrast to corporate SOA development, SAs are seen as moving targets and in a state of perpetual beta. Requirements are often suggested and even implemented by users who were not the initial authors or users of the application, demonstrating a community interest and ownership mentality that is far removed from the traditional controlled environment of the corporate application. See Table 2 for a side-by-side comparison of SOA and SAs.
Table 2. SOA and SA development life cycles
| SOA/Traditional IT development | Situational applications | |
|---|---|---|
| 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, SA usually changes to accommodate business
changes SA 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 solutions | Little or no focus on scalability, maintainability, availability, and so on |
| 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 |
The deep-seated difference between SOA and SAs is in the social aspect, a principle widely considered to be at the heart of the Web 2.0 movement (from which centrally driven SOA can also benefit). Situational applications evolve through feedback from user communities; their very existence relies on this architecture of participation. The social aspects are compared in Table 3.
Table 3. Social aspect -- differences between SOA and SAs
| SOA | Situational applications | |
|---|---|---|
| Stakeholders | LOBs' executives/corporate IT | Individual developer/self-organizing small team; user community that's formed around the SA |
| Targeted users | Large, generic group | A known individual (often the application builder) 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 |
SA builders report improved satisfaction with their jobs and the sense of "being in control." IBM market research shows that users of SAs view them as of core importance. More than half of users regard them as "mission critical" and rate them "very important" to the success of their everyday activities, their departments, and their companies (from "Changing the corporate IT development model: Tapping the power of grassroots computing," October 2007; see Resources for a link).
Now let's take a look at the technology changes (summarized in Table 4) that boosted the rise of SAs.
SAs' focus on user experience and highly interactive client applications readily reflects in its use of technologies and tools. Ajax, through its utilization of rich UI controls and access to Web-based data, enables major improvements to Web application responsiveness and performance. Ajax achieves high interactivity through only partial page retrieval from a server and refresh in a browser.
Table 4. SOA and SA technology preferences
| SOA | Situational applications | |
|---|---|---|
| Maturity | High, proven technologies | Frequent use of less mature and emerging technologies |
| Preferred technologies, architectural models, and standards | Web Services Description Language (WSDL), WS-*, SOAP, Business Process Execution Language (BPEL), Java™ 2 Platform, Enterprise Edition (J2EE), XML | Ajax, REST, Atom, RSS, JavaScript Object Notation (JSON), XML, microformats, Flash, Ruby on Rails, PHP, JavaScript |
| User interface | No focus | Emphasis on Rich Internet Applications (RIA) through use of technologies, such as Ajax, Adobe Flex, Adobe Integrated Runtime (AIR), OpenLaszlo, and XAML Browser Application (XBAP), as well as integration at the glass patterns |
| Tools | Stand-alone integrated development environment (IDE) | Browser based |
The REST architectural style, which uses Uniform Resource Identifiers (URIs) to identify Web resources, allows equal accessibility to those resources from browsers, mobile devices, server applications, linking from e-mails, and bookmarks, which makes this programming style attractive to a wide range of client applications. Because REST style services can use the Web infrastructure for caching, they can achieve quicker response times. Given that REST doesn't need to maintain communication state, you can improve the server scalability with its use—you can use different servers to handle initial and subsequent requests.
SA applicability to the enterprise
Web 2.0 communities formed in the enterprise often see corporate IT responsible for the SOA implementation as inefficient and unable to meet business needs. While many SA enthusiasts see SOA as a heavy weight, there are some striking similarities between the two (as indicated earlier in this article).
Development of both SOA and SAs are often motivated by bringing about business flexibility. Corporate IT shouldn't ignore the complementary nature of SOA and SAs; SAs make important contributions that SOA can capitalize on, including:
- User focus and participation.
- Techniques for building highly interactive applications.
- The opportunity to address areas that were considered too niche before.
By taking advantage of the enormous potential of community-based development in the enterprise, SAs can make the benefits of an SOA-enabled organization more pervasive. The opportunities are tremendous, as summarized below.
SAs empower businesses by:
- Encouraging innovation at departmental and individual levels—the knowledge worker can react quickly to the business situation.
- Eliminating frustrating miscommunication and interpretation of requirements between business and IT.
- Improving employee morale through better solutions and empowerment.
SAs improve business solutions by:
- Creating applications that are better fit to LOB problems.
- Satisfying short-term knowledge workers' needs.
- Addressing niche market (The Long Tail) requirements.
- Combining tactical SA-based solutions with the overall IT portfolio.
- Focusing on the end user and creating a rich user experience.
- Enriching IT data portfolio with unique, hard-to-recreate data that's created by individuals and small teams; they get richer and "cleansed" as more people use them.
SAs help improve ROI by:
- Shortening the development life cycle.
- Eliminating formal development activities when they're not needed, thus increasing productivity.
- Cutting the costs of the overall development process.
- Creating applications that weren't written before, because they weren't affordable.
At the same time, introducing SAs into the corporate computing environment increases challenges for the IT department, as summarized below.
IT department can view SAs as "controlled" chaos because:
- There's no formal budget; SAs are built and run under the radar of central IT.
- The architecture of participation includes users as co-developers.
- There's spontaneous development and evolution with applications being in perpetual beta.
- There's little focus on nonfunctional requirements, such as scalability, availability, and maintainability.
- Best practices of adoption in enterprises don't exist.
Integration of SAs is pushed to the edge because:
- Control is moving from applications to fine-grained services and data feeds.
- Internal and external services and data feeds are mashed inside the enterprise firewalls.
- Applications are shared on a global scale.
- Businesses must embrace the Web as a platform on which to conduct business.
Management of situational and enterprise applications is complicated due to:
- Multiple development and operations environments, such as J2EE; Linux, Apache, MySQL, PHP/Perl (LAMP); and Microsoft .NET.
- Increasingly harder end-to-end systems management in a mixed environment (for example, monitoring, event analysis, root-cause detection, and patch management).
SAs create data security, privacy, and integrity challenges, including:
- Enterprise data as an enabler; opening up enterprise data sources is a long and complicated process, involving many stakeholders.
- The ownership of unique data produced by LOBs and individuals raising data-providence questions.
- Encouraging unintended uses of SAs (formal control versus education and guidance).
Enabling SAs in the enterprise requires additional resiliency from the existing corporate infrastructure. SOA can help mitigate some of the challenges by, for example, reusing services and infrastructure created by SOA initiatives for SA management, operation, and governance.
While many IT departments are skeptical about the usefulness of SAs to corporate computing or wary of using externally developed APIs inside their firewalls, the IBM CIO office decided to unleash the use of SAs inside the enterprise. To better understand both the challenges and opportunities of adopting community-based development, the IBM CIO office established an initiative called The Situational Applications Environment (SAE). Envisioned as a living lab experiment to observe and harvest best practices, the SAE is depicted in Figure 1.
Figure 1. The SAE concept inside IBM
Share this...
Stay tuned for Part 2 of this article series, which describes the architecture and lessons learned from building this SAE. Here's a summary of early business benefits already observed:
- Collaborating communities established themselves around common business topics of interest, thus increasing reuse of assets and solutions.
- Some applications were evolved to include additional and improved features not initially envisioned by application builders. Through their comments and direct contributions, users made applications more useful to themselves and others.
- Business users' needs forced the IT department to open corporate data sources as consumable services that enabled fine-grained access to data.
- Situational development allowed LOBs to take more control in deciding which projects get done and how they are done—either with SAs or traditional development.
Leveraging SA development with SOA in enterprise computing has the potential to fundamentally transform IT's role from the solutions developer to the solutions enabler. We believe this is a required change for IT to remain relevant.
Learn
-
"Impact of
service orientation at the business level,"
from the IBM Systems Journal, gives an overview of how businesses use
componentization and a services-oriented environment to create on demand solutions.
- Read "SOA in action inside IBM, Part 1: SOA case
studies" (developerWorks, August 2006).
- "SOA
Anti-Patterns" (developerworks, November 2005)
presents a great overview of anti-patterns.
- This Web 2.0
blog entry describes Web 2.0 as "actually the most massive instance possible of service-oriented architecture."
- Read Clay Shirky's essay titled
"Situated Software."
- Get more information about The Long Tail, a term first coined and popularized by Chris Anderson.
-
"Changing the corporate IT development model: Tapping the power of grassroots computing",
provides further examination into how SAs are used.
- Dion Hinchcliffe from ZDNet offers his views on
the impact of grassroots computing
Mashups: The next major new software development model?.
- Nicholas Carr gives some interesting statistics,
and his usual interesting viewpoint, on Web 2.0 in the enterprise in his posting,
Two views of Web 2.0 in business.
- Learn more about the REST architectural style for distributed systems.
- "What
Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software"
by Tim O'Reilly, gives a great perspective on the Web as a platform and where Web 2.0 tools fit
into that platform.
- 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.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
- Get started on SOA with WebSphere's proven, flexible entry points
- Building SOA solutions and managing the service lifecycle
- SCA/SDO: To drive the next generation of SOA
- SOA reuse and connectivity
- Browse for books on these and other technical topics at the
Safari bookstore.
- Check out a quick Web services on demand demo.
- Get an RSS feed for this series. (Find out more about RSS.)
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Luba Cherbakov, an IBM Distinguished Engineer, is a technical leader in Application Innovation Services, IBM Global Services. She is a recognized expert in the architecture, design, and development of complex enterprise applications, using service-oriented and component-based methods. She is also an author, an advocate, and a contributor to the Service-Oriented Modeling and Architecture (SOMA) method (see Resources), reference architecture assets, the Architectural Description Standard, and grid computing offerings. A member of IEEE Computer Society and ACM, Ms. Cherbakov has a Master's degree in computer science from George Washington University, with a major in software and systems and a minor in artificial intelligence and simulation.
Mr. Bravery is a senior IT architect in IBM Software Group Architecture Board Incubator Projects team. He's on a rotational assignment with the IBM CIO Office as the chief architect of the Situational Applications Environment, for which he recently received an IBM Outstanding Technical Achievement award. Mr Bravery has a rich background of experience working in the emerging technology field in areas such as object-oriented programming, content management and portals, and multichannel architectures. His recent work has been around simplified programming models and Web 2.0 technologies, and how they can be applied to development in the enterprise. Mr. Bravery is a member of the British Computer Society and holds an honours degree in physics from the University of Birmingham, UK.
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
