One of the most enduring principles I have learnt as a former implementer of products, is the line between technical work and functional work is dotted and very grey. In more traditional implementation methodologies, the delineation between technical work, managing the technical aspects of a product, and the functional work, working with the business, has been encouraged to be separated with little flexibility. It was not uncommon to see functional people throw technical aspects of a solution to the more technical people in an implementation. In most cases, the method used for throwing across the fence, as it was commonly called, was not communicative leading to incomplete or incompatible solutions.
Let me give you a concrete example. I was working with a customer as a technical consultant quite a few years back. One day while working at my desk, two functional architects were discussing the different possibilities they could configure to satisfy a requirement. They were bouncing ideas. I joined in on the conversation and suggested functionality that was already in the product which could be used to satisfy the requirement if configured in a certain way. Without hesitation, they suggested to me, perhaps, I restrict my ideas to my technical skills. They effectively discounted my suggestion as it came from a technical person rather than looking at the idea on its merits.
Perhaps that example is extreme. Let me look at it from another perspective with another example. As a product developer, we are always attempting to marry technology directly to satisfy business goals. it is a common principle of any product to exploit technology for business benefit. We introduced Information Lifecycle Management capabilities into the Oracle Utilities products several years ago. The idea is that transaction data, the bulk of the storage usage in any implementation, has a lifecycle that can be exploited to optimize the storage footprint. We determined the best approach was to marry the extensive Information Lifecycle Management capabilities in the database with some inbuilt capabilities for the business to set their goals. Thus the Information Lifecycle Management capability was born. It had a business aspect and a technical aspect, but to truly implement the capability to its fullest extent the two aspects have to work together. In theory, the idea was to marry the two approaches to implement a more satisfying outcome overall.
There was one problem we did not anticipate. In most of our customers the technical people rarely talked to the business in their terms, so there was a disconnect in planning your Information Lifecycle Management and actually implemented it. For example, the first step in the process is the agreeing the retention periods for transaction data. When we launched the Information Lifecycle Management capability, I literally had a number of technical people swamp me after the session, asking how they could get their business to make that decision or maybe Oracle should make that decision for them. They wanted to avoid the discussion altogether. I suggested some techniques for them to start the discussion with their customers. Their comments confirmed my suspicions about this technical and functional divide.
Now I am hoping you are not thinking I am highlighting the divide and leaving it at that. There are ways of addressing this and being successful. Here are some of my suggestions:
Over time the divide will reduce to the point that both sides of a solution are considered and you would breed success.
Oracle Utilities, including Opower, partners with the world's hardest working electric, water and natural gas companies to empower, enhance and enable your every single day. From cloud-native products and better grid management tools to support for every single step of your customer's journey, we have the answer. Learn more at oracle.com/utilities. Get specific product information as quick as clicking right here.