Approaching Zero Downtime with A Robust Software Architecture

Nothing feels quite like the frustration of your essential program breaking at (usually) a critical time. While failure is just part of the deal with any software, you can find programs with far fewer problems — those designed by architects. As a result the role of software architecture is helping you achieve that necessary zero downtime architecture

What is Software Architecture & Its Importance?

Architecture in buildings combines the necessary part of holding up a building with aesthetics. In software, architecture is the high-level structures within the system. Software architecture refers to creating and documenting these structures. In other words, it’s how a program is organized and behaves. This involves functionality, usability, and yes, even aesthetic concerns.

When building a skyscraper, an architect will take into account the soil. If she does not, the entire project is at risk. Likewise, a software architect must consider key situations, design for common problems, and ponder the long-term consequences of each decision. Just as a poorly designed building will soon fall over or crack, the poorly planned software can be buggy, unstable, may not support requirements, and may be difficult to manage.

Of course, any project has tradeoffs between the ideal and what is feasible in the amount of time and budget provided. Part of software architecture is deciding what tradeoffs are manageable. Architects must also balance what management wants and what users can do. So an architect will consider:

• How the application is to be used and managed
• The requirements, including security, configuration, and performance
• How users will interact with the application
• How it will be maintained over time as programs around it update and change

But more than all this, a software architect has the power to consider what might go wrong with a program, which can affect your business.

Common Points of Failure

Failure is part of programs. Depending on the type of application you are building, you may have a list of standard failure points to consider. However, some aspects of failure are frequent across programs, including:

• Hardware
• ISP
• Database servers
• DNS servers
• File servers
• APIs
• Other third-party services

Your development team should have a process in place to identify failures and follow up.

Keep in mind that people are an often overlooked point of failure. This is not meant to blame anyone; if only one person has the keys to the castle, you’ve created a point of failure if something happens to him or her.

The Role of the Software Architect in Zero Downtime

If architecture is so important, aren’t all programs designed by one? Unfortunately, no. Like any project, physical or virtual, those paying the bills might decide to cut corners in one way or another. In software, the role of architect might get the ax. Often people assume developers don’t necessarily need to start with an overall plan; they just write code.

But as people in our business sometimes say, “If building engineers built buildings with the same care as software engineers build systems, the first woodpecker to come along would be the end of civilization as we know it.”

When hiring a software development team, talk to them about whether an architect is involved. One architect explains that primary role of software architects should be to take part in the development and actually write some code, but most software developers are not architects. “Every software team needs at least one person who is able to take a holistic view of the software being built, create a vision for the team to work with and ensure that any high priority risks are identified and mitigated.”

Yes, you’ll pay more, but an architect will create a better, longer-lasting program. He or she will:

• Create and test models to identify risks.
• Use models to communicate the design to your team and confirm it will work for all stakeholders.
• Design a program flexible enough to adapt over time.
• Identify and track engineering as it occurs, watching for mistakes or issues that might pose problems later.

If you feel like your development team missed a step or two, talk to us about creating a program with a holistic view or click here to know about our lean development process.