Friday Jun 20, 2014

Building Infinite Scrolling in Oracle Commerce

I have to start by saying that the approach I've taken to implement infinite scrolling may not be considered best practice.  I simply found an approach that worked for my purposes and I thought I would share…


Background
The application I'm working with is an internal Oracle application built on Oracle Commerce (version 10.1.2 / 3.1.2 at the time this was written).  It's not a commerce application, but it does use the ATG 'platform' (modules DSS and below), as well as Endeca.  I have a repository that I index in Endeca, and I leverage Endeca Experience Manager to render some of the key pages of the application.  So, as it relates to infinite scrolling, I was starting with an experience manager driven page which contained a ResultsList cartridge, not unlike what you may see in the Commerce Reference Store (CRS).

Approach
There is a generic approach to designing infinite scrolling.  At a high level, you remove any kind of paging logic, you use javascript to notice when the user scrolls to the bottom of the initial results, and when that happens, you make some kind of call to get more data, and you append that data to your results.  The affect is that it seems like as you scroll, the results just keep going.

As I got into it, I found that there's a bit more to consider…  How to make the scrolling seem smooth instead of feeling jerky.  How to work through all the javascript event logic so that there are no unnecessary calls being made.  How to keep track of what was handled by the paging logic (the last record received, how many to get next, etc).  I was happy to find that most of these were actually fairly easy to figure out.

The original ResultsList cartridge (mostly borrowed from CRS) had two JSP's; ResultsList.jsp, and paging.jsp.  Just about all the work was done in ResultsList.jsp and paging.jsp was called to provide the page links at the top of the results (so you could click page 1, 2, 3, 4, etc).

For infinite scrolling, I had to rearrange things.  First, I pulled out the results formatting logic from the ResultsList.jsp and put that in a new JSP called ResultsFormat.jsp.  ResultsFormat.jsp simply takes an array of records and formats them - into a table in my case.  What was left in ResultsList was the call to ResultsFormat as well as the new javascript logic that deals with handling scrolling.

The next JSP I created is called recordRequest.jsp and it was called (by ResultsList.jsp) whenever the user scrolled down and it was time to get more data.  Instead of cramming a bunch of Endeca java code into that JSP, I created a droplet (EndecaInfiniteScrollDroplet) which contained all the Endeca Presentation API work.  The droplet would query Endeca and return the results in an array.  The recordRequest JSP really did nothing but invoke that droplet and pass the results array to the RecordFormat.jsp.  

This is a good time to point out that using the ATG - Endeca integration and Experience Manager, when the page loads for the first time, you get a data element called contentItem.  The contentItem contains a number of things, one of which is the initial result set.  So, in my application, I configured the ResultsList cartridge to return 100 records at a time, so that initial page would have the first 100 records (available to me in the contentItem).  

I didn't want to change how that worked, I wanted to leave that part alone and only figure out how to get the subsequent records I need when the user scrolled down…  So, this left me in the situation where I'm getting Endeca records from two different places; the initial set from the contentItem, and the rest from calls using my droplet (called each time the user scrolled to the bottom of the page).  This is why I decided to create a single place to format the records - for reusability and consistency.  All I really had to do was to make sure that my droplet returned an array of records that was the same as what was available in contentItem.

So, there are a few more moving parts, but it's really not too bad.  To summarize, here's a list of the pieces:
  • ResultsList.jsp - the main JSP, contains the javascript to handle scrolling
  • ResultsFormat.jsp - takes an array of records and formats them appropriately
  • recordRequest.jsp - was called upon scroll, and it invoked a droplet to get more records
  • EndecaInfiniteScrollDroplet - encapsulates all the Endeca API code to get more records

Rather than try to paste sample code snippets into this post, I thought it would be easier if I just provided all the relevant code in case you want to browse through it (keep in mind, this is not at all supported - just sample code).  If you do try to implement this and have questions, please let me know and I'll do what I can to help.

Thursday Jun 27, 2013

Oracle Commerce Responsive Design white paper now available

There is a new white paper available here that covers how responsive design can be implemented on Oracle Commerce.  Have a look and let us know your thoughts!


-- Glen 

Monday Sep 24, 2012

Design for complex ATG applications

Overview

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.


Application Design

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...

Code / configuration - assemble into modules

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)
The next layer up could be multiple modules for each country (you could replace this with region if that makes more sense).  We'll define those modules as follows:

  • 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:



Web applications

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.


Reference infrastructure

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


Governance / organization

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

Summary

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.

Key ATG architecture principles

Overview

The purpose of this article is to describe some of the important foundational concepts of ATG.  This is not intended to cover all areas of the ATG platform, just the most important subset - the ones that allow ATG to be extremely flexible, configurable, high performance, etc.  For more information on these topics, please see the online product manuals.


Modules
The first concept is called the 'ATG Module'.  Simply put, you can think of modules as the building blocks for ATG applications.  The ATG development team builds the out of the box product using modules (these are the 'out of the box' modules).  Then, when a customer is implementing their site, they build their own modules that sit 'on top' of the out of the box ATG modules.  Modules can be very simple - containing minimal definition, and perhaps a small amount of configuration.  Alternatively, a module can be rather complex - containing custom logic, database schema definitions, configuration, one or more web applications, etc.  Modules generally will have dependencies on other modules (the modules beneath it).  For example, the Commerce Reference Store module (CRS) requires the DCS (out of the box commerce) module.

Modules have a ton of value because they provide a way to decouple a customers implementation from the out of the box ATG modules.  This allows for a much easier job when it comes time to upgrade the ATG platform.  Modules are also a very useful way to group functionality into a single package which can be leveraged across multiple ATG applications.

One very important thing to understand about modules, or more accurately, ATG as a whole, is that when you start ATG, you tell it what module(s) you want to start.  One of the first things ATG does is to look through all the modules you specified, and for each one, determine a list of modules that are also required to start (based on each modules dependencies).  Once this final, ordered list is determined, ATG continues to boot up.  One of the outputs from the ordered list of modules is that each module can contain it's own classes and configuration.  During boot, the ordered list of modules drives the unified classpath and configpath.  This is what determines which classes override others, and which configuration overrides other configuration.  Think of it as a layered approach.

The structure of a module is well defined.  It simply looks like a folder in a filesystem that has certain other folders and files within it.  Here is a list of items that can appear in a module:

MyModule:
  • META-INF - this is required, along with a file called MANIFEST.MF which describes certain properties of the module.  One important property is what other modules this module depends on.
  • config - this is typically present in most modules.  It defines a tree structure (folders containing properties files, XML, etc) that maps to ATG components (these are described below).
  • lib - this contains the classes (typically in jarred format) for any code defined in this module
  • j2ee - this is where any web-apps would be stored.
  • src - in case you want to include the source code for this module, it's standard practice to put it here
  • sql - if your module requires any additions to the database schema, you should place that schema here

Here's a screenshots of a module:

Modules can also contain sub-modules.  A dot-notation is used when referring to these sub-modules (i.e. MyModule.Versioned, where Versioned is a sub-module of MyModule).


Finally, it is important to completely understand how modules work if you are going to be able to leverage them effectively.  There are many different ways to design modules you want to create, some approaches are better than others, especially if you plan to share functionality between multiple different ATG applications.


Components

A component in ATG can be thought of as a single item that performs a certain set of related tasks.  An example could be a ProductViews component - used to store information about what products the current customer has viewed.  Components have properties (also called attributes).  The ProductViews component could have properties like lastProductViewed (stores the ID of the last product viewed) or productViewList (stores the ID's of products viewed in order of their being viewed).  The previous examples of component properties would typically also offer get and set methods used to retrieve and store the property values.  Components typically will also offer other types of useful methods aside from get and set.  In the ProductViewed component, we might want to offer a hasViewed method which will tell you if the customer has viewed a certain product or not.

Components are organized in a tree like hierarchy called 'nucleus'.  Nucleus is used to locate and instantiate ATG Components.  So, when you create a new ATG component, it will be able to be found 'within' nucleus.  Nucleus allows ATG components to reference one another - this is how components are strung together to perform meaningful work.  It's also a mechanism to prevent redundant configuration - define it once and refer to it from everywhere.

Here is a screenshot of a component in nucleus: 



Components can be extremely simple (i.e. a single property with a get method), or can be rather complex offering many properties and methods.  To be an ATG component, a few things are required:

  • a class - you can reference an existing out of the box class or you could write your own
  • a properties file - this is used to define your component
  • the above items must be located 'within' nucleus by placing them in the correct spot in your module's config folder
Within the properties file, you will need to point to the class you want to use:

$class=com.mycompany.myclass

You may also want to define the scope of the class (request, session, or global):

$scope=session

In summary, ATG Components live in nucleus, generally have links to other components, and provide some meaningful type of work.  You can configure components as well as extend their functionality by writing code.


Repositories

Repositories (a.k.a. Data Anywhere Architecture) is the mechanism that ATG uses to access data primarily stored in relational databases, but also LDAP or other backend systems.  ATG applications are required to be very high performance, and data access is critical in that if not handled properly, it could create a bottleneck.  ATG's repository functionality has been around for a long time - it's proven to be extremely scalable.  Developers new to ATG need to understand how repositories work as this is a critical aspect of the ATG architecture.  

Repositories essentially map relational tables to objects in ATG, as well as handle caching.  ATG defines many repositories out of the box (i.e. user profile, catalog, orders, etc), and this is comprised of both the underlying database schema along with the associated repository definition files (XML).  It is fully expected that implementations will extend / change the out of the box repository definitions, so there is a prescribed approach to doing this.  The first thing to be sure of is to encapsulate your repository definition additions / changes within your own module (as described above).  The other important best practice is to never modify the out of the box schema - in other words, don't add columns to existing ATG tables, just create your own new tables.  These will help ensure you can easily upgrade your application at a later date.

xml-combination

As mentioned earlier, when you start ATG, the order of the modules will determine the final configpath.  Files within this configpath are 'layered' such that modules on top can override configuration of modules below it.  This is the same concept for repository definition files.  If you want to add a few properties to the out of the box user profile, you simply need to create an XML file containing only your additions, and place it in the correct location in your module.  At boot time, your definition will be combined (hence the term xml-combination) with the lower, out of the box modules, with the result being a user profile that contains everything (out of the box, plus your additions).  Aside from just adding properties, there are also ways to remove and change properties.

types of properties

Aside from the normal 'database backed' properties, there are a few other interesting types:
  • transient properties - these are properties that are in memory, but not backed by any database column.  These are useful for temporary storage.
  • java-backed properties - by nature, these are transient, but in addition, when you access this property (by called the get method) instead of looking up a piece of data, it performs some logic and returns the results.  'Age' is a good example - if you're storing a birth date on the profile, but your business rules are defined in terms of someones age, you could create a simple java-backed property to look at the birth date and compare it to the current date, and return the persons age.
  • derived properties - this is what allows for inheritance within the repository structure.  You could define a property at the category level, and have the product inherit it's value as well as override it.  This is useful for setting defaults, with the ability to override.
caching

There are a number of different caching modes which are useful at different times depending on the nature of the data being cached.  For example, the simple cache mode is useful for things like user profiles.  This is because the user profile will typically only be used on a single instance of ATG at one time.  Simple cache mode is also useful for read-only types of data such as the product catalog.  Locked cache mode is useful when you need to ensure that only one ATG instance writes to a particular item at a time - an example would be a customers order.  There are many options in terms of configuring caching which are outside the scope of this article - please refer to the product manuals for more details.


Other important concepts - out of scope for this article

There are a whole host of concepts that are very important pieces to the ATG platform, but are out of scope for this article.  Here's a brief description of some of them:

  • formhandlers - these are ATG components that handle form submissions by users.
  • pipelines - these are configurable chains of logic that are used for things like handling a request (request pipeline) or checking out an order.
  • special kinds of repositories (versioned, files, secure, ...) - there are a couple different types of repositories that are used in various situations.  See the manuals for more information.
  • web development - JSP/ DSP tag library - ATG provides a traditional approach to developing web applications by providing a tag library called the DSP library.  This library is used throughout your JSP pages to interact with all the ATG components.
  • messaging - a message sub-system used as another way for components to interact.
  • personalization - ability for business users to define a personalized user experience for customers.  See the other blog posts related to personalization.

Thursday Feb 09, 2012

ATG in the Telecommunications Industry

The purpose of this post is to describe how ATG can help organizations in the Telecommunications industry achieve their online goals.  ATG has established a leadership role in the overall practice of online commerce and service.  Many of the top retailers around the world use ATG to drive their online business, and in many ways, retailers’ requirements for a commerce platform are similar to that of a Telco.   Common needs between the two industries include performance, scalability, advanced personalization capabilities, optimized business tools to control the site(s), and the need for a commerce platform that provides a careful balance between offering a rich feature set along with the ability to extend / customize the platform to meet the organizations needs.

ATG has proven success with some of the leading telco providers in the world.  We have worked closely with these organizations both to ensure their success as well as understand the value ATG delivers to them.  We have found that there are numerous requirements that are unique to the Telecommunication industry, some of which are discussed below.  When possible, we will also use this document to describe best practices for particular use cases.

Product availability / compatibility

The following examples are primarily geared towards the wireless product line, but the general concepts can be applied to other types of products as well.

Mapping between services and geography

It’s quite obvious that not all service plans are available in all geographic regions.  During the shopping process, it’s necessary for the customer to identify their geographic region (typically by entering their zipcode) in order for the site to only show service plans that are available in their area.  Measures should be taken to ensure that the customer does not have to enter this geographic information more than one time (preferably, across sessions).  ATG provides this capability as an out of the box feature (called Persistent Anonymous Profiles).  For more information on ATG Profiles, see this post.

Mapping between devices and services

Not all wireless service plans are available for all devices.  There needs to be a mapping between device and service plan to ensure that the customer selects a valid combination.  It’s common to represent this as a many to many relationship.  ATG’s Data Anywhere Architecture makes it possible to define these kinds of complex relationships. 

Mapping between accessories and devices

Not all wireless accessories will work with every device.  For example, an iPhone case will certainly not fit a Blackberry phone.  When a customer has selected a device, they should only be presented with accessories that will be compatible with that device.  Ignoring this need will certainly result in unhappy customers and a high return rate for accessories that are incompatible with the selected device.

How to present these complexities to the customer in a way that is intuitive within the shopping process

While it’s essential that the relationships above are enforced to avoid allowing the customer to purchase incompatible products, the work doesn’t stop there.  There are many ways to represent these relationships in the shopping process, but many of them may seem confusing to the customer.  Great care needs to be taken to ensure that the customer has an easy time understanding how to navigate these choices.  There are different approaches to this, some which are rigid and drive the customer down a particular path (see diagram below).  Others are more flexible, allowing the customer more freedom in their shopping process.  For example, perhaps the customer wants to select the device prior to selecting which service plan they want.  Which approach (or the degree of freedom your site employs) and it’s effectiveness will depend on your target audience.  ATG cannot make this decision for you, but there are tools in the platform that will help you to try different approaches, and measure the effectiveness of each with the goal of helping you to find the right mix for your customers. 

Technical side-note

The task of modeling the ATG catalog structure to accommodate the mapping described above should not be taken lightly.  Theoretically, there are many ways to do this, but there are two very important things to keep in mind:

  1. Depending on how the catalog is modeled, performance could be anywhere from very good to unacceptable given the complexity of the relationships between the items (compatibility).  Steps need to be taken to ensure that performance is acceptable during the customer experience.
  2. Regardless of the size of the catalog (number of items) or the complexity of the relationships between items, the catalog must be designed so that it's easy to manage.  Many times, data feeds will populate a significant portion of the online catalog, but the rest is usually managed using ATG's Business User tools (such as ATG Merchandising).  Take time to ensure that the design of the catalog can easily be managed by business users.

Personalization

What are common personalization goals for telcos?

The term Personalization means different things to different people, but within the context of the organizations online business, it generally boils down a few things; learning more about customer behavior, adapting the site to be more relevant to the customer, and helping guide the customer through various complex transactions (checkout, service, etc). A simple example of a common personalization use case would be the following:

  • A customer comes to the site, and enters their zipcode
  • Next, they spend some time browsing the Blackberry phones section of the site
  • You now know the geographic location of the customer, and the type of device they are likely to be interested in.  It would make perfect sense to adapt the site so that the 'featured devices' change from whatever the generic featured device set was for anonymous customers to something that would highlight the devices that seem most relevant to the customer.  Perhaps you could also offer a 'Which Blackberry is right for you' graphic that takes the customer to content that helps them to decide which Blackberry device is the best fit for their needs.  All the while, you could highlight some service plans that are available in their area as well as compatible with Blackberry devices.

To ATG, Personalization is part technology, but to a larger degree, it’s a strategy that our customer must define.  Our goals are to ensure that our tools enable our customers to fully implement their Personalization strategy as well as to provide best practices around personalization.  Click here for more information about ATG Personalization.

Product Bundling

Pre-defined by business

Bundling products and services together into logical sets of offerings has numerous advantages; provides the customer with an easier way to purchase the set of products / services, allows the organization to have more flexibility with respect to pricing, and it increases the adoption rate of less popular products by bundling them with the more popular items at a perceived low cost.  The task of determining the bundle mix is almost always done at a high level within the Marketing department, and then implemented across all the channels in a consistent manner.  The online channel needs to be flexible enough to handle any bundle mix the Marketing department defines.

Flexible

Although the business will likely define the basic structure of the bundles, there is usually some degree of flexibility offered to the customer within the bundle structure.  For example, a particular bundle may require that the customer select from a certain class of broadband, select various options for their home phone service, and select certain options for their TV service.  The choices they make within the three products (internet, phone, and cable) will affect the overall package price.  The bundle now has a well-defined set of products included, but with some degree of configurability within each product.

Reverse engineering into a ‘better package’

Another concept that some organizations strive for is to recognize which products a customer already owns (or has in their cart), and try to upsell them into a ‘better package’.  The better package would likely be a bundle that includes all the products they currently have as well as one that they customer does not have.  The advantage to the customer is that they can get an additional product for a small cost (due to how the bundle is priced).  The advantage to the organization is that they increase their adoption rate for the added product.

Custom storefronts  (B2B)

While the B2C site will typically drive the most traffic, the B2B sites may actually be driving the most revenue.  The B2B site will be the destination for your business clients to manage their services, order additional devices, etc.  Each of these sites will typically have a common set of capabilities, but will differ to some extent in terms of products available, pricing, and will generally have a co-branded look and feel.  For the sake of simplifying the terminology, let's call each business clients site a microsite.  Most of the requirements for the B2C site will also be required for the B2B site.  In addition, the B2B site will likely have some additional requirements as follows:

  • Catalog - Each microsite will need to show only the products that are allowed based on the contract between the tow companies.  ATG provides this capability in the form of ATG Custom Catalogs.
  • Pricing - Each microsite will need to apply specific (negotiated) pricing based on the contract as well.  ATG provides this capability via ATG Price Lists.
  • Organizations / roles / approval workflow - The business clients will need some security in place to ensure that people are creating orders that are appropriate for their business.  This means that the ability for them to 'self-administer' the site becomes critical.  These include functions like being able to define a multi-level organization, ability to assign meaningful roles to people, and defining an approval workflow for orders placed (including limits on order values).  ATG provides all of these capabilities.
  • Presentation / UI - Each business client may prefer some kind of unique style for their microsite.  There are plenty of different ways to accomplish this in ATG, and the best approach will depend on how you envision these creative aspects being managed.

Merchandising / Content Management

Managing a commerce site depends on a variety of people with a range of different skill sets and responsibilities.  One of the more important aspects to managing a commerce site is how to manage the catalog as well as the content.  ATG provides  a number of tools that allow business users the ability to make the necessary changes to both the catalog and content.  The primary tool for this purpose is ATG Merchandising.

Regardless of the types of products contained in the catalog (wireless devices, service plans, media downloads, etc), there will almost always be attributes that need to be added to the definition of the category, product, and SKU.  ATG's catalog is extremely flexible, and is designed to be extended in this way.  For example, the out of the box SKU definition does not have a property called 'GPS Enabled' with a true or false value.  This may be something you will need to add to the definition of the SKU in order to properly present the details about the product (or to use this attribute in rules where you filter out any SKUs that have that property set to false).  The point is that every ATG implementation will require some degree of extending the catalog definition, and the ATG business user tools will automatically interpret those extensions and present the UI appropriately with no additional coding.

Promotions / Discounts

Many retailers tend to make great use of discounts in order to entice customers to place orders.  Telecommunications organizations have the opportunity as well, but probably not with the same degree of flexibility.  Promotions / discounts for telecommunications sites tend to be used more as an instrument to affect pricing overall.  The most obvious way to affect pricing is by altering the actual price of a product in the price list.  It's also common to set the price of a bundle to a particular base price, and then the price will adjust up based on the options the customer selects.  If there is a desire to move more customers into a more expensive option, discounts could be used to give the impression to the customer that they are getting a good deal.  ATG provides for the ability to offer percent off, amount off, or fixed price on items, orders, or shipping.

Multi-language / multi-currency

Many sites will have a requirement where they need to present the catalog / content in multiple languages, as well as present pricing in multiple currencies.  This is especially true in Europe.  ATG's commerce platform fully supports multiple languages and multiple currencies.  Some ATG customers decide to create a single site supporting multiple languages and currencies (a centralized approach), while other customers will instead create a different site for each country that will only support a single language and currency (distributed approach).  Which approach you choose is up to you, but it's important to note that either is possible.

Self service / My Account

Online service is an essential aspect to overall customer satisfaction and retention.  Online service can involve a number of areas including finding the answer to a technical question, viewing statements, paying your bill, changing service plan, etc.  Some of these functions are best handled by exposing functionality from the backend systems as opposed to building this functionality in ATG.  A good example is viewing past statement.  There is no real benefit to re-creating this functionality within ATG as there is not likely to be any personalization or selling opportunity within that context.  Rather, it's probably better to simply get the customer the information they are looking for as quickly as possible.

Alternatively, ATG does offer a series to applications that can certainly help customers find answers to commonly asked questions.  This would be an example of functionality that is most likely best delivered by ATG.  In fact, if the customer has authenticated (we know some information about them) then there may be the opportunity to enhance their self service experience by guiding them to the most appropriate information based on what we know about them (products owned, etc).

This is an area where it's common to have some overlap between ATG and other applicaitons, so it's important to have a clear understanding of the capabilites of each applicaiton, as well as a clear understanding of what you're trying to achieve in this area.

Integrations

Without a doubt, the backend systems within the typical telecommunications organization are highly complex.  There are usually many systems which provide various functions, and each one tends to have it's own lifespan (recently added, mid-life, being phased out), which means there may be a situation where there is an 'old' customer master, and a 'new' customer master in production at the same time.  There is usually a mix of enterprise applications which have been customized to some degree, along with applications built internally by the IT group.   It's common for the IT group to split their time between supporting the enterprise applications and creating the integration infrastructure between them.

Virtually all ATG implementations require integrating to a number of third party applications, and it's no surprise that this tends to be a very important aspect of building out the site.  Some common integration points include things like sending the order to an order management system, receiving catalog feeds, pricing feeds, inventory feeds, tax calculation services, payment processing services, cross channel customer lookups / matching, fraud detection services, etc.  There are things for the IT group to consider when designing an integration:

  • Should the integration be real-time or batch?
  • Should it be synchronous or asynchronous?
  • What transport should we use?
  • How should we handle error conditions?

The ATG platform contains a variety of tools / API's that will help the IT group to simplify / standardize these integrations.  The Data Anywhere Architecture, Web Services, and Integration Framework should be considered when designing integrations to these backend applications.

Business concepts

Think like a retailer

This just make sense...  If you want to be effective at selling online, then you should think and act like a retailer.  In other words, you need to:

  • Merchandise the site in a simple and coherent manner.  The goal is to help customers navigate to the products / services they want as quickly as possible.
  • Provide an intuitive shopping process and avoid exposing all the complexities normally encountered when purchasing complex items.  Remember, the primary goal is to complete the sale, so creating unnecessary obstructions to checkout will make only push you further away from your goal.
  • Ensure that the site performs well.  Nobody likes to shop on a slow site.
  • Don't feel compelled to offer every product possible online as some of them just don't fit very well.  Use the 80/20 rule here and sacrifice complex situations to retain the simplicity of the customer experience.

Be open to re-org (combine business & IT into a closely knit group)

Consider creating a new online commerce group that is comprised of everyone who will actively maintain or support the site including both business and technical people.  This concept has had proven success in the past for a number of reasons:

  • Faster time to market - By bringing the technical and business people together, changes to the site tend to happen in much less time because the walls between the groups have come down.
  • Common goals - Everyone in this group should be measured by the performance of the site.  In this kind of environment, people tend to become much more cooperative in order to meet their common goals.
  • Single focus - People in this group should have a very sharp focus on the online business, and their level of channel expertise will increase over time.

Ensure the business is actively driving requirements (beware of making false assumptions)

Telecommunications organizations are commonly IT driven companies.  Creating an effective online commerce application absolutely requires the synchronized efforts of both the IT group as well as the business side.  

Conclusion

In order to compete in the extremely competitive online commerce space, Telecommunications organizations will need to find ways to differentiate themselves in the eyes of their customers and business clients.  ATG's commerce platform provides an an excellent foundation to build your customer facing sites on.  Many leading Telecommunications organizations around the world have already experienced success online with ATG.  Hopefully, this post has provided some insight into how ATG can help these organizations meet their online goals.

About

Welcome to the Oracle Commerce Product Strategy Community. We are dedicated to driving Best Business Practices across Oracle ATG products, Oracle ATG and Endeca Solutions and overall eCommerce Strategy. We welcome all collaborative discussions on blog posts. If you have a question for one of our experts, feel free to ask it here:
ATG Business Forum

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today