IBM Global Services Relies on Drupal to Deliver E-Commerce

Transcription

1 Acquia Product Overview IBM Global Services Relies on Drupal to Deliver E-Commerce Customer Profile Major Supplier of Commercial & Residential Heating Oil Customers: Daily Site Usage: Acquia services used: Enterprise Network Support Integrating Open Source Social Publishing Software into a Multi-Tier Application Solution Acquia is currently supporting an innovative utilities delivery company. The differentiating factor for this client is the utilization of technology to reduce operating costs, increase efficiency, and pass significant savings onto their customers. Specifically, this company has replaced the slower, paper-intensive method of traditional order fulfillment with a more direct online model. In addition, they are using extensive back-office applications to reduce waste and unnecessary cost at every point of the fulfillment process, including GPS analysis to optimize delivery routes. As a result, this Acquia customer is creating a new business model, where users can order heating oil and manage their account easily online, while saving money through fully optimized delivery. The success of this business model depends upon a 3 tiered application stack, including Open Standard Drupal providing a front end CMS interface, a custom-coded middleware layer, and a back-end applications layer. Delivered by IBM Application Innovation Services with Drupal support provided by Acquia, this elegant and effective integration provides the customer with an end to end solution for customer ordering, fulfillment and account management. Identifying the challenges and requirements As a startup, this organization had no legacy products that needed to be replaced. In this sense, the company was in a unique position; it had the luxury of not having to swap out an existing infrastructure. At the same time, it also needed to make a substantial investment in a business model based on technology that hadn't yet been tested or implemented which made immediate technical success paramount. In order to ensure success the organization brought its requirements to Ted Tritchew, the Delivery Executive for IBM Application Innovation Services, part of IBM Global Business Services. Experienced in finding the right solutions for customers, IBM Application Innovation Services is focused on integrating systems together, when no commercially available e-commerice solution will work.

2 Requirements Provide a seamless user experience Enable cost savings through logistical applications Deliver a stable integration capable of growth Avoid extensive front-end customization Provide tools for customers to self-serve and manage account According to Tritchew, the customer's requirements were consistent with typical solution scope. They mandated several requirements. First, they needed the brand to benefit from web 2.0 functionality, such as blogs, RSS feeds, polls and content sharing mechanisms. They also needed tools to optimize the visibility of the site, so that they could effectively market it, and new customers could discover and find the site. They required a user interface that was powerful, but intuitive. Cross-browser functionality had to be maximized. In terms of processing and user controls, the site had to perform quickly. Of course, they needed a secure system, and one that would integrate seamlessly with back-end applications. We often do work for customers who require CMS integration to e-commerce. In this instance, the back-end application tier would enable order fulfillment, including order status and history, account status and management, as well as the ability to analyze and optimize the order fulfillment process. The IBM team started with a functionality matrix that would prioritize what the customer would need in their end-to-end solution, both in terms of what was needed at the time of launch, and longer-term needs as the company grew into providing additional services. The proposed strategy was a 3 tiered platform, with an open-standard CMS front end layer, a custom coded middleware layer, and the back-end layer. The openstandard CMS would provide tools for building the front tools quickly, as well as offering some structure and reliability over a custom solution. The custom middleware would accept application calls, and pass information onto the ERP system. The challenge wasn't finding an application stack, recalls Tritchew. There are an abundance of potential solutions. The challenge was finding the right combination, or stack, of technology that would meet the customer's requirements. In addition to the previously mentioned requirements, the customer had a very short time to market. With a stated time frame of six months, Ted recognized that a reliable beta would need to be online within four months. The IBM team needed to provide a solution that could be launched quickly, and was supportable. There was interest in Open Source Software (OSS), but there were limitations on what constituted an approved OSS solution. Both the client and IBM brought their own requirements about acceptable technologies, based on precedent and reliability. It also goes without saying that as a startup with no current revenue, that there were budgetary constraints placed on available technology choices. Building the 3 Tier Application Strategy Ted Tritchew approached the selection process and planning with a well tested model - the self-service ecommerce application pattern. This architecture breaks the solution up into 3 tiers a presentation tier for the front end, a back-end application tier for managing data and logic, and a middleware tier that would interface between the back-end and presentation tiers. With so many available products and technologies, Ted Tritchew's team relied on a functionality matrix. By combining the client requests with IBM standards, a matrix was created that assigned points based on various attributes of potential solutions. The team took a systematic approach to evaluating various options for each respective tier.

3 Presentation Tier: Selecting Drupal and Acquia Candidates for the presentation tier included Drupal, Joomla and the Java-based Alfresco. Custom-built solutions using Java Server Faces, Ruby on Rails and the Zend framework were also considered. Ted Tritchew proposed Drupal, as he has on several recent projects. Using the comparision framework, Drupal was the favored presentation tier choice, based on supported features, stability, extensibility, security, documentation, and overall quality. We selected Drupal because it best fit our priority matrix, and because it passed our initial due diligence. To ensure the customer buys into our vision, we present a side by side comparison of features, functionality, advantages and drawbacks to each potential solution. This comparison framework is built around customer requirements, and points are assigned to respective technology, based on the priority of requirements. Solution 3 tier-solution: Drupal front end, custom middleware, IBM application back-end IBM developed solution Drupal support provided by Acquia Another important factor was Acquia, which provides enterprise-class, commercial software support for Drupal. Acquia also offers their free packaging of Acquia Drupal a tested, pre-packaged set of Drupal core and modules that Acquia provides. By implementing Acquia Drupal and using Acquia for support after the project was launched, Ted could guarantee Clickfil the reliability they needed. Acquia is in a unique position as an open-source support provider, said Ted They don't generate revenue directly from a complimentary packaging of Drupal. Instead, they offer the most stable and useful set of modules, allowing them to more effectively support paying customers. Selecting Acquia allowed us to fast track development with pre-tested modules, and provided some peace of mind that after our development team left, there would be some continuity and subject matter expertise in the form of Acquia support. Web Application Tier: Custom Solutions The middleware consists of a web application tier responsible for some of the application business logic and accessing the backend application. It also provides an important layer of abstraction between the presentation layer and the back-end applications. By creating and managing interfaces that are made available to the UI presentation layer, a necessary level of stability can be reached. The middleware layer was custom-built, and was dictated by a combination of the customer's IT strategy, and the type of applications that are needed in this case the integration between the Drupal presentation tier, and the back-end application tier. Guided by these directions, the IBM team designed the layer using Linux, WebSphere, DB2, and Java-based custom development. It was a good fit with the requirements, and involved technology that IBM was well versed in supporting.

4 IBM, On Acquia Selecting Acquia allowed us to fast track development with pre-tested modules, and provided some peace of mind that after our development team left, there would be some continuity and subject matter expertise in the form of Acquia support. Ted Tritchew Solution Architecture The 3 tier architecture was designed to enable users to conduct utilities transactions and manage their account, while providing cost savings through streamlining operations on an ongoing basis. From a usability perspective, the interaction would begin at the presentation layer. Users would request and submit information via a web browser, which would interact directly through the Drupal presentation layer. This presentation layer would interact with the logic layer, which would manage account information and data, as well as interacting with the IBM-based application layer. In this particular case, because financial transactions were occurring, the back-end application system was also interacting with two third-party systems, including a credit card service provider, and an ACH service-provider. Key components to the Drupal-based presentation layer include a standard LAMP stack, using Acquia Drupal To deliver the necessary functionality, CCK, Views, Panels, Location and GMap modules were used. A series of custom modules were also developed, including object-oriented modules for a SOAP-client framwork, Forms API abstraction, a Logging framework that interfaced with watchdog, and a large number of forms for collecting user input, many of which are passed through the logic layer to the application layer. The web application logic layer relied on WebSphere 6, and shared a Linux hosting environment. It is important to note each layer is fire-walled from each other off from the other respective layers, for stability and security. The mid-tier helps isolate the complexities of the application tier, making customization of the presentation layer easier and more effective. Sample Interaction Pattern Through 3 Tiers An example of an interaction pattern would be a user-driven request for determining heating-oil availability, and price savings, based on the user's location and amount of oil used. Submitting the form through the Drupal UI layer, an AJAX call is made to a web service in the logic layer. The logic layer would look up mapping information in a database. This information would be passed to the application layer, which would calculate the savings and availability. This information would be passed back to the middle web application layer. The middle layer would then return the availability and savings information to the Drupal presentation layer via SOAP. JQuery displays the information to the user. This process meets the requirement of sub-second responsetime, a standard benchmark requirement for this project.

5 Building the Solution and Managing Best Practices There were a series of logistical challenges that the team faced in building the 3-tiered application, which are common to these types of projects. First, as a start-up, the business goals and operational requirements that must be met through the project were not completely developed, and subject to ongoing change. Ted's team undertook Agile software development methods (SCRUM), meaning that they would build each of the 3 tiers in parallel using collaboration between self-organizing cross-functional teams. This allowed the team to adapt to the client's evolving goals,and provided the development teams with understanding and visibility across the 3 tiers. Agile development is test intensive, and Drupal's UI was quickly recognized as a useful medium through which to conduct unit tests. Back-end application integration is often challenging, as developers are making changes to the system during deployment. Most e-commerce applications fail because of difficulty in integrating with enterprise applications. APIs are often poorly documented, rapidly evolving, lacking both test systems and suitable test data. The use of the middleware layer helps in solving these issues. A service oriented architecture (SOA) hides the application layer behind the mid-tier. A mock framwork can be used in place of the back-end environment, until it is developed enough to be integrated. Drupal team development posed its own challenges, particularly in making sure the efforts of multiple developers are merged correctly, and work end-to-end with one another. A central Drupal Integration Server was used. The environment used a cronjob which checks for changes to MySQL every few minutes. Source control will reload local databases, so that Drupal developers can work locally. Check-in to source files are detected, which can trigger a Drupal build, which will launch and test the server. To make Drupal custom form development more efficient, Tritchew's team employed a custom object-oriented Forms API. This provided an object-oriented class hierarchy for forms and forms elements (such as Checkbox, TextField, Form, FieldSet, etc.). Forms and form elements are rendered into Drupal Forms API arrays, and can be fully unit-tested using PHPUnit. Ensuring security is a critical concern. An independent team works alongside the main team to perform security audits and testing of the site, prior to launching the site into production. These simulated attacks are conducted throughout development.

6 Reaching Success and Understanding Effective Multi-Tier Integration The IBM Team is experienced in building robust, multi-tier application solutions. Tritchew cites several factors in the success of this particular project. The Drupal framework was a key building block. It offers the tools and ability to integrate. Real time integration to access the back-office line of business applications was critical. Our development, application and architecture patterns have been shaped over time. My advice to organizations looking to build a similar application would be to invest time up front. Projects like these depend upon understanding how the layers will work, and not underestimating them. Once the technology is selected, its crucial to coordinate a team with expertise for each of the respective layers. The customer launched their full site in the fall of As of the publication of this case study, it has incurred no unplanned downtime. Drupal has provided the customer with a set of tools that make it easy for its users to interact with the company and manage their own accounts online. It also new content to be added without requiring web coding expertise. As new functionality is desired to interact with customers and to build a community, the customer is well poised to add those modules with the assistance of Acquia and their Enterprise Network Support subscription. The customer is also counting on using the interactive, community-driven tools that Drupal promotes, to get important user feedback feedback which will be used to improve how the customer can meet user needs. Contact Acquia Acquia, Inc. 150 Presidential Way Suite 310 Woburn, MA Phone: ACQUIA [email protected] MSKU#: 0020