Skip to main content

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect. 

They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about. 

He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things.

He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something in this field, by establishing why a need exists and then later explaining the concept.

There are three things covered that influence architecture. First, agility, which is the speed and coordination to change. Most companies try to embrace this, but many businesses fail at it. Second, velocity, which is the speed of something in a given direction. Third, modularity, which is when independent parts can be combined in lots of ways. They went over the upsides and downsides to each, and you have to compromise many times at one aspect for another

I thought one of the most interesting parts of the podcast was when he said that if you wanted to see what was coming next in technology, read academic papers from twenty years ago. It takes that long for one level of the level of architecture, hardware, to catch up to another, software. It is only recently that we can implement this technology.

Another interesting thing he said was that one of our biggest inhibiters to evolution is the integration of data and functionality. He foresaw a paradigm shift in how we handled this.

As a parting message, he was asked, “what would one piece of advice you would give to an aspiring software architect,” and his answer surprised me. He said to work on people skills, and that was the “hands down” most important advice he could give. This skill is so key in everything you do, including lead and mentor. I found this incredibly interesting, because I am often reminded about how we never do everything in a bubble, and it is extremely important to be able to “play well with others.”

Comments

williambli92982 said…
You must take part in a contest for top-of-the-line blogs on the web. I will suggest this site! casino blackjack

Popular posts from this blog

Sprint 5 Retrospective (Capstone)

It is a shame that we are so close to the end of the semester. We were gaining so much momentum. It took us a while for us to get off the ground, but once we did, we never stopped gaining speed. I feel we will be able to keep this up through this last sprint. My hopes at the beginning of the semester for what we could accomplish were unrealistically high, but I am not disappointed with what we accomplished. We have not completed a full working component quite yet, but we are very close. I think our efforts are best spent finishing the one we are currently working on and doing it right. If we divided our efforts into starting something new, we run the risk of not fully completing anything. In the sage words of Ron Swanson, “Never half-ass two things. Whole-ass one thing.” If we are able to get the tabs working beautifully, I will be happy with our effort. I have felt that our group has done a phenomenal job this sprint and every sprint before with our communication. We have a few ...

Testing: Like Destroying Sandcastles

https://joecolantonio.com/testtalks/223-testing-dream-journaling-smashing-sand-castles-with-noemi-ferrera/ In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject. Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out.  The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of lookin...

Data Structures Primer

I've been a tutor for this past semester to students taking Introduction to Programming. Many who have come to my session are moving on to Data Structures next semester. They asked if they could have a primer as to what to expect. I have some resources that I have found helpful both while taking the course and tutoring it in the past. It will take me a little bit to compile a good list of those, but for now, here is a bare-bones list of topics of topics you might expect to see for a data structures course: Part 1: - Running time of code segments (Big-O Notation) - Abstract Data Type (ADT) - Interfaces (when to use "implements", cannot instantiate them, what inheritance is) - Superclass, subclass, method overriding/overloading - Abstract classes Part 2: - Binary Search Trees - Stacks (and its four methods — push, pop, peek, empty) - Linked list (single, double, circular) - Prefix and postfix notation (compare to infix) Part 3: - Min/Max Heap - Hash Table...