Enterprise Ajax + SOA = User-Driven IT
Alone, SOA and Ajax both promise considerable payback to IT, but combined the two technologies are two sides of the same coin enabling a new class of Web-based applications called 'Rich Enterprise Applications' or REAs.
Not only does REA capitalize on the technical strengths of Ajax and SOA, it also provides a platform for dramatic productivity gains by empowering end-users to interact and integrate in ways never seen before.
Ajax + SOA = REA (Rich Enterprise Apps)
Combined, Ajax and SOA enable Rich Enterprise Applications, which places the power and enablement directly in the hands of the end user. With the potential for significant user empowerment within REAs, there can be considerable pressure from the user community for IT to make it happen.
As a result, REAs will have a very substantial impact on future enterprise architecture planning and design. In some organizations this effect is already being seen, particularly in larger organizations that were early-adopters of SOA.
Many early-adopters have finished one or two large SOA efforts for application-to-application integration needs but haven't extended these newly-unlocked data assets directly empowering their business users. And as we all know, the purse strings in most industries are in the hands of the end user. It's all about the end user and Ajax does something to SOA that SOAs alone do not account for: they provide the 'last mile' of business functionality to the users.
Enterprise Benefit of REA
An example of a world-class REA might help explain their use, benefits and impact on practical enterprise architecture planning and design. One of the most mature REA implementations we've seen to date has been an Ajax-based 'webtop' for the Department of Defense intelligence analysts. Every analyst starts with an empty webtop and a set of SOA services-based information sources for consumption.
Services can consist of planned/expected events such as facts or statistics from archival databases or third-party news services. Many of the services available for consumption are straight pass-throughs of SOA-type services from existing intelligence data sources. Others are 'virtualized' services from less formal sources like databases or EJBs [Enterprise Java Beans] and some are 'service mashups' that combine two or more granular sources into a composite service that is more useful to the analysts than the granular sources alone.
Once a service is selected, it can be personalized in a variety of different ways. For example, filters can be applied, display fields can be changed and formatted, and maps can be overlayed on geospatial records. As you would expect from any quality Web 2.0 application, specific data records/items can be shared or socialized with other users in the community. For instance, users can place a data item on a webtop 'ticker' with an expiration period and have it show up on the ticker of other analysts. Many of the services also allow data updates back to the original source, with updates made on one webtop immediately reflected on every other webtop that has the same data displayed.
Takeaways from REA
The big takeaways from this REA example? First, the user is in the driver's seat and they are behind the wheel of a very powerful vehicle. This user-empowering REA can apply to employees in every industry such as medical records technicians, sales reps, call center employees, credit analysts or claims adjusters.
Secondly, in this example REA (as in almost every REA), Ajax and SOA are hand-in-glove. It is very hard to say that Ajax is 'pulling' versus SOA 'pushing' Ajax in the enterprise's architectural plans. Perhaps that merely depends on your specific role in the organization and where your organization lies in the adoption curve for Ajax and SOA. But the power of the two technologies combined is certainly more relevant than either technology alone on its own.
It's important not to mistake REAs for portals. Instead, think of REAs as portals without portal services. While today's portals help with a single point of entry for corporate information, they've turned out to be a dumping ground for too much information. REAs on the other hand let the users not only select the information they want and how they want to see it, but it also let's users 'mashup' the disparate pieces of data for a personalized view - a new kind of user-driven integration. When users share these ad-hoc micro integrations, it essentially drives the "long-tail" of the integration effect.
How REA Fills the Gap for User-Driven IT
But as you may have already realized, there are components missing from today's typical enterprise architecture to that would enable support of an REA like this. Proper service granularity is still an art form. Data 'push' into browser-based applications isn't commonplace. Service 'virtualization' and 'service mashups' are largely unheard of.
All of this communication needs to be done securely following the service-availability policies of the underlying services, with all of it scaling elegantly to highly distributed user communities.
Let's not forget that most organizations do not have Enterprise Ajax development teams just sitting around waiting on SOA projects to go into production. They need tools that support visual development, debugging, and code reuse while providing the 'tables and buttons' widgets developers come to expect from IDEs. The IDE must also help them create code that is light-weight and optimized for execution in a browser.
Smaller but no less important are issues such as cross-browser compatibility, multi-language support, web content accessibility guidelines and a coexistence strategy with the aforementioned web portals.
This is why Ajax and SOA or as they should be known as, REA, will have an enormous impact on future enterprise architecture planning and design. With users ultimately demanding REA-type capabilities from IT, it is inevitable that your next enterprise architecture will be user-driven. In the next few years most business applications will be REA-based and the onus will be on IT to plan for this demand.
The first installment discussed uses and benefits of REAs and some technical challenges. In future editions of the series, we will discuss the architectural elements needed to implement REAs successfully.