Case Study: Learning to KISS eCommerce design?

More than a decade after the dot.com bust, we seem to be witnessing another version of an eCommerce boom, a 2.0 if you will. While rest of the economy continues to lag, the success of Linkedin, Pandora and other internet IPO's this summer is getting business and IT leaders excited about eCommerce strategies and implementations.

One can argue that the success of dot.com 2.0 startups is more due to innovative business models than a radical innovation in technology. The tools and technologies for web development have matured, and so has eCommerce development life cycle. The proliferation of web technologies and tools, along with maturing industry also means one is likely to see the usual clutter of incompatible tools and technologies, version incompatibility, challenges with back-end integration.

For a consulting Enterprise Architect like me, the challenges translate to opportunities (there is demand for good eCommerce Systems Integrators and Architects!) In my day job, I have been consulting with a client on eCommerce program governance, roadmap definition, alignment with the corporate Enterprise Architecture blueprints. It is not all strategy work there is the roll-your-sleeves solution delivery: helping teams’ firefight rollout of functional and technical enhancements. My observations on eCommerce Enterprise Architecture - not in a particular order - follows.

The Program: eCommerce implementation for a large (Fortune 500) firm headquartered in Ohio. The company is focused on Supply Chain management for a specific business vertical. The current phases of eCommerce platform are focused on enabling Business-to-Business (B2B) integration though the architecture roadmap includes evolving towards B2C too.

Organizational IT: Federated, shared services model. The eCommerce strategy and applications are owned by a senior executive (technology solutions owner). Integration - including SOA, J2EE services - is a shared service. Configuration Management is owned by another organization as are Database and systems administration and Quality Control/Assurance. Needless to say backend systems (SAP et al) are owned by other LOBs. The company's Enterprise Architects are similarly verticalized, with a couple of them aligned to eCommerce programs and one focused on integration. The eCommerce Architecture is a "next generation" solution intended to upgrade the "legacy" web application and expected to evolve into the front end for most of the lines of business.

Architecture: The eCommerce Architecture is based on an IBM centric web-commerce stack : IBM's Portal, Commerce and Web Content Manager products integrated by Java. DB2 is the Commerce data repository while solution from Endeca is leveraged for product feeds and search. Java is also leveraged to develop web services and real-time integration with back-end order processing, fulfilment and pricing systems of which there are more than a few including SAP based and homegrown solutions; typical of fortune 500 organizations.
Most of the design and development of the eCommerce platform is sourced to vendors. Sometime ago, the client wanted to move away from Vendor A; in stepped my employer. I got engaged during the vendor transition phase: a fascinating opportunity for a consulting Architect. After a successful vendor transition, I lead the team through a critical project that helped them find their way around intricacies of the client’s IT shop. Observations from the trenches include:

• Division of labor being taken to an extreme: There is a specialization of skills, even within a single vendor’s stack. Most of the younger generation developers - read those with about 3-6 years experience - are content to hone their skills in a specific toolkit, be it Websphere Commerce, Websphere Portal or WCM. Few developers seem to have the aptitude or inclination to span the technology stack, even within a vendor’s platform, which is a problem and an opportunity: It is a problem most large eCommerce programs are plagued with, and an opportunity for astute developers to scale up and become uber application integrators.


• Remote development. Offshore service providers, including my employer, are taking on larger Systems Integration programs. And although offshoring IT services has got commoditized, almost every large program seems to go through similar learnings. Onboarding and enabling right skills is part of the challenge, exacerbated by the division of labor. Having a Business Analyst and Technical lead sitting in Anytown, USA guiding a portal developer sitting in Bangalore, and commerce guy in Mysore can be challenging at best; made worse when the portal developer does not understanding squak of the underlying commerce services or database.


• We are yet to realize the promise of plug and play. There is a proliferation of tools and technologies and most don’t plug-and-play without a lot of plumbing. Many products within the same vendor’s architecture also require additional time and effort in “integration”


• Services? For most part, the promise of SoA is yet to be realized. Period.


• Complexities of build and deployment


• And then there is the backend….. Most eCommerce systems are intended to enable a web front-end to enable customer self-service. Internet is ‘yet another’ channel for back-end systems that can range from legacy mainframes to contemporary but equally complex backend systems.

Back to my day job. I continue to bridge the gap between our techies and the client's Enterprise Architects and technologists. And my team is trying to help fix some of core issues - including the ones highlighted above - in the current landscape that prevent the system from scaling up. I wouldn’t be leading the gig if the ‘Architects’ had kept things simple to begin with.

Bottomline: When it comes to Architecting eCommerce systems, we don’t KISS! Most of us come out of Engineering and IT dreaming of developing simple, elegant and functional solutions to business problems. The new generation of developers architecting eCommerce applications seem to have skipped class when that lesson was being taught.