ATG Dynamo – back to basics

I worry that ATG has mis-focused it’s energy.

In the last few years, ATG has introduced (or purchased) a number of new products which sit on the existing stack. Ticketing Features, Search, Merchandising, Campaign Optimizer, Knowledge, Self Service, Response Management, Commerce Service Center, Outreach, and Customer Intelligence). I haven’t had a chance to play with all of them yet. I’m sure they’re all very neat. I’m more sure that they help sell license dollars to marketing and business people.

I’m not trying to undercut the value in that. I see it. I totally think ATG should be expanding their offering, meeting customer needs, making money, etc… What bothers me is that if you look at the same time period which all of those new product were introduced, you’d see almost no changes or enhancements to the underlying product stack, what they now call the ATG Adaptive Scenario Engine (or ASE) which consists of DAS (ATG Dynamo Application Server) or DAF (Dynamo Application Framework), DPS (Dynamo Personalization Server), and DSS (Dynamo Scenario Server). Sure, there are some bug fixes, a little feature here and there (like adding forgot password support in 2006.3). But nothing significant. The programmers guides for ATG 7.0, 7.1, 2006.3, and 2007.1 look REALLY similar.

New features in DAS/DAF, DPS, and DSS may not close multi-million dollar deals, but they DO help your developers, and that satisfaction is often the key to a company staying on a platform versus moving to another option.

Some examples of technologies I would have liked to see integrated into the core stack:

• JSF: JSF itself can be difficult to use, but with Facelets or better yet a JBoss Seam style support framework, it is a real pleasure. Even if ATG didn’t want to adopt JSF, supporting some JSF style features would be great. Things like templating, themes, richfaces style AJAX generating libraries, and so on.
• EL: I’d love to see EL used all over.
• Logging: Why do we have to wrap all of our logging calls in the if(isLogging…) block? Make the logging call smart enough to know when to log and when not to log. Oh, you’re worried about the performance impact of all the String construction and concatenation that happens in the log statements, and doing that all the time even if the logging level in question is disabled? Use EL and placeholders like Seam does. logDebug(“Creating user #{Profile.username} at #0”, System.currentTimeMillis()); Then the String concatenation only happens inside the logDebug method IF that log level in enabled.
• Better AJAX and Flash/Flex front end integration support.
• JMX/MBean management used extensively.
• Security. The current security around the ACC, RMI exposed calls, the connection module -> DRP transport, etc… are all pretty bad.
• OpenSSO support, SAML support, etc…
• A database schema reverse engineering tool to create repository definitions from an existing set of tables.
• Conversation scope: This has been needed for years.
• Out of the box javascript to provide additional request data such as resolution, connection speed (best guess), OS and browser info, etc… I want all the information that google analytics can come up with, available for personalization and scenarios without having to hack together my own javascript and back-end AJAX-y receiver.
• The ability to flip a single config and get google analytics style metrics. Yes, I know I can configure all sorts of scenario driven logging and reports and what not. But I want a “metricsOn=true” flag and a nice dashboard I can give to a business person.
• CA-Lite: I want to be able to define content or a page region as dynamic, update it through a handy admin with a preview function and maybe some go-live go-dead dates. I don’t need versioning, or publishing workflows. I just want to be able to say “this block here is dynamic”, and then go in and create and edit content for that block. No new database tables, no Slot configuration. Something simple and out of the box.
• Captcha
• Page Flow: something like Java Page Flow or jPDL. The ability to define the site map graphically, and the transitions and transition actions or state changes or state pre-requisites in a single location is amazing.
• Support for jPDL and BPEL in the same process management engine that drives scenarios. Or make scenarios into BPEL flows. Or something.
• Cluster management tools: let me see the health, state, performance, uptimes, etc… of my whole cluster. Let me change a property cluster-wide. Let me bring instances in and out of my cluster from a single admin point. Some of that buck gets passed to the App server seeing as DAS is a dead product now, however there’s still a lot of DAF and ATG specific information and actions which make sense to have available at a cluster level.
• Documentation: the documentation has holes and issues.
• EAR Packaging improvments: the documentation, tools, and testing around this whole area leave a lot to be desired. Getting existing application packaged up easily is harder than it looks, and there are lots of odd errors that crop up. If you’re going to drop DAS, you better have AMAZING support for getting people going on JBoss and WebLogic.
• Etc…

I could keep going, but you get the idea. There’s lots of room for improvement in DAS/DAF, DPS, and DSS, and yet they have really been languishing for years. Even ATG Commerce has been pretty stagnant, with the possible exception of Merchandising (which is itself just a set of templates around CA), which really is a new add-on, not an enhancement of the core ATG Commerce framework.

Does ATG have to keep up with something like JBoss? No, of course not, but these gaps have been there for years.

Anyhow, consider this a plea for ATG to spend some time really focusing on delivering the best, most up-to-date framework they can, supporting the latest and greatest technologies that everyone is using.