Identifying Requirements and Asking Questions like a Data Scientist – For Solutions and Cloud Architect

A key role of any successful architect (Network, Cloud, Data, Application etc.) is the ability to detect the various drivers, goals and needs.

In order to identify or detect the actual needs or drivers, typically, a set of questions need to be asked. However, it is common that the most challenging part is not about obtaining the right answer, instead, it’s more about asking the right question. In data science this might be referred to as ‘interesting question’ (a question that can lead to have more insight about the data or subject).

Ideally, to be able to ask ‘interesting questions’, as an architect, you need to have a good understanding and practice of ‘critical thinking’. With critical thinking the focus must never be around being aggressive or criticizing facts or information. Instead, is it all about finding the critical questions, that ultimately will help you shake out the bad assumptions and inaccurate conclusions. One of the main data scientist mindset or approaches is to be be able to “Identify cause vs. symptom and the associated consequences”

 In problem solving situations, a solution architect might rush to get to an answer as fast as possible, to be responsive to stakeholders. This is commonly, derived by the desire to help in such situations. The question here, Have, you ever provided a recommendation and then led to create new problem(s) down the track, or ended up to create a new challenge to help with?

Let’s consider this simple example, a financial services organization, was going to introduce a private cloud orchestration system to provide ITaaS for the different internal departments. However, the project team kept missing the deadlines for the solution launch to be in production environment. Taking this sample scenario in consideration let’s try to identity causes vs. consequences.

Q-1) What was the main reason making the project team to miss their deadlines of going live?

A-1) There was a delay in completing the automation code.

Is this a cause or symptom?  In fact, it’s a symptom, so we should not put our efforts at this stage on this point, instead we need to find out what led to this delay (as long as there is a symptom, there must be a problem)

Q-2) Why the automation code delayed?

A-2) We had to change some of the specifications to comply with the company security standards.

Again, here we have another symptom, this is not the root cause!

Q-3) Why this was not included from the beginning?

A-3) Because the standards of the expected features and functionality of the new ITaaS operational model was not finalized.

Again .. We have another symptom here,

Q-4) So why this last symptom was happening?

A-4) Because, from the management and IT executives, there was no clear agreement or direction about how this new model should be operated, in turn, this impacted some of the expected features and functionalities of the new ITaaS operational model.

After going through this root cause identification analysis, it is obvious now, it’s not the developers issue and the actual cause is not even related to any technical aspect.

Let’s take this process a step further, and assume that you as the solutions or cloud architect of this project provided recommendation here about the operational model to be centralized in which each entity or department needs a new private cloud service to consume has to go through the central entity to request it.

What are the consequences of this decision or recommendations?

Typically, this recommendation cloud lead to a longer time to market, as each entity need to request any service and go through a central approval and assurance process, whether it’s for development, testing or production. As a consequence, it may reduce customers’ satisfaction, speed to introduce new services, etc.

This was just hypothetical example, the key point here is that, by taking a step back before you answer or ask any question and think critically about actual causes along with the potential consequences of any recommendation you want to make, you’re going to detect the actual problem(s) that should be optimized or resolved and, ultimately, you’ll have better visibility and awareness to avoid creating new unforeseen problems.

In brief,  a top-down approach should be considered when trying to identify a problem or an actual root cause, while, a bottom-up approach should be used when you are trying to anticipate the consequences.

Categories :
Marwan Al-shawi – CCDE No. 20130066, Google Cloud Certified Architect, AWS Certified Solutions Architect, Cisco Press author (author of the Top Cisco Certifications’ Design Books “CCDE Study Guide and the upcoming CCDP Arch 4th Edition”). He is Experienced Technical Architect. Marwan has been in the networking industry for more than 12 years and has been involved in architecting, designing, and implementing various large-scale networks, some of which are global service provider-grade networks. Marwan holds a Master of Science degree in internetworking from the University of Technology, Sydney. Marwan enjoys helping and assessing others, Therefore, he was selected as a Cisco Designated VIP by the Cisco Support Community (CSC) (official Cisco Systems forums) in 2012, and by the Solutions and Architectures subcommunity in 2014. In addition, Marwan was selected as a member of the Cisco Champions program in 2015 and 2016.