Any customer can have a car painted any colour that he wants so long as it is black.
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?
~ 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:
Advantages 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:
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
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
Advantages of Customizations
- Functionality meets your requirements more closely
- More costly than deploying a "plain vanilla" solution
- Requires specialized development skills
- May require updates, testing, and maintenance whenever:
- New EBS patches are released
- New architectures are deployed
- New technology certifications are released
- Increases support complexity and overhead
- Can potentially complicate upgrades to new EBS releases
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 ImplicationsTipping the Scales
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.
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
- Forms Personalization - Get It While It's Hot!
- Getting Personal with OA Framework Pages
- New Whitepaper: E-Business Suite Development Using OAF & ADF
- Extended Support Fees Waived for EBS 11.5.10 and 10gR2 DB Through 2011
Comments (10)
Hi Steven, thanks for your great blog entries, it's always very helpful what you and your colleagues post here.
Regarding customizations: agree with you from the technical perspective that customizations are increasing complexity and bring a lot of risks and costs and additional work.
However I think you forget the functional perspective here: it's not that we create customizations because we like them, it's because the features that we need are not available in the standard software.
In our system we made a couple of customizations and till now we did not face major issues with customizations when it comes to patching/upgrading. So I think it's more important to have certain guides and rules for implementing customizations. If you follow those recommendations you are not 100% safe but at least can avoid many conflict situations.
Next to that personally I always differentiate in my developments between "extensions" and "customizations". The extensions offer additional functionality on top of the standard functionality, and worst case that should happen after patching/upgrading is that the extension does not work anymore, but the standard functionality is still guaranteed. A customization is for me then really changing standard behavior.
So besides of looking at it from a technical or admin perspective I would love to see an article focusing on development. We know the Developers Guide, but it's a heavy book... a short overview of the most important "DOs and DONTs" for customizations would be nice. But I guess creating such a list is not an easy task.
Thanks, David.
Posted by David Weber | November 11, 2009 1:21 AM
Posted on November 11, 2009 01:21
Dear Steven,
Is there any guidelines/ framework methodology in particular in the form of Templates which will be helpful for clients like Military Hospitals, when they go for Oracle EBS R12 Implementation from prior legacy systems.
Best Regards,
Balasubramanian.C
ERP Systems Analyst-Oracle EBS R12
Posted by Balasubramanian | November 12, 2009 1:36 AM
Posted on November 12, 2009 01:36
Steven,
Great article and as you stated, how many miles is your leash is the question. Organization, often view IT as a silver bullet and instead of taking a hard look at their business processes will prefer to customize or extend the e-business suite. Much easier to have our development staff create a new form instead of mapping our processes to the out of the box form or report!
Well… once you reach the end of your leash and your IT department realizes all they are doing is supporting those customizations is when the real discussions start happening. At least this is how we got there at my organization. Spending 10 developers’ time to upgrade from 11.03 to 11i meant stopping any new development for the organization for over a year. Now release 12 is knocking on the door and this will imply seriously looking at decommissioning customizations and extensions. Now the organization gets it, feels it and they hopefully understand the cost of customizing and extending the e-business suite.
Gaby
Posted by Gaby | November 12, 2009 5:04 AM
Posted on November 12, 2009 05:04
Dear Balasubramanian,
I'm not personally familiar with any such templates, but that doesn't mean much. I'm in Development, not Consulting, so I don't have a lot of visibility into the scope of our "EBS Accelerators," which are created for various vertical industries and uses.
If you'd like, I can pass your email on to someone in our Oracle Consulting group on your behalf; they can look into this for you. Let me know if you'd like someone to contact you about that.
Regards,
Steven
Posted by Steven Chan
|
November 12, 2009 8:50 AM
Posted on November 12, 2009 08:50
Hi, David,
I fully agree with you: indeed, there are features that some customers consider mission-critical that aren't built into the E-Business Suite.
I also agree that there's an important distinction between "extensions" and "customizations," but this is a pretty subtle one that's often lost on developers who are new to the E-Business Suite. I would consider custom code that's loosely-coupled with the E-Business Suite to be an extension, but an invasive change to code or screens provided by Oracle Development to be a customization.
Building extensions according to the guidelines laid out in the Developer's Guide is a bit of an art, naturally. I think your suggestion of having a short overview of the key principles is a good one. I've passed it on to our Applications Technology Group, the group that owns that guide. This is the perfect kind of material for either a whitepaper, a conference session, or even a web-based seminar.
Regards,
Steven
Posted by Steven Chan
|
November 12, 2009 10:02 AM
Posted on November 12, 2009 10:02
Hi, Gaby,
"How many miles is your leash?" is a great way of putting things.
Back when I was a management consultant, I often preached that using specialized IT systems that supported unique business processes was a way of creating competitive differentiation.
But that's really only true for very unique, customer-facing business processes. Generic business activities that are focussed on internal processes, as opposed to things that affect a company's customers, are largely irrelevant to the competitive equation. After all, how much competitive advantage does a new way of, say, entering internal expense reports confer on a business? Not much, I'd suggest.
Your experience is very similar to that of many customers, and your yearlong 11.0.3 to 11i upgrade experience is really sobering reading. I hope that your R12 upgrade is much simpler and faster!
Regards,
Steven
Posted by Steven Chan
|
November 12, 2009 1:08 PM
Posted on November 12, 2009 13:08
Hi Steven
Great blog - thanks!
As somebody who has implemented at various sites for a decade, I'm in general agreement with you.
I've one suggestion for Oracle products though - it would be great to have a tool for web apps which allow non technical people to easily add business logic to the app.
Forms Personalization is excellent with this, but there really isn't a smart / easy tool available otherwise which allows you to say "if you're a male, you're not allow to fill in this information" etc.
I reckon that a usable solution to this, modeled on the Forms Personalization approach, would limit hundreds of "customizations" and associated audit reports etc etc.
And when you think about the basic needs of an application (inserting and maintaining data & then turning it into information), that would probably be half the battle won!
Greg
Posted by Greg Frost | November 16, 2009 5:49 AM
Posted on November 16, 2009 05:49
Hi, Greg,
That's an interesting suggestion. I think that being able to declaratively define business logic would be very useful. Building such a thing... well, that might take some time. I'd suspect that the end-product would likely resemble our development tools like JDeveloper so closely that it might be a wash.
It never hurts to ask, though, so I've passed on your suggestion to our Applications Technology Group for their review.
Regards,
Steven
Posted by Steven Chan
|
November 17, 2009 12:13 PM
Posted on November 17, 2009 12:13
Hi steven,
nice blog. It's always pleasure to read thruogh your blog. We get lot of good info to start with. In my experience we have done lot of customisatons and I don't think there is any 1 company in this world without customisations.
I have one suggestion related to patching or upgrade process. Is it possible to notify the dbas if the patch they are applying is overwriting any file that is customised? If there is something like that then atleast we get know what might fail after applying the patch. I have seen cases where we applied patch and then realised some of the customisations are gone after testing.
Thanks,
raj
Posted by Rajkishore | November 18, 2009 8:29 PM
Posted on November 18, 2009 20:29
Hi, Raj,
Yes, you can flag specific files that you've customized and have warnings generated if AutoPatch is about to replace them. The method varies by EBS release. In Apps 12, for example, check out the "Registered Flagged Files" functionality in this manual:
Oracle Applications Patching Procedures -
http://download-west.oracle.com/docs/cd/B34956_01/current/acrobat/oa_patching_r12.pdf
There's a really nice web-based module within the R12 Oracle Application Manager that allows you to register your customized files.
Regards,
Steven
Posted by Steven Chan
|
November 19, 2009 10:46 AM
Posted on November 19, 2009 10:46