Lets postpone this release or lets have these features in next release. First release should address fundamentals or the foundation. We will do the rest in subsequent releases. Is this a common statement you hear? I have seen and heard such statements so many times especially in eCommerce and when a heavy product such as ATG is involved.
Don’t get me wrong. I am an ATG evangelist; It is one of the fantastic products that i have worked on. The reasons for delayed ATG implementations are not because of the product per say but largely due to the interpretation of what it does and mainly because of not giving due focus where it is needed. Let me get into some details:
Reason 1 – ATG is not a functional package but a fantastic toolkit:
It is not a functional package that allows you to chose the functionality out of the box like an SAP or Siebel etc but it is rather a framework. For instance, ATG gives you the relevant toolkit/framework and components to use and build your own features without needing to worry about the underlying technology implementation. So, I can build my own promotion types or change my own catalog structure. But can a business user make these changes and expect to see something on his/her website? The answer is No! You still need IT involvement to choose the UI template, extend your catalog by changing the relevant XML files, add new columns to the table and worry about publishing the data that business user sets to a separate database that is read by the website etc.
Reason 2 – ATG is like a lego block which is good and bad!:
It is almost like a lego block and lets you make whatever shape you want to make. This is fantastic from a flexibility standpoint but it also means that a lot of control is given away to the guy making the object off a lego block. The more complex the object under construction, the more complex it becomes to modify or maintain it.
Reason 3 – The cost of ignoring data:
When it comes to eCommerce, people tend to ignore the significance of working with data right from development. Developers focus mainly on the functionality and try working with dummy that makes the functionality work. A lot many issues related to data are caught when the business users start testing the product. Each attribute of a category, product or SKU is important as each attribute can participate in a promotion rule and change the behavior of a promotion or an offer. Also, the data as seen by a supplier is different from a merchandizer. So, if somebody does not sit and map the data elements from the backend source system to how it appears on the website, it can cause a lot of heartburn at the end of the implementation.
Reason 4 – Integration with third party:
eCommerce landscape is vast and there are lots of popular and niche services which can be integrated seamlessly with a platform such as ATG. For e.g.: BazaarVoice provides excellent Review and Rating service, Core Metrics and Choicestream provide product recommendations, Endeca provides search and navigation, Google provides the mapping service, Paypal, Cybersource, etc provide payment integration … the list goes on. Now, each of these integrations require work and sometime they can contradict each other. In one of our implementation, we found that the Axis based web service integration for Cybersource was conflicting with the Web service we had used for postal code lookup. Basically, Cybersource had implemented WS-Security and required few additional attributes in header while the postal code lookup did not want that. So, we ended up rewriting lot of code to make sure the conflict was removed.
Reason 5 – User Interface is key:
Choosing the right template for my category landing page, product details page, etc is extremely important and the earlier you make the choice, the better your implementation quality is. As ATG does not offer much help on UI look and feel front, the changes in look and feel also require you to make changes to code and test it thoroughly in different browsers, etc.
Reason 6 – Learning Curve:
ATG is not easy to understand for a novice. People often think that I know java and ATG is based on Java so, i know ATG. Even experienced folks in java struggle to understand the framework in one go. ATG implements fantastic design patterns which very few people can comprehend. It is all about Dependency Injection. Unless you have worked with frameworks such as Spring, it is very difficult to understand this. In fact, one good ATG interview question can center around this basic concept – How can you tell the formHandler which handle method to call? How does a module depend on other modules?
Pipeline is another design pattern that is implemented in ATG and this typically impacts your complete request and response processing. So, if one does not how to use the pipeline components (i.e. what should typically be a pipeline component and what should not), it can lead to issues which are very difficult to debug and solve. Droplets and tag libs are other components that are very ATG specific. There is a bit of learning curve in understanding these.
ATG is a vast and complex framework. Designing and implementing efficient projects in ATG require sound knowledge of technology fundamentals along with the knowledge of the framework. We have worked on rescuing many jeopardized ATG implementations and the reasons listed here are often the main factors behind derailing ATG implementations.