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.)( Thank you. If you enjoyed this article, get free updates by email or RSS - © Copyright Kevin L. Jackson 2016-2018)