How to integrate your AWS event-based system with external/legacy systems using RESTful APIs
In my Reading list post, I listed a book I recently completed. This is my 'book review' of it, of sorts..... After I read this book, I wrote an email to a senior executive, which I have converted into the blog post, where I link some lessons in the book, to situations I see in the company. It details how this book caught my attention on the parallels to my work environment, and the similarities I have come across, almost as if history repeats itself. I think this specifically applies to the enterprise corporate environment, where the saying "If history has taught us anything, is that it has taught us nothing" is so apt, as make the same mistake over again.
Names have been changed to protect the innocent
I have always been following the telecoms industry, watching our competitors, and a keen reader. I’ve read a few books on innovation, and they always mention how, when big companies fail to read the market and adapt to changes in the ecosystem, and rely on past success and ‘how they always did things’, then failure soon follows. The typical cases are Kodak, Nokia, Commodore, Palm, etc.
However, what really made that real for me, was the book Fumbling the Future: How Xerox Invented, Then Ignored, the First Personal Computer, which gives an inside view into how Xerox lost their monopoly, and ignored some major inventions that they had made, because they were too reliant on past successes. I have listed the key stand-outs for me, which really hits home because of the parallels to our company. My views are admittedly more constrained to this region (where my experience lies), but it may apply across the Group as well:
Their market dominance came from major innovations they made in R&D, in designing Xerography, which they became over-reliant on, with investing more in R&D.
Very much like our initial investment 22 years ago, and based on innovations like pre-paid. Yet we have not made any major innovations in the past 10 years. We still mainly rely on voice revenue, and we don’t seem to have a clear way to monetise data and digital services. I’ve worked on projects like Location Based Services, Instant Messaging (before the days of WhatsApp), and those projects have died, not coming even close to making a profit.
Xerox Identified that they need to change with the vision of “Architecture of Information” in the effort to become an IT player, in the new digital “Office of the future” which they foresaw at that time. Yet they failed to deliver on that, because even though they developed new technology, they did not think it could sell well, or scale, or they thought the market was not ready for it.
Similar to our vision of the “Delivering a Bold New Digital World” – but can we follow through on the huge potential we have in terms of scale across 22 OpCos, access to growing markets in Africa, by taking bets on new solutions and ideas, using Open Source
In an effort to leap frog into the IT world, they purchased SDS for a very large some of money, and then promptly failed to capitalise on it. There was a clash of cultures, and ways of work, so they just ignored it.
This is similar to our purchase of a large ISP, and eventually selling it for a loss.
We also bought another ISP later and formed our Enterpise unit. I worked in SA for the last two years, trying to integrate their team and technology into the larger company, and it was very tough because of the clash of cultures. ISPs were formed in garages with one Linux box, while Mobile Operators start out with a R500M license. That difference drives the way that they think and build services, and that dichotomy was the reason that we are not fully realising the investment in the company it bought.
Xerox founded PARC Innovation labs, which developed the PC and many innovations that were ground breaking, but failed to capatalise on it, by ignoring it, and still developing printers with out using the innovations from PCs
Competition from Japanese smaller players started to erode their markets
Smaller OTT players, like Whatsapp, Google, etc are eating into markets where we should we dominant
Litigation and Anti-trust issues
Similar to issues we had with the regulatory fines, and in getting access to spectrum.
Company restructures – They too made restructures to cater for changing markets, but the people and the mindset remained the same, and they kept on making the same mistakes. They also hired and poached from the competition, but then there was a clash of cultures and mindsets
I just came across this article, which says Xerox desperately needs to change:
On the other hand, our competitors are perceived to be more tech-savvy, and open to innovation:
While we announced our IOT/M2M platform in 2015, it has still not earned critical mass. Our competitors have a few thousand SIMs on their IOT platform.
Our competitors are using AI and machine learning, and are also more developer friendly – back in 2009 they had portals where devs can go and test out APIs, what we hoping to achieve now.
Our competitors, to the best of my knowledge, have not been in any major re-structures and retrenchments like us. They also have a more consistent Leadership structure with more stable time in office.
I joined here because of the huge potential to make change, and to learn and bring new ideas, that will hopefully be able to influence services and technology across the Group.
- A few years ago, the previous CTIO said “we are not a software company” – which means that we could not hire developers, or doing any custom changes, rather just use whatever the vendor sells us. I believe we desperately need “key” in-house dev skills, that allows us to be flexible. I seen the difference with working at Enterpise over the last two years, when we had our own in-house developers.
- We are too ‘corporate’ and risk averse. We need to be more ‘start-up’ and agile, not working on big projects, but doing smaller projects really quickly. The recent POC is a perfect example – it took only 6 weeks.
- Instead of big projects, lets do smaller ones, starting with one OpCo, and from those learnings, scale out to other OpCos
- Similar to that, I believe big platforms, are too large to manage and scale. Mostly because we are then too reliant on these large partners, and they then take us for a ride.
- Use smaller partners – local vendors and software houses in each OpCo– which are more niche, focussed on what they do, and don’t promise the world like big partners.
- Issue a mandate similar to Amazons, that demand that every new platform expose its capabilities as APIs.
- Cloud first: as a rule, we should in investing in skills in Cloud Infrastructure on AWS, Google Cloud, Azure, IBM – and that every new app/service first needs to be deployed to the Cloud, and only if it cant, then only do we consider on-site hardware. I have spent the last year working on AWS and Google Cloud, and I believe there is a solid business case to save on costs and time to deploy on-site hardware.
- Much more use of Open Source software, not just in side use cases, but key areas like middleware, portals, big data, etc.