Any customer can have a car painted any colour that he wants so long as it is black.
~ Henry Ford
Ford’s now-famous words seem a little quaint today.  We live in the Golden Age of the Consumer, where virtually everything can be customized or personalized in some way.  If you can customize mass-produced consumer goods, it seems reasonable to expect that you should be able to customize something as strategic and mission-critical as an enterprise resource planning system, too.  But just because you can, does this mean that you should? Personalizations are Persistent The E-Business Suite has acquired increasingly-powerful personalization features over the years.  These features allow you to personalize existing EBS screens with your own branding, corporate logos, colour schemes, field names, explanatory messages, and more.  My fellow blog authors have previously written about personalization options here (for Forms personalization) and here (for OA Framework personalization).  These types of personalizations are metadata-driven, which means that they are preserved and work even when the underlying screens are updated by EBS product teams via new patches.  This is the primary benefit of using the standard Apps personalization features: your changes are persistent and will continue to work even if the underlying screens are patched at a later date.  Going Beyond Personalizations You might have a unique service offering, product, or business process.  You might need to capture or manage information about your business, products, or customers in a way that differs markedly from the way the E-Business Suite’s designers originally intended.  From a system administrator’s perspective, you might need to deploy the E-Business Suite in an architecture, topology, or system configuration that aren’t supported via AutoConfig yet.  The E-Business Suite’s personalization features, while useful, may not be sufficient to meet these types of specialized requirements.  At this point of your analysis, it will be useful to consider the advantages, disadvantages, and implications of customizing your the E-Business Suite in an invasive way. There are many ways of customizing or extending your EBS environment.  These include:
  • New business rules or data transformations
  • New or custom screens
  • Integrations with external systems
  • Use of third-party utilities or extensions
  • Creation of new reports
  • Creation of new workflows
  • Integrations with standalone APEX applications
All of these customizations need to be considered in terms of their invasiveness.  The more invasive the change, the greater the long-term implications. Advantages of Customizations
  1. Functionality meets your requirements more closely
Disadvantages of Customizations
  1. More costly than deploying a “plain vanilla” solution
  2. Requires specialized development skills
  3. May require updates, testing, and maintenance whenever:
    • New EBS patches are released
    • New architectures are deployed
    • New technology certifications are released
  4. Increases support complexity and overhead
  5. Can potentially complicate upgrades to new EBS releases
Understanding the Implications of Customizations As regular readers of this blog know, we frequently release new technology stack patches, certifications, architectures, and systems management features.  Apps product families (e.g. Financials, Supply Chain, Human Resources, etc.) aren’t standing still, either.  They’re constantly updating their products with new features and enhancements, too. Let’s assume that you have the resources to address the first two potential issues of increased cost and skills.  What remains are the implications of keeping up with your friendly developers at Oracle:  
Testing Implications I’ve spoken with a number of customers who tell me that their customizations have prevented them from applying the latest ATG Rollup or upgrading to the latest database release.  They might have had staff to perform the original customizations years ago, but they no longer have the capacity to regression test their environments with new patches or technology stack components.  In some cases, formal development records detailing the customizations have been lost, making it extremely difficult to perform any impact analyses or tests.  These customers can’t go forward, and they can’t undo their customizations, either.  These customers are stuck. If you’ve customized your E-Business Suite environment in some way, you need to ensure that every new certification, patch, or newly-supported architectures work in your customized environment.  Depending upon what you’re considering introducing into your environment, you may need to perform functional tests, performance benchmarks, scalability testing, and even security reviews.  If you’re thinking of customizations, it is extremely important not to underestimate the costs of maintaining and testing them. Support Implications If I were an IT manager considering customizing the E-Business Suite, the primary factor affecting my decision would be the support implications.  Oracle certifies and supports generic E-Business Suite environments.  If you invasively customize your system in some way, you should understand and plan for the fact that Oracle can only provide patches for issues that can be reproduced in uncustomized, “plain vanilla” E-Business Suite environments. Customers who can succinctly describe their customizations when logging Service Requests with Oracle Support will have a distinct advantage over those customers who wait for Oracle Support to stumble over a customization.  Upgrade Implications Premier Support for E-Business Suite Release 11i ends in November, 2010.  At OpenWorld this year, it was abundantly clear that many of you are planning your upgrades to E-Business Suite Release 12 now.  If you’ve customized your Apps 11i environment in some way, your Apps 12 upgrade plan needs to consider whether those customizations are still needed.  Given the many new features in EBS 12, it’s entirely possible that your customizations may now be redundant or obsolete.  One major Apps 11i customer with several thousand customizations observed that at least half of those were already built directly into R12, obviating the need for forward-porting.
Tipping the Scales I’ve had the pleasure of working with countless EBS customers over the years.  My impressions are that systems administrators with uncustomized Apps environments are generally more-receptive to keeping up with the latest patches, are more willing to consider upgrades and trying new technologies.  This makes a lot of intuitive sense. As a battle-scarred Oracle developer, I would venture that very few customers can justify the extremely-high costs and long-term systems management implications that come along with invasive customizations.  That said, every customer has their own business case for customizations.  Your mileage will vary.  Everyone going through this analysis will have their own factor weightings, costs, and benefits of customizing their EBS environments. I’d be interested in hearing your war stories about customizations, both good and bad.  Feel free to share them in a comment or by dropping me a line.  Related Articles