Michaela Murray

18 August 2020

The IT Architect Interviews #4: The Senior Software Development Engineer & Architect

What does it take to be an IT Architect and what do they do? To find out, Redgate’s Michaela Murray is interviewing a number of Architects, each of whom have a different perspective. In this episode, she talks to Lace Lofranco, Senior Software Development Engineer & Architect at Microsoft, to discover what drives her and what her role actually entails.

Lace, could you tell us what your role is at Microsoft.

I’m a Senior Software Development Engineer and part of the Commercial Software Engineering team. As the data expert, I focus on Big Data analytics, machine learning, data engineering, and scalable architectures.

How does being an Architect fit into that role?

We don’t really have a traditional Architect role in the team I work in. The tech lead fills that role because it’s important for someone to own the decisions and be responsible for the overall architecture of a solution. But just because you’re the Architect, it doesn’t mean you’re on your own. You still rely on lots of subject matter experts to create the holistic picture of the overall architecture and develop it.

Based on my experience in other companies, the Architect isn’t necessarily part of the implementation team.  I think it’s a lot better when the Architect owns the decisions and is accountable until the end of the project. In our case, the tech lead is the Architect but he or she also fills the role of Software Engineer, so they’re responsible for the delivery of the architecture as well. That ensures you really think about it because you’re on the hook to deliver the actual system.

So it’s not the traditional Architect role in other companies where there’s a very hard line between being a Software Engineer and an Architect, and typically the Architect would not actually write any code at all. I believe that in order to be an effective Architect, you need to have the applied experience and be fairly hands-on during the entire lifecycle of the project.

How do you see the role of an Architect evolving over the next five years or so? Do you think Microsoft’s approach of having the tech lead filling the role will become more common?

It depends on other folks’ experience but from our perspective it’s worked well because you’re personally accountable for the architecture, not just in the design phase but also in the delivery phase. That makes the design a lot more important because it’s not something you just chuck over the fence.

I guess that means you have to have really strong skills in both design and also in implementation.

Exactly. And even if you don’t have exactly the right skills for that specific project, there are always subject matter experts you can consult with and who can help with designing the architecture. There might be parts where you’re not 100% sure it will work and that’s where we focus on seeing if it’s even possible. We fail fast basically. You learn really quickly that one part isn’t going to work, straight up front, not a month into design or a month into development. So you want to fail fast at the start, spike specific areas you’re not sure about, then make a call depending on the findings.

With the Architects being part of the development team, how do you bridge the gap that often exists between IT and business?

The CSE team has a game plan we follow when kicking off an engagement that has three steps. We don’t really want to talk about tech very early in the engagement, so the first phase is consulting with the business to understand what the problem is and what we’re trying to solve. That stops us jumping ahead to a particular technology or having a bias. I have a technical affinity toward Apache Spark, for example, so I’m often prone to thinking ‘Oh, Spark could fix this’, but it’s not always the best option. Basically, this is a scoping phase.

The second phase is all about designing. Once you know what you’re building or the problem you’re trying to solve, that’s when technology comes in. It’s where the Architect role kicks in and it’s more than just a bunch of visual diagrams. You actually write code to resolve any spikes that come up.

Once you have a preliminary design which has been reviewed by not just yourself but also the subject matter experts, that’s when we start the third phase of building. It’s a very agile iterative process with sprints, a backlog of tasks and a retrospective at the end of each sprint. Even with the design phase upfront, it might change depending on things we learn along the way or areas we didn’t account for. So the design isn’t necessarily set in stone, it’s still fluid in the sense that you can change it during the build phase.

Importantly, though, we always build the solution with the customer. There is no Microsoft team and there is no customer team – it’s a single team pulling from a single backlog and we work as a group. So it’s not just the actual thing we’re building, it’s the way we build it that we want to leave with the customer. You can’t really accomplish that without bringing the customer along the journey. A nice side-effect of this is that you don’t really have a big handover with the customer at the end because they were part of the journey. They know exactly how everything works and how to run it in production.

I guess your top tip on how to bridge the gap between IT and the business would be to involve them from the very start and throughout the whole process?

Yep, absolutely. We always want to have regular touchpoints with the main stakeholder of the system, usually the product owner from the customer side who makes the call on which features are to be implemented. We want to make sure that they’re part of it every step of the way. We also involve them in the retrospectives and typically have demos of the things we’ve built during the sprint. That way, they know whether or not we’re on the right track because it’s a very tangible aspect of what we’re building.

A lot of companies and organizations are migrating to the cloud now. Where does that come into the picture? How do you know if it’s the right move for a customer and how do you know if it’s successful?

It’s largely about maturity. There’s obviously a tech maturity and while you can just ‘lift and shift’ your existing architecture to a certain extent, it’s probably not the best way to migrate into the cloud. There’s a bit of redesigning of your current architecture that needs to take place if you’re moving from an on-premises system.

The other angle is the change management, the people side of things. The reality is that it’s very different operating an on-premises IT system compared to one that’s in the cloud. So there’s definitely a change management approach that lots of folks overlook and it’s something you need to factor into the migration. What are the new processes and governance activities you need to think about now that you’re in a cloud environment as opposed to on-premises, for example?

In terms of success, that’s measured by the number of end users who are actually using it, and the growth in those users. Those are always a good sign that things have gone well.

Lots of people are also talking about DevOps now, for both the application and the database. It sounds like the team you work in are pretty well versed in it, but what does it mean to you?

I’m a big fan of the definition of DevOps from Microsoft’s Donovan Brown. Not because he’s from Microsoft, but because a lot of people use it: DevOps is the union of people, process, and products to enable continuous delivery of value to our end users. I also lean towards the three ways in The DevOps Handbook, about enabling the fast flow of work from left to right and constant feedback from right to left, and creating a generative, trusting culture.

They’re both valuable because a lot of people think if they do CI/CD that’s DevOps and it’s a mistake. It’s about people and processes, fast workflows and feedback, and a different kind of culture.

Typically in teams which have a very strong DevOps culture, the hard lines between Architects and developers and testers and operations no longer exist or at least are very blurred. Sure, there might be someone who is the designated Architect, or sort of in charge of the CI/CD pipeline or someone is the database expert, but everyone is expected to know the process end-to-end. So typically you wouldn’t have a designated tester for example or designated ops team – everyone is accountable for the end result.

What kinds of volume of data are you dealing with and do you see your clients having a strategy to move from gigabytes to terabytes to petabytes?

Volume definitely plays a role in how we design systems and what challenges we face building them, but what folks kind of forget about is the variety and velocity side of things. Variety goes beyond the very clean world of relational data because sometimes you have to deal with JSON objects that might not be very high volume but are very complicated in their structure. I find that that’s a little bit more common than high volume engagements, because only very large companies will have datasets with hundreds of terabytes or petabytes. One of my last engagements was a very nested JSON structure which I had to make accessible in a format better suited to do ad-hoc reporting and analysis. And increasingly, we have to think about the velocity of data, which is all about streaming and making sure that the data comes in at regular intervals.

What I’ve seen in this series of interviews is that there are lots of ways for Software Engineers and DBAs to learn and develop in their role, but there’s not a lot out there for Architects. What would you advise people to do?

Don’t be the smartest person in the room. You might find yourself in a very comfortable position where you are that person and it’s no longer a challenge. You want to always try to be in a position where you have people you can learn from. I’m very fortunate to be in Microsoft where it’s a huge company and in the team I’m in there’s always someone who knows more than me in a specific area. It’s not a negative that you’re not the smartest person in the room, I think that’s actually a positive because you’re continually learning new things.

What’s the best way for people to get ahead when they’re first starting out as an Architect?

My advice is to not sit on your hands and wait for someone to go and find you, but to be very proactive in actually finding a mentor, a person who is going to help you in your career. Go to meetups, to tech meetings, and talk to people. 19 times out of 20, you’ll might not get a whole lot out of it, but you just need that one time you’ll meet someone who just changes the course of your career exponentially for the better. It happened to me and I’m very grateful for my mentor. For the rest of the times, these meetups might just be an incremental improvement but it’s still better than just sitting on your hands and waiting for things to happen.

Once you’ve found more senior architects you can learn from, proactively ask questions. Find out not just what technical architectures they’ve design, but more importantly how they designed it and why they made the specific technical design decisions that led to the final architecture. Understand the processes for eventually coming to these technical design decisions and what were the pitfalls they encountered. No one is going to be an expert at everything but having a personal methodology of getting to the right answer or at least something close is more realistic, and in my opinion, a more valuable skill to have.

Last question and probably the most telling. What do you think will be the next big thing in tech?

I don’t see massive changes in the short term but I do see a significant trend in applying DevOps principles to other areas. Data is one of those things where it’s very difficult to apply DevOps around automated deployments because data has state. It’s therefore a little more difficult to apply things that you would normally do with application layer code for example.

Beyond that, DataOps and MLOps are coming into play, where we’re looking at the way data is used in areas like IoT and artificial intelligence and thinking of how we can apply DevOps to it. There are a lot of areas where DevOps principles can be applied in a more specialized manner as opposed to a more general sense.

Cool. That was all I had, Lace. Thank you so much for making the time for me today.

Look out for other episodes in this series, featuring Michaela Murray interviewing:

• Darren Dawson, Pre-Sales Architect at WARDY IT Solutions
• Chris Slee, Solution Architect at C5 / Bank of Queensland
• Kris Bock, Machine Learning / Data Science Architect at Microsoft

This series of interviews concluded with an online panel discussion hosted by Michaela, during which all of the Architects discussed what the future holds for IT Architects when there’s no blueprint. The recording of the lively and informative debate is now available to watch on-demand.