What Is The Most Important Part of Architecture?

A bald man in a suit smiles for the camera.

Cloud Computing Evolves: An Interview with Mats Johansson

By G C Network | June 6, 2019

Recently, Ericsson Digital released an amazing report on Edge Computing and 5G. In it, they explained how distributed cloud computing is paving the way for the future of network communications. They…

Rexroth unveils rexroth rexroth rexroth rexroth rex.

The IoT Nexus: Bosch Connected World 2019 in Berlin

By G C Network | May 11, 2019

Next week, I will be influencing #LikeABosch as I accept an invitation from the company to attend Bosch ConnectedWorld 2019 (BCW19) in Berlin, Germany. This is one of the world’s largest international…

A group of people sitting at a conference table.

Survive and Thrive With Digital Transformation

By G C Network | April 17, 2019

First cloud computing then multi-cloud. How can we get ahead of this digital transformation nightmare? These are the laments heard in conference rooms and board meeting around the world. While…

A cartoon man standing next to a white tesla model 3.

The “George Jetson” of Today

By G C Network | April 13, 2019

  He grew up in Silicon Valley, landed his first job at Apple Computers, was introduced to Nobel Prize winners by his dad and today, he takes a self-driving car…

A city at night with the words 5g on it.

MWC19: Where Telecommunications and Cloud Meet

By G C Network | March 23, 2019

As a cloud solution architect, my passion is learning the details about how cloud computing uniquely supports specific business cases. This curiosity is what drove my excitement when Ericsson invited…

Tulane university school of professional advancement logo.

Tulane University SoPA Selects “Architechting Cloud Computing Solutions”

By G C Network | February 16, 2019

Last week, Packt Publishing announced that “Architecting Cloud Computing Solutions” by Kevin L. Jackson and Scott Goessling was selected for use by the Tulane University School of Professional Advancement, Applied Computing Systems & Technology Program as the textbook for…

A group of doctors looking at a computer screen.

5G Wireless Technology Connecting Healthcare

By G C Network | February 16, 2019

Healthcare is in the middle of massive change. Called digital transformation by many, this term describes the industry’s pursuit of the many promises offered by connected patients, connected caregivers, and…

A woman wearing a red jacket and necklace.

Maria Lensing: The Network Platform for Healthcare’s Future

By G C Network | February 16, 2019

As a girl, Maria and her family traveled to Memphis, Tennessee to get cancer treatment for her sick brother. The miracle she observed, as the healthcare providers saved her brother’s…

An image of a network of dots and lines.

How “Big Iron” Does “Big Regulation”

By G C Network | January 10, 2019

According to Verizon, there were over there were over 53,000 security incidents in 2017, with over 2,200 of those identified as confirm data breaches. A Ponemon Institute study also showed…

Two different signs that are side by side.

Mainframe Synergies for Digital Transformation

By G C Network | January 10, 2019

In July  of 2018, Broadcom announced its intentions to acquire CA Technologies. In the press release, Hock Tan, President and Chief Executive Officer of Broadcom, said: “This transaction represents an…

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.)

Posted in

G C Network