Podcast: Challenges of the Software Architect

Software Architect Mark Richards

Mark Richards and Neal Ford- O’Reilly Software Architect Series

The title of “Software Architect” is often an ill-defined role. In the pursuit of a software architect role many critical facets of the skillset are frequently overlooked. It is also increasingly difficult to gain necessary experience as a software architect when most software architects focus on an average of one architecture a year-and frequently never see the full lifecycle of their work.

This week I sit with Mark Richards, author of several popular books and Software Architecture as well as hit O’Reilly video series and we discuss the challenges facing our industry and how to be better.

If you are a software architect who wants to build their skillset, or if you’re an aspiring architect do take a moment to look at our training opportunities.

ArchConf East is taking place December 12-15, 2016 in ClearWater FL.

Also, don’t miss Mark Richard’s 3-day architecture workshop, December 5-7 in Atlanta, GA!


Full Transcript:

[background music]

Michael Carducci:

You’re listening to “The No Fluff Just Stuff” podcast. The JVM Conference Series with dozens of dates around the country. They’ll be one near you. Check out our tour dates at NoFluffJustStuff.com.

I’m sitting here with Mark Richards, our resident software architecture expert, one of them. I know you’ve always been a popular speaker on the tour as well as in your architecture training sessions. Let’s talk about that. Let’s talk about architecture a little bit, why it’s important. Maybe, what are some of the most misunderstood concepts in the area? I feel like it is one of those things that are misunderstood.

I always knew a software architect, it’s something you automatically become after a certain number of years. Your first job, you’re assigned the title junior developer. Then, after a while, you quietly remove the junior because you feel like you’ve graduated.

Then, after a while, you start calling yourself senior developer, lead developer, and then software architect. It’s after 10 years, “Oh, I’m still doing software development, but I must be a software architect.” Have you seen that? Is it just me, that you start calling yourself that after a while, but there’s so much more?

Mark Richards:

Absolutely. You know what, Michael, it’s that one of the biggest problems it’s an ill-defined role, first of all. Some people consider an architect an uber-developer. Other people consider an architect, those that don’t even code.

There’s a whole gamut of range. But even more to the point, the journey from developer to architect is extremely difficult. One of those reasons is the lack of material in order to know what that progression is coupled with the ill-defined role, as well as the fact that a lot of that is simply born of experience, getting those lessons learned.

The problem is you may only do one, maybe two architectures a year. One of the big issues with architecture now is the fact that a lot of architects create an architecture in terms of this big upfront design and then move onto another project.

One of the issues that’s happening or it has been happening in the industry is that architects aren’t involved in the full life cycle of the project. Hence, you have no validation of whether those decisions and choices that you made were actually valid.

A lot of architects will make the wrong choice, not get that validated because they don’t see the full life cycle of that application or that architecture implemented, and therefore they keep making the wrong choice over and over and over. It is, in fact, a very difficult journey and a difficult role to define.

Michael:

Meanwhile, in that type of situation, the developers that are handed this architecture in the end, they start pounding it to fit, paint it to match. No, it’s not really anybody’s fault because the developer’s pointing this way, the software architect’s pointing that way and you move on.

Well, there’s a really important piece that gets missed in that is the evolutionary aspect of software architecture that nothing is static, especially in our industry in things we’re building.

Mark:

Exactly. This has been an ongoing problem in terms of this whole staging. In other words, you do the architecture, then you do the design. You do development. You do the implementation. The point is we have learned. We’ve learned a long time ago, but it still gets validated that that model doesn’t work.

The whole idea now is rather than simply focusing on, “What should our architectures look like in five years to support the business?” instead of crystal-balling that, what we should be looking at is more, “How can we make our existing architectures evolutionary so that we don’t have to crystal ball?”

In other words, if those architectures can evolve to the changing landscape of both business and technology, then we no longer have to think, “In five years, what do we have to go to, in six years or three years even for that matter?” because we can’t project what business is going to be like or even technology for that matter in a three to five-year time frame.

Michael:

We’ve already learned that doesn’t work. We’ve learned that it didn’t work a long ago when we started moving away from waterfall, this idea that we can gaze into the future and know, on day one, exactly what the requirements are going to be on day 600.

Mark:

This, Michael, has given a rise to a lot of the latest trends, especially when we use the terms, for example, microservices or service-based architecture. There’s several reasons why these are so popular. One of those aspects is, of course, evolutionary, but it’s also the need for our architectures to be agile.

We’re told, “Make your architectures agile.” What in the world does that really mean? One of those layers as we start peeling it apart is modularity. The more modular our architectures are, the faster we can respond to change.

That has given rise from the monolithic architectures which we would immediately go to more modular-based or service-based architectures which is what we’re seeing the trend in the industry moving towards at this point.

Michael:

Now, of course, those come with their own challenges, too.

Mark:

Absolutely. Because, especially, the biggest challenge, well, you know what, Michael, there’s two big challenges as we start to move towards this modularity because we’re talking about distributed systems. Distributed systems didn’t work well in the ’90s.

Michael:

No, they didn’t.

Mark:

We learned a lot of mistakes, but we have more reliable networks. We have more sophisticated tooling. We’re trying it again. To some degree, it is working, but there’s some challenges associated with distributed computing or, I should say, distributed architectures in terms of managing latency, distributed transactions, managing contracts.

All of these things make it very difficult. There’s another aspect though, Michael, that’s also happening, that is the organizational change that comes about from this movement towards modularity. The more modular and distributed we make our architectures, the more organizational change that’s required to match those architectures.

Those two things are the biggest challenges that I’m seeing in the industry right now in terms of embracing even the notion of microservices or modular architectures in general.

Michael:

Neal Ford is fond of saying that you have to be at least this tall to…

Mark:

To use microservices, right? [laughs]

Michael:

…to use microservices. When you talk about organizational change, is that in terms of everything that is required, the organization around what you need to really do microservices right? Or do you mean within the business?

Mark:

No, really both because, if we look at microservices, and this is a very interesting topic, this tangent we’ve gotten on, because the choice of whether to use a certain architecture pattern, in fact, as we’re learning does have implications on the business as a whole. For example, it’s no longer an architectural or a technical decision to use microservices.

There’s changes in the development teams and the way those development teams are structured in terms of cross-functional teams with service owners and domain owners. That goes all the way through testing, different ways of testing because, now we’re not only testing one application, we’re testing thousands of applications. That automation is a see change for most testers.

Scenario testing and dependency management all the way through the pipeline through deployment. Even deploying thousands of applications is a whole different model than just deploying one. The story’s not over because then we have monitoring of those production environments. This is where automation is really taking over, but it also requires that organizational change of the way we view our pipelines and the way we deploy software.

We no longer have one moving target that gets scheduled from week-to-week in terms of its progression across the staging integration systems, environments.

Michael:

Sure.

Mark:

Rather, now we’ve got potentially hundreds or thousands of different moving parts going through that pipeline at the same time. This is a big organizational change.

Michael:

You have to have the people to support all the process that goes around that, the testing, the DevOps aspect of it, and all these other pieces.

Mark:

Precisely, as a matter of fact, to your point, it’s not only just the technology or IT because business analysts, in terms of defining the root cause analysis of, “What needs to change?” Well, before, it used to be one big application. You can get your head around that one big application from a business analyst or product owner standpoint.

Now, what we’re looking at is such a level of distribution and modularity that it’s hard to understand what needs to change to implement this particular business feature. That analysis in terms of change analysis is very, very difficult as well.

That also plays into that area of the business. It’s not just technology, it’s also business.

Michael:

Would some of that guidance, if you will, fall under the purview in the role of a software architect that part of your job is to not only sketch out these architectures, but be a thought leader for other areas of the organization?

Mark:

Absolutely. As a matter of fact, I’m going to channel Michael Nygard, who’s very fond of saying, “A software architect must be involved in the full life cycle of a project.” I couldn’t agree with him more on that.

This is really broadening that role of an architect, not only from the technical aspect but also those soft skills in terms of the negotiation skills, the facilitation skills, the leadership skills of that architect to be able to manage the implementation of that architecture not only from a technical development standpoint but all the way through the entire life cycle, even validating it from a business capability standpoint.

Yes, I would entirely concur that does expand the role of an architect, absolutely.

Michael:

These are the aspects that are really, really ill-defined, that are frequently overlooked, all the soft skills that are necessary, the leadership in general is necessary. A lot of people think, “Well, I’ve been coding for so long, I’ve built some good applications, therefore I’m ready to be an architect,” and there’s so much more that falls into it.

There’s so much success or failure that ultimately rides on your shoulders.

Mark:

It’s interesting, Michael, you say that because I get not pushback but challenged really in terms of the question, “Why should I need to know negotiation skills as an architect? This seems like that’s something that would be more in a business.” It’s really easily answered by saying, “The decisions that you make as a developer are really not challenged.”

I may make a certain decision to use maybe a strategy pattern or an observer pattern from design patterns in order to solve a particular problem in my code. I may get applauded for it. No one really cares. But if I make decisions as a software architect, those will generally be challenged.

Depending on the magnitude of that change, I have to know negotiation skills. I have to know leadership skills, communication skills to be able to get those decisions pushed through the business.

Michael:

That’s one of the challenges that a lot of people with a software engineering background run into is they feel like they’re making a good case because logically it makes sense for them that, “We’re going to build this. It’s going to work this way.”

One of the sessions I give, The Influential Engineer, which is exactly about that being more persuasive, being able to make a more effective case rather than just a good logical case because people, as we know, aren’t logical.

Mark:

Precisely.

Michael:

Making that case to the business that, “We need to make all these changes to implement this strategy, this pattern,” is I say in the course, in the talk, that it’s not enough to have a good case. Success goes to those who can make their good case well.

Mark:

See, that’s precisely it, exactly. Too many software architects focus on the technology aspects, as you said, in terms of the justification and don’t translate those to business justifications in terms of that business value. That is a necessary step.

In order to do that, however, an architect has to have those people skills, those soft skills but also knowledge of the domain, in other words the business they’re working in. This is a lot. This is a lot to place on an architect.

Michael:

Yeah. Well, I want to talk about microservices, cover one more thing, because I know it’s a very interesting space. There’s a lot of buzz in that space. The joke is if you go to a conference, if you had a conference Bingo card, microservices would be the free in the Bingo.

But there’s a lot of buzz around microservices for a good reason, but not everybody has the organizational structure to implement a microservice architecture. What are some of the lessons that you can learn from microservices if you’re not in a position to implement everything? What are some architectural lessons you can learn and apply to whatever you’re at, wherever you’re at right now?

Mark:

One of the biggest lessons learned in that case really is knowing that microservices is necessarily a very restrictive architecture style. It’s restrictive on purpose in order to achieve some of the testability, deployment, and high agility capabilities of that architecture pattern. The problem, as you’re describing, is a lot of times it’s not feasible.

In those particular cases, it’s moving towards looking at hybrids. In other words, instead of dividing your application up into a thousand small pieces, dividing your application up or partitioning it in terms of maybe 6 or 12 areas of the application and sharing a database context as opposed to being able to split that, your large relational database into hundreds of different individual schemas or databases.

These things as well as coupling that with the whole DevOps requirement for microservices, and I say requirement because of, it’s not feasible to manually monitor and manage the life cycle of hundreds to thousands of small applications. It’s just not feasible. All those pieces are required.

Moving to more of a service-based approach even as a transitionary point to microservices is a very smart move. In my experience, most of the companies that I’m working for, originally started out with all the best intentions of using microservices and quickly found that fine granularity of those services really does not suit them well.

They end up towards these more coarse grain services, i.e., what I like to call portions of the application, which then still are achieving some level of scalability, better testability, better user deployment, but without the complexity of the organizational change, DevOps, containerization, registry tools.

Now, granted, monitoring tools, these all help, but my point is they’re not required because it comes more feasible to manage 6 to 12 applications manually.

Michael:

Versus a thousand or more.

Mark:

Correct. This is what I’m seeing in the industry is the desire to move to microservices, and maybe eventually get there, but this transition point in terms of this service-based architecture where you really are not hitting the tough nuts, like breaking apart a database. That’s a tough nut to crack.

However, splitting your application apart to achieve better testability and decoupling a modularity is not as hard of a nut to crack. This transitionary point is what I’m seeing happening in the industry.

Michael:

Absolutely, for a lot of organizations that might be a sweet spot. It’s still worth learning the broader ideas in the architectures around microservices, but then cherry picking the pieces that are going to bring the most value to you and to your organization.

Mark:

Precisely. Exactly, yeah.

Michael:

One of the things I really like about your style of teaching, both in your classes and your training courses, is that in addition to laying out these patterns saying, “Hey, here’s one way of doing this. Here’s one way of doing that,” and talking in broad strokes about architecture, the really hands-on nature of the katas.

Mark:

That is what has made, we like to call it the three-day hands-on architectural workshop. You might be confused about hands-on because, usually when you think about a workshop, you’re sitting there with a laptop, installing code, and stuff like this. How do you do that with architecture?

The architecture katas have paid off in spades with that. The kata, being a Japanese word for form, is originating from katas that you may have in karate, for example. These are movements, forms that you can actually use as a grounding to build a solution. That’s exactly what the katas are.

Yes, in the three-day architecture training that we say, all through all three days, we work on katas, to be able to exercise the concepts that we’re using. This idea really originated from Ted Neward who observed, as an architect, you may have the opportunity to work on maybe one, maybe two architectures a year.

How can you possibly gain the level of experience that we need with that few of architectures that you can work on?

This is where the idea of the katas came from. It does add a lot to the course, to be able to actually practice some of the aspects, for example, of identifying characteristics, driving characteristics, those ileitis which then drive patterns, then selecting patterns which then drive which components you’re going to have, that whole process of building out an architecture, and actually being able to do that through katas.

Michael:

Not only do that, but get instant feedback.

Mark:

Correct, yes, exactly, because being able to present that architecture is also a valuable experience. That, in and of itself, is in fact a kata. Being able to present an architecture, knowing how to document and diagram your architecture, effectively present it to different stakeholders, whether they be peers or other software architects, maybe it’s developers, maybe it’s stakeholders, business people.

These are all different ways of presenting an architecture.

Michael:

You’ve almost got to speak a different language because what one person values as an engineer, another person values as a software architect, and another person values as a business owner. Those are completely different perspectives.

Mark:

Precisely, yes, exactly.

Michael:

That’s where I see the biggest value is that you’re able to do this over and over again and the interactive nature of that. The fact that, during the presentation as a group, people can reflect on these things as well. You get the benefit of the experience of doing it several times. You get the benefit and experience through other people’s work, and you’ve got, obviously, your expertise and guidance throughout this whole process as well.

Mark:

Well, one of the other key aspects of not over the course, but even just doing katas, if you were to do brown bags, is the importance of working in architecture teams. Working on a kata individually will only get you so far. It’s learning how to work with other architects and architecture teams whether it be two, three, four, or even up to five people.

Different ideas, different approaches bring light to other alternatives that you may not have ever thought about as an architect. I still maintain, no one single architect knows exactly all the solutions. It’s that collective knowledge and experience which is what gives us great architectures.

I love working in architecture teams. Now, granted, I have had some struggles in architecture teams and sometimes it doesn’t work. Architects, as we all know, tend to be arrogant, egotistical, and my way or the highway. “There’s only one way to do this architecture.”

Michael:

Obviously, the listeners are excluded, but in general.

Mark:

Listeners excluded, in general. All kidding aside, knowing, creating that unified vision of architecture, working together to create that, and using that collective knowledge has been so valuable. It has created some really wonderful working architectures.

Michael:

I’m fond of the quote that Bill Nye was created for coming up with. He said that, “Literally everyone you will ever meet knows something that you don’t.”

Mark:

I love that.

Michael:

That’s particularly germane or particularly pointed when it comes to working in these architecture teams, that I might be this 20-year veteran software architect who’s seen it all, done it all, but I guarantee you, somebody in that room is going to have a different perspective, a different experience, and some nugget of information, that nugget of experience maybe, that is absolutely key.

If you can go into the room with that perspective that, “I do not know it all,” you’re going to be so much more successful.

Mark:

Also, learning people skills is probably one of the bigger challenges because, although I do training in the workshop, as a matter of fact, we spend an entire day on the soft skills of architecture, the techniques, and stuff.

While I can do some level of training in leadership, negotiation facilitation, forming boundaries around teams, and guiding development teams, a lot of that I can lay the seeds, but it has to be learned. Working in architecture teams, especially, being involved in development teams really helps build those people skills.

They are necessary to be a successful software architect. To be an effective software architect, you have to have those communication skills, those people skills. Knowing how to get along with people, it’s absolutely necessary.

Michael:

Ironically, I joked in the beginning about how a software architect is something you just automatically become after 10 years, but it’s those exact skills that you don’t need necessarily as a software developer.

Mark:

Correct.

Michael:

I say that because, truthfully, to be effective in any endeavor, you need more soft skills, you need more people skills. It’s less important as a software engineer and it historically has been. We sit in the dark room, write code, and hand it over to the business.

It’s, all of a sudden, everything that’s worked among your peers, software engineers, maybe your line manager, and maybe a project manager, all of a sudden, the entire landscape has changed.

Mark:

Absolutely, yes. As a matter of fact, one of the other big challenges in that path, now that you bring up the moving from developer and the skills of the developer are two fairly major, what I like to call, paradigm shifts. It’s the way, first of all, we think about technology because, as a developer, we have our expertise, that area of expertise that we all know, love, and that we do every day.

However, as a software architect, you still have to maintain that level of depth, that technical depth. You have to maintain it, but what’s more important is the technical breadth. In other words, knowing about 12 different technologies as opposed to 1 really well. That’s just technology. We’re talking tools and frameworks and passion technologies and platforms, you name it.

This is a huge paradigm shift because most people who transition to software architect think, “Well, I have to go deep in these languages, these technologies,” and there’s no way you have the bandwidth to go deep. It’s not necessary to go deep. In other words, as a software architect, you have to change your way of thinking. It’s more important to go wide.

We’re still maintaining some level of depth, your chosen areas of expertise, but you let that slip a little bit to be able to go wider in terms of that technical breadth. The other paradigm shift is really that line that divides a software architect from design. This is always one of those gray areas. Where does architecture end and design begin? This is always one of those very interesting discussions.

This is one of those other paradigm shifts because, as a software architect, we quite frankly define the components, the operations of those components, how they interact with other components. A component being a building block of an application. Then that is what we hand off to developers or development teams to be able to design those components, to be able to figure out the class diagrams.

The problem is in the transition from developer to software architect, this is the other paradigm shift, because we are so ingrained in the technology. As a software architect, I’m defining a component and I say, “I know exactly how I would write this. I know exactly the algorithms that should be used.”

The tendency is we steal away the art of programming away from our development teams because we are giving them the solution instead of the building blocks. That’s hard.

Michael:

Now, all they’re doing is typing it up.

Mark:

Exactly.

Michael:

Which is soul crushing.

Mark:

It is so hard to remove yourself from saying…

Michael:

To let go.

Mark:

…”I know how I would code it, but I got to let go.” That is the other paradigm shift.

Michael:

Wow.

Mark:

Those are the two biggest challenges in my view of that transition to software architect.

Michael:

Well, I want to bring it home because I know understanding that there’s so much to learn. Obviously, we understand the depth of this. You and I and the tour because you’ve got the architecture training you’re doing with No Fluff. You’re coming to ArchConf, I assume.

Mark:

Oh yeah.

Michael:

We’ve got ArchConf coming up as well this year, but what’s something that somebody could do today? If I wanted to start moving in a direction or if I’ve had the ambition to start moving in that direction and I’m not going to any training right away, I’m not going to any conference right away, what’s something I could do right now?

Can you recommend a book, a resource? I know you’ve got your O’Reilly videos.

Mark:

As a matter of fact, that is just such a lead-in to plug all of my videos from O’Reilly, my books from O’Reilly, but the point is I do have a lot of books and videos on software architecture, which, if you go to my website, wmrichards.com, go to the Publications section, and you’ll see links. Many of those are free.

As a matter of fact, if you have Safari Online, all of that’s free. But a lot of the books and reports that are written are, in fact, free from O’Reilly. Aside from the plug, which thank you, Michael, for allowing me that, a little input, but all kidding aside on that plug, it’s really focusing, in my opinion, on getting that leadership and people skills piece under your belt.

Getting that domain knowledge, starting to prepare in that way leads you into understanding some of the more technical aspects of architecture, understanding the patterns, understanding architecture styles, the characteristics of those styles and which ones. That’s more of the technical side of architecture. That will come.

There’s lots of resources to be able to find that information, but focusing and really concentrating on working with your team, being a leader on your team is a great way of preparing you for that road to being a software architect. You’re going to basically be building that platform on which to really excel.

Most of the challenges I’ve seen from other folks who are in that architecture space is backwards. They get the technical aspect of architecture, but then they can’t communicate with teams. They can’t lead teams. They can’t present architectures. They can’t negotiate. That’s what usually those glass ceilings then exist. It becomes a very frustrating job.

My words of advice would be check out my website under Publications. Grab all of those things, some of the videos that Neal and I have done, videos that I have done, books and stuff like that. But more to the point, really to sum it up, focus on leadership aspects.

Michael:

Wonderful. Well, Mark, thank you for your time. I appreciate it.

Mark:

Thanks, Michael.

Michael:

I’ll see you at ArchConf.

Mark:

Cool.

[background music]

Michael:

At No Fluff Just Stuff, we bring the best technologists to you on a road show format. Early Bird discounts are available for the 2016 season. Check out the entire show lineup and tour dates at NoFluffJustStuff.com.

I’m your host, Michael Carducci. Thanks for listening and stay subscribed.

[music]

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*