Michaela Murray

15 July 2020

The IT Architect Interviews #1: The Pre-Sales Architect

In this series of interviews, Redgate’s Michaela Murray talks to a range of IT Architects to find out what they do, what drives them, and the biggest challenges they face when planning IT transformation initiatives. In this episode, Michaela talks to Darren Dawson, Pre-Sales Architect for WARDY IT Solutions, an IT consultancy in Australia.

Darren, could you first tell us how you ended up in this role? Was being an Architect something you always wanted to do?

After being a Developer, a DBA, a Sysadmin, and having started Flight Centre’s move to the cloud, I sort of fell into the Architect role. As the senior tech resource, a lot of staff looked to me to help them with what they were working on. It meant I needed to broaden my skills because an Architect’s role is to draw boxes and arrows between different technologies, resources and solutions and make them work.

We’ve heard during conversations we’ve been having with Architects that people often mistake the role for a project management type position. How do you see the two differing and what does being an Architect mean to you?

An Architect liaises with business entities, business people and technical people to understand the business, technical, functional and non-functional requirements of what’s needed. The task is to then put together an overarching architecture by working out the pieces of the puzzle that build out the full solution. While Architects might not understand the deep detail of some of those technologies, they need to know what a particular technology is capable of.

Is it a challenge dealing with the business people on one side and the technical people on the other who are actually going to implement the solutions you come up with? Do you have conversations where you find yourself in the middle?

Yes, sometimes. I think some technical people have a great difficulty talking at a business level. When I talk to C-level people I actually have a different personality to when I’m sitting in a technical meeting and I speak basically two different languages. At the business level you talk about return on investment, while a technical person is looking at improving performance, for example.

How do you see the role evolving over the next five to ten years? What do you think will change as time goes on?

A lot of companies five years ago were looking for solutions that required them to code. I think there’s going to be a big shift to low-code or no-code solutions. We’re seeing that a lot with the cloud now, especially in the Azure space that I mainly work in. It’s very drag-and-drop and allows you to do a lot of orchestration with a minimal understanding of SSIS code.

In the past, if you wanted to move data from one place to another you’d need to write an awful lot of T-SQL packages or integration services, whereas that’s now handled by orchestration packages and you just link to them and grab the dataset and tell them where you want to put it.

Similarly, you don’t write a payment gateway from scratch any more. There are plenty of cloud providers that provide an API and you just wire your solution into their gateway, whereas previously companies wrote their own.

It sounds to me like that makes it easier, but what kind of challenges does it bring?

Previously an Architect would have written a specification, the internal developers would have developed it and it would have been tested. Now it’s a case of evaluating the different options out there to see which is the best fit, so Architects are doing a lot more Proof of Concepts of SaaS type products.

That makes sense. We often hear Architects described as the bridge between IT and the business. Is that how you see yourself?

With larger organizations not so much because they typically have internal business analysts who fill that sort of role, but definitely with smaller organizations. Their IT teams tend to be heavily technical so Architects are the bridge between them and the business that is looking for an outcome or a solution.

Do you have any tips for how to make the bridge better or easier?

I think the main one is understanding who you’re talking to when you’re in a meeting. I like to spend the first part of a meeting talking about what people have done before and where they’ve come from. I also research people on LinkedIn because it’s a beautiful resource for telling me what roles someone has done before. You have to talk to a CIO who has come up through the business side very, very differently compared to a CIO who has come up through the IT department.

For me, it’s also a little different because rather than being an Architect for one company, I work for a system integrator in the data platform space. So I talk to a lot of medium to large enterprises, to government, both state and federal in Australia and around the world. My role is to walk in, be briefed on a business problem and try and work out a solution with what can sometimes be little initial understanding of the rest of the business.

That’s why building a rapport is so important. A good start is try and get to know the people personally because as an Architect I’m going to be interacting with them for quite a while.

You mentioned working on a cloud project earlier. When is the right time to migrate to the cloud, how should a migration be approached, and what would you measure to know whether the migration was successful or not?

Small organizations usually find cloud transitions simpler and more cost-effective. For bigger organizations, we usually recommend they do it when they’re going through a hardware refresh or data center renewal to avoid throwing out a lot of expensive existing hardware. The second piece of advice for larger companies is to start small and just pick one service that can be easily moved and supported in the cloud. So it might be that they keep their OLTP services on-premises but build a modern data warehouse in the cloud.

So organizations should think about where they can get the most benefit?

Yes – the most expensive way to go to the cloud is just to pick up your virtual machines and migrate them. Other than saving a bit on overhead for your DBAs and your admins, there aren’t a lot of benefits. It’s also very important to look at re-architecting your applications for the cloud. If you’re going to try and do it the same way you’ve done it on-premises, you’re not going to see much benefit at all.

We do, though, see a lot of benefit of moving to a Platform as a Service (PaaS) solution, getting rid of your Infrastructure as a Service (IaaS) web servers and running InApp services with deployment slots. There are lots of advantage with continuous integration and continuous delivery pipeline deployments and all that sort of stuff if you’re developing websites.

On the data side, with the SQL PaaS services, they’ve got high availability and geo-redundancy built-in, which is a lot simpler than building out your own multisite Windows clusters and then running SQL Server availability groups on top. It’s a single, simple interface and a lot less moving parts for your DBAs and Sysadmins to look after.

And how do you measure success? What kind of things would you be looking at to see whether a cloud migration was successful?

From the business side they want the advantages of robust High Availability and Disaster Recovery services, and faster reporting, and then the big one is cost. Most CFOs and businesses need it to be cheaper than running on-premises.

You mentioned continuous integration and continuous delivery which brings DevOps into the picture. We hear a lot of talk around DevOps, but I think people have quite differing opinions on what doing DevOps means. I’d be interested to know what it means to you.

DevOps has still got a long way to go in its implementation and a lot of companies I see struggle with it. They try to bring in the whole of the CI/CD infrastructure in one go, rather than phasing it in, maybe starting with source controlling code and then looking at pushing deployments through different environments in the pipeline. A lot of companies also want to start with their key app when it’s better to pick a mid-level web app with a simple database at the backend. One with not too many moving parts while they’re trying to build and understand the process.

What’s the role of an Architect in adopting a DevOps methodology?

It’s about trying to build DevOps in from the start for every cloud migration. So when we build Azure Data Factory pipelines we take a DevOps approach, when we build the infrastructure, we do infrastructure as code and that’s stored using DevOps processes. And when we build the database schema, that’s included in the DevOps process as well. For the Architect, it’s about making sure that the platform is there and instilling an infrastructure as code mentality right from the start.

You work with lots of different customers. Have you seen a growth in the volume of data they handle?

Yes, quite a lot now. Storing terabytes of data is not uncommon, especially in modern data warehouses.

When it comes to recommending solutions to companies, do you have a preference for a custom or off-the-shelf approach? How do you decide?

If a client has a development team that has the capability and availability, then sometimes a hand-coded solution is the right way to go. But I think in this day and age with so many cloud services and SaaS products available, code is really just integrating different pieces of off-the-shelf solutions together. There might be a little piece that you need to hand code but most services have an API you can tap into and it’s just about integrating between different services. You’d have to have a really specialized use case to want to be coding from scratch.

What drives your decisions? Is it business outcomes or technical solutions or possibly something else?

At the end of the day it’s the business that should be driving it, not just because there’s some new fancy piece of leading-edge technology. It’s more about what’s the right solution for the business outcome and the business constraints. So it’s all about their requirements, their constraints that I look to.

How do you stay aware and up-to-date of new tools and technologies? What forums or blogs sites or events do you go to or tune into?

A lot of what I do is more data focused, so I’m part of the Queensland SQL Server User Group and I try to get to SQL PASS every couple of years. On the Azure cloud side, I subscribe to all of the Azure newsletters that are coming out, along with others from heavyweights in the industry like the newsletters from Brent Ozar and the Redgate Update.

What about sources of information aimed at Architects?

That’s where there’s a lack of resources. It’s more drilling into individual services and getting an understanding of them and then working out how to join them together. Microsoft has got some information on its Azure reference architecture site and that’s probably the starting point for a lot of my architecture pieces when we’re developing for Azure. AWS has the same kind of resource site for its architectures.

In terms of your day-to-day work, what are the highs and the lows?

The high is clients understanding a solution when I present it to them and being excited about how it resolves their business issue or adds functionality they didn’t have before. The low is when clients just don’t get it, or when I’ve come up with a beautiful solution and their consultants can’t implement it properly.

What’s your top tip for someone starting as an Architect today

Engage with business stakeholders. The most critical thing that most technical based Architects miss out on is that the business says ‘This is my problem’ and they immediately start drawing the solution on a whiteboard, making lots of assumptions rather than asking more questions. I don’t want to see four bullet points and four pages of assumptions – I want to see four pages of requirements. If you’re putting assumptions in, you’ve probably not asked enough questions.

That’s good advice, I like that. Final question. In your opinion what’s the next big thing? What are you most excited about?

It’s got to be AI and machine learning. We’ve been storing massive amounts of data in the last five years and we’ve had no idea what to do with it until now. If you didn’t understand R and some pretty complex maths equations, you had no way to mine the data. Machine learning is getting to a point where someone with the business domain knowledge can start to extract a lot of detail out of their data, without necessarily knowing how to code in R or Python. That’s a pretty exciting future.

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

• Chris Slee, Solution Architect at C5 / Bank of Queensland
• Kris Bock, Machine Learning / Data Science Architect at Microsoft
• Lace Lofranco, Senior Software Development Engineer & 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.