Customization
February 16, 2007 | By Joel Dehlin | 12 Comments
My background is in software development so my first inclination in solving a business problem is to turn to custom software. I have to fight that urge as off-the-shelf applications are often more cost effective than custom-developed ones.
Commercial off-the-shelf (COTS) applications are wonderful if they match your business process. Many of these applications incorporate process models which are based on industry best practices and thus if you can match your business processes to industry practices, you can benefit from an industry’s collective wisdom. Plus you have many more users testing “your” code for you. Your company may use a small percentage of the available features of a given solution, but the economies of scale a vendor leverages in creating a COTS application make a 10% value proposition worth the full investment in the product.
Note I said “if they match your business processes.” If they do not then you have two choices. You can change your business process to match the tool (much easier said than done) or you can customize the tool.
Customization. Traditionally, when we’ve needed to make a change to a COTS application, we’ve customized the tool. It’s so easy to do! You don’t have to worry about buying new equipment, testing new configs, installing new baselines, testing in staging, etc, etc, etc. You just do some simple “configuration” (read: write code) and publish the changes out to production in the tool that’s already been pushed there. It’s typically that easy.
But is it worth it?
Firstly, you can rarely build what you’d REALLY like to build with the simple customization tools available in a COTS application. If you can live with vanilla then the simplicity in using these configuration tools can be worth it in the short-term.
So what happens when you upgrade? That’s when you feel it in your pocket book. We’ve been riding the upgrade train of our ERP system for years. We’ve made many, many customizations. They’re necessary customizations, but they make our upgrade to new versions of our software very painful. At some point you start to wonder if it wouldn’t have been smarter to write the software yourself instead of purchasing an expensive COTS application. I’m coming to the conclusion that the answer is no for many COTS applications.
Here’s the credo we’re developing at the Church wrt COTS applications.
- Buy over build when possible, but only if we’re willing or able to bend our business process to match the tool we would be purchasing. When customizing, abstract code from the COTS application (and especially the DB tables) when extensions are necessary.
- We look carefully at the number and severity of customizations we’ll have to build and if we determine that they will pass a certain threshold, we decide to build.
This approach isn’t always a popular one:
“We’ve already got an ERP system! Let’s use it!”
“The vendor promises a smooth upgrade path!”
“The tools are soooo simple!”
But we think it’s the best one for us.
Doug Von Feldt said...
I have been involved in software development for 20 years and have seen a lot of changes in philosophy over the years. Since ERP systems have become so popular over the past 10 or so years, many companies elect to install the canned package and then customize it. During my years of ERP implementation consulting (JD Edwards), I have been involved in hundreds of new ERP implementations. The first thing that most people want to do is customize everything. Even if they say they don’t want to make customizations, they still do it. At the very first meeting that I had with the client I would always tell them that almost every client that I had regretted making customizations within a year of going live. I felt it was my duty to point it out and then help them make the right choices on how to properly customize the applications.
Most companies spend millions of dollars on ERP implementations and then pay a lot of money on maintenance each year but can’t do much because of the custom code. The last company that I was with had customized the Order Entry application and it was impossible to upgrade. After a few years there, we started a project to completely rewrite the application using the JD Edwards tool set, but outside of the standard application, just using the underlying database. Once this was completed, we were finally able to do much needed upgrade to the system. Now there is a path for future upgrades and the Order Entry system really works they way it should.
In the current company that I work for, they implemented JD Edwards 10 years ago and have not done a major upgrade since then. It is just too much work. What I find amazing is that the company has paid maintenance costs, which I agree must be done, for the past 10 years and hasn’t taken any new major releases. The amount of the maintenance agreement with JD Edwards is about 10% of the yearly IT budget. (All maintenance agreements are about 27% of the yearly budget.)
So the point is what would have happened if the company would have built their own system 10 years ago, got what they wanted, and would have save millions is maintenance costs over the years.
In today’s complex environment there is a place for COTS applications, but there is also a place for custom developed software. Each company and industry is unique and must make the decision based on the best available information at the time.
February 16, 2007 7:45 am #
Gene said...
“Buy over build when possible AND when we’re not willing or able to bend our business process to match the tool we would be purchasing.”
Your losing me here. Sounds like you’re saying to buy instead of build if your business process will not match the tool you’re going to buy. Doesn’t make sense. Typo maybe? The tool has to meet your needs or there’s no point in purchasing it…
[Joel: Sorry I wasn't clear, Gene.
Buy COTS if you can, but only if the tool matches your business process or you're willing to change your business process to match the tool. When you do large customizations then do so in an abstracted way which doesn't tie you to the system.
Otherwise build.
I've updated the post a little for clarity. Thanks!]
February 16, 2007 8:35 am #
Brian Smith said...
This is a much more complex issue than the blog allows you to properly address. Volumes have been written on the subject and there are examples to support every possible position of the discussion. One of the fundamental issues in adopting an ERP system is data architecture. Historically, businesses reap the most benefit through greater data integration. The ERP benefit curve is exponential; benefits accrue faster the more business process are within the ERP system. Successful installations require it.
All consulting groups advocate the following generally accepted best business practices:
1) Use an ERP system. Every business consulting group lists this as the single most important best practice.
2) Modify your business processes, when possible, before customizing the ERP system because customizations increase the cost maintenance and upgrades.
3) Modify the ERP intelligently. Each ERP system is different in how you approach customizations. Each method of customization has its advantages and disadvantages.
4) Build your own application, only if it is provides a strategic advantage or if the business function is not provided by the ERP.
****
Four methods exist to provide an ERP customization:
A) Customize delivered code,
B) Clone the delivered code and customize,
C) Create custom code within the application,
D) Create a custom application and interface it with the ERP system.
Each customization must be evaluated for the appropriate method of customization. As you, mention ERP tools make the first three easy to do and manage. Each method has a cost to maintain as well as its benefits. While customizing delivered code is often considered more costly that is NOT necessarily so. The nature of the change is most important. Security, controls, usability, training, support, data integrity and interoperability must be considered in addition to upgradeability.
****
“Cost” seems to be an overriding consideration: This presupposes that custom applications are inherently less costly than customizing an ERP. Evidence suggests that this is not always, mostly or even necessarily the case. Expensive? ERPs cost a lot of money, but complex custom apps generally cost even more to develop. Different costing methods (incremental, full or life cycle, etc. as well as IT operations, business processing and opportunity costs) can generate different results.
Upgrades and system rewrites are costly but generate benefits in architecture, functionality, usability, reliability. ERP systems cost approximately 1,000 hours per module to upgrade every 4 or 5 years INCLUDING customizations. Complex systems can’t be rewritten within that timeframe.
Consider the cost of maintaining tax compliance rules for the federal government, 50 states and 10,000 local tax jurisdictions, not to mention Canada versus applying 7 updates from a vendor at less than 40 hours per update. Want to outsource payroll, expect to pay double or triple the cost of doing it in house.
[Joel: Thanks for your thoughtful comments.]
February 16, 2007 6:58 pm #
Tom Johnson said...
Hi, I actually just a suggestion rather than a comment related to your post. Would it be possible to integrate the Google Maps API with a geocoding program and a ward membership database so that we could map home and visiting teaching routes more effectively? Has this ever been explored? It would be one of the most useful tools ever.
[Joel: Not only possible, but likely. Stay tuned...]
February 16, 2007 7:12 pm #
Rob Watson said...
Our core business is development of curriculum content for elementary schools. We custom-built a learning management system (LMS) to serve our customers instead of even considering COTS. Our custom app quickly grew into a Big Ball of Mud. Our customers _hate_ it. Then our lunch got eaten by a vendor whose core business it was to build LMSes.
Stick to your core business. Let vendors do the rest. Draw a “reverse” Venn diagram of the requirements regions where your vendor CANNOT provide what you need and then ONLY customize in that region IF the risk is low that doing so will affect your upgrade path. Keep the people who did the customization on your team and on your payroll (or transfer knowledge to their successors). Never let that information reside exclusively with the vendor (who will turn around and charge you a premium for using it, ironically). Document obsessively what you customized so that any adjustments you might have to make after an upgrade will go more smoothly. The document again after the upgrade.
Losing perspective on your core competency and product can end up costing you both the development dollars AND customer goodwill if (when) things go badly.
February 16, 2007 9:50 pm #
Richard said...
If you buy off the shelf, how can you distinguish yourself if you run the same software that everybody else does?
For a commercial company, I think doing your own thing is usually the best way to go – except maybe for business processes that can’t be improved anymore.
February 17, 2007 7:38 am #
Aaron said...
I read an interesting case study recently (http://misqe.org/showabstract.jsp?ob1=68&ob2=92) providing some criteria for determining when to bend to accomodate the “vanilla” ERP system and when customizations make sense. Basically, the authors suggest that bending to the vanilla system is preferred if the organization-software misalignment is a result of voluntary rather than imposed structures. The exception comes when the voluntary strucutre (those that orignate with the organization rather then due to industry or environmental factors) is closely tied to the business strategy / competitive position of the organization.
February 17, 2007 9:51 am #
Aaron said...
Jon,
Regarding my last comment: a point of disclosure. I read that article during a class as part of my PhD studies. I currently work for the journal that published that article, but I don’t receive compensation for marketing or links, nor is advertising part of my job function.
February 17, 2007 10:00 am #
Daniel Longmore said...
This blog entry certainly deserves comment. Sorry mine is a little off of the topic. I really hope this comment makes it to you and is not considered spam. I have been following your blog posts for a little while now. I have also been involved in the LDSTech forum. It is that effort that has spurred me on to writing this comment. In the hopes that you will pass it along to your peer at the Church who is over the Family History Technology. Here it goes… To use the old saying “put your money where your mouth is”. With a little twisting the saying could be “put your coding where your agile words are”. May I please explain further. I think that many of members of the church could benefit from just a small change in the current familysearch.org website. It might be easiest if I explain what I do not need. I do not need someone to give me a nice interface where I can connect everyone together (GENi has done it for me). I do not need a place to enter research collaboration or enter biographical stories or keep pictures (WeRelate has done it). What I need is a way to simply track my opinions of what temple work has been done for a person. I say my opinions because that seems to be the biggest factor I run into. Everyone has their own opinions about what work has been done (and not done). I’m not so interested in knowing whose opinion is correct. I just want to be able to choose which I work I think is right and have it stored for me somewhere. That way I can move on to those that I cannot find valid work for and do their work. Let me give you an example of what I mean. I imagine myself working with my research on Jane Doe (at the WeRelate site) and wondering what work there is at the familysearch.org. So I click on a link at my WeRelate site that does a search of familysearch.org for the person and up pops all the temple ordinance work on record for that person. I can then scan the screen looking for temple ordinances work I feel is right and when I see something that I looks correct I simply put a check in the check box to save it as my opinion of what work has been done (becuase I have a login it saves my choices into a database so when I return I can see my choices). I could go on with many other ideas however this is the real central one. I am sure with others input something even better than my idea can be developed. The point is something small today is better than a hoped for future big thing. This is just pure honest desire to get something done (not critiscm). I love all that is being done for me by all the wonderful people there. Thanks for being a listening ear.
February 17, 2007 11:45 am #
Rob Watson said...
Daniel,
Others can correct me if I’m wrong, but I believe that TempleReady information is about to be or already is available on familysearch.org. I believe that was announced in the latest GC. The idea is that the Church knows definitively which persons have had work done (with the exceptions of ambiguous names and dates, which will always be a problem). It’s just that in the past the TempleReady “database” as it were has been disconnected from the family research side of things.
February 20, 2007 8:52 am #
Randy said...
COTS software has a place, you just have to know what it is. Like the wise man once said, “If the only tool in the box is a hammer, every problem looks like a nail.” You can’t always do what you want with ’standard’ software, and for those issues there’s a developer out there somewhere earning a paycheck.
February 20, 2007 3:31 pm #
Benjamin Hofmann said...
Unfortunately most businesses are not open to changing their processes and it doesn’t always make sense to do so. Some industry experts suggest purchasing a COTS framework that you can build on. The framework would include common components but is designed and is expecting customizations. It is kind of a half-and-half system.
I’ve heard this suggested for content management systems and feel other application like ERP systems could benefit from this approach as well. Have you had much experience in using a framework instead of a full COTS?
February 23, 2007 4:00 pm #