Saturday, January 27, 2007

When Does AJAX Make Business Sense?

Hard-nosed executives recognize that there are costs associated with any benefit. To convince today's upper-level decision makers to approve strategic investments, they need to hear more than phrases like "essential to the business," "the results are too unpredictable," and "yields intangible benefits." In the world of Web development, the move from HTML to AJAX-powered HTML can often be achieved at a relatively low cost, but there are both direct and indirect costs associated with AJAX that must be taken into account. A close analysis of these factors will enable business managers to make more well informed decisions when considering AJAX adoption in a particular application and across their organization.

Let's look first at the expected benefits from AJAX.

AJAX is all about ways to create a more interactive and productive connection between a user and a Web-based application. Because AJAX provides similar advanced user interface features to those in desktop applications (such as advanced UI controls, animated effects and adjustable layout controls) ­ thereby providing the visual and interaction tools needed to make the application self-explanatory ­ users spend less time learning and operating the application. The AJAX partial page update feature minimizes user delays by eliminating the "click, wait, refresh" approach of pre-AJAX HTML applications.

Beyond better user interfaces for existing applications, AJAX enables new classes of applications that fall under the umbrella term Web 2.0 that also fit into a Service Oriented Architecture (SOA). Among the next-generation applications that will power the enterprise and the Internet of the future are the following:

* Users as co-developers: New AJAX-powered environments, such as application wikis, are empowering users to create their own customized mashups including personalized dashboards and situational composite applications.
* Collaboration: AJAX technologies are typically the centerpiece of Web 2.0 information collection and sharing environments that harness the collective intelligence of disparate communities.
* Software above the level of a single device: Web 2.0 is accelerating the movement from installable desktop applications to Web-based applications, thereby leveraging the advantages of networks and information sharing.
* Cross-device applications and mobility: Simultaneous with the adoption of Web 2.0 is the growing proliferation of Web-capable mobile devices. AJAX technologies enable Web 2.0 applications across both large-screen desktops and small-screen mobile devices.

AJAX often boosts developer productivity. There are many AJAX technology providers, including both commercial products and open source initiatives. As a result, developers will find the off-the-shelf components, toolkits, frameworks, educational materials, and other resources they need to produce and maintain next-generation Web 2.0 applications built with AJAX. And due to open source alternatives, AJAX provides zero-cost deployment options as well.

Because of competitive pressures, vendors often vie for your AJAX business based on the developer productivity benefits they offer. Two common productivity features are UI markup languages (UIMLs) and IDE integration. The UIMLs allow for the use of declarative approaches using HTML and/or XML for large parts of an AJAX application. IDEs can provide source code completion, source code highlighting, drag-and-drop authoring, JavaScript debugging, XHR monitors, runtime stack views, and variable watching.

AJAX and SOA need each other so both can reach their full potential. SOA's encapsulation of business functionality into discrete services with well-defined Web Service interfaces makes it easier for AJAX toolkits to facilitate the creation of Rich Internet Applications (RIAs). AJAX applications need to leverage business functionality, but, in the absence of SOA, AJAX toolkits must have myriad adapters supporting disparate technical means of accessing that functionality. The more that SOA advances, the more the toolkits will be able to streamline access to business functions by supporting Web Service client technology. Thus, SOA helps move AJAX forward.

Conversely, AJAX helps SOA move forward. We need RIA technologies to be able to exploit and justify the significant investment that SOA entails. The ability to create mashups, dashboards, and composite applications relatively rapidly to respond flexibly to changing business conditions is the essence of the ROI that we expect from investing in SOA.

In addition, AJAX deployment offers several long-term strategic benefits including:

* Replacement for desktop applications: AJAX offers a desktop-like user experience while retaining the benefits of server-based application deployment, centralized infrastructure administration, easier scalability, and immediate availability of application updates to all users. As a result, AJAX helps accelerate the movement away from installable, two-tier, client/server applications to multi-tier Web applications.
* Higher customer expectations around the user interface: The industry is embracing richer, more desktop-like, user interfaces for customer-facing Web applications. In many circumstances, adopting AJAX techniques is becoming a business requirement to maintain parity with the rest of the industry and match growing user expectations about Web-based user experiences.
* Operations efficiencies: In today's global economy, cost efficiency is more important than ever. AJAX techniques can help maintain the efficiency and competitiveness of internal systems.

What Are the Costs Associated with AJAX?
The costs for adopting AJAX depend on the circumstances of the application you're developing. In cases where AJAX snippets are added to existing HTML applications in an ad hoc manner, the incremental costs can be small. On the other hand, if the AJAX deployment strategy requires significant retooling of the existing IT infrastructure and substantial staff re-training then costs obviously go up.

It's also important to keep in mind that AJAX techniques require developers to learn techniques on both the client side as well as the server side.

On the client side, developers may have to familiarize themselves with one or more AJAX client-side toolkits, along with programming techniques for incremental DOM updates, XHLHttpRequest-based client/server communications, and asynchronous communications event handling. Most of these techniques require incremental knowledge on top of existing expertise with HTML and JavaScript.

On the server side, re-education requirements depend on the AJAX toolkits in use. For some toolkits, developers may have to familiarize themselves with the AJAX toolkit's UI markup language and its server-side AJAX APIs.

Most AJAX applications leverage an AJAX framework but still require some level of customization by the development team. A key factor in calculating the cost of adopting AJAX is the amount of customization work required to complete the task. If the AJAX framework's built-in features are sufficient for your needs then your AJAX development costs will be lower.

For existing applications that are modified to take advantage of AJAX techniques, end users will require some re-training on the applications' new AJAX-powered user interfaces.
New Issues to Manage
Like anything else, the AJAX technique of partial data exchange can be misapplied so that server and network loads increase in an undesirable manner. So it's critical that AJAX developers are made aware of the importance of these issues and that bandwidth behavior is tested before applications are deployed.

Another concern is the misapplication of AJAX "push techniques," where AJAX toolkits enable servers to push incremental data to clients without requiring the clients to poll periodically. Developer education about these issues and pre-deployment testing of the application's network behavior are important.

With mashups plugging in third-party components there are potential security implications. It's recommended that IT managers establish a company policy on mashup products and technologies, such as only installing markup frameworks from trusted suppliers; only allowing components from trusted sources; and requiring secure gateway facilities that control the domains with which particular components can communicate.

Typically each AJAX toolkit has its own features, markup, and APIs. Long-term maintenance costs will be minimized if the application uses a popular Ajax toolkit that's familiar to a large pool of developers and by ensuring that the Ajax toolkit is OpenAjax-conformant. (See "Managing Long-Term Costs with Help from OpenAJAX.")

Other Factors To Consider
Now let's take a look at some additional key considerations in the cost/benefit analyses of adopting AJAX and determining ROI. Some important points to keep in mind include:

* Interaction and user experience requirements: If a given application requires either high levels of user responsiveness (that is, it's undesirable to use the old-style "click, wait, refresh" HTML technique) or requires a self-evident desktop-like user interface (to limit training costs) then AJAX techniques can reduce user wait time and improve productivity in a measurable way.
* Network bandwidth requirements: Applications that generate high levels of network activity often benefit from AJAX techniques by leveraging the partial data exchange and partial page update features associated with AJAX. AJAX techniques often replace full-page requests with small data exchanges, reducing network bandwidth requirements, minimizing server CPU processing, and improving response times.
* Scalability requirements: Large and/or growing user populations require scalable application deployment architectures. In such scenarios, it's critical to determine whether the AJAX-enabled application offers appropriate scalability characteristics.
* The mission-critical nature of the application: The greater the strategic value of the application, the greater the investment in RAS (reliability, availability, serviceability) required. Highly mission-critical applications may be less desirable early candidates, but offer the highest ultimate return.
* The complexity of database interaction: AJAX will be more difficult to apply where there's no good separation of back-end databases from the Web-tier application logic. Relevant questions to consider: Is the application tightly coupled to a back-end database? To what degree is transaction integrity and recoverability critical, and how do these factors relate to AJAX partial update techniques?
* The real-time nature of the underlying application: In general real-time monitoring and real-time business applications benefit significantly from AJAX, particularly the push technologies available in some AJAX toolkits.
* Systems integrator requirements: If the application requires involving a systems integrator then it's important to determine how familiar the integrator is with AJAX and the AJAX toolkits that you plan to use on the project.

Managing Long-Term Costs with Help from OpenAjax
The OpenAjax Alliance produces various specifications that define OpenAjax conformance, an industry trust mark that promotes interoperability. As OpenAjax conformance specifications emerge, customers who require compliance from their AJAX vendors will increase their interoperability, safety, and choice, and thereby help manage the long-term costs of adopting AJAX.

Conclusion
The move to AJAX is part of a business operations strategy and is often coupled with the move to SOA. Arriving at estimates of return on AJAX or SOA is a difficult challenge for IT managers and executives. IT can support and even lead the effort by providing recommendations on appropriate questions to ask the business side of the house. IT can also help generate the answers needed to estimate ROI. Establishing an IT-user team to help the business drive the direction of the AJAX effort can be a forum for confirming and refining ROI estimates. Making the leap to AJAX isn't something that can be done overnight or with the snap of your fingers. It involves serious consideration and an honest internal evaluation. But by taking all of these points into account, decision makers will be better equipped to pave the way toward AJAX adoption.

Friday, January 12, 2007

Ajax emerging as RIA alternative of choice,

Ajax emerging as RIA alternative of choice, says Burton
By Rich Seeley, News Writer
10 Jan 2007 | SearchWebServices.com

Ajax is positioned to become "a mainstream tool used by Web developers as an alternative to other rich Internet application (RIA) technologies," writes Richard Monson-Haefel, senior analyst with the Burton Group Inc. in a report released today.

In my opinion, these JSF-based approaches will remain niche players.
Jason Bloomberg
Senior Analyst, ZapThink LLC.

Organizations considering RIA options are advised in the report to begin working with Ajax as opposed to the competing technologies including Adobe Flash, Java applets, Microsoft's Windows Presentation Foundation/Everywhere (WPF/E), Mozilla's XML User Interface Language (XUL) and Scalable Vector Graphics (SVG). However, Monson-Haefel does predict that Flash will be the choice for applications that require sophisticated animation as he finds it unlikely that Ajax will evolve to provide those capabilities.

"The principal advantage of using Ajax over other RIA technologies is its seamless integration with Hypertext Markup Language (HTML)," the Burton analyst writes. "Rather than being isolated to a box or a page component, Ajax functionality mixes well with HTML, allowing rich graphical user interface (GUI) capabilities to be incrementally added to existing Web sites without having to re-implement content."

Another advantage of Ajax, according to Monson-Haefel is that it can be used with "just about any application platform that supports the Hypertext Transfer Protocol (HTTP)." Ajax is compatible with PHP, Perl, Active Server Pages for .NET (ASP.NET) and Java 2 Platform, Enterprise Edition (J2EE), he notes.

The Burton report, "Ajax: A Rich Internet Application Technology", recommends that organizations take an incremental approach to implementing Ajax recognizing that while most of the technologies involved have been around since the 1990s, commercial tools for Ajax development are not yet mature.

While the report aims at organizations looking to dip their toes into Ajax, it notes that sophisticated Web developers are already making use of the technology. As sophistication grows, Monson-Haefel predicts more integration with the Adobe Flash products for streaming content and animation.

He notes that Ajax "is not as mature as Adobe Flash and has historically been viewed as a complex approach to RIA development." The reliance of Ajax on JavaScript, which not all Java developers are familiar with, has meant that advanced Web developers have been the primary audience for Ajax. However, he notes that is changing with "Ajax-enabling frameworks such as Java Server Faces (JSF), as well as Ruby on Rails, Struts, ASP.NET and PHP, which make it easier to do Ajax without being a JavaScript programmer.

On the JSF front, vendors are making progress, says Ted Farrell, chief architect and vice president of tools and middleware, at Oracle Corp. He notes that his company, along with Sun Microsystems Inc. and IBM, all now have implementations of JSF that developers can use with little or no JavaScript coding in their Ajax applications.

"As tool vendors, our design time has gotten better for JavaServer Faces," Farrell said. "I think we got smarter over the last two years in making components, shaping them to be simpler for the user rather than having them be complicated. So there's a combination of the components getting better and the tools getting better having lowered the barrier for people to start using and being successful with JavaServer Faces. applications."
For more information
Check out our Ajax Learning Guide

Ajax after the hype


Farrell also sees Ajax emerging as the RAI technology of choice and JSF as the way most developers can work with the technology.

"Developers don't have to learn anything new," he said. "They're still programming in JSP and JavaServer Faces like they always did. They get the advantage of being able to build rich Ajax-based applications."

However, Jason Bloomberg, senior analyst with ZapThink LLC., remains skeptical of the JSF tools.

"We've seen one other vendors tout the benefits of JavaServer Faces -- ICEsoft out of Calgary," Bloomberg says. "They also offer a JSF approach for creating Ajax apps without the need for scripting in JavaScript. An additional benefit is that it deals with cross-browser issues, but the downside is that it's a Java tool only for Java developers. In my opinion, these JSF-based approaches will remain niche players, while the language-neutral guys like Nexaweb and JackBe, as well as incumbents like Adobe and Microsoft, will become established as the leading players."

Tuesday, January 09, 2007

It’s Curtains For Portals

Tuesday, 09 January 2007

By Robin Bloor, Partner


Portals first emerged when the browser captured the hearts, minds and imagination of the software industry. With the advent of the browser, the windowed desktop was suddenly passé and the assumption was that the browser itself could become a kind of desktop. It wasn’t websites like Yahoo!, Excite, Lycos and AOL were also dubbed portals because they provided a similar kind of entry point to surfing the web.

Early portals evolved into the idea of an “Enterprise Portal” - portal software that provided a coherent access to all relevant enterprise applications, as well as to information available in the enterprise and to relevant external information services. Business users could arrange ‘portlets’ by choosing elements from a common set of interfaces to back office systems. Access to intranets, extranets and useful Internet resources could also be available. The business user could simply “pick and mix’, with a little help from IT.

It Was Never Going To Work

This idea was never going to work because there were too many business applications that portals could not accommodate (Windows and client/server apps, AS/400 apps, old mainframe apps, etc.) It was never going to be possible to convert all of those applications to have browser front-ends before the browser front-end itself changed. Here we are in 2007 and it has changed. Everybody’s talking about Web 2.0; Web 2.0 is certainly not your elder brother’s browser interface.

The portals that have been built and implemented are usually half-solutions at best. The rug is being pulled from under them because Web 2.0 is promising a shiny new GUI and portals are already beginning to look like something the dog won’t eat.

It Was All Wrong Anyway

In my opinion, portals were a wrong idea from the start. The crux of the matter is this: When you want to use some sort of access device, be it a desktop or a laptop or a PDA, you want either to navigate to stuff or do stuff. In a sane and secure world, you need to authenticate who you are before you can do anything. Authentication requires some kind of ID management software. If there were such a thing as a “portal” it should have a deeply intimate relationship with an ID management system that would ultimately allow the user to invoke permitted applications. So far so good - we might just be able to imagine a portal that does that - I believe that Sun has such a product.

But the next requirement simply blows everything away. The “portal” needs to be able to present a workable interface on whatever access device is being used (or possibly, refuse to execute because it isn’t possible) for whatever service has been requested.

For this, you need much than just a browser. You actually need a whole Service Oriented Architecture. What we are gradually uncovering here is a whole set of presentation services that needs to include identity and security services, messaging services (both for work flows and communications), interface presentation and translation (possibly dynamic) and probably, registry-based navigation.

And that is why it’s all over for portals; portals are miles away from being able to fit into SOA. Even if Web 2.0 wasn’t making them look terribly long in the tooth, they’d become an embarrassment when you tried to integrate them into a Service Oriented environment. It’s time to close the door on portals, and tiptoe quietly away.

Sunday, January 07, 2007

The SOA Forecast for 2007

Document ID: ZAPFLASH-200713 | Document Type: ZapFlash
By Ronald Schmelzer
Posted: Jan. 03, 2007

For those in the United States, 2007 has started out with a bang – two major snow storms in the Rocky Mountains and a persistent warm front that’s keeping the entire East Coast in unusually warm weather for this time of year. Even more so, it’s football season in the US and both the New England Patriots and Baltimore Ravens are in the playoffs – the two teams representing ZapThink’s two office locations. Of course, speaking metaphorically, with regards to SOA, 2006 ended with a bang and 2007 is already showing considerable warmth and competitive vigor. ZapThink has seen SOA take off even more aggressively than we anticipated at the beginning of 2006, and all indications show that SOA strength will be further reinforced and expanded in 2007 to many corners of the IT environment, throughout the world and in many different industries. And so, during this season of sultry winter weather and competition, it is time to evaluate our predictions from the previous year and forecast th e architectural and competitive climate for SOA in 2007.
2006 SOA Predictions: Four for Four!
In last year’s 2005 SOA Scorecard and 2006 Predictions ZapFlash, we predicted that companies would move beyond their tentative SOA projects to more substantial projects leveraging emerging best practices for all aspects of the Service lifecycle. More specifically, we bemoaned the fact that companies were thinking too much about having a bunch of Services (so-called “ABOS”) and not enough about an architecture oriented towards the ongoing evolution of those Services. We surmised that companies would soon wake up to the fact that SOA demanded true enterprise architecture activities, artifacts, and skills, and less-so just rote software development and technology implementation. Indeed, we believed that one side-effect of the maturation of SOA projects was that companies would finally give proper emphasis to the use of a registry/repository throughout the Service lifecycle, effective Service lifecycle manage ment, and a comprehensive IT governance framework. We predicted that an emerging set of next generation SOA projects would put some enterprises in technology leadership positions, and indeed, it seems that all of those predictions came to pass in the year preceding.

Continuing on the thread discussed earlier with regards to maturing SOA implementations, we also predicted the SOA governance space was ready for a major shake-out and consolidation. Boy, were we right on target! 2006 bore witness to the frenzied acquisition of all things governance and registry related as well as the emergence of Service lifecycle vendors as the next must-have technology in any SOA infrastructure portfolio.

Our next prediction was that emphasis would shift from being solely Service provider centric to an increase in awareness, and implementation, of Service consumer-centric tooling and methodologies. For sure, 2006 emerged as the year that Ajax moved from being an acronym to being a metaphor to all things Service consumption-centric that enhanced the browser experience as a first-class environment for user interaction. But even more so, 2006 saw the emergence of real Service consumption and composition tools that aimed to facilitate the creation of Service-oriented Business Applications (SOBAs) and Enterprise Mashups that free the consumer-focused developer from having to worry about the location and implementation details of the Services they consume. Indeed, have we already reached the Web Services Tipping Point?

Another prediction we made last year was that regulatory compliance would take center stage in 2006. Specifically, we said that there would be a dramatic increase in the number and capability of SOA-based compliance solutions coming to market in 2006. Some of these solutions may be in the form of composite applications, while others may simply be sets of Services. Either way, SOA will become increasingly critical to many enterprise's compliance initiatives. The result was more compliance-focused SOA initiatives than we have fingers on our hands to count! Multi-national firms in particular found that compliance with global regulations that continue to change at relatively unpredictable rates has, as a result, an unpredictable burden on their IT departments and thus they must find a way to grapple with such external change factors. ZapThink released a survey of SOA consulting firms in mid 2006 with the main finding th at SOA itself is a hard sell for most companies, but a focus on selling solutions to common business problems, of which solving compliance problems is a key one, is a cake-walk.

2007 Prediction #1: SOA Quality and Testing Market the Next Must-Have Space
So, it seems that we were right on target with our 2006 predictions. Maybe they just were too obvious when we made them at the end of 2005. So in this iteration, we’ll try to make some predictions that are less so, or at the very least might be up for debate. One prediction is that the new, hot area in the SOA marketplace are testing and quality tools and solutions for SOA. While SOA-focused testing and quality vendors have been around for at least five years (we first covered them in our Web Services Testing report in 2002), the impetus for widespread adoption of testing across the full Service lifecycle hasn’t been there for much of that time.

However, that is set to change in a big way in 2007. Now that companies are through with their proof-of-concept and play phases of Web Services-centric adoption (less SOA and more ABOS), they have to grapple with the real issues of evolving SOA: change and version management, testing in a production environment (runtime testing), quality assurance of all SOA artifacts including contracts, policies, schema, models, declarative composition and process metadata, and other forms of metadata, as well as deal with change-time and run-time governance that demands more than simply testing the code that exposes a Web Services interface. As a result of this heightened awareness of the real challenges in maintaining a SOA implementation, demand for SOA quality and testing solutions will skyrocket in 2007, leading to greater acquisitions, increased consolidation, new venture creation, and boatloads of case studies on the topic. Watch this space for the real action.

2007 Prediction #2: Enterprise Architect Drought
One dire prediction for 2007 is that there simply won’t be enough qualified and SOA experienced enterprise architects (EA) around. Sure, there might be many “paper architects” – that is, those that claim EA and/or SOA skills on their resumes or in their career history, but much of that experience will be attendance at a few vendor-heavy SOA courses, the development of Web Services-centric interfaces, and a sore lack of any methodology, modeling, Service lifecycle, or governance experience to speak of. Yes, it might just be that the biggest force gating widespread adoption of SOA is not the technical complexity of SOA projects (one can actually say that the technology part is relatively trivial), but rather the organizational, architectural, and skill gap that most companies have in making this architectural change a reality.

ZapThink has seen first-hand evidence of this lack of EA skills. First, there is a significant demand in the marketplace for experienced SOA talent. Second, we are seeing a burgeoning of SOA consulting companies that offer kick-start approaches to SOA in which they supply the experienced architects and their customers supply the heavy-lift labor to implement the Services. Already we’re starting to see a bifurcation in the IT community between architect and developer, with development seen as an increasing commodity whereas architecture is an increasing scarcity.

ZapThink is doing something about this lack of EA talent. In fact, we’re doing two big things about it this year. First, ZapThink launched its Licensed ZapThink Architect (LZA) program in late 2006 with little fanfare, but we are planning to trumpet its increasing value and successes with greater volume throughout 2007 and beyond. While certifications do exist for aspects of SOA, they are usually specific to a particular technology du-jour or an individual vendor implementation. Increasingly, individuals are looking to go beyond understanding of what SOA is and dive much deeper into how to do it right. The demand is thus more than just training, but also the backing of a qualified third-party organization to endorse their existing SOA skills, enable continuous improvement, enhance networking in the community, and enhance their current SOA-enabled careers. ZapThink is filling the unmet need for knowledge and credentials in th is area with its new LZA program. You’ll see increasing references to the LZA program throughout 2007, and you can dive deeper into details at http://www.zapthink.com/lza.html.

In addition to the LZA program, ZapThink will release within the next week or two its Architect Resource Center (ARC), a partnership with recruiting firm Excel Partner to list qualified EA and SOA resources on the ZapThink site to meet the needs for SOA resources. Indeed, ZapThink is now in the position to directly help end-user firms hungry for SOA talent, through our new ARC offering, and if our prediction comes to pass, we’ll probably find more demand for such resources than even we have the capacity to supply.

2007 Prediction #3: The SOA Suite Busts a Few Buttons… Open Source the Remedy?
The final prediction ZapThink will stick its proverbial neck out to make for 2007 is that the SOA suites might get a bit too big in 2007. Warren Buffet is fond of saying, “don’t ask a barber if you need a haircut”. What he means to say is that vendors of a service or a product have a self-interest in promoting the need for products that probably won’t keep you away from their sales department for long. While there’s no doubt that SOA vendors are solving real problems with products that, in many cases, actually work, the problem is that these SOA solutions have grown from individual, point-products that solve discrete SOA problems to gigantic SOA suites that seem to be every bit the monolithic platform that they had been intended to replace. In fact, we have been quoted as saying that monolithic SOA platforms, in which you have to buy all the various parts of the solution in order to get the true value as promised by the vendor, is at its core an un-SOA philosophy.

The idea of SOA is to promote loose coupling and composition in an environment of continuous change and heterogeneity. A proper architecture should be blind to the underlying runtime infrastructure, messaging protocol, or application server environment. Want to implement SOA on a Commodore 64 and COBOL-based mainframe environment using CORBA over a token-ring network? Knock your socks off – there’s nothing un-SOA about that. But saying that you need to use a single messaging bus, Service container environment, or management infrastructure to get any value out of SOA is being disingenuous to the SOA mindset, and a disservice to end-users looking to finally take control of their own IT environment.

One potential antidote to the vendor indigestion that many end-user firms are experiencing is the burgeoning of open source efforts that take a laissez-faire approach to technology implementations. ZapThink is starting to see increasing use of Apache and a multitude of other open source technology underpinnings for a variety of the runtime and design-time aspects of SOA, including Service exposure, messaging, composition, rich client, and even security and reliability offerings. The Eclipse Foundation has really hit a stride with regards to dominating the development landscape for many SOA efforts. While it would be hard for us to say that such open source efforts would crimp the businesses of the well-established software vendors, it is clear that those efforts are not outlying or rogue efforts proposed by small departments of large firms or by small companies. Rather, it is precisely the behavior of many large software companies that is encouraging or forcing the han d of large companies to seriously consider open source Pepto-Bismol for their vendor-induced heartburn.

The ZapThink Take
In addition to the above predictions, one significant observation in 2006 is the state of global adoption of SOA. Is the United States behind the rest of the world with regards to SOA adoption and maturity? Probably not, but it certainly isn’t ahead. Indeed, most of the largest, advanced, and oft-quoted examples of SOA projects in both the press and by software vendors in 2006 were in Europe, Canada, Asia, or Australia. There’s so much to analyze and understand in the trends towards global SOA adoption that we’ll leave this topic for a future ZapFlash, but rest assured this IT movement is unlike most others with respect to adoption.

There are probably a few more predictions we could make for the year, but we’ll be brief for the sake of your reading time and also so that we have more material for future ZapFlashes. Regardless of where you think SOA is heading, it’s clear we’ve crossed some sort of chasm with regards to SOA adoption. More companies than ever are already supposing that they’re going to Service-orient their systems and businesses , and this is resulting the growth and value of SOA throughout the world. ZapThink wishes you all a wonderful, healthy, and rewarding 2007!

Tuesday, January 02, 2007

SaaS in 2007: It’s about services, doh!

Good post by Phil Wainewright


In my trio of predictions for SaaS in 2007, I've saved the biggest trend till last. The coming year will see a growing acknowledgement that SaaS is just part of a wider move towards Internet-based automated services. This is such an all-embracing trend that it will drive several other sub-trends, each of which can be turned into a prediction of their own. All of these emerging phenomena will be signs of the wider underlying trend taking hold.

More acquisitions of SaaS vendors by business service providers. I already highlighted several examples during 2006. The most telling was ADP's acquisition of Employease in August. As I said at the time, this wasn't a case of ADP moving into the SaaS sector:

"… it's merely extending into new areas of automated business services — and that's what the on-demand revolution is really about — using software to do a better job of operating automated business services."

Proof that this wasn't just a one-off came in testimony from Progress Software's SaaS partner ecosystem, which as a result of acquisitions now includes US Bank and legal and business information provider LexisNexis. Then in November, American Express Business Travel made a $22.5 million investment in Rearden Commerce alongside the launch of Axiom, an AmEx-branded 'intelligent online marketplace' based on Rearden's hosted employee services platform. My verdict on the deal:

"American Express is the grand-daddy of business service providers and so the alliance with Rearden both reinforces and further validates the trend."

The acquisition trend will accelerate in 2007 as business service providers recognize the potential of SaaS solutions to enhance and modernize their service offerings, extend their market reach and enrichen their profitability.

An expanding universe of partnerships between SaaS vendors and other online service providers. The flipside of business service providers acquiring SaaS capabilities is that SaaS vendors will increasingly package online services into their offerings. Discussing this trend in November, I mentioned examples from Landslide and Winweb, two vendors serving the small business market that bundle optional virtual assistant services with their on-demand applications. I noted that:

"…these solutions focus on live business results that really matter to their customers. They're not selling software, they're focusing on what customers actually want to achieve."

Another example is Klir Technologies, which aggregates information from vendor support databases and industry publications into its on-demand systems management application. This means that when users get an alert of a problem, the application can automatically retrieve relevant background information, cutting the time it takes to identify and implement a fix.

During the course of the year, this 'mashing up' of on-demand software and other virtual services will make the term SaaS increasingly redundant. Software in itself 'as a service' is not where we're headed. It's just services, with software as just one of several supporting enablers, and the Internet as another.

Convergence of Web 2.0 with SaaS and SOA. Look at any well-known Web 2.0 provider — Flickr, 37Signals, YouTube, Skype, Feedburner — and one thing they all have in common is that they're hosted services, resident on the Web. Of course, no one calls them SaaS, in part because this mode of delivery is taken for granted in the Web 2.0 arena, and in part because, although they rely on some pretty powerful and innovative software, what they deliver is a complete usable service, not just a raw software tool. In this context, SaaS is just the software industry's way of catching up with what Web 2.0 represents: a move towards using Web-resident software to deliver the services that people want to use.

A separate but related development in the enterprise software world is a move to what's called service-oriented architecture (SOA), which is a way of designing software infrastructure as a set of autonomous on-demand services. As Microsoft's Gianpaolo Carraro and Fred Chong have written, this enables a composition layer where services can be assembled into applications as required. Those services will typically come from inside the enterprise, but it's just as easy to include services from external providers and fold them into the mix.

Whether they're internal services or external services, Web 2.0 mashups or enterprise 1.0 legacy applications, the overriding trend I'm highlighting here is that It's all about services:

"… Some of the services are like components. Others are like applications. A further bunch are like Web 2.0 information feeds and mashups. Another set are more like semi-automated business services that deliver real-world business results, such as shipping an order or transacting a payment. The common unifying factor here is a services idiom, in which providers autonomously deliver results according to contracts. That describes SOA and SaaS and Web 2.0."

Aggregation as the new competitive battleground. One of the least appreciated strengths of the on-demand model is its ability to leverage shared services. When hosted systems managemnt vendor Klir Technologies launched in September, one of the things that fascinated me was its use of the shared services model to slash the cost of keeping up to date with manufacturers' device interfaces:

"For every application or class of device that Klir supports, it writes code to query the standard interface developed by the manufacturer, and then it hosts that code in its data center. Because of its shared services architecture, that code is instantly available to all its customers. That’s it. No messing about with agents. No deployment delays. It’s compelling because you can imagine how many applications and devices there are in the world, and how often a systems management vendor has to develop, distribute and deploy new agents because some application vendor or device maker has decided to upgrade their new systems management interface. Klir’s shared services, standard-interface, no-agent model allows it to implement support across its entire customer and prospect base for any new interface, within just a few days of that new interface appearing."

As I noted above, Klir also leverages links to third-party information sources, with similar economies of scale.

This ability to aggregate shared services is absolutely core to the on-demand model, and it was interesting that the ability to integrate different services came up as one of the most important future themes when SaaS CEOs discussed What's next for SaaS at the recent SIIA OnDemand Summit:

"There's clearly a shared belief that integration will happen through some kind of hub — though no clear view as to whether that hub will be a platform, a marketplace or a customer-facing aggregator. The inherent risk here that vendors have to be wary of is the potential to become dependent on — and perhaps at the mercy of — an intermediary who takes control of the customer relationship. Several vendors were evidently alive to the flipside opportunity this represents of themselves becoming the hub that others depend on."

One of the most critical challenges for vendors in 2007 and beyond will be winning the race to aggregate shared services in the way that best meets their customers' needs while securing the vendors' own competitive position. There are many aspects to get right, including technology, choice, positioning and pricing. It will probably take more than a single year before a definitive outcome begins to become clear and we can judge who the winners finally are. One of the most interesting contention points will be getting the balance right between predetermined aggregation by the vendor or by its ecosystem partners and on-demand aggregation by the end user (especially in the context of client-centric aggregation platforms, which I touched on in my previous SaaS in 2007 posting).

Emergence of the on-demand business. Concluding my recent definition of SaaS, I wrote:

Essentially, this is just a new spin on business services, which is something we've had since before the advent of the Internet, or even of computing itself. It's business services, automated by software and connected up by the Internet.

The corollary of having a new way of delivering business services is that businesses can organize themselves and operate in innovative new ways. Fellow-ZDNet blogger Joe McKendrick has called this the loosely coupled business. It's now possible to set up in business using on-demand services and Internet-based communications without having any of the bother of acquiring premises, staff, manufacturing plant or distribution facilities.

This goes way beyond business process outsourcing, in the same way that SaaS has gone way beyond application outsourcing. Thinking in terms of outsourcing internal capabilities retains the old mindset of a monolithic corporation. It's not BPO, it's about contracting for services, and being able to do so for services that previously could only realistically be performed internally.

This change in how businesses are built and operated parallels the change that's taken place in manufacturing over the past two decades. A hundred years ago, the norm was for a manufacturer to custom-build every component that went into any of its products. Ford even smelted its own steel and generated its own electricity. Today, look at your mobile phone, assembled from parts manufactured by a myriad of different suppliers, relying on intellectual property contributed by dozens of different patent holders, each of whom earned a royalty when the phone was made. Today's world is built on connections, and the on-demand business is one that successfully exploits those connections to deliver the service its customers demand economically, efficiently and profitably.