Tuesday, January 12, 2010
High Level Enterprise RIA Requirements and Specifications
When you sit down to issue an RFP for an enterprise Rich Internet Application (RIA) platform or framework, what are the high-level considerations that most other enterprises consider important? How do your goals for deploying a RIA platform affect the high-level priorities that you set? We’ve talked with hundreds of our customers and prospects around the world about their RIA deployments and RIA planning.
From the outset, it became clear that ISVs and companies that operate large public websites have different requirements than enterprises when it comes to RIA. Enterprises place a much higher priority on ease-of-development and reduced complexity while large ISVs and Website Companies seemed to thrive on approaches with a diversity of tools. Enterprises were also much more concerned about information than they were appearances. The UI was important, but certainly not as important as issues such as transactional integrity, operational reliability and security. Scalability requirements, on the other hand, reached their peak with the large website operators and ISVs, even more than the large enterprises. Midsize enterprises had relatively modest scalability needs.
What follows reflects some of the common-threads or consensus around best practice for RIA platform selection, specifications and requirements enterprise IT needs. One of the initial trends that we noted is that the desire for RIA was usually driven by either the need to enhance the enterprise capabilities of delivering compelling user experiences for users of their public-facing websites or it was driven by the need for enhanced user experiences in the use of internal enterprise applications. In this latter group, the need was often expressed as a desire to evolve from existing application platforms to newer platforms with RIA capabilities.
Enterprise RIA Platform Requirements.
Many large and mid-size enterprises write their own software applications to support proprietary or unique business processes. Today’s client-server applications are typically characterized by uninteresting gray screens and text with a high-degree of transactional functionality around structured data as opposed to more visually appealing layouts and rich media types involving unstructured data. As “the Facebook Generation” enters the workforce, expectations for immersive and dynamic user experiences are increasing within the enterprise. But the transactional sophistication of data-centric business applications must not be sacrificed.
Ease-of-development. Typically, customers desiring a new application platform were concerned about the effort required to build or migrate applications. The need for developer productivity topped their list of requirements and typically became the starting point for discussions. “How difficult is it to develop applications?” was a common question. Although not always expressed as a requirement, a metadata centric application platform will go a long way toward optimizing ease-of-use for developers.
Compatibility with Existing Platforms. At the same time, there was a desire for continuity. Enterprises considering new RIA platforms want the solutions they begin to deploy to be compatible with existing platforms. Interestingly, this did not usually mean that they wanted to continue using the same legacy tools and languages such as RPG, COBOL, Java or C++. But rather, it meant that they wanted to be able to access the data and business logic layers of those applications while simultaneously deploying on a RIA platform. This desire for composite applications is matched by a desire to gradually replace legacy code with new business logic utilizing more service oriented approaches.
Leveraging Existing Skillsets. Enterprises tend to employ a more mature workforce than ISVs and websites. As a result, they seem to have an even higher concern about skills compatibility. We often heard about developers nearing retirement and their reluctance to learn new programming languages. This sometimes led to a requirement that the new RIA platforms offer paradigms and approaches with a low learning curve and compatibility with existing skills.
Vendor Support. Once these concerns were met, enterprise buyers then became interested in the vendors standing behind the RIA platforms and tools. Vendor longevity, community footprint, support services offered and vendor reputation for reliability were all especially important to enterprise IT buyers seeking to replace current application platforms with a RIA application platform.
Enterprise Website RIA Requirements. Interestingly, even within similar types of companies, the RIA requirements expressed varied notably for those whose primary need was not for internal facing applications but rather for their public facing websites. Where the concerns expressed around enterprise IT platforms primarily had to do with the impact on the companies IT culture (ease-of-use, platform compatibility, skillset compatibility, vendor support).
Browser Independence. Although it may seem counterintuitive, one of the primary needs expressed by those seeking RIA capabilities for their websites is browser-independence. The goal is to offer application capabilities in RIA clients that are independent of the browser and all of its security, performance and other limitations.
Cross-platform, cross-database support. For enterprise websites, customers also often expressed a need for compatibility with existing servers, but this need was often expressed as server neutrality. When drilling down on these requirements, however, it seemed most enterprises were looking for server side technology that was cross-platform and cross-database capable in case the underlying infrastructure changed.
Web friendly client footprint. Enterprise IT departments seemed frequently expressed the need for efficient RIA client footprints. With a RIA client footprint that is too large, the company’s website vistors may become impatient or even abandon the site. With a client footprint that is too light, however, capabilities will be constrained. The debate between the benefits of a fat client versus a thin client are not new. In the context of RIA, it has led Magic Software Enterprises to describe its RIA client as “neither fat nor thin, but fit: the right fit for both power and efficiency.”
Ease of updating. The ease-of-updating the RIA client was another frequently identified requirement of those enterprise buyers seeking enhanced capabilities for public facing websites. With sites servicing the public, onerous update processes are problematic.