the waves of building software
07 October, 2021 - 9 min read
the waves of building software
a field guide to the history of how we got where we are
and a few lessons from riding the waves
I have this little guideline to talk about the waves of software development in the enterprise.
It largely mirrors what is going on in the consumer world, but as all things driven by such a large market where it's feast or famine, the consumer world tends to move quite a bit faster out of necessity.
Where the enterprise, for sanity and stability, needs to move much slower. Neither good nor bad, but certainly seems to be the case.
This is how the waves have come, crested, and subsided, giving energy to the next in line.
the dot com wave
In the '90's, companies at first were putting up outward facing websites as a bit of a gimmick, showing off that they were in the forefront of technology.
It's initial uses were no different than a digital phone book, with slightly more information. Then came products, notably forgotten companies pushing the fold like pets.com, where people were now starting to engage with companies in more ways than getting their number or address to mapquest their way to a brick and mortar store.
Within the large global enterprises though, a front facing site only went so far, providing information about products or helping meagerly drive inside sales teams.
The real wave of this boom inside the enterprise was the rise of intra-nets
the rise of intra-nets
Companies were now able to spin up websites just for their employees to use, that would provide needed information, statuses, or even just creating digital records of what was being done by files.
Emailing, then instant messaging, teamed with this digital copy of business practices lead to a big jump in efficiency. No longer were people needing to call one another to pass information, it can be done asynchronously. Same is to be said of waiting for someone to process over a stack of papers, just to then have them all delivered at once to the next chain in the process.
Now as soon as someone was done with one, it was moving merrily along via electrodes in the walls.
the mobility revolution
Next came mobility, first starting with wifi connectivity and mobile hotspots allowing work to be done in more places. With improvements to VPN protocols, people were able to securely connect to their work environments from, well, anywhere with a connection.
Then starting with the often overlooked blackberry, people were able to be even more mobile. Looking at emails and responding from golf courses, at their kids soccer match or anywhere in between.
Suddenly and rather forgetting-ly, we were all able to keep in touch with work after hours, outside the bounds of our office walls. No doubt leading to many more conflicts with one's own work|life balance, but increasing the bandwidth of communication and progress nonetheless.
There's little doubt though, that the real uptick came when Steve Jobs strode out to the stage in his classic turtleneck and showed the world the first iPhone.
Suddenly, we had a tailor made device to serve as a looking-glass to the digital realm.
quick aside: Funny enough, Jobs didn't want to encourage developers to build apps native to the devices, his vision was for an improvement to web-protocols and frameworks that would allow for apps living on the web, with a launching point from the home tiles. Not creating a new ecosystem within the device itself.
through the looking-glass
What this revolution meant for the enterprise, was ten fold. Now instead of only focusing on creating internal tools for their employees to leverage, enterprises with consumer models could create experiences and interfaces to connect with them directly.
Pairing this with Google developing and launching the Android operating system, there suddenly was a huge market to be had in the: go-anywhere, connect-anytime, talk-directly, share-suddenly, never-miss-a-moment.
Seemingly simple interfaces we take for granted now, like being able to take a picture of a whiteboard and upload it directly to slack to share with a college, is incredibly revolutionary and on a soft level, completely changed the speed we work.
From sales teams being able to log and view accounts right before their lunch meeting with a new prospect, to executives asking for documents while their at a board meeting, all the way through new job candidates touching up their resume from their phone-- mobile brought a whole new dimension to the game.
This meant companies increasing their internal development of employee apps, whenever IT could get the budget, but also adopting more applications from 3rd parties. Consumer facing enterprises may have been the biggest winners in the first part of this wave, creating direct lines to their customer bases for everything from tracking orders, customizing them, or later in the track, creating unique mobile experiences.
cloud game cometh
Next up we have our current wave that's cresting, cloud services.
Mobile architecture was largely built upon the legacy web that proceeded it. Large servers housed by enterprises, with firewalls around them only letting necessary information in and out ( many run by the company in-house might I add ).
With API architecture and protocols becoming more ubiquitous and easy to develop and maintain, this started to change. ( for those not in the know, an API is not to dissimilar from that old can and a string way of talking. It's the interface for two systems to ask, and receive information, so long as the right security information or the like is included, serving as the agent which makes sure the string is tight in this analogy. )
In the cloud wave, enterprises were able to offload their traditional server architecture, to someone else's rack, saving them money and maintenance, only needing to handle the software running on it.
It at first was as simple as having another company holding the physical hardware for your Microsoft server virtual machine. Like many things in and out of tech, the application of that simple idea can get stretched far and wide.
Having that framework, now meant that instead of having that provider serving up a virtual machine for me, what if it just hosted up an app that I built?
Now companies could host websites, or even power those new mobile apps where another enterprise would handle the bandwidth. All I need to worry about is making my app work and have a great experience.
Leading to more specialization of work, companies could just focus on the app development and not have to stand up all the architecture underneath that's powering it ( This is a revolution that's currently happening in A.I. and something I'll talk about some other time ).
Much of the world we enter through our mobile, tablet or desktop looking-glasses is completely reliant on this cloud system. Companies like Salesforce have made a multi-billion dollar enterprise by building a software system that lives on another company's servers.
To say nothing of the many apps we're all hopelessly addicted to and struggle when they go down.
the next wave is here for those that are ready. micro-services
I adore linux. The open source nature of it, the fact that I can get it working on just about any device, and just how much I can do with it.
There's two things in my life that I've maintained since I was a kid. Playing guitar, and hacking on linux.
So when I first started hearing about micro-services and containers, my interest wasn't just peaked, it was floored.
Let me explain why.
We have this mixed-cloud architecture that I explained above. Where we can package up apps and deploy them to a server that someone else is serving up for us.
What containers and micro-services allow us to do, is break that app up into allllll of it's tiny little components, and in essence, create them as their own discrete apps.
That feature that pulls the data out of a database? Make that it's own tiny service.
The front-end? Tiny service.
The engine that calculates all of the exchange rates? Tiny service.
The feature that sends alerts to your phone? Tiny service
Each of these tiny apps, or micro-services, are housed inside a container. A container, is a small virtual linux system that's only comprised of the packages that is needed to run it. Making it incredibly fast and stable.
From a redundancy perspective, what this allows for is the development and design teams to play around more with changes without having it break much else other than what's directly effected by that feature. Allowing for more updates, more improvements, and less outages that take everything down when releasing a new build, because the builds should be happening frequently across separate tiny apps.
Now looking at it from a product and architecture lens, instead of needing to copy out some code that pulls data into a new app that I'm building, I just have this new app integrate with the existing container that's up. Reducing the time to develop, testing, and maintenance of code across multiple apps.
lessons from riding the waves
Real transformation wasn't baked into any of these waves. Companies in large part were forced by opportunity or market forces to jump into the next improvement as it was happening.
Think about it, how many companies when they moved from physical files to digital, stepped back and thought, "do we really need this form?" or, "if we just do this and that, wouldn't we save time?"
No, they just jumped in full steam ahead and were jovial at the results they were getting. Which is understandable, a lot of uncertainty was existing at each step of the way.
But now we're at a critical moment where we know how technology has unfolded the past 20 years, and how to build and work within it. There's an immense opportunity out there for the companies that recognize this and start looking over all of their business functions and practices with an eye to transform.
When they do start to change practices, if they do so in a micro-service federated architecture, the combinations of what they'll be able to build and support is quite literally endless.
Because the truth is, while the next 20 years is uncertain what tech will bring with the ever approaching tidal wave of A.I., one thing is certain, your legacy architectures won't preform and slow businesses won't be able to keep up.
But that, is for another article.