Tips for Architecting Successful Solutions & Systems, Part 1: The Base Principles

So, you want to be a software architect? It’s a lofty goal, but a very marketable set of skills. In this multi-part series, I will provide background and guidance based on my experience architecting software solutions for the past 20 years. This series will cover a range of mostly technical topics, and will include numerous tips as well as my secrets to success.

While this series will have a slant towards SharePoint, it is not specific to SharePoint or Microsoft’s platform. These principles, tips, and secrets will also be applicable when architecting systems using any software technology.

Base Principles

As we get started, I would be negligent if I didn’t cover some well-tread but necessary ground work first. In this section, I will discuss a number of base principles – or what I like to call “immutable truths” – to architecting. Let’s start with the first:

You cannot properly design without knowing what the customers’ or market needs are.

Am I stating the obvious? Perhaps so, but I still see this as a fundamental mistake even with seasoned veterans. Aside from the obvious needs analysis or business outcomes that will be gathered (these are often labeled functional requirements), here are a few other questions you also need to also ask before you get serious about designing the system:

[RegUserOnly]

• How many users will use the system?
• What are the performance expectations?
• What are the security requirements?
• How long is the system expected to last?
• What are the uptime and recovery objectives?

Some people like to call these non-functional requirements. This is not a complete list of questions, but enough to give you an idea. Keep in mind that you probably won’t be able to get answers to all of these. Getting good non-functional requirements is a challenge, which is why many analysts forget or don’t bother to ask. However, even when you can’t get an answer, you should still be thinking about these requirements. In the case where you can’t get an answer (“I asked, but no one knows”), you need to make up an answer. Seriously. Of course, we don’t actually say “make up an answer”, but rather state these in a form of an assumption.

Assumptions

For example, let’s say you can’t get a clear answer to what the performance expectations are. Maybe the sponsor or stakeholder just says, “It must be fast.” Fast is a relative term, I’m sure we all agree. To properly architect a system, you should have something specific mind, such as the average response time or other metrics that are based on the type of system or app that will be created. Or, maybe you don’t get an answer at all. Or, the customer may say, “You’re the expert. Shouldn’t you be telling me how fast it should be?” 

If this happens, come up with a set of assumptions that represents your expert opinion. If you are designing a web-based system, you might state something like: “The system response time must be 2.0 seconds or faster 95% of the time.” This is much better because you now have a hard requirement that you have documented. This becomes the target that you aim for when designing the system. Since it has been stated as an assumption that has been documented, if this target changes, you have some recourse to manage the change. The bottom line is the success of your design will depend on whether it meets these both functional and non-functional requirements. Make sure you have answers or assumptions to these.

Trade-Off Considerations

There are trade-off considerations in each design choice you make.

Trade-off considerations are a part of life. You’re used to them. For example, “Do I get up at 6 a.m. to go to the gym?” There are pros and cons to whether you do or don’t, including short- and long-term implications. In your mind, you are weighing these to see where the scale tips for that moment in time.

The same is true in system design. “Should we write this functionality from scratch or use a third-party component? Should I cache this large object in RAM or fetch it from the database each time?” As before, there are trade-off considerations with these as well. I bring this up because there aren’t that many obvious answers when confronted with the design choices we need to make. This is what makes architecting a system a challenge. It’s also where experience goes a long way. Think of it this way: An architect is like a judge – one who considers all the evidence before making a fair and balanced decision.

Return on Investment

And don’t forget perhaps the most important but often overlooked trade-off: return on investment (ROI). Demystifying ROI from an economics or accounting perspective can be a real challenge, but’s let’s only focus on the most fundamental for our purposes. Also, I’m not talking about ROI from the overall system perspective (even though that’s important and does matter), but in the context here, I’m talking about the ROI for these individual trade-off considerations.

For example, say you need to consider the disaster recovery (DR) implications of the system. Building in a DR failover and failback mechanism to a secondary data center with near zero data loss is daunting and expensive. If you’re asked to do this, do your best to try and justify its value. Another is, “Do you go with enterprise licensing or standard licensing for your database server?” You may need to work with your CFO or other accounting resources for some help here, especially if you need to quantify soft ROI. For example, if we invest additional time to make our user interface responsive to mobile devices, the user adoption will increase.

What’s Next?

Once you’ve covered the basic principles and established expectations with the business, the next step toward architecting your system is understanding cloud considerations. As you’ll learn in our next article, the cloud changes most of the rules and can be both a disruptor as well as a welcome improvement to how we architect software solutions. Join me here on the AvePoint Community for the next installment in the series, where we will cover cloud considerations.

To learn more about how AvePoint can help you meet your specific business requirements with custom solutions, visit our website today.[/RegUserOnly]