The Current State of ATG Oracle Commerce
In my previous blog post I covered the origins and marketing winning strengths of the ATG eCommerce platform. Today I want to talk about the current state of the ATG platform, now known as Oracle Commerce.
Overly Mature Technologies
When ATG was being written, core technologies had to be invented since there was nothing else out there. Those brand new technologies were, and in many ways still are, great. Nucleus, Repositories, the Servlet Request Pipeline, Scheduler, the Profile system, the Cache system, the Catalog system, Inventory, CSC, BCC, and more were created out of that initial necessity. However, in the past 15-20 years very little has changed. The Repository framework is largely the same as it was 20 years ago. That it still functions and performs as well as it does today is a testament to how brilliantly it was designed at its initial inception.
However, the lack of innovation and lack of continued investment in the core technologies of the platform have led to a great deal of non-standards based, antiquated technology. In the past decade, or longer, most of the changes to the ATG Oracle Commerce platform have been adding 3rd party integrations (primarily to other Oracle products, and then discontinuing those integrations later), or slowly adding acquired technology into the platform, like Endeca Search and Experience Manager. While some of these integrations provide great value, many of them are little more than adding new paint or new shiny wheels on your older-model car. Meanwhile the engine, brakes, and frame haven’t been touched in 20 years.
One clear, but basically harmless, example of this neglect is that the ATG Oracle Commerce web admin is still written using JHTML pages! It has been over 18 years since ATG recommended moving from JHTML to JSP, and yet there are still 599 JHTML pages in the ATG Oracle Commerce product itself.
A much more dangerous issue is the amazingly slow progress made on removing Flash Flex from the BCC interface. Oracle has been working on this for over five years. Initially, it was to be a move to pure HTML5, and now to Oracle JET. This migration was finally completed in the Oracle Commerce 11.3.2 release. Unfortunately, this leaves a major problem for all clients using any versions older than 11.3.2, which only came out a few months ago. As of the end of 2020, Flash support will be removed from browsers, and this will cause major issues for retailers using the BCC or CSC applications.
While the BCC UI is certainly complex, it should not have taken five years to upgrade it from Flash to HTML5. That should have been a focused project and could have taken less than a year, rather than being a back-burner goal that was done in small bits over years and years.
Missed Opportunities
There’s certainly wisdom in “if it ain’t broke, don’t fix it”. A stable mature platform that still performs well shouldn’t be thrown away needlessly. However, the lack of investment in the core of the platform is showing through today. It’s much harder to find developers for ATG Oracle Commerce, since it’s essentially built entirely on old proprietary technologies rather than commonly used modern frameworks and tools. It also means that many fundamental improvements in the Java language aren’t used within the platform.
Off the top of my head, Java has introduced things like NIO, resource management in try statements, Optionals, Generics, Annotations, Lambda expressions, Streams, Modules, Logging, and more since the ATG code base was written. Not only are those generally not used in the Oracle Commerce code, but in your own custom code it’s implicitly discouraged or sometimes impossible, to really leverage modern development approaches due to the need to adhere to the older technology used in the platform itself.
Imagine, if you will, an alternate universe Oracle Commerce, where the core code is using modern Java features with all the performance and scaling gains therein, where Annotations are used instead of inheritance, where common technologies like Hibernate, Spring, Thymeleaf, Grade or Maven, etc. are all used. You’d have a higher performing and easier to extend system, which would also be easier for developers to work on due to less core proprietary tech.
Another area of concern is the lack of updates to the overall architecture of the platform. Certain architectural choices, which made perfect sense initially, make it difficult or impossible for ATG Oracle Commerce to take advantage of modern DevOps approaches like CI, Cloud, Auto-Scaling, Auto-Healing, Docker, Micro-services, Headless, and Serverless. For example, the BCC deployment topology architecture makes auto-scaling and auto-healing extremely difficult to achieve (although we have done it here at Black Magic Consulting).
While Oracle has slapped some REST-like web service endpoints onto the platform, it’s far from a micro-services based architecture at any level. While many other web and Ecommerce platforms now come with Docker images, CloudFormation deployment magic, AWS friendly architecture, rapid development support and tooling, etc., ATG Oracle Commerce development and deployment is a very complex and manual process, and hasn’t changed in ages.
Neglect of a Platform
ATG Oracle Commerce 11.0 was released on January 11th, 2014. In over 6 years, we are only up to 11.3.2. A few point releases, no major releases, and I would argue very little to show for 6 years of development effort by a company with the resources of Oracle. It’s clear, to me at least, that Oracle is focused on Oracle Commerce Cloud and is letting the on-premise Oracle Commerce platform die on the vine through purposeful neglect. Times have changed, and unfortunately ATG Oracle Commerce has not.
