Are you an Excel mastermind? Maybe you’ve built some excellent spreadsheet calculators and want to turn them into something better? Let me tell you a little about our journey of becoming an enterprise-ready B-BBEE software-as-a-service business.
Governance and data privacy
We started like most software companies: a small team of starry-eyed developers hacking away at a project the CEO was personally overseeing with immense anticipation and excitement.
We started building the BEEtoolkit near the end of 2008. It was replacing Mpowered’s first Software-as-a-Service called BEEmotion. This all happened near the time when B-BBEE self-assessment was supplanted with formal accreditation, and B-BBEE strategy was becoming a concern for many enterprises.
BEEtoolkit was released about a year later, and we started selling it predominately into the automotive industry in which we had developed a strong foothold via our B-BBEE consulting team.
We started acquiring progressively larger and more complicated customers. Their demands led us to build a sophisticated scorecard consolidation engine to handle calculating B-BBEE across corporate structures. With this growing complexity in the B-BBEE environments, we also began to encounter corporate IT and so began our journey to enterprise readiness.
I distinctly recall meeting with the CIO of a large, international insurance underwriter. He reamed off a list of onerous demands that we’d need to meet before they’d consider allowing our application into their environment. It was that moment that we entered our first internationally-based security due diligence.
We studied existing information security standards like ISO27001 and started formalising a host of processes and procedures. We changed our hosting and infrastructure provider to a top-tier (and expensive) enterprise hosting company. Each due diligence that we entered became an opportunity to polish and hone our governance and data privacy practices. We hired legal consultants to educate the business on POPI and general data privacy practices, ensuring that our data privacy maturity drove policy from our technology, all the way up through to our people and ways of work.
Today, we seldom see a question in due diligence that we hadn’t seen a 100 times before, and developed a process to handle. Getting here hasn’t been easy, though. We were trying to build software for pete’s sake! Not corporatise ourselves. But good governance has an excellent side effect: nights of sound sleep knowing that you’ve done everything you can to be a responsible custodian of your customers’ precious data.
Upstream dependencies
Most software companies have several stakeholders that guide their development activity. The most obvious is their cohort of customers. Software businesses that don’t listen to their customers are at risk of playing in an echo chamber of their thoughts and falling out of relevance.
Competitors are also a voice in the mind of many a product manager. The activity of your competitors could reveal an undiscovered trend that you need to capitalise on before it’s too late.
Good product managers deliberately gather insights across these two essential groups of people. They apply their mind to filter the ideas and find the golden signals in all the noise. This process is a busy and challenging job, requiring sound judgement, scepticism of assumptions and careful management of one’s own bias.
B-BBEE software companies have yet-another-upstream-stakeholder though: The DTi and sector charter councils. We’re not building apps led exclusively by our vision of what our product should be. Our core value proposition is the fact that we encapsulate all the calculation and interpretative nuances of legislation defined by a completely independent 3rd party. This dependency is scary stuff.
This 3rd party is free to change the B-BBEE requirements at pretty much any time. These changes can be benign and have a low impact on your product. Or they could be sweeping and require that you scrap your carefully crafted roadmap and vision boards for a turbulent scurry to unpack, spec, build and test some new calculation or sector code.
We’ve always thought this would be a seasonal activity that would pass. But it has proven to happen regularly enough that it has kept us really, REALLY, REALLY busy. A huge part of a B-BBEE software company’s workstream is keeping up with the latest changes in B-BBEE and making sure that these changes are reflected intuitively and accurately in the product.
Abstraction
Which brings me to abstraction. As Bruce Tognazzini said:
“It’s hard to read through a book on the principles of magic without glancing at the cover periodically to make sure it isn’t a book on software design.”
You may not think it (given all the hype), but it’s easy to code. In much the same way that laying bricks and pouring concrete isn’t that hard.
The real art and science lie in understanding that local geology needs to be taken into account when constructing a building of substantial size. The foundations, configuration of steel and stone, planning around natural groundwater flows etc. become the key to building a high-rise residential complex that will remain sturdy for decades and require very little restorative maintenance. That’s why we send people to a university to become civil engineers.
Coding an application that works in not the hard part. Coding one that anticipates change in the right place, that is easy to test and scale is the hard part. This takes a team of very experienced and pragmatic software engineers.
You know that your software design (how you’ve grouped the code, exposed it and coupled the modules together) is sound when a new requirement comes along, and it’s easy to add to the system. The challenge with B-BBEE is that we can’t reliably predict what future changes may occur. It’s hard to peek into the future and anticipate that this module needs to be able to bend, while that one can remain rigid. Evolving architecture is inevitable.
But evolving architecture requires more than just a team of coders. You need specialists that understand the domain and can help build the system of tomorrow while maintaining the version of today. Your system becomes like the human skeleton: repairing and replacing itself slowly over a matter of years such that you pretty much have a new skeleton every decade or so (true story: https://orthoinfo.aaos.org/en/staying-healthy/bone-health-basics/).
Building scalable, reliable, and future proof B-BBEE software is expensive. I have a profound respect for our team of developers. We have some brilliant people solving some complicated technical and commercial problems.
Conclusion
So should you start a B-BBEE software company? We’ve been honing ours for ten years. It’s not been easy and continues to keep us on our toes.
I’ve heard it said that entrepreneurship requires a little ignorance. If an entrepreneur knew all the challenges they would face on day one; then they probably would’ve walked away. I’m glad we didn’t.
Author – Gary Greyling, 15 April 2020