IT Architecture Design 101: Information Gathering Best Practices

At some point or another, all IT organizations will go through a process where they must determine how to get from ‘Point A’ to ‘Point B’.  This journey could come in the form something large in scope, such as an IT organizational transformation, or something limited in scope, such as virtualization refresh.

Regardless of scope and complexity, company size or industry, certain fundamentals of design will always apply.  Today, we’ll take a look at information gathering, and how to make sense of it all.  So let’s start with a level-set.

Every project starts with information gathering.  As such, information gathering should not be limited to those employees of an IT department, but rather from all aspects of the business where a project would have some impact.  Those responsible for supplying this relevant information are referred to as Key Stakeholders.  All information, provided by all key stakeholders, are logged as artifacts.  An artifact is neither positive or negative, correct or incorrect; but rather a truth that will ultimately be classified as either current state ‘Point A’, or desired state ‘Point B’.

There are four classifications for artifacts:

  • Business Requirements
  • Constraints
  • Assumptions
  • Risks

Business requirements, are broken down and classified, into two sub-sections:

  • Functional Requirements
  • Non-functional Requirements

A functional requirement describes what a solution, or service, must do.

For example, let’s say you were interviewing the Security Manager, who was identified when the project began, as a key stakeholder.  The Security Manager provided the following artifacts for the datacenter refresh project:

  1. BR001: The selected architecture must support users in both the primary and secondary datacenters.
  2. BR002: Security administrators must be able to monitor traffic on the network in both the primary and secondary datacenters.
  3. BR003: The monitoring system must limit access to authorized users only.

As you can see, from the three artifacts above, they describe the architecture needed to fulfill those functions.  So, the functional requirements become the Business Requirements of a design.

A non-functional requirement describes the ‘quality’ of a solution, or service.  These non-functional requirements are broken down into five two sub-sections:

  • Availability
  • Manageability
  • Performance
  • Recoverability
  • Security

So let’s say you were interviewing that same Security Manager.  Later on in the meeting, that Security Manager provided three additional artifacts for the datacenter refresh project:

  1. C001: The selected architecture that support the users in both the primary and secondary datacenters must be active/active to support all users, should any one datacenter go offline.
  2. C002: The traffic monitoring solution our Security administrators will use must be backed up each night, and be restored within four hours, should a system failure occur.
  3. C003: The monitoring system must limit access to authorized users only, ensuring that we continue to meet all PCI-DSS governance and compliance regulations.

As you can see, from the three artifacts above, they describe the quality necessary of the business requirements.  Put another way:

  • In statement one, we have an Availability constraint.
  • In statement two, we have a Recoverability constraint.
  • In statement three, we have a Security constraint.

While it may seem as if those three statements are also requirements, open-design architecture standards tell us to classify these as the Constraints of a design.

An assumption is an artifact that describes a state, an event, or a situation that has not been validated; as such, has a low probability of causing a decrease in business value, or preventing the ability to fulfill a business requirement defined by key stakeholders.  An assumption can be made, due to a timing conflict for example, but must be proved prior to the start of a project.  Here are a few noteworthy points:

  • Assumptions are commonly described as “Artifacts that are accepted as truth or certainty, without real-time proof.”
  • When an assumption is proven to be true, it could be removed entirely and/or noted as a fact in the project notes or appendices.
  • If an assumption is proven to be false, it is reclassified as a risk.

Let’s go back to our Security Manager.  Just before the meeting ends, that Security Manager provided one more artifact for the datacenter refresh project:

  1. A001: In several internal discussions with my peers, regarding this project, the Network Manager mentioned several times the other leaders that the WAN connectivity between the primary and secondary datacenters would be more than sufficient for this project.

Four things could be taken away from the one artifact listed above.  They are:

  • This statement, while it may be a truth, is hearsay and unproven.
  • Verify the Network Manager is listed as a key stakeholder to interview.
  • If the Network Manager was already interviewed, verify this artifact has already listed as an assumption.
  • Verify with the Network Manager, as to when the WAN connectivity validation, will be made available to the project team.

A Risk is an artifact that describes a state, an event, or a situation with a high probability of causing a decrease in business value, or preventing the ability to fulfill a business requirement defined by key stakeholders.  The three most common risks to a project are:

  • Lack of tangible business value.
  • Financial requirements, in direct conflict, with functional and/or non-functional requirements.
  • Fear of change.

Let’s swing back to our datacenter refresh project.  Your interviewing the Finance Director responsible for the project funding.  During the meeting, the Finance Director provides the following artifact:

  1. R001: The financial budget has been defined for the project. The business was satisfied with the valueadd and ROI, and has approved the project funds.  The financial investment for the datacenter refresh will be spread over a three-year period.  The business has turned over year-one funds to the IT Director to procure the necessary hardware, software, and contracts needed.

That’s sounds pretty good!  Then why is a Risk?  Well, there are three reasons for this:

  • Although the financial budget, that was submitted for the datacenter refresh project was approved, the funds are not yet available for year-two.
  • Although the financial budget, that was submitted for the datacenter refresh project was approved, the funds are not yet available for year-three.
  • Should the financial position, or posture of the business, change between year-one and year-two and/or change between year-two and year-three; the funds are not yet secured to spend. Thus, the project is at risk, until year-three funds are turned over to the IT Director to procure the remaining hardware, software, and contracts required for project completion.

So, if we were to wrap this up and tie it off with a bow… artifacts can come from any part of an organization.  They can be tangible or intangible.  An artifact is neither positive or negative.  They can be a truth, or a perceived truth.  They can be a requirement, a constraint, an assumption, or a risk.  Regardless of where they land in a given project, they are the backbone for success or failure.

 

Happy designing!

 

Jason Nizich, VCIX-DCV | vExpert, is a Principal Architect at Data Strategy.