February 3, 2020 — Best Practices
13 factors to consider before developing your own renewable energy software
At first glance, the prospect of building your own renewable energy software may seem like a logical decision. But let’s look at some of the factors that can make in-house renewable energy software development problematic — and potentially undeliverable.
At first glance, the prospect of building your own renewable energy software may seem like a logical decision.
After all, if you have a team of developers and a history of in-house software development, making your own renewable energy software might be your default path.
However, we often hear from organizations who have either investigated this option or embarked on a new development project, only to abandon the work because of the scale, complexity, and challenges of building renewable energy software.
As well as the stories we hear from organizations that become our clients, we know from experience that software for this sector must meet a raft of evolving demands. The renewable energy industry is still young, and hardware, software, and processes are still being refined and optimized; keeping up with these changes places heightened demands on a software team.
Let’s look at some of the factors that can make in-house renewable energy software development problematic — and potentially undeliverable.
1. Software is like an iceberg
Software can be deceitful. On the surface, the challenge looks surmountable. You can see that you’re faced with something big, but that’s okay because you have skilled people who know how to handle it.
But as work begins, the true scale of the problem is revealed. After six months of development, you discover that one component of your IT environment is incompatible with your new application. And after another three months slide past, your team reports that a key feature requires code expertise that they don’t have. And this is still just the tip of the iceberg.
2. Architects hold the keys
On any software project, there are usually one or two people who know the entire application inside-out. Tech companies take steps to institutionalize this knowledge and to incentivize key people to become a permanent part of the company.
Jobs are no longer lifelong positions. People change jobs frequently. This is inevitable, but it can be dangerous for software teams that rely on a few key people who own the application. One departure can leave you with a crushing technical debt — and more delays.
3. A long road to market
Developing renewable energy software is likely to take 12–24 months, depending on how many developers you have available to dedicate to the project. With testing and bug-fixing, it could be years before you have functional software to manage your renewable fleet. Few companies can wait for a solution to be fully operational — assuming it ever is.
4. The telephone game
Your in-house team of developers might be ready and willing to build your solution, but there’s a risk that what you want is not what you get.
Even with the most rigid processes, clearest specifications, and most detailed requirements, your intentions can get lost in translation. After months of development, you discover that a key feature is missing, and hundreds of hours have been spent building a solution that doesn’t yet have a problem.
Choosing a third-party solution means getting a known quantity: the features are built and the capabilities defined. You can evaluate the software on its merits, knowing the full extent of its current feature list and its product roadmap.
5. An expensive detour
For non-software companies, developing a new application is likely to be an expensive distraction from your primary line of business. Software projects can take entire teams many months of effort — and the end result may well be ineffective, problematic and expensive to maintain.
While the new software is being developed, which tasks and upgrades are your developers neglecting — and how long can your other applications go untended before they fail?
6. Inflexible solutions
In-house software can seem as though it offers greater potential for customization. In theory, this seems fair. If you build your software, you can build it any way you like. You can, in theory, build all the features that your stakeholders demand. You can, in theory, get the perfect solution for your organization.
The reality usually looks more like this:
You give your developers a list of requirements and they start work on planning the build. After two months they report that some of your requirements are unachievable within your timeframe.
You proceed with a simpler approach, missing out on some of the core functionality. After another 18 months and many technical hiccups, the software is ready to use. It functions, but it resets itself every time the wind picks up. Your developers are frantically working on a fix.
In the meantime, you discover that your competitors are producing more energy from a smaller fleet and that they achieve greater efficiency by having a clearer picture of their performance. You ask your developers to add this functionality, but they are already struggling to maintain the core application. You try to hire additional resources but the only people who respond to your job ads have either the software expertise or the industry experience — never both.
Clearly, there are no guarantees that your in-house team will be able to provide the customization you require.
On the other hand, if you start with a robust, proven solution for managing your renewable energy fleet, then it is far simpler to customize the application or add new features over time. Building is always easier when you start with a stable foundation.
7. Data insecurity
In-house software development seems to offer control over your data, which in turn suggests security. The reality is that connecting your software to a variety of wind turbines is surprisingly complex. Every connection between your fleet, your network, and your servers presents vulnerabilities. Without the experience of interfacing with renewable energy hardware, you may find that your data is unwittingly exposed to hackers and snoopers, or that third parties can interfere with your operations through wide-open backdoors.
Having first-hand control of your data is not always the safest option, particularly if third-party organizations have rigid security processes that have been tried and tested in the field. You can often find greater protection within the security of the herd.
8. Never-ending development
Once the software is developed and deployed, it will require regular maintenance, upgrades, changes and bug fixes. Managing your software will never stop, so you must always maintain a team of specialists that can keep the application working to its full potential.
Very few companies want to have a perpetual commitment to maintaining software that only they use.
9. Failed software
Developing software is notoriously difficult. The Standish Group conducts surveys of software projects, and they routinely find a failure rate of around 20%. Year after year, the success rate rarely creeps above 30%. While these figures may be imprecise, the broad consensus is that a significant percentage of software development projects fail. Even governments aren’t immune to the iceberg-like dangers of software development. In the UK, a string of major software projects have made headlines because of enormous cost overruns and a number of outright cancellations.
10. Closed ecosystem
Your in-house software can be fraught with problems and inaccuracies — and some of its shortcomings may be difficult or impossible to identify without comparing its performance on other deployments. Third-party software has the advantage of being tried, tested and improved by other energy producers. You benefit from the operational experiences of your peers and competitors.
Capacity is the biggest challenge in software development — according to 26% of respondents to a 2018 State of Software Development Report
11. Niche developers are hard to find
According to a study by EDC, there are 23 million software developers in the world. Of course, you can’t hire any developer to work on your project. You need talented people who are experienced, available, interested in your business, proficient in relevant languages — and who have experience dealing with the unique challenges of interfacing with wind farms and solar plants. The original pool of developers soon dwindles to dozens. And it’s unlikely that many of those will be available when you need them.
12. Will it scale?
Developing a solution for 10 wind turbines is quite different to building a platform that can manage 10,000 turbines and 15,000 solar panels in 12 different locations. You could easily invest hundreds of thousands of dollars in building a platform that is not capable of growing with your business.
SaaS companies are built around the concept of elasticity, of being able to contract and expand their capacity to meet changing levels of demand. This absolves you of the responsibility to forecast demand and manage unexpected fluctuations; the challenge is offloaded to a specialist company.
Relying on a SaaS model to manage your renewable estate means you can face the future without fear. If your fleet grows through expansion or acquisition, you can be ready to manage the additional demand overnight, without requiring any additional infrastructure or development resources.
13. Will it integrate?
How many third-party solutions will easily or automatically interface with your DIY energy software? The answer, probably, is very few, or none. The likely outcome is that integrations with your existing solutions (of future additions) will be possible, but costly and time-consuming to achieve.
Conversely, third-party solutions have already been integrated by different companies using a different mix of software and hardware, so they are far easier to connect to your core applications and services.
So, what will you choose?
Of course, the obvious problem with this breakdown is that we’re biased.
Clearly, we want you to choose Greenbyte to become your data hub for renewables.
But there’s more to it than simple self-interest.
We’ve spent the past decade building software for renewable energy companies. We’ve worked through countless glitches, bugs, and roadblocks. We’ve spent days and nights wrestling with intractable issues and incompatible systems in order to fight climate change with code. We’ve gone through the growing pains and produced a solution that can manage and optimize large fleets of wind and solar assets. Our solution has already been tested in the most demanding conditions, and it has demonstrated its capabilities and resilience.
Whichever route you choose, we hope you are successful. All of us working in renewable energy share the goal of building a more sustainable future. We all recognize that the key to true sustainability is a model that marries profit and efficiency with our green goals.