What Is The Most Important Part of Architecture?

I always find it interesting to hear what people view architecture as. A lot of people think it’s just about the design aspect, where you get to put pen to paper and create a solution. Even more people think that it’s just about putting together different technical components in a server room. And these people have interesting opinions on the importance of those activities to architecture. But, at the end of the day, the MOST important part of architecture is one thing and one thing only: requirements.

Requirements

Without requirements, you have no idea if you are actually designing a solution that matters. Without requirements, you have no way of knowing if those technical components that you are including on the server rack will actually be used. In short, you are only spending money without knowing if it’s worthwhile.

We all know of solutions that have been put into place and yet no one uses them. Why is that? Well, one very simple reason – no one bothered to check with the stakeholders what exactly they wanted. What’s the point of spending money on all those components if no one is going to use what you put together? That’s why you gather requirements so that you don’t waste money and actually have a usable solution. Not a solution that works but one that is actually used.

When you gather requirements, you don’t just sit down at a desk and dream up what you think the solution should meet. That’s just navel gazing and it’s no better than designing or building without requirements. Requirement gathering is all about talking to stakeholders to understand what they want and need. You gather those requirements and only then do you start looking for a design approach.

Now, when you say stakeholders, what do you mean? Well, remember that stakeholders include everyone that has a stake in how a solution works. So, it’s not just the end users that are interfacing with the solution or just the business owner who is providing the money. It’s also the operations folks that are supporting the solution. Remember, if the operations team can’t properly support a solution or would need to spend extra money to support it, then you have a more expensive solution than you may have wanted in the first place. So make sure you talk to the operations people about what they need in a solution as well.

Now, you’ve identified the stakeholders that you want to talk to and you are now scheduling meetings to gather those requirements. How do you do that? I would highly recommend that you don’t talk to them all in one room at the same time. There is always the proverbial ‘wallflower’ that sits in the back and doesn’t say anything but who will have a very valid point about a requirement. You will have domineering personalities that will want to be the focus of the meeting. And there will be people that lose focus during the meeting and do other things.

Instead, schedule one-on-one sessions with every stakeholder. A good requirement gathering session will average to 45 minutes per person, so schedule an hour for each person. Trust me; it may seem like you are spending a lot of time on this but it will save you a lot of money over the longer term if you do things correctly from the start.

Now, you’ve scheduled your session with your stakeholders. How do you conduct the meeting? Well, first off, treat it like you would an audit. You don’t go in with preconceived ideas of what the solution is. What you do is ask your stakeholder very broad, open-ended questions and let them talk. Don’t show any indication on how you feel about a particular requirement that they bring up, just note it down. I would highly recommend that you have a spreadsheet for all the different requirements areas (for example, availability, security, maintenance, usability, etc.) so that you don’t forget to ask about them. And then just let the stakeholder talk and go in whatever direction they want to go in.

Once you’ve interviewed all the stakeholders, consolidate all the requirements and replay them back to the stakeholders as a whole. This is the time that you’ll want to have all the stakeholders in one room. You want them to see what the requirements are and agree to them before moving on. And you are bound to have conflicting requirements that will need to be hashed out between the stakeholders and reach mutual agreement.

Once the stakeholders have agreed to the requirements, you can now start going down the road of designing and building your solution. But ALWAYS refer back to the requirements at every phase. Don’t just gather the requirements and forget about them. Those requirements drive the success of the project, and the closer your end solution is to those requirements the more successful and used the project will be.

Oh, one more thing. There are always requirements that come up AFTER the gathering phase. If that happens, two things have to be kept in mind. First, it means that you didn’t do a good job at collecting the requirements in the first place and you need to figure out a way of improving your requirement gathering process. Second, accepting new requirements at this stage means going back and changing designs or builds, which costs time and money. Often, it’s better to just leave the new requirement for the next phase of the project rather than going back and reworking your design.

Requirements are the flesh and blood of a good solution, regardless of whether you are talking about security, infrastructure, application, or a network solution. And if you do it properly, your requirements can help make you a very successful architect moving forward.

If you found this article interesting and want to learn more about architecture and cybersecurity, you can explore Hands-On Cybersecurity for Architects. The book follows a clear, concise, and straightforward approach to explain the underlying concepts and enable you to develop, manage and securely architect solutions for your infrastructure.  

( This sponsored post is part of a series designed to highlight recently published Packt books about leading technologies and software applications. The opinions expressed are solely those of the author and do not represent the views of GovCloud Network, GovCloud Network Partners.)