IT reference framework

IT Reference
Framework
Encouraging smarter discussions and connecting the dots !
By Richard Diver

Richard Diver
• Solution Architect for security, cloud and
infrastructure technologies
• 20 years experience across industries and
geographies
• A visual communicator, thinker, innovator

Introduction • There is a need for common language and reference
points when discussing technology and building
solutions
• We have to view a solution from end to end, with
consideration of how each component connects to the
next
• The proposed framework needs to be repeatable,
extendable, and easy to understand
• It also needs to be visually appealing; the use of icons
helps with visual recognition, and less wording
• The framework also needs to have some key principles
to follow when using it to create a solution specific set of
diagrams

Remember the OSI Layers?
• Simple and clear
• Common language
• Visual reference
https://en.wikipedia.org/wiki/OSI_model

Key Principle 1:
The two most important elements in every solution that
we need to control are:
1. Identity: the end user trying to gain access to the
system, the administrators building and
maintaining it, and the security contexts that run
the backend processes
2. Information: from raw data to highly sensitive
information. Storing, analysing, and displaying
accurate data in a timely fashion
Everything else in a system should be designed to
helping the user get to the information, and keeping the
data secure from unauthorised access and distribution

Building a framework
• There are many ways of explaining how
solutions work, and even more ways of
drawing the solution in a basic or complex
diagram.
• Because every solution contains common
parts, a framework needs a standardised way
of displaying solutions specific components,
and how they integrate with other
components.
• Using a number reference allows for ease of
reference when explaining the solution in
written text.
• The framework also needs to work for both
cloud solutions, as well as existing on-premises
solutions.
• This diagram shows the first stage of the
framework - defining the component layers:

Highlighting Options
• This model uses a greyscale theme to allow a
simple view without distraction of colour themes.
This can be tailored to meet the needs of the
designer.
• One option is to grey out the items that are not
applicable. You can also add colour to the icons,
or the wording, for those items you want to
specifically show.
• See the next slides for examples, the solution
highlights the following scenario components:
• A corporate user on their Windows 10 Laptop
connected using Public WiFi
• The user is browsing to their OneDrive for
Business files, using IE 11
• OneDrive for business is built upon SharePoint
Online, which is part of Office 365, hosted on
Microsoft Azure in Australia

Collapsed View
• Once the first stage is used to explain the
possible options, and highlighting the chosen
scenario, the next step is to use this
information to present more details to the
solution.
• Firstly we need to make more room on the
screen…

Detail Blades
• This view can also be used with a default set
of icons to represent the layers without
specifically choosing any options.
• With the navigation collapsed, we can show
the details. These examples are based on my
experience with Office 365 and Microsoft
Azure.

Key Principle 2:
To encourage adoption and ease of use, a framework
must be consistent but also customisable:
1. Layout: Be creative with content, there are specific
elements that should remain the same, such as:
- Naming conventions
- Numbered layers
- Navigation and transition
2. Branding: the creator of the solution design should
be able to apply their own branding and colour
schemes to enhance the appearance and be
identifiable to the creator/owner

Solution Blades
Another view that would work well is to use the same method as the Azure Ibiza portal: Blades to open up
and explain solution components in more detail, using navigation down the left hand side for the layers, and
along the top for the various phases of deployment or approach to an issue:
• Example 1: Information Security: Identify, Protect, Detect, Respond, Recover. Use these headers to explore
and explain the approach across all layers to ensure thorough analysis, design, and implementation.
The next examples focus on specific layers to show how the components interact to build a whole solution:
• Example 2: Infrastructure as a Service (IaaS): show specific focus on a specific layer such as 9: Platform.
Explaining components available like storage, compute, virtual networks, and Azure Active Directory (AAD)
• Example 3: Office 365: show the various platforms and products that are used to deliver vast array of
productivity solutions

Key Principle 3:
A common language is required to enable quick
recognition and fair comparisons:
1. Vendors: there are numerous ways to present the
same information – get their solution to match
your understanding and environment specifics
2. Experts: Industry and solution experts should
create and publish their work based on templates
to make the work repeatable, standardised, and
share the approach and learning with others

Richard Diver
www.rdiver365.com
@rdiver

IT reference framework

More Related Content

Similar to IT reference framework (20)

Recently uploaded (20)

IT reference framework