Architect Tip: Developer vs Architect

Architect Tips

Welcome to Architect Tips presented by Clear Measure, a software architecture company. Empowering .NET development teams to be self-sufficient, able to move fast, deliver quality and run their software systems with confidence. Make sure to subscribe on YouTube or your video podcast feed. If you have a question for the show, send them to [e-mail] and the next tip could be yours.What's the difference between an architect and a developer? Let's talk about that. Now, as a developer, when you're joining a team, you're shown the ropes. You have a new workstation and you're given a tour of the documentation of the software at the source code and you're given a first assignment. You're given the spec or the design for something to change first, where to go, what the process is, how to build the software, how to test the software, run the automated test Suites, build, and deploy to not only locally, but maybe a test or a TDE environment before ready for manual testing and then you get to work. Now, I understand that some of your experiences as a developer are that you get thrown in there, you're told nothing, software has no documentation, the source code is disorganized, there's no build, no automated testing. No nothing. And you're given a bug and say, hey, go fix this and you’re fending for themselves, for yourself, either one of those scenarios.

You, as a developer, your job is to write code that is a change to the Software System. A change that is determined to be useful by somebody else and to actually make that happen and produce a new build of software with that change without breaking something else. Okay, your job is to do things, is to implement the changes that are necessary. All right. Now let's talk about the world of an Architect.

Architect is what I do. If I'm an architect, well, your umbrella starts with possibly ambiguous conversations with somebody who is funding the software, or maybe who owns the software, and they have some business objectives, outcomes that they want from the software and they're talking about it generally. And it's your job as the architect to just hear what they're saying and what their goals are and to start formulating that

into some type of plan to make that happen and to make that happen via one software application between a mix of changes to a number of software applications, whatever the scope is. Because you as an architect, some architects work at the scope of a single small application, some Architects work at the scope of an entire organization with dozens and dozens of systems that all have a dependency graph between them. So as an architect, your scope can be really, really huge at massive companies and massive organizations or it could be very, very confined for a particular application, but the one common thread of what an architect does is translate the ambiguous to a business outcome facilitated by software and so the developer’s scope in the process is here, when we've already decided what we're going to change, now, go implement it in the code, the Architect’s job is very broad. Starting with whatever conversations with business stakeholders, all the way through breaking down the designs that we're going to select for proof of concept. If necessary, break it down into a sequence of work that can be done in order by a developer or multiple developers, the testing and the overseeing that we have proper quality control promotion to downstream environments. And then, as we push it into production to make sure that the business outcomes that we were designing for are actually happening. Because if it didn't we're not done yet because we were asked for a particular outcome and then we hypothesized that a set of designs will achieve the outcome. We aren't done until we've actually achieved those outcomes because it may take a couple of tries and say when we implement few designs, we made some progress but we're not yet there. Now we need to know we need to come up with an additional design to help with that. So that's you as an architect. Now architecture ,the word architecture itself, doesn't have a good definition, try doing an internet search, you're not going to find much or you're going to find a lot of stuff but you're not going to find agreement and you'll see things like architecture is the carefully designed structure of something. Or architecture is the hard stuff or architecture is the intersection of designs that produce the hole and you'll have a myriad of other commentary and message boards. All about what architecture is but that's not what's so important.

What I want to focus on is the role, not architecture, but developer and architect. And some of you listening to me, who are developers, you're thinking, wait a minute...I do all the stuff that you just described as the architect role, that's great. That means that you are fulfilling the architect role. And it's good to recognize that you're already doing some or a lot of that job. Now, the biggest thing about an architect is that Architects produce outcomes a long time old scripture says “you shall know them by their fruit”, Matthew 7:6 16 and that is true. Architects produce outcomes. If an architect is not producing an outcome by orchestrating an ambiguous request into everything concrete that needs to happen, then they're not doing the architect job. So hope that helps with a difference between an architect and a developer and go empower your team.

Thanks for watching Architect tips! If you would like help improving your team, speed, quality or software stability... Send us a note to architecttips@Clear - measure.com. On behalf of everyone at Clear Measure, thanks for watching and may God bless you.