Over the past years I have been involved in the realization of a number of products and services for utilities, energy companies and Horizon 2020 projects. I have had the opportunity to work in numerous environments using various methods to develop and operate software and services. What are my personal takeaways? A lot but first and foremost keep the concept simple, really simple!
The future role of technology within energy is to enable use cases, which in turn release efficiencies in the main objectives of your business. Technology will allow "energy actors" to create trustworthy insight which to date has been:
1. Beyond human comprehension
2. Not deliverable within a timescale which is relevant
3. Difficult to demonstrate value based on multiple dispersed or "stacked" benefits
If you operate in the trading area of an organisation or find yourself within the asset delivery side, the recipe and approach for comprehending your technology road map is the same, what varies is the ability to understand and appreciate business level problems, challenges and opportunities which are presented within and around your organisation.
I have worked on a number of projects of late which have had phenomenal levels of governance and structure applied to them. Leveraging the very best of TOGAF, SAFe, Agile, Architecture (all of the current buzz words and acronyms). What has surprised me is the variability of success in projects which are all apparently operating in line with "best practice". It is not uncommon for the approach to project delivery to be perfect however the actual output of efforts does not align with the vision. Why is this? What is going wrong? And longer term, where are we going to end up?
In this blog entry, I am going to attempt to over simplify some of the areas of product and service development which are often overlooked, areas which can introduce substantial cost, impact customer experience, security and reliability and also only surface as issues later in programme delivery.
Observation 1 - Decide on what your selling. Is it a Product or is it "as a Service"?
This is the biggest decision you will make as the path you take to develop a product follows a commonly understood approach with well appreciated ways to release and resource. The minute you open up the world of "as a Service" you have a different set of requirements around operating and maintaining the service along with infrastructure needed to support the service. These areas are far more demanding throughout the life-cycle of the service and dramatically increases the exposure and risk of the organisation.
Observation 2 - What are the biggest User Experience areas to apprehend?
1. What is the expected service latency end to end? Most energy related services are built to create insight, for control of a grid, optimal operation of a generation asset or to gain insight to trade in a market. All of these drive time constraints for turnaround of the product or services you propose to build.
2. What is the value associated with the insight you are creating and what is a reasonable level of resilience and reliability to have? For a Product, it may be acceptable to have 9-5 office hour levels of support. For a real-time Service you are looking at on call engineering support, operation centers and a full appreciation of Mean time between repair (MTBR) - (MTBR in process systems can balloon requirements to be able to deliver the service within half the time of the customers expectations. This is to ensure there is a window to identify any issues which may arise when operational giving you an opportunity to rectify, something that is commonly overlooked.)
3. If I am building a solution on cloud infrastructure, what are the requirements for reliability and security which my clients would expect? Do I need to replicate across numerous locations? Do I need to impose geo fencing on certain data stores? Am i expected to encrypt data at rest and/or on the move?
Observation 3 - Can the Product or Service be configured to meet the needs of all?
The objective of many solutions is to offer a common tool or capability to industry for many users to leverage it in an efficient manner. The unique nature of all users and clients needs to be captured and configurable into the systems you propose to build. The uniqueness of a client should never have to be embedded into a product or service via customization of code or services. This defeats the purpose and value of a generic, configurable service and ruins the ability to align all users on a common platform. If you modify your product it becomes a non-transferable solution.
For today I will leave my pondering at that, and wish you happy product and system development. More to follow on vision and governance of the same. Happy to chat, J