Generally, I would venture to say any website that uses a little more interactive and dynamic technology (i.e. not just publishing “flat” HyperText Markup Language [HTML] pages) and supports some kind of online commerce, community, or other value-added activity that is enabled by the network would have Web 2.0 traits. But, is it still more buzzword than anything else, and is it being used to put “lipstick on a lot of pigs” even now?
Or, is Web 2.0 a genuine set of technologies that can even provide the “richness” of traditional desktop applications (read Microsoft Office) to the Web-based applications, without all the price and/or performance pitfalls/traps that are often associated with Office Business Applications (OBA)? At least we need to keep a close eye on how the next generation of office workers are using social networking sites/communities like Tagging, Facebook, Twitter, Instant Messenger (IM), etc., as they can give us a clue how effective collaboration should be driven into next generation of enterprise applications (of course, provided the security and privacy standards have been met).
The bloggers and market observers have certainly been buzzing about the advent of Web 2.0 for some time now, with recent discussions going in the direction of whether it is really a big deal after all (i.e., whether it should rather be called Web 1.1 or it has already earned the 3.0 designation) and whether the venture capitalists (VC’s) are slowly reaching the disenchantment stage (possibly similar to the dot.com era at the turn of the century).
In any case, while there is no debate that Web 2.0 has penetrated even the corporate world to a degree (as seen with wikis), and especially in some consumer-oriented front-office applications, my interest here is rather the importance of Web 2.0 deployment within the traditional enterprise applications.
Namely, when a leading enterprise applications planning (ERP) vendor announces that its product suite is Web 2.0-enabled (or compliant), as in recent cases of press releases (PR’s) from Oracle (evaluate its flagship product) and SAP (evaluate its flagship product), how should users react? Should they swoon in excitement or largely yawn and remain indifferent? In other words, during selection questionnaire/request for information (RFI) documents’ creation, should these capabilities be rated as “must have”, “nice to have” or something else?
Another phenomenon I’ve long noticed regarding the enterprise application space is the seemingly large disconnect between vendors’ (and analysts’) hype for cutting-edge applications/product modules — and the general market’s preparedness to embrace the new technology. It seems like there’s a several year lag before customers are ready to evaluate new products’ capabilities. Is there even a benefit to being a “laggard” vendor in each new application area/technology whiz-bangs (e.g., product lifecycle management [PLM], business intelligence (BI)/analytics, Software as a Service [SaaS], Web 2.0, service oriented architectures [SOA], etc.) to avoid some of the learning curve, and better address real needs of the market, when the time is ripe?
Well, the fact is that traditional (pre-Web and Web 1.0) enterprise applications were limited in a couple of ways. For one, any kind of processing that had to be run on the server side (e.g., a user enters data as to apply for a loan from the bank) required the user to input data, which would then be sent to the server to process it, and only then to return a new generated page to the user with the results. Also, the user interface (UI) elements were of quite limited interactive capabilities and user friendliness. Such limitations could in the past be overcome in various ways (workarounds):
1. Some innovative vendors have solved the problem of server processing by dividing the screen into sections, so that only one section would send all the data to the server. Thus, this was the only section to be reloaded, while the other sections would obtain the data from this one. These vendors were real pioneers by inventing solutions that Asynchronous Java and XML (AJAX) has subsequently addressed, albeit a few years later;
2. Also, if the data from server were not needed to process certain information, then the processing could be done on the client side via JavaScript programs; and
3. JavaScript was also used for more interactive UI applications.
The advent of Web 2.0 has largely solved the above shortcomings in two ways:
1. AJAX allows the capability to send only a part of the data from the web page to the server for processing without the user having to leave the page. This ability has enabled web applications to function like desktop applications; and
2. Many companies, groups and/or associations have written libraries of java scripts (e.g., the Dojo framework) and since JavaScript and web browsers have meanwhile become much more powerful, such a combination has brought out a powerful “rich” UI, which has also converged the functionalities of web and desktop applications. The best example of this is when, e.g., in Google Search a user starts to write a sentence, the engine captures keystroke events, and after every keyed letter, it sends to the server what has been typed so far. Then, the server sends back the most popular phrases (and links) so far that start with such a combination of letters (the “courtesy” of AJAX), while, underneath the search field the UI shows those phrases (the “courtesy” of advanced JavaScript) so that the user can at any time select (the most suitable) one.
The nifty “mouseover” functionality is enabled by HTML and JavaScript, whereas AJAX enables that the data within the mouseover window can be sent to the server, which then processes it and refreshes the mouseover window. Certainly, there are a number of “richer” and more powerful client plug-in’s, such as Lazlo, Curl or Adobe Flex, but these are not “pure HTML” or “zero client” like AJAX (which can be some developers’ preference).
The bottom line: if a vendor cites that its applications are Web 2.0-enabled, it is most likely that the software is harnessing new capabilities of the Web. For users, it should mean that they should be able to better and faster (more efficiently) conduct business within the application. For instance: a user (purchase clerk or manager) is placing a purchase order and has to select a supplier. In old Web applications, he/she would have to click on the lookup field/icon (in case of the company having hundreds or thousands of suppliers) and to then type some criterion. After clicking the submit button, the new page would show the possible results, so that the user can select a certain supplier, and then continue to input all other necessary data for the order. Conversely, Web 2.0 should allow the user to type the partial supplier’s name (a la Google Search) to immediately receive the potential matches, select the correct one and continue accordingly.
Further, Given that Web 2.0 is first and foremost an application interface question, there is certainly an opportunity for value added resellers (VARs), and some vendors have thus far acquired a number of partners who have spun up slick web interfaces into their ERP backends. We expect to see more of that in the future - and encourage it, especially if most of the business logic is in the database (since it is then a fairly simple thing to do). At least in manufacturing, before we see much of business-to-consumer (B2C) stuff like mass market social computing, we’ll likely see more business-to-business (B2B) industry oriented stuff like MFG.com or other online marketplaces.
In any case, this is an area where we might have even expanded partner opportunities thanks to the open source or SaaS play — people can work through an integration with, e.g., the xTuple PostBooks accounting product or Salesforce.com (evaluate the product) customer relationship management (CRM) product suite (within the Salesforce.com Apex platform), and do all the experimenting before they even contact the vendor. While only time will tell how deep and successful these integrations (or partnership deals) will be - but certainly a big part of the open source and/or SaaS value-add is to have a greater ability to make these kind of connections oneself, and we expect to see more of that in the future.
Hence, what is your stance towards the importance of Web 2.0 technologies, and do you consider them in your current software evaluations?
Or, is Web 2.0 a genuine set of technologies that can even provide the “richness” of traditional desktop applications (read Microsoft Office) to the Web-based applications, without all the price and/or performance pitfalls/traps that are often associated with Office Business Applications (OBA)? At least we need to keep a close eye on how the next generation of office workers are using social networking sites/communities like Tagging, Facebook, Twitter, Instant Messenger (IM), etc., as they can give us a clue how effective collaboration should be driven into next generation of enterprise applications (of course, provided the security and privacy standards have been met).
The bloggers and market observers have certainly been buzzing about the advent of Web 2.0 for some time now, with recent discussions going in the direction of whether it is really a big deal after all (i.e., whether it should rather be called Web 1.1 or it has already earned the 3.0 designation) and whether the venture capitalists (VC’s) are slowly reaching the disenchantment stage (possibly similar to the dot.com era at the turn of the century).
In any case, while there is no debate that Web 2.0 has penetrated even the corporate world to a degree (as seen with wikis), and especially in some consumer-oriented front-office applications, my interest here is rather the importance of Web 2.0 deployment within the traditional enterprise applications.
Namely, when a leading enterprise applications planning (ERP) vendor announces that its product suite is Web 2.0-enabled (or compliant), as in recent cases of press releases (PR’s) from Oracle (evaluate its flagship product) and SAP (evaluate its flagship product), how should users react? Should they swoon in excitement or largely yawn and remain indifferent? In other words, during selection questionnaire/request for information (RFI) documents’ creation, should these capabilities be rated as “must have”, “nice to have” or something else?
Another phenomenon I’ve long noticed regarding the enterprise application space is the seemingly large disconnect between vendors’ (and analysts’) hype for cutting-edge applications/product modules — and the general market’s preparedness to embrace the new technology. It seems like there’s a several year lag before customers are ready to evaluate new products’ capabilities. Is there even a benefit to being a “laggard” vendor in each new application area/technology whiz-bangs (e.g., product lifecycle management [PLM], business intelligence (BI)/analytics, Software as a Service [SaaS], Web 2.0, service oriented architectures [SOA], etc.) to avoid some of the learning curve, and better address real needs of the market, when the time is ripe?
Well, the fact is that traditional (pre-Web and Web 1.0) enterprise applications were limited in a couple of ways. For one, any kind of processing that had to be run on the server side (e.g., a user enters data as to apply for a loan from the bank) required the user to input data, which would then be sent to the server to process it, and only then to return a new generated page to the user with the results. Also, the user interface (UI) elements were of quite limited interactive capabilities and user friendliness. Such limitations could in the past be overcome in various ways (workarounds):
1. Some innovative vendors have solved the problem of server processing by dividing the screen into sections, so that only one section would send all the data to the server. Thus, this was the only section to be reloaded, while the other sections would obtain the data from this one. These vendors were real pioneers by inventing solutions that Asynchronous Java and XML (AJAX) has subsequently addressed, albeit a few years later;
2. Also, if the data from server were not needed to process certain information, then the processing could be done on the client side via JavaScript programs; and
3. JavaScript was also used for more interactive UI applications.
The advent of Web 2.0 has largely solved the above shortcomings in two ways:
1. AJAX allows the capability to send only a part of the data from the web page to the server for processing without the user having to leave the page. This ability has enabled web applications to function like desktop applications; and
2. Many companies, groups and/or associations have written libraries of java scripts (e.g., the Dojo framework) and since JavaScript and web browsers have meanwhile become much more powerful, such a combination has brought out a powerful “rich” UI, which has also converged the functionalities of web and desktop applications. The best example of this is when, e.g., in Google Search a user starts to write a sentence, the engine captures keystroke events, and after every keyed letter, it sends to the server what has been typed so far. Then, the server sends back the most popular phrases (and links) so far that start with such a combination of letters (the “courtesy” of AJAX), while, underneath the search field the UI shows those phrases (the “courtesy” of advanced JavaScript) so that the user can at any time select (the most suitable) one.
The nifty “mouseover” functionality is enabled by HTML and JavaScript, whereas AJAX enables that the data within the mouseover window can be sent to the server, which then processes it and refreshes the mouseover window. Certainly, there are a number of “richer” and more powerful client plug-in’s, such as Lazlo, Curl or Adobe Flex, but these are not “pure HTML” or “zero client” like AJAX (which can be some developers’ preference).
The bottom line: if a vendor cites that its applications are Web 2.0-enabled, it is most likely that the software is harnessing new capabilities of the Web. For users, it should mean that they should be able to better and faster (more efficiently) conduct business within the application. For instance: a user (purchase clerk or manager) is placing a purchase order and has to select a supplier. In old Web applications, he/she would have to click on the lookup field/icon (in case of the company having hundreds or thousands of suppliers) and to then type some criterion. After clicking the submit button, the new page would show the possible results, so that the user can select a certain supplier, and then continue to input all other necessary data for the order. Conversely, Web 2.0 should allow the user to type the partial supplier’s name (a la Google Search) to immediately receive the potential matches, select the correct one and continue accordingly.
Further, Given that Web 2.0 is first and foremost an application interface question, there is certainly an opportunity for value added resellers (VARs), and some vendors have thus far acquired a number of partners who have spun up slick web interfaces into their ERP backends. We expect to see more of that in the future - and encourage it, especially if most of the business logic is in the database (since it is then a fairly simple thing to do). At least in manufacturing, before we see much of business-to-consumer (B2C) stuff like mass market social computing, we’ll likely see more business-to-business (B2B) industry oriented stuff like MFG.com or other online marketplaces.
In any case, this is an area where we might have even expanded partner opportunities thanks to the open source or SaaS play — people can work through an integration with, e.g., the xTuple PostBooks accounting product or Salesforce.com (evaluate the product) customer relationship management (CRM) product suite (within the Salesforce.com Apex platform), and do all the experimenting before they even contact the vendor. While only time will tell how deep and successful these integrations (or partnership deals) will be - but certainly a big part of the open source and/or SaaS value-add is to have a greater ability to make these kind of connections oneself, and we expect to see more of that in the future.
Hence, what is your stance towards the importance of Web 2.0 technologies, and do you consider them in your current software evaluations?
