I read a blog post this morning by someone known as “raf,” titled The Curse of Knowing How, or; Fixing Everything, that has inspired me to share my own thoughts on the subject. Several themes from the post resonated deeply with me, especially based on my experiences in Oracle EPM and integration development over the course of my consulting career:

• Knowing which problems are worth your energy.
• Knowing which projects are worth maintaining.
• Knowing when you’re building to help—and when you’re building to cope.
• Knowing when to stop.

Early in my career, I was used to being a self-sufficient application administrator and had just enough programming knowledge to be dangerous. My first instinct was always to code my way through integration challenges.

Before I even got into Hyperion/Oracle EPM administration, I worked as an admin for a PDF report bursting tool called DocumentDirect for the Internet by Mobius Software (now owned by Rocket Software). One of our recurring challenges was maintaining monthly security updates for sensitive commission reports as managers changed roles.

To solve this, I built a quick Java application that took an HCM report and generated an XML file, which we could upload to update security roles each month. This saved a ton of time and ensured consistent role updates. It was efficient and effective—but ultimately short-lived.

The problem? I wasn’t part of IT. I was in a shadow-IT role within the Financial Systems department, reporting up through the Controller and CFO. No one else on the finance team had the technical chops to maintain what I had built. So when I left the company, my slick little Java app effectively died with me.

When I moved into EPM consulting, I brought that same mindset to client engagements. I could write elegant Python or Java solutions to streamline integration processes and save time. The downside? Many clients didn’t have the resources or the technical depth to maintain the black boxes we consultants left behind.

It takes a more mature mindset to recognize the risks of this approach. If your code breaks a year or two down the line (especially during a critical close cycle) and no one can fix it, that’s not innovation. That’s failure.

This is why the “KISS” principle (“Keep It Simple, Stupid”) can be essential in integration work. Sure, we can create all kinds of sophisticated solutions in Oracle EPM using event scripts and custom reports on integration tables. But before I do anything like that, I need to know that the client can support the customization. Additionally, the implementation partner is committed to writing the most complete, user-friendly documentation imaginable.

My goal is to share some wisdom that was given to me early in my career. It took me years to truly understand the “why” behind that advice. Hopefully, by sharing this, I can help flatten someone else’s learning curve.