Designing Software Architecture: Tips and Tricks for Success

The faces of a woman and a man looking at a computer screen.

I spoke with Jerry Clinesmith, software architect at Koen Health in Dallas, and he offered some insider tips on designing software architecture.

Find out how to become a software architect in part one of our interview.

Read on to find out about Jerry's favorite tools when designing system architecture, and what software methodologies he recommends:

When designing the architecture for a new system, what is your thought process?

Break large problems into smaller ones. It sounds simple, but I think this is one of the primary traits needed to architect anything. See the big picture, and then dive deeper. Start with the high-level responsibilities, and continue breaking things down until everything has its purpose. 

What tools do you use when designing the architecture for a new system?

I usually start with whiteboard sessions with the entire team and have product managers, QA, operations and developers throw in opinions. Work toward a high-level picture of the system that everyone can agree upon. Further design sessions happen with just the development team to work out details. Visio is great for UML, database diagrams, flowcharts, network topology, etc. You'll need different designs depending on the audience (i.e. operations will want machines, network diagrams, firewalls, etc.). Balsamiq is good for mockup UI's – they look as if they're drawn by hand – which is great to let everyone get an idea of how things will look. It's fast to create and simple to change, perfect for early designs. Working code works great as well! I usually work very closely to create the first pages, services, and tests for the application. These serve as a model for the team moving forward.

As an architect, which software methodology do you prefer?

Definitely Agile, but in its "pure form" that is light on processes. Focus on solving the user's problem – everything else is second. I like small iterations (one week) early in the project to make sure everyone stays on the same page, and then two-week iterations as things hit their stride. Agile accepts that change as part of building a system and embraces it. Automate as much as you can: developer environment setup, continuous integration and continuous delivery if you're ready for it. Writing the scripts to automate the process serves two purposes: working documentation and a process that is fast and repeatable. I'm not hardcore TDD, but I think testing is important. Having tests mean you can move quickly, stay flexible, refactor and change as needed. No one person needs to have the entire system in their head – the tests describe how it’s supposed to work and make sure that it does. Keep an eye on your test times – slow tests and complicated setups usually mean there are opportunities to improve parts of the code.

What do you enjoy the most about designing the architecture of a new system?

Solving problems! Giving the user something that improves what they have today, redesigning a slow system to be fast or breaking big, ugly code into well-factored systems.

What are your tips for the software development or design process? Share them in the comments.

Looking for a software architect job? Check out our current job listings and figure out the salary range for software architect jobs in your area:

Get the Salary Calculator



More Resources: