Needless to say, some ATG applications are more complex than others.  Some ATG applications support a single site, single language, single catalog, single currency, have a single development staff, single business team, and a relatively simple business model.  The real complex applications have to support multiple sites, multiple languages, multiple catalogs, multiple currencies, a couple different development teams, multiple business teams, and a highly complex business model (and processes to go along with it).  While it's still important to implement a proper design for simple applications, it's absolutely critical to do this for the complex applications.  Why?  It's all about time and money.  If you are unable to manage your complex applications in an efficient manner, the cost of managing it will increase dramatically as will the time to get things done (time to market).  On the positive side, your competition is most likely in the same situation, so you just need to be more efficient than they are.

This article is intended to discuss a number of key areas to think about when designing complex applications on ATG.  Some of this can get fairly technical, so it may help to get some background first.  You can get enough of the required background information from this post.  After reading that, come back here and follow along.

Of all the various types of ATG applications out there, the most complex tend to be the ones in the telecommunications industry - especially the ones which operate in multiple countries.  To get started, let's assume that we are talking about an application like that.  One that has these properties:

• Operates in multiple countries - must support multiple sites, catalogs, languages, and currencies
• The organization is fairly loosely-coupled - single brand, but different businesses across different countries
• There is some common functionality across all sites in all countries
• There is some common functionality across different sites within the same country
• Sites within a single country may have some unique functionality - relative to other sites in the same country
• Complex product catalog (mostly in terms of bundles, eligibility, and compatibility)

At this point, I'll assume you have read through the required reading and have a decent understanding of how ATG modules work...

When it comes to defining your modules for a complex application, there are a number of goals:

• Divide functionality between the modules in a way that maps to your business
• Group common functionality 'further down in the stack of modules'
• Provide a good balance between shared resources and autonomy for countries / sites

Now I'll describe a high level approach to how you could accomplish those goals...  Let's start from the bottom and work our way up.  At the very bottom, you have the modules that ship with ATG - the 'out of the box' stuff.  You want to make sure that you are leveraging all the modules that make sense in order to get the most value from ATG as possible - and less stuff you'll have to write yourself.  On top of the ATG modules, you should create what we'll refer to as the Corporate Foundation Module described as follows:

• Sits directly on top of ATG modules
• Used by all applications across all countries and sites - this is the foundation for everyone
• Contains everything that is common across all countries / all sites
• Once established and settled, will change less frequently than other 'higher' modules
• Encapsulates as many enterprise-wide integrations as possible
• Will provide means of code sharing therefore less development / testing - faster time to market
• Contains a 'reference' web application (described below)

• Sits on top of the corporate foundation module
• Contains what is unique to all sites in a given country
• Responsible for managing any resource bundles for this country (to handle multiple languages)
• Overrides / replaces corporate integration points with any country-specific ones

Finally, we will define what should be a fairly 'thin' (in terms of functionality) set of modules for each site as follows:

• Sits on top of the country it resides in module
• Contains what is unique for a given site within a given country
• Will mostly contain configuration, but could also define some unique functionality as well
• Contains one or more web applications

The graphic below should help to indicate how these modules fit together:

As described in the previous section, there are many opportunities for sharing (minimizing costs) as it relates to the code and configuration aspects of ATG modules.  Web applications are also contained within ATG modules, however, sharing web applications can be a bit more difficult because this is what the end customer actually sees, and since each site may have some degree of unique look & feel, sharing becomes more challenging.  One approach that can help is to define a 'reference' web application at the corporate foundation layer to act as a solid starting point for each site.  Here's a description of the 'reference' web application:

• Contains minimal / sample reference styling as this will mostly be addressed at the site level web app
• Focus on functionality - ensure that core functionality is revealed via this web application
• Each individual site can use this as a starting point
• There may be multiple types of web apps (i.e. B2C, B2B, etc)

There are some techniques to share web application assets - i.e. multiple web applications, defined in the web.xml, and it's worth investigating, but is out of scope here.

In this complex environment, it is assumed that there is not a single infrastructure for all countries and all sites.  It's more likely that different countries (or regions) could have their own solution for infrastructure.  In this case, it will be advantageous to define a reference infrastructure which contains all the hardware and software that make up the core environment.  Specifications and diagrams should be created to outline what this reference infrastructure looks like, as well as it's baseline cost and the incremental cost to scale up with volume.  Having some consistency in terms of infrastructure will save time and money as new countries / sites come online.  Here are some properties of the reference infrastructure:

• Standardized approach to setup of hardware
• Type and number of servers
• Defines application server, operating system, database, etc... - including vendor and specific versions
• Consistent naming conventions
• Provides a consistent base of terminology and understanding across environments
• Defines which ATG services run on which servers
• Production
• Staging
• BCC / Preview
• Each site can change as required to meet scale requirements
  

It should be no surprise that the complex application we're talking about is backed by an equally complex organization.  One of the more challenging aspects of efficiently managing a series of complex applications is to ensure the proper level of governance and organization.  Here are some ideas and goals to work towards:

• Establish a committee to make enterprise-wide decisions that affect all sites
• Representation should be evenly distributed
• Should have a clear communication procedure
• Focus on high level business goals
• Evaluation of feature / function gaps and how that relates to ATG release schedule / roadmap
• Determine when to upgrade & ensure value will be realized
• Determine how to manage various levels of modules
• Who is responsible for maintaining corporate / country / site layers
• Determine a procedure for controlling what goes in the corporate foundation module
• Standardize on source code control, database, hardware, OS versions, J2EE app servers, development procedures, etc
• only use tested / proven versions - this is something that should be centralized so that every country / site does not have to worry about compatibility between versions
• Create a innovation team
• Quickly develop new features, perform proof of concepts
• All teams can benefit from their findings

At this point, it should be clear why the topics above (design, governance, organization, etc) are critical to being able to efficiently manage a complex application.  To summarize, it's all about competitive advantage...  You will need to reduce costs and improve time to market with the goal of providing a better experience for your end customers.  You can reduce cost by reducing development time, time allocated to testing (don't have to test the corporate foundation module over and over again - do it once), and optimizing operations.  With an efficient design, you can improve your time to market and your business will be more flexible  and agile.  Over time, you'll find that you're becoming more focused on offering functionality that is new to the market (creativity) and this will be rewarded - you're now a leader.

In addition to the above, you'll realize soft benefits as well.  Your staff will be operating in a culture based on sharing.  You'll want to reward efforts to improve and enhance the foundation as this will benefit everyone.  This culture will inspire innovation, which can only lend itself to your competitive advantage.