6.1 Architecture Documentation Part 1

00:00

and welcome back

00:02

to Episode 13 off Cyber security architecture, fundamentals,

00:07

architecture documentation, Part one.

00:12

In this session,

00:14

we will cover a bit about

00:16

why do we need to do architecture documentation?

00:20

Cover some off the architecture art effects that you need to document

00:25

and go true. A few model views that that I used to represent a systems, namely the model view runtime view the plumbing view and data of you.

00:40

So why do we need to document the architecture

00:45

in any system life cycle?

00:48

We would have to create an architecture

00:51

idea from scratch or using architectural patterns, design patterns or from our experience, et cetera.

00:59

This is the same whether it's for a system all for software.

01:06

We were also need the ability to evaluate the architecture.

01:10

Is it good is it bet doesn't fit the purpose.

01:15

And with the feet back,

01:17

we would need to refine, update or effect earthy architecture along the way.

01:23

And once the design is final,

01:26

we used the architecture to guide the implementation

01:32

the same way a building engineer would use the architect's blueprints

01:36

and building

01:38

a skyscraper.

01:40

And similarly, when the architect used the blueprint to enforce the design in building a building

01:48

in the same way

01:49

the software architect system architect. A cyber security architect.

01:53

We used the architectural documents to enforce that

01:59

the design is followed by the builders

02:05

and what pins the entire life cycle together.

02:07

This communication.

02:09

So the architecture documents served as a conduit for clear and accurate communication off the design up and down.

02:21

Did letter

02:22

no

02:23

for the document to be understood, offer the designed. To be understood, the architect must be able to communicate all the considerations behind every decision.

02:34

This would be your architecture decision documents, which will be covered in a next session.

02:39

Most architectural document starts in a piece of paper, a PowerPoint presentation.

02:46

But for more complex system, it's useful to have an architectural tool

02:52

to Lincoln all the various subsystems together,

02:55

it would be difficult to link 50 subsystems together death on an Excel spreadsheet or a piece of paper

03:05

final. What architecture, tools and use in your organization IDed system engineers or the software architects. They might have a tool that can be extended to the cyber security architect.

03:19

When we talk about architecture design, we have to cover all perspective.

03:23

We need to cover the processes the operations and the data flows. And not just the static technical deployment

03:35

a system list for a long time. The documents help in future re engineering projects. Sometimes people have to understand why certain decisions was made in a point of time

03:46

on the documents served. This purpose

03:51

an additional benefit off having good and clear documentation.

03:54

Yes, we can help to catalog assets that can be reuse. This would serve as building blocks for new projects that may come along after.

04:04

So what are the architecture at effects? Well, we've gone true moves of it in the early sessions off this course. First of all the trek models,

04:15

this is the basis off the design. Therefore, the trip models have to be captured accurately and clearly.

04:26

The tread models also help us to design the test cases.

04:30

S controls are put in place to mitigate the threats identified.

04:36

The test cases develop should also form part off your architectural documentation.

04:44

We would also need to capture the technical system designs. What are the platforms used? The components used in so far

04:51

and also the processes need to run the system.

04:56

How the system is deployed also needs to be clearly documented.

05:01

This includes the sizing requirements off the components that you need

05:06

set up

05:10

makes. We have to document how we ended up into certain decisions.

05:15

This will be covered in an accession

05:16

and finally, any compliance checklist that you need to set this fire, the auditors or

05:24

regular tree

05:25

authorities.

05:26

Okay, let's get started on architectural artifacts or what use and software design. It's an example.

05:35

An architect

05:36

can consider the system in at least four ways

05:40

how it is structured and set of code. That's the model of you,

05:45

how it is structured as a set off elements that have run time presence. This would be the runtime view.

05:54

How are the artifacts organized in the fall systems? And how is the system deployed to heart way?

06:00

This would be the deployment view,

06:04

and lastly, what is the structure off the data repositories? This would be the date of you or the data mortal.

06:14

All these views refer to the same system. They're just different perspective for different stakeholders.

06:23

This is similar to a building architecture where you have the plumbing for the plumber,

06:29

the electrical wiring for the electrician and so on.

06:32

The architect must ensure that all the views are consistent.

06:40

Let's start with the modern view.

06:42

So this shows the structure off the system in terms of unit off implementation.

06:47

The elements in this view include the models, such as court units that implement such functionality

06:56

and the relationship between this morning,

07:00

for example,

07:01

is a part of B

07:03

are a depends on B

07:05

r A s A B specialization or generalization.

07:10

These can be drawn using standard UML,

07:14

which is the unified modeling language.

07:17

It is extremely useful to use standard notation for your diagrams so that its better understood

07:25

fire all stakeholders.

07:27

Next, we have to run time view.

07:30

This shows the structure off the system when its executing

07:33

the elements. Here are the runtime presence example T processes the threats, the serval, it's or the Windows applications. The deal. Els.

07:44

You would also show some of the data stores in use during runtime

07:48

and the relationships and these would be how the interact with each other.

07:55

Are they a local call or synchronize our asynchronous do not the examples I should underwrite.

08:01

There is the informal notation which is usually used in the presentation in the Power Point

08:07

and a formal UML notation below.

08:11

I would always recommend having a former notation use so that we could communicate with people, also your organizations, who will not be familiar with some off your own naming conventions.

08:24

In the deployment view,

08:26

we show at least two distinct but related structures

08:28

Hotwire infrastructure,

08:31

all structures of directories and fouls deployed in the system.

08:35

In this example, I shows that a heart where and the communication bus

08:43

and the second example shows the location off certain directories in certain service.

08:48

Again, do take note off the informal and formal notation.

08:54

While the informal notation looks good in a PowerPoint, the former plantation makes a lot more sense to a system or to a designer, especially if you're using

09:05

architecture tools to document your work.

09:09

The last few I'm talking about would be the data Mona view.

09:13

This should not be new to most people in 19. As this is thought and more schools,

09:18

you may ask, What is the value off this for the security architect? Well, sometimes the security architect needs to review the data models to ensure that the right data it's not exposed to the wrong person,

09:33

and it's helpful to understand the data structure when booting rules to detect unauthorized sequel cost, for example,

09:46

to go bore into details off this discipline.

09:50

Here are some Resource Is you can read.

09:52

Firstly, that's the System Engineering Book of Knowledge

09:58

Bye IEEE,

09:58

which is a lot of information around system architecture and documentation.

10:05

And another good resource is the U. S. Department of Energy Enterprise Architecture Document, which is available online.

10:13

So to wrap up

10:16

in this session, recovered briefly the need to have proper documentation,

10:20

the various architectural artifacts and the various perspective models offer system

10:28

do re true all the reading materials to get a better understanding off why each one is important.

10:35

In the next session, I'll be covering on how to document architecture decisions.