Wednesday, February 08, 2006
This post was also published in InfoWorld.
"Integration" is the third rail of enterprise IT. The mere mention of the word raises terrifying thoughts of huge budgets, endless meetings, and extremely complicated software.
But the days where each enterprise application is an island are coming to an end--even things as simple as an employee directory now need to integrate the HR systems of multiple divisions, accommodate cross-reporting and virtual teams, and integrate outsourced third parties. Like it or not, essentially every enterprise application today requires integration.
Naturally, enterprises have taken notice of the rise of "mash-up" applications on the Internet that integrate data from a variety of sources in new and useful ways. The trend was kicked off with sites like Housingmaps.com, which displays Craigslist housing listings on Google Maps, and has now reached quite a pinnacle with a conference called Mashup Camp where numerous people demonstrated useful mash-up applications.
Front-end integration has become the enterprise equivalent to the mash-up movement. It works by integrating Web services and databases at the web tier, using lightweight technologies like LAMP. With lightweight architecture, it is very simple to integrate data from a variety of internal and external sources and present the data with a rich AJAX user interface. One example of front-end integration is a call center application that integrates data from CRM and ERP systems as well as FedEx, so that customers are not waiting as call center reps are endlessly typing lookups into three different systems.
Remember, however, that back-end integration is still necessary to create non-user facing services that require multi-phase commits or long-lived processes. Multi-phase commits involve coordinating across multiple data stores to ensure that data is updated on all of them or none of them, most commonly for financial types of transactions where money is being moved. Long-lived processes involve coordinating multiple steps across many systems, such as handling exceptions in supply chain management where a shipment needs to be diverted automatically to a new plant. These types of projects are very expensive and cumbersome, and the most popular technology for back-end integration is of course J2EE servers and their Integration Server offshoots from vendors like IBM and BEA.
But as evidenced by the growing use of mash-ups on the Internet, very useful integration projects can be delivered quickly and economically on the front-end, using lightweight architecture.
Wednesday, February 01, 2006
This post was also published in InfoWorld.
At the last InfoWorld SOA Executive Forum, I asked the audience for a show of hands on the following question: "Who thinks it's easier to build an app that communicates to a web service than it is to write an app that communicates to a database?" Of this very sophisticated audience of senior IT architects and managers only two people raised their hands.
After having spent countless amounts of time and money implementing service-oriented architectures, enterprises are finding that it's still incredibly difficult to build new user-facing applications that tie services together. Why? Because enterprises are trying to build composite apps with traditional technologies such as J2EE.
It's hard enough using this approach to build a basic HTML application that talks to a single database. It is nearly impossible when you're using the same tools to create applications with rich interfaces that integrate with multiple services including RSS, SOAP, REST and database stored procedures. Java is great for doing certain kinds of applications, including things like ERP systems and transaction orchestration. It is not ideally suited to line-of-business IT types of developers trying to rapidly develop rich new applications that integrate services from an SOA infrastructure.
On the Internet, composite applications are commonly called "Web 2.0" or "mashup" applications, and feature rich AJAX user interfaces that integrate data from multiple data sources. If you look at Web 2.0 companies that are having success, such as Facebook, flickr, Friendster, and MySpace, they're all running a lightweight architecture, the open source LAMP (Linux, Apache, MySQL, PHP/Python/Perl) stack on large clusters of commodity machines.
When "Web 1.0" happened, consumers could use their computers to buy plane tickets, check the weather, and buy books. But when they went to work, if they wanted to change their health plan, they had to call HR. If they wanted to find the latest price of a part, they had to call their supplier and have a price sheet faxed to them. This disconnect between home and work life very quickly evaporated, and now virtually all information that people need at work is available online.
Large organizations need to quickly deliver composite apps, like CRM applications that integrate services. That way they can show, for example, that a customer's last five orders have been delayed before they make a sales call and get ambushed by an irate person on the other line. Before the web, the user facing applications within an enterprise were usually written with scripting languages like Visual Basic and Powersoft's PowerScript. By using the next generation of scripting languages PHP, Python, and Perl -- instead of Java, line of business IT can create applications much more rapidly that integrate diverse services, bringing Web 2.0 style applications to the enterprise.