Software architecture in 2019

Software is increasingly becoming more complex, and dealing with the changes happening in the software industry every day is something all developers, especially software architects, need to pay attention to.

While software architecture isn't anything new - the speed of mobile undoubtedly has put critical elements of creating software outside of the main focus for some, but there is a conference dedicated to software architecture that puts developers architecture, and just about everyone touching software development in the light. It's called The O'Reilly Software Architecture Conference, and it's happening February 3rd - 6th 2019, in New York, NY.

We recently sat down with Neal Ford to talk about software architecture in general and what it means to large development teams, and indie's too. Neal is Director, Software Architect, and Meme Wrangler at ThoughtWorks. He's also authored six books, and spoken at over 300 conferences on, or around this topic.

The below excerpt is insanely valuable advice to anyone touching software development, but it's in no way a complete guide - that's something you can get at their conference. Early Price passes are on sale now through December 14th, and App Developer Magazine readers can save 20% on their passes when they use code DEV20 at checkout. This is one of the first conferences of the year for developers, and it comes recommended by many leaders, including the staff at ADM.

ADM: Software architecture is a term that morphs every year as new platforms come online at a blinding pace, how would you define software architecture as it exists today?

Ford: I see you're starting with the easy questions! One of the first requests I received when I first became conference co-chair of the O'Reilly Software Architecture Conference was for a concise, succinct definition of software architecture…and I refused! The great definer in the software world is Martin Fowler, and even he famously declined to define it in his famous white paper Who Needs an Architect?, eventually falling back onto Ralph Johnson's famous definition: "Software architecture is about the important stuff…whatever that is". I eventually created a sprawling mind map that touched on many of the areas of responsibility for modern-day architects, but it was woefully incomplete, partially because it's a constant moving target. For example, ten years ago, architects had virtually no influence on things like operations. Now, however, with the rise of architectures like microservices, operations and DevOps have become an integral part of architecture. Software architecture continues to rise in interest because companies and enterprises have realized that, when done well, it confers a strategic advantage. For years, many companies viewed software as overhead. The smart way to handle overhead is to minimize cost. However, some companies viewed software and architecture as strategic, blindsiding traditional companies. Science fiction author William Gibson has a great quote: "The future is already here, it just isn't very evenly distributed." Companies who still view software as overhead will likely see a rude awakening in the near future.

ADM: Does software architecture apply to indie developers, as well as large teams of developers?

Ford: We have a specific target demographic in mind for O'Reilly Software Architecture Conference we call "Accidental Architects". Regardless of the ability to define it, software architecture certainly encompasses decisions that have long-term impact and implications. Even on one-person teams, someone must make those kinds of decisions, regardless of title. We firmly believe that an architect is a role, not just a title, and many different people on projects may play that role at different times. Thus, we believe that the more developers understand about architecture, the better their burgeoning decision-making process can be. We always include a number of sessions tailored to developers making the gradual transition to architect. And we also feature a popular Software Architecture Fundamentals two-day training class explicitly for that purpose.

ADM: How do programmers and software architects differ?

Ford: Rich Hickey, the creator of the Clojure programming language, has a great quote: "Developers understand the benefits of everything and the tradeoffs of nothing", to which I've added, "Software architects must understand both". Software architects gradually realize that everything is a tradeoff of some kind (even things you don't think are a tradeoff often just means you haven't identified it yet). Mostly, software architects are developers who have seen lots of code bases and thought about what worked and didn't work. One of my tongue in check definitions of software architects is someone who has "seen enough terrible code bases to recognize another one upon sight".

ADM: With so many platforms that could influence software architecture - all with a different approach, are there common principles that exist among them to help developers create good architecture?

Ford: Regardless of software architecture, good engineering practices provide those principles to build any kind of software. In fact, in the most recent ThoughtWorks Technology Radar, one of the themes called Enduring Engineering Practices addresses this. New architectures become successful when architects, developers, operations, and other roles figure out how to apply proven engineering practices to them: continuous delivery, testing, collaboration and so on. Just like any kind of engineering, new innovations must fit into existing ecosystems because we gradually evolve things, not in giant leaps.

ADM: Low code and no code platforms are exploding in use, but does software architecture matter when using low code platforms like Outsystems or Filemaker? And does a developer using those platforms have any influence over the architecture itself?

Ford: Low code environments continue to wax and wane in the software world. In the 1990s, we had RAD tools (Rapid Application Development) and 4GLs (Fourth-generation Languages like dBASE, FoxPro, PowerBuilder, and so on) and CASE (Computer Assisted Software Engineering) tools. Yet each of these approaches ended up failing. We analyzed this problem in our Building Evolutionary Architectures book and called it the Last 10% Trap. Back in the 1990s, I worked for a consulting company who built applications for clients using Microsoft Access; we eventually shuttered that part of the company because we noticed a common pattern: all Access projects started as a booming success yet ended in failure, and we wanted to understand why. In all low-code environments, 80% of what you want to create is fast and easy to create because you're building something the tool is suited for. The next 10% is possible but difficult because you reach some limit to the tool but can figure out a way to work around it. However, the last 10% is impossible, because you're trying to achieve some outcome beyond the capabilities of the tool or framework. Regardless of how powerful the 4GLs were, we eventually switched back to general purpose languages because of architectural concerns. Low-code environments must have some kind of runtime to support the code you don't write, and it has architectural characteristics: performance, scale, elasticity, availability, reliability, and a host of others. No one yet has created an environment that provides the flexibility of general purpose code plus proven architectural patterns to build real systems.

ADM: Tell us about The O'Reilly Software Architecture Conference you host, how did it get started, and what is the main focus for developers attending?

Ford: We started O'Reilly Software Architecture Conference just as companies started realizing how important architecture can be when done correctly. Success stories like Amazon and Netflix along with the corresponding rise in architectures like microservices provides an excellent basis for a new conference. Many developer conferences feature a track on architecture, but they can't go very deep or broad on architectural topics like a dedicated conference can. Because we're only about software architecture, we have in-depth talks about cutting-edge technologies. But we also have space for aspects of the job that challenge many software architects, particularly new ones. For example, it doesn't matter how brilliant your technical vision is if you can't present it to management effectively. Soft skills like presentations, meetings, managing developers, and other topics also have a space at the conference.

ADM: For developers wanting to attend the conference, what are the main takeaways you hope they walk away with?

Ford: O'Reilly Software Architecture Conference is a great conference to learn about the cutting edge innovations in the software architecture world. To that end, our morning sessions are 90 minutes, so that the speakers have time to delve deep into subjects. The afternoon sessions are 50 minutes, allowing us to feature more talks. Thus, attendees can create a balanced schedule between technical topics, soft skills, learning new techniques or platforms, and a host of other activities. One thing we have learned about our attendees is that they love to network, so we provide lots of opportunities, including a party game where teams build an architecture while onlookers observe and comment. Many architects within companies don't have many peers; coming to this conference provides a great place to network, learn, and commiserate with peers within and outside their normal industry.

ADM: How do you see software architecture changing as more complicated elements such as machine learning, augmented reality, and cloud-native application gain traction?

Ford: The way it always has. Five years ago, we didn't have Kubernetes; ten years ago, we didn't have microservices. One key lesson from any long-time observer of architecture is that it never ceases changing, and the pace of change continues to increase. Thus, we must become better at building evolvable architectures because we cannot possibly predict what the ecosystem will look like in any long-term future state. A common question I get: "What is the next big thing in software architecture going to be?" My reply: "I have no idea!" Because it will come like all major change has: a small change will trigger another small change, which in turn will trigger another small change until, fractally, the entire ecosystem has fundamentally changed. The more we build architectures with the expectation of change the less we'll be surprised with it arrives.