5 Reasons The Software Architect’s Star Has Fallen
For decades, the Software Architect was considered something of a technical god among mere mortals. They envisioned grand structures of code, designed edifices to geekdom — then imposed their constructs upon Software Engineers. Once their virtual monuments were complete, Systems Engineers would then have them dropped on their heads, often with little warning.
Those days are gone.
The first rumblings from within Mount Olympus were heard with the advent of microservices. The roaring Cloud, and especially serverless computing, has blown the top off altogether.
Why has the Software Architect been brought so low? Offhand, five reasons come to mind.
1. Software Architects love to design things themselves.
Every queue, heap sort or hashmap that came before is of lesser quality than the one that they would design. Often, these design efforts would take weeks.
Have you ever tried to design a truly reliable queue? In the new Cloud order, a queue can be had in minutes — with a few clicks of the mouse or a few lines of Terraform. And it’s better than literally anything designed from scratch by the average Software Architect.
2. Software Architects love large software constructs.
Some call these constructs monoliths. They’re huge, complex, and — in many cases —understood only by their creators.
Microservices take a hammer to monoliths. Serverless computing dynamites them. What results are lots of tiny pieces of code that can be easily glued together by someone other than a Software Architect. These tiny pieces then become small constructs that work together — like ants. In short, mere mortals can design and build small constructs.
3. Software Architects love modern software languages.
Strongly-typed, Object Oriented languages come to mind. Including Java and C# — which Software Architects use (much like Latin in the Middle Ages) to intimidate lesser mortals. They sneer at Python, node.js, and — heaven forbid — BASH.
However, in microservices — and especially in the cloud — each small construct is built out of whatever tool is best for that micro piece. Much of the time, if not already most of the time, the best tool is not a strongly-typed OO language.
That trend has been taken to the extreme in serverless computing — where most software constructs are small (under 100 lines), functional programs that each do a single thing. Why carry around all the weight of an overstuffed, long-winded language when you don’t need it?
4. Software Architects love software.
It’s right there in their job title. Before the cloud, the majority of work in any software solution, probably the vast majority, was bespoke. Now the script is flipped. Bespoke software is the lesser part of a modern solution — with third-party systems, tools and DevOps glue code making up the majority.
Software Architects don’t do systems, tools and glue code — because they’re myopically focused on software.
5. Software Architects love complexity.
This is understandable. Big, complex software constructs provide great job security. When software devolves to tiny constructs that each do a single thing, software’s complexity disappears. Building these small constructs is relatively easy. Which means the Software Architect is reduced to a Software Engineer. No deity enjoys being mortal.
If you’re wondering who replaces the now-deposed Software Architect and his central vision, the answer — riding in on the cloud — is the Solutions Architect.
In my next post, I’ll offer five attributes of a Solutions Architect. For now, however, join me in a moment of silence for the Software Architects among us.
Feedback? contact Joe with any comments
About the Author
An experienced C-Level executive with a breadth of experience in operations, sales, marketing, technology, and product development. Joe specializes in innovation and change leadership, having had success as both an entrepreneur and intrapreneur, across numerous industries including defense, insurance, telecommunications, information services and healthcare industries.
Joe relishes the opportunity to make a real difference, both in the success of the corporation and in the lives of the people he interacts with. A self-starter that neither requires nor desires large amounts of oversight having succesfully built numerous DevOps teams and Solution Architected some of the most advanced and secure utility computing applications.