Being a solutions architect is fun. You get to design systems, talk to a bunch of different people, and offer guidance to other developers.

If you’ve recently made the move from developer to solutions architect, congratulations!! Welcome to the technical world of system design.

A misconception I see regularly with new SA’s is that they think their job is solely to come up with a way to solve a business problem. While that is fundamentally correct, there’s a whole lot more to it than that.

While a race car driver’s job is to drive a car around a track, their objective is to do it faster than everyone else. A solution architect’s job is to design systems, but their objective is to do it at the lowest possible cost.

What is Cost?

Cost is not just how much money you have to spend to do something. It’s a bit more involved. Simply put:

Cost = Time x Money

What does this mean to a solutions architect?

It means you should design a system in a way that requires as little money as possible to operate but you must also consider the time it takes to implement.

Your software company is a business, and the bottom line of any business is to make cost-effective decisions. As an SA, it is your job to design software in a way that is the most cost-effective for your company.

Contributing Factors to Cost Effectiveness

Now that we know cost is a combination of time and money, let’s talk about some ways we can design systems that keep it down.

Go Serverless

One of the least expensive ways to build a new system is building serverless. A serverless solution is a pay-for-what-you-use model that automatically scales with load. If users only are in your system from 9-5 Monday through Friday, you are only paying for resources during that time. You don’t pay for uptime at night or over the weekends.

You get billed for consumed resources like compute time and data transfer.

Think about your electricity bill. The cost varies every month based on how much you use. Serverless is the same way. Plus, there are some easy ways you can optimize a serverless API to make it even less expensive.

Time to Develop

When it comes to calculating cost, most SA’s don’t forget to include the time it takes to develop. This metric includes the total time of a development team from start to finish.

It includes time from a business analyst to determine requirements, developers to write the code, quality assurance to test it, and your time to come up with the design and plan. There are many moving pieces in development that take a simple “oh, that can be done in an hour” to taking 3 or 4 or more days.

When you’re designing a system, make sure you take development into consideration. Are you designing something that is technically difficult and from the ground up? Will you be taking advantage of systems that are already in place? How can you use what you have now to speed up the work and drive the cost down?

Are you using a cloud provider like AWS to host the application? Can you take advantage of a managed service like SNS to publish to webhooks to cut down on development?

As a solutions architect, your job is to not only design a system, but identify areas that can be reused to get your time to market faster.

Photo by Sigmund on Unsplash

Time to Configure

At my job, we commonly refer to configuration as the C word. Sometimes a necessary evil, configuration can make or break an application when it comes to cost.

If your application took 2 months to build but 5 months of a professional services engagement, you didn’t do a great job keeping that cost down. That’s 5 months of people from your company dedicated to setting up an application for a client.

Chances are when the next client comes on, there’s going to be another pro-serv effort that takes just as long. This will reoccur for every client, resulting in an ongoing cost for your app.

It is your job to design the system in a way that minimizes configuration time and maximizes reusability. In most cases, you could even hardcode your app until a feature request comes in.

Are there tools you can build that makes it easy to move configuration from one customer to another? Can you take advantage of what is already there?

Spend some time talking with an implementation specialist and see what makes their job easy or hard. Take that into consideration when you’re coming up with a new solution.

Time to Troubleshoot

It’s all fun and games until that first defect rolls in.

I remember the first time I tried to troubleshoot an issue with a choreographed business process. I was so confident I knew the ins and outs of the system. I knew how the data flowed and what all the pieces were that made it tick.

But when somebody asked me where their data was, I got that deer in the headlights look. I froze. I stumbled around the AWS console trying to find messages that may or may not have been sent.

I couldn’t do it. And I wrote the app!

How could I expect our technical support team or maintenance developers to figure it out? It was going to take significant training and upskilling for my maintenance team to figure out what to do.

That takes time. It drives up the cost.

Try to use industry standard tech and best practices. Design your system with supportability in mind. Can people find answers to what they are seeing on Stack Overflow? Are there logs that allow for easy traceability in the managed services you’re consuming? How easy is it to walk through the data flow in a business process? Can you hire somebody with the required skill set from outside the company?

Most importantly, keep it simple. A good architect makes a complex solution out of a complex problem. A great architect makes a simple solution out of a complex problem.

The easier it is build, often the easier it is to troubleshoot.

There will always be issues with a piece of software. Minimizing troubleshooting time will yield a tremendous ROI because the more users you bring on, the more issues they will find.

Photo by LumenSoft Technologies on Unsplash

Time to Support

Slightly different than troubleshooting, support is how easy your app is to use, navigate, and solve the business problem.

If you’ve ever hung out with a call center support specialist for a day, you’d realize clients call for every reason under the sun.

I can’t login.

Where did the little button go that brings me to my favorites?

It just doesn’t work. It worked yesterday, now it doesn’t.

This key to the cost isn’t as much architectural as it is centered around user experience. Some solution architects might think UX is not their responsibility. And in a way, they might be right.

But you can help drive the user experience by providing shortcuts, tools, and robust APIs that enable maximum flexibility. Design the app in a way that allows you to do CI/CD. Focus on small, incremental changes instead of big, jarring updates. That way you minimize disruptions to your end users.

Much like troubleshooting, support is an ongoing cost. If you’ve done your job as a solutions architect, you’ve built a flexible, intuitive system that minimizes calls and ultimately drives the cost to support down.

Conclusion

Software is a big game of checks and balances. Do you spend a little bit more time up front building out a piece of architecture to reduce ongoing costs like configuration or support? How much is too much?

Can you get away with hardcoding potentially configurable pieces of your application? Have you designed the app in a way allows for easy troubleshooting when it gets into the field?

Is it worth writing your own tooling to help configure, troubleshoot, or support the application? Do these tools already exist with a cloud vendor?

There are serious benefits to spending the time walking through different scenarios up front. You figure out where the time is going to be spent in your app. You can help reduce the configuration costs. You can provide easy ways to troubleshoot issues.

Building an application is not a fixed cost. It’s ongoing and is contributed by many factors. As a solutions architect, you are ultimately responsible for deciding where the majority of the cost comes from.

The butterfly effect suggests that something as small as a butterfly flapping its wings could cause enough disturbance to change the path of a tornado. Small things add up to make big changes.

Solutions architects are butterflies. The seemingly small decisions they make in system design have dramatic effects on overall cost to a software company.

Next time you’re building a system, think about the 5 components to cost: operation billing, time to develop, time to configure, time to troubleshoot, and time to support. What can you do to design in such a way that maximizes one-time costs and minimizes reoccurring costs?

If being a solutions architect were easy, everybody would do it. But it’s not. And you don’t care.

Just remember there’s much more to it than simply saying “this piece connects to that piece this way.”