The shape of software architecture
Five things we learned from the O’Reilly Software Architecture Conference 2015.
Magleby Maersk am Maasmond (source: Kees Torn, Maersk)
Last week, I had the opportunity to see the first Software Architecture Conference spring to life after a winter of preparation. Software architects, with or without the official title, swarmed the halls learning from speakers and attendees alike. I count myself among the people who were learning. Many notions about this profession and skill set have become clearer to me and I’m already planning to keep the content coming. I’m also in the early stages of developing out the next Software Architecture Conference (spring 2016).
Within this piece you’ll find my takeaways and lessons learned from the event. I expect these initial impressions to both shape our upcoming exploration of software architecture and be shaped by continued shifts within software architecture.
Learn faster. Dig deeper. See farther.
You, too, can be a software architect
Start cultivating solid problem solving and team management skills whether you’ve been on the job for six weeks or six years. In your spare time you’ll need to make sure that you keep up on new and old frameworks, techniques, and programming languages. Being a software architect isn’t about being the best Python programmer in the workplace. It’s about being able to identify and solve problems for your business. What is the multi-year time and budget investment for the new architecture and how fast will it be recouped? If you want to be a software architect, you should invest time in understanding how your business works and where software architecture investment sits within the company.
Related keynote:
Software architecture as a skill rather than a job title
Chances are, you’re probably already an accidental architect dealing directly with and around your company’s architecture. Depending on the size or structure of your company you may not have someone with the official title of “software architect,” but you can be certain that you have a software architecture of some size and complexity. That development, optimization, integration, overhaul, or evolution falls on the engineers and IT teams. If you find yourself in a position such as this then you are likely cultivating software architecture skills on the fly. You’ve possibly also been thrown into management of project, products, and people, or some combination of the three. So, whatever your title is – team lead, developer, software engineer – be sure to think about the big picture as well as the one in front of you. Learn about transitioning microservices or reactive architectures, continuous delivery, and containerization. You’ll be a better team lead, developer, or software engineer.
Related interview:
Ivory tower vs in the trenches
The old concept of a software architect hidden away planning out a monolithic architecture is becoming harder to find in reality. With the myriad choices in styles, frameworks, techniques, and languages now available, being a modern software architect is much more about assembling the right team of experts around you and guiding that team toward answering your company’s and your consumers’ needs. Furthermore, the belief that you are now “management” and no longer have to “do” is a bad idea. While you are surrounded by a talented team, you still need to be able to make decisions about technology and troubleshooting.
Related keynote:
What is the reality: microservices vs monolithic
Some joked our conference could have been subtitled “Microservices, Microservices, Microservices!” As you probably know — and as was clear from the sessions and discussions at the event — microservices are the new hotness and have been for a couple of years. But is the excitement and attention paid to them a reflection of what is out in the actual world? Simple answer, no.
Netflix, Orbitz, and Gilt are implementing microservices and talking about how they’re doing it at meetups and conferences. However, I always like to take a moment to remember that there are millions of developers and thousands of companies out there, and only a percentage of those people and organizations show up at tech conferences, and even fewer give talks. Scott Hanselman calls these folks the Dark Matter Developers: The Unseen 99%. Architecture across industries didn’t instantaneously change and may not for a variety of reasons. At O’Reilly we think that every business is a software business, which is generally true, but that doesn’t mean microservices is a fit for everything or that you can throw legacy architecture out with the bathwater. We will continue to see a shift toward these loosely coupled systems, though it will take time to permeate all companies and it will continue to shift. Just take a look at The Reactive Manifesto.
Related keynote:
What you do today matters tomorrow: Coding for the next person
Whether you’re using microservices or building a monolith, what you do today will echo for years to come. One of my favorite questions is “How do you cope with legacy?” I keep that question vague for a reason. Legacy can be a good or bad thing and can take the form of fairy tale or horror story. Legacy can be very tactile thing, like a lawn of Android sculptures outside of Google’s main campus, or it can be ethereal, like “Steve Jobs once said to me…” stories. One thing is certain, however; legacy evolves with age and can take on a shape that was never intended. So, create, architect, solve, and code like it matters, because it does. If nothing else it will matter to the next person.
Related keynote:
As always, this is a snapshot of where my thoughts are today, but I guarantee they will evolve and change over the coming months. Stay tuned for a variety of content on software architecture from blog posts to videos as well as trainings to events.
The preceding is part of our ongoing exploration into learning how to solve programming problems.
Public domain nautilus image courtesy of Internet Archive via Flickr.