fbpx Skip to content

What Is The Most Important Part of Architecture?

Transformation Network

By pwsadmin | May 15, 2021

The Achilles heel of every transformative business model is their reliance on ever increasing amounts of data that need to be transported quickly across wide area networks and processed at edge computing end points. To meet this expected demand, the global telecommunications industry is rapidly moving toward a future in which networks must have the…

Essential Characteristics of Cloud Computing as Digital Transformation

By pwsadmin | May 15, 2021

Hybrid IT blends traditional datacenters, managed service providers, and cloud service providers to deliver the necessary mix of information technology services. This IT consumption model enables a composable infrastructure which describes a framework whose physical compute, storage, and network fabric resources are treated as services. Resources are logically pooled so that administrators no longer need…

Transformation Innovation

By pwsadmin | May 15, 2021

4 Factors Driving Digital Transformation ROI The critical assessment factors for cloud ROI risk probability are the following:      Infrastructure utilization Speed of migration to cloud Ability to scale business/mission processes Quality delivered by the new cloud-based process  These four factors directly drive digital transformation ROI because they affect revenue, cost, and the time required to…

Transformation Frameworks

By pwsadmin | May 15, 2021

Digital transformation necessitates changes in an organization’s operational processes. According to Harvard, a focus on operations can lead to business process optimization and entirely new revenue streams. Three common routes for this are the following:      Robotic process automation (RPA) which uses artificial intelligence to automate routine activities      Remote worker enablement that uses workspace virtualization and…

Transformation Infrastructure

By pwsadmin | September 26, 2020

Hybrid IT enables a composable infrastructure which describes a framework whose physical compute, storage, and network fabric resources are treated as services. Resources are logically pooled so that administrators need to physically configure hardware to support a specific software application, which describes the function of a composable architecture. This type of transformative infrastructure is foundational…

Essential Characteristics of Cloud Computing as Digital Transformation

By pwsadmin | September 25, 2020

A survey of 2,000 executives conducted by Cognizant in 2016 identified the top five ways digital transformations generate value:      Accelerating speed to market      Strengthening competitive positioning      Boosting revenue growth      Raising employee productivity      Expanding the ability to acquire, engage, and retain customers   Digital transformation is also a cultural change. Cloud Computing as Digital Transformation Since cloud…

Embrace Transformation

By pwsadmin | September 22, 2020

From a business perspective, differentiating business processes and quality customer service are central to overall success. Business leaders must therefore clearly identify and measure how information technology contributes to the value of every key business process. They must also know how to most cost effectively use IT when the task is merely the management of…

Computer Vision Advances Zero-Defect Manufacturing

By pwsadmin | July 25, 2020

by Kevin L. Jackson Electronics manufacturers operate in a challenging environment. It’s hard enough to keep up with the ever-accelerating rate of change in the industry. Now customers want increasingly specialized product variations in less time and of higher quality. Meeting this demand for increased product variation can seriously impact the bottom line. Such variability increases…

Real-Time Analytics Power the Roadway of the Future

By pwsadmin | July 25, 2020

By Kevin L. Jackson The complexities of citywide traffic are pushing the limits of existing transportation management systems. Outdated infrastructure is based on proprietary, single-purpose subsystems, making it costly to acquire, operate, and maintain. And current roadways are simply not prepared for the future of autonomous vehicles. Enter the SPaT Challenge, an initiative encouraging cities and…

Thriving on the Edge: Developing CSP Edge Computing Strategy

By pwsadmin | March 6, 2020

Communications Service Providers (CSPs) are facing significant business model challenges. Referred to generally as edge computing, the possibilities introduced by the blending of 5G networks and distributed cloud computing technologies are redefining how CSPs operate, partner, and drive revenue. A new Ericsson Digital whitepaper entitled, “Edge computing and deployment strategies for communication service providers,” addresses these challenges…

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

Leave a Comment





Crate

Purchase Crate

Shipping and discount codes are added at checkout.

Checkout
Scroll To Top