In the continuing Baby Steps to SOA series, we follow Doug and the IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. Previously, we introduced the problem and the team, started planning and analysis, decided on some metrics, and refactored the website applications. Most recently, the team has tackled identity management, introducing a CMS, building data services, and now continues by centralizing their eCommerce functionality.

The Evolutionary Roadmap

• Step One: Analyze and Plan
• Step Two: Measure It
• Step Three: Three Tiers for the Website
• Step Four: Single Sign-On
• Step Five: The Move to a CMS
• Step Six: Data Services
• Step Seven: Centralizing eCommerce
• Step Eight: Sharing the Business Tier
• Step Nine: Moving beyond the website
• Step Ten: Riding the ESB

Step Seven: Centralizing eCommerce

One of the most costly and difficult pieces of software that a team can handle is an eCommerce solution.  If your web application is providing a shopping cart and integrating to a payment gateway, you have probably dealt with thousands of issues related to PCI compliance, dropped credit card transactions, lost orders, miscalculated taxes and shipping costs, slow performance, difficult user information validation, etc.

Additionally, if you have multiple web applications, you have likely copy-pasted a lot of this code between applications and now have two or more of these systems that are having these problems, and are needing to roll out fixes and changes to all of them.  In this scenario, the team needs to consider moving to a centralized eCommerce solution for all of their applications that use eCommerce.

Of prime importance is meeting the Payment Cart Industry Data Security Standard (PCI DSS).  Most custom solutions for eCommerce are likely not compliant, especially regarding the submission of orders and transactions.  It may be that your first focus should be on making sure the payment gateway integration is behind a web service inside of a firewall and using encryption so that your application is not transmitting card holder data over a public network when speaking with the payment gateway.

When choosing to centralize this business logic, as with most architectural decisions, there are really two options:  Buy or Build.

Option 1: Using existing Software as a Service (SaaS) solutions

The transition from a custom solution to using a SaaS solution (like Shopify) can be difficult, as our home-grown systems have become accustomed to having complete control over customizing all user flows in the system.  Integrating with an external system is no small task, but has great ongoing benefits as the vendor takes on:

1. Maintenance of the eComms solution
2. PCI compliance needs
3. Infrastructure requirements
4. Ongoing software improvements
5. Payment gateway integration
6. Design (in some cases)

The first step, obviously, is to find a solution that works for your needs.  Practical eCommerce posted a review on 8 SaaS shopping carts (2011) that can get you started, including the previously mentioned Shopify.  You can also read Ben Adams‘ slideshare on the considerations for selecting a SaaS vendor (2012).  The following excerpt is particularly relevant:

Things to look for in a vendor pitch or RFI response

• Focus on value and not just cost
• No mentions of the word ‘enterprise‘
• Live reference application demo displayed on their cloud
• Clear roadmap focused on delivery of business capability and not just gloss
• Pre-integrations with other Third Party solutions
• Developer tool-kit based on open standards
• Robust, global infrastructure including DR, CDN
• Security ‘out of the box’
• Clear platform scope
• An agile way of working

The next step is to begin the integration.  Depending on the flow you take the user through, and what steps need to occur before and after the eCommerce flow begins, this can be very difficult.  Make sure you consider what these integration needs are when selecting your platform.

The temptation may be to try to “keep things the same” but use the SaaS instead of the current flow.  There will be limitations on whatever platform you select, and the fewer customizations you make to the SaaS solution the easier your upgrade paths will be.  In terms of application lifecycle management (ALM), you should consider updating your existing application flows to integrate more easily with the SaaS solution, as long as your users still gain the essential business value they are looking for.  If something seems very difficult, or costly to integrate, ask yourself: “Does the user need this feature?“.

Most of the time, the answer is “no”.  You do not need to keep all the features you previously had in the new version of your software, especially if those features are not providing value.  This will be a good time for some clean-up!

Option 2: Building it yourself

If the vendor options are outside your price range for your revenue income from eCommerce, or if the amount of customization you need to be able to support is simply not feasible with a SaaS solution, then the team will need to build their own centralized platform.

My recommendation is to roll this out iteratively.  Depending on your needs for centralization, there are certain logical points where you can draw a line in the sand for where the centralized functionality begins:

1. Payment Gateway:  This is the lowest level sharing of eCommerce logic.  Involves setting up a web service wrapped around transactions to the gateway so that all eCommerce applications can use the same payment submission gateway logic and not have to think about how to communicate with the payment provider.
2. Payment Submission Site:  This centralizes only the part of the eCommerce flow where the user begins the process of checking out.  The user interfaces are usually custom in each application, and when the user chooses that they are ready for checkout they are sent to a centralized website which will take their payment information and then communicate with the payment gateway.
3. Cart solution:  This provides a centralized cart, checkout, and payment system.  Each application has custom catalogs and then when the user decides to add to a cart, they are actually adding to an integrated centralized cart system.
4. Full eCommerce solution: This provides a centralized catalog, cart, checkout, and payment system.  Usually requires some way to ‘filter’ the catalog so that users only see the catalog items relevant to the site they are visiting.

By first rolling out a Payment Gateway webservice, all applications can move that extremely similar code into a centralized location.  In addition, this will likely help the infrastructure team start working towards better PCI compliance by securing those transactions inside of a protected network.

The next steps gradually move the user interface out of a single application and into a centralized one.  You may decide to make one of your web applications the “master” and then run all of the other sites through it.  This will make the development on the single “master” site much easier, especially if the other applications are very small and don’t require much customization beyond the master sites needs.

However, architecting in this manner makes it less obvious for developers maintaining the master site of the dependencies or impacts to integrated satellite applications.  For this reason, moving the eCommerce into its own physical application can expose this need for dependency verification whenever new changes are rolled out.

In Our Scenario

Doug and Lynn’s team behind BuyMyWidget.com is primarily focused on eCommerce (as their domain name suggests).  This is their main form of revenue, and they have spent millions of dollars over the years developing the eCommerce solution.  While performance and security issues exist, the team has solidified the solution for the most part.

However, over the years, a new “Events” application has sprouted which also has eCommerce needs.  This site sells registrations to events related to their line of business.  Lynn has made sure that both applications are using the same payment provider, but all of the business logic is completely different between the two sites.  Even the user interfaces have different flows, capture different information, and have a different design.

Doug has also been informed that in the future, the business would like to start marketing to new verticals, and potentially build new revenue streams using the eCommerce solution that has been built.  One executive has even asked if it would be possible to sell the platform behind BuyMyWidget.com as a service to other companies!  Given the current business trends at BuyMyWidget, and the investment already made, Doug does not feel that a SaaS solution is in their best interest.

Lynn would prefer a SaaS solution so her team would not need to maintain all of the complexities of the existing eCommerce solution, but is intrigued by the idea of potentially productizing their platform.  Given the mandate to stay with a custom solution, Lynn has identified the following primary issues with the current system:

1. The Events application is always a version or two behind in eCommerce features delivered on the primary eCommerce platform.
2. Bugs have been identified in both applications, but are not always fixed in both applications.  Maintaining fixes across the streams is time-consuming and difficult as the code is not exactly the same.
3. PCI compliance is not currently met for all requirements.

Doug and Lynn agree to only move the payment processing logic behind a web service for now, to provide the immediate fixes over the transaction processing to both applications.  After that, a new code project will be developed for common eCommerce business logic and classes.  Both applications will then be updated to use these common DLLs to manage bug fixes and new enhancements until the entire platform is centralized.  If platform centralization is not needed, the DLL logic can then be moved to a service to make deployments easier and expose the logic to all applications.

How much will this step cost?

For either option, the budget for this step will likely require a senior architect, two senior developers, and a testing resource for regression while the UI business logic and payment provider code is being centralized.  If the team is custom building the centralized eCommerce platform from an existing application, the cost will increase proportional to the amount of effort required to centralize the business logic.

If the team purchases a SaaS solution, an architect will likely be needed to handle the integration between the purchased product and the existing applications.  A project management resource will likely be needed to coordinate the vendor work alongside the IT team’s efforts.  The budget should include some additional project timeline to compensate for the integration issues that will occur.  Most SaaS solutions will not work exactly as needed out-of-the-box, and aligning changes with a vendor inevitably adds unexpected delays to the project.  Additionaly, SaaS solutions will also include an ongoing service or licensing cost.  Usually these costs vary based on packages or features purchased.

In either case, if any part of the user interface is going to be centralized between multiple applications, an analysis of the flows needs to be done.  A UX resource should be brought in to design a common flow for all applications.  The development team can then support the changes and start building out the centralized application piece by piece.

Budget will also be required for any performance, security, and PCI-compliance scans required to verify the solution.  The vendor may be able to cover most of this in a SaaS solution, but the integration points will still need to be verified.

What’s next?

This series continues with the team sharing their business tier across applications.