system thinking and problem solving for IT solutions

lauren II

lm_5_-_deployment_view.pptx

Home >Information Systems homework help >system thinking and problem solving for IT solutions

Lesson 5.3

UML Deployment Diagrams

Lesson 5.2

Distributed Systems Architecture (DSA) for Deployment

Lesson 5.1

Basic Vocabulary of the Deployment View

Learning Module Table of Contents

Reference

Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition). Chapters 21 and 20.

Lesson 5.4 (time permitting)

Using Deployment Diagrams to Illustrate the Development View

Lesson 5.3

UML Deployment Diagrams

Lesson 5.2

Distributed Systems Architecture (DSA) for Deployment

Lesson 5.1

Basic Vocabulary of the Deployment View

Let’s get started with the first lesson of the module

Reference

Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition). Chapters 21 and 20.

Lesson 5.4

Using Deployment Diagrams to Illustrate the Development View

System Architecture Views (using the ISO/IEC 42010 standard)

REF: ISO Software Architecture Standard as described by Rozanski and Woods

CONTEXT Views

FUNCTIONAL View

DATA View

TIMING View

DEVELOPMENT View

DELPOYMENT View

(we are here)

OPERATIONAL View

Not a new idea in systems design

Other architectural standards

Kruchten’s 4 + 1 architecture (IBM)

IEEE Standard 1471 that is the basis for your textbook

Zachman’s Framework for Information Systems Architecture

The Deployment View focuses on how hardware and software elements of your new system will be distributed or assigned across a network.

The deployment view includes both technical and non–technical sub-views.

The deployment view shows how various implementation components will be distributed to specific ”nodes” on the network.

The deployment view shows the communication lines (wired and wireless) between processing nodes

What is the Deployment View of a System’s Design?

Overview of the Deployment View

Characteristics	Explanation
Definition	Describes the processing and storage environment of your IT system/solution, and the potential points of failure for which you may need a service disruption and business continuity plan.
Concerns	All hardware, software, and storage nodes required for your system Commercial (third party components) that must be purchased Software components that must be built and where each will be executed (run-time environment) Data storage components, capacity, and recovery Network requirements and capacities Points of failure
Architectural Descriptions	Run-time models Network models Technology dependency Models
Possible Problems	Unclear or inaccurate dependencies between required nodes in the network Unproven technology choices, or obsolete technology choices Missing or poorly developed service level agreements with user community Lack of necessary technical knowledge or expertise Deployment becoming an after thought – compromising design and construction already completed Poor or no capacity planning analysis No service disruption business continuity plan, or disaster recovery plan and environment

REF: Adapted from Rozanski and Woods (2012)

UML Deployment Diagrams

Overview of the Deployment View (continued)

Characteristics	Explanation
Applicable Stakeholders	System owners System users System designers System builders System sustainers Technology partner
Applicability	All but the simplest systems

Deployment is all about Nodes and Connections

Nodes are physical or virtual computers (at locations; usually data centers) to which you will assign system components that you either purchase, or design/build.

Client nodes

Server nodes

Storage nodes (where the data is actually stored)

Other device nodes

Middleware nodes (many types)

Nodes are connected in a network

Preview Deployment Diagram (from UML)

FIGURE 21.1 in Rozanski and Woods (2011)

Diagram will usually require extensive use of stereotypes and tags

Frequently supplemented by textual narratives and tabular specifications as needed to communicate essential design prerequisites for system builders

This sample will be walked through later

Steps to build the Deployment View for your system

Identify all nodes required in your production environment

Some will come from your context diagrams

But many were hidden in the black box on your context diagrams

Must determine a “pattern” for your processing nodes

Identify all components and their Make versus BUY versus RE-USE (previously built or bought) decisions (not done exclusively by systems analyst in isolation; you need help from IT infrastructure staff, technology vendors, technology specialists, and consultants)

Record all communications paths between nodes.

Assign components to nodes

A checklist is provided for completeness and quality of your chosen architecture and its Deployment Diagram

Step 2 Checklist

Have you mapped all of the system’s functional elements to a type of element in your runtime platform?

Have you mapped them to specific hardware devices if appropriate?

Is the role of each piece of your runtime platform fully understood? Is the specified hardware or service suitable for the role?

Have you established detailed specifications for the system’s hardware devices or the hosted services that you require? Do you know exactly how many of each device or how much of each service is required?

Do you have service-level agreements for the elements of the runtime environment that are supplied by third parties?

Are the guarantees in the agreements suitable for your system? Can you test whether the guarantees are credible or not?

REF: Rozanski and Woods (2012) Chapter

INSTRUCTOR SUGGESTION: Convert these questions to a word document to formally use as a checklist whenever you implement a new IT system or solution

Step 2 Checklist

Have you identified all third-party software and documented all the dependencies between system elements and third-party software?

Are the network topology and services required by the system understood and documented?

Have you estimated and validated the required network capacity? Can the proposed network topology be built to support this capacity?

Have network specialists validated that the required network can be built?

Have you performed compatibility testing when evaluating your architectural options to ensure that the elements of the proposed deployment environment can be combined as desired?

Have you used enough prototypes, benchmarks, and other practical tests when evaluating your architectural options to validate the critical aspects of the proposed deployment environment?

REF: Rozanski and Woods (2012) Chapter

INSTRUCTION SUGGESTION: Convert these questions to a word document to formally use as a checklist whenever you implement a new IT system or solution

Step 2 Checklist

Can you create a realistic test environment that is representative of the proposed deployment environment?

Are you confident that the deployment environment will work as designed? Have you obtained external review to validate this opinion?

Are the assessors satisfied that the deployment environment meets their requirements in terms of standards, risks, and costs?

Have you checked that the physical constraints (such as floor space, power, cooling, and so on) implied by your required deployment environment can be met?

Do your hardware and service specifications include an appropriate amount of headroom?

Does your Deployment view include a specification of a disaster recovery environment, if required?

REF: Rozanski and Woods (2012) Chapter

INSTRUCTION SUGGESTION: Convert these questions to a word document to formally use as a checklist whenever you implement a new IT system or solution

Lesson 5.3

UML Deployment Diagrams

Lesson 5.2

Distributed Systems Architecture (DSA) for Deployment

Lesson 5.1

Basic Vocabulary of the Deployment & Development Views

Let’s get started with the first lesson of the module

Reference

Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition). Chapters 21 and 20.

Lesson 5.4

Using Deployment Diagrams to Illustrate the Development View

Distributed Systems Architecture (DSA)?

A distributed systems architecture (DSA) communicates to various stakeholders (usually with an illustration) how all system components (purchased, built, or used as-is) will be distributed across a network architecture for your system.

“Today, the computer is the network” Scott McNealy, founder and former CEO, Sun Computing

Scope of Distributed Systems Architecture (DSA)

Identification of relevant business locations (including possible mobile and external locations)

Identification of points of interaction between your system and existing systems and computing devices (NOTE: “computing devices” includes computers of all shapes and sizes, as well as any other device or machines into which a dedicate computer is embedded)

An architectural pattern for organizing your computing devices and how they will communicate with one another

Most common pattern today is multi-tiered client/server

Second most common pattern is peer-to-peer

Many other patterns existing in the literature (see next slide for great references)

Patterns can be combined

FUTURE IMPROVEMENT: Create a map between quality properties and DATA domain.

Page 15

Good Books on Reusable Patterns for Your Future Systems

Reminder: Deployment is all about Nodes

“Non-shared” Client nodes

“Shared” Server nodes

“Shared” Storage nodes (where the data is actually stored)

Other “shared” device nodes

“Transparent” Middleware nodes (many types)

Types of Client Nodes in a DSA

Personal computers (desktop and laptop)

Mobile devices

Smartphones

Tablets

Smartwatches

Smart wearables

Terminals

Infotainment systems in vehicles

Automated Teller Machines

Point of Sale cash registers

“Embedded” machines and devices

Types of Server Nodes in a DSA

Web Servers: serve up web pages and process messages to and from pages

Application Servers: execute business logic associated with an application

Database Servers: Execute database commands and stored procedures

Mail or Instant Messaging Servers: provide email services to an applications

Groupware/Collaboration Servers: provide work group and work flow services

Fax Servers: provide facsimile services to information system applications

Print Servers: provide shared printing services to information system applications

Terminal Servers: allow client computers to emulate other clients

Identity Servers: provide shared security services to an application.

Portal Servers: consolidate access to multiple systems (e.g. myPurdue)

And many more …

Other “nodes” in a DSA

SHARED STORAGE NODES

Example, SAN = Storage Area Network

A place to store data (not just alphanumeric data; but also documents, images, messages, etc. needed by your system and applications)

Does not include executable database code (e.g., SQL and PL-SQL). Such code is executed on a database server

OTHER SHARED NODES

Example - workload balancers

Route messages to duplicated servers to balance workload and provide failover

Example - Hardware Firewalls

“Hides” servers to protect them from external intrusion

Authorized users get dedicated “punch throughs” for legitimate connections

MIDDLEWARE NODES

Sits between clients and servers, or servers and other servers, to solve specific availability and integration problems

Uses of Middleware

Provide a more functional and reusable set of application programming interfaces to allow systems to:

Increase reliability and availability across networks

Mitigate differences in technology across systems

For example, enable database interoperability and synchronization despite use of very different database structures and technology that evolve over time

Locate various software components transparently across a network, thus providing interaction with other services and applications

Glue together components with reusable services

Standardize security across distributed networked applications

Usually run on their own computers; simple (meaning dedicated to one or few of the above uses)

Usually purchased (no need to constantly reinvent the wheel)

Middleware Technologies

Conceived as a layer of software that sits in between processing nodes in your system

Different experts consider different technologies as middleware

Middleware usually resides its own simple, dedicated servers (one per type)

OTHER SYSTEMS

YOUR SYSTEM

Business Process Orchestrators

Transports

Message Brokers (between servers)

Queues and shared services

MIDDLEWARE

Types of Middleware

Transport … moves messages, instructions and data between different processing nodes, accounting for the possibility of conflicting technologies and disruption

Queues and shared services ... provides a run-time environment for multiple users of a business logic component of a system

Message brokers … provide shared services, including management of services that might become temporarily unavailable

Business Process Orchestrators ... coordinate activities of a single transaction across multiple computers, including “rollback” (meaning un-doing) if a transaction fails/cancels at some point

Lesson 5.3

UML Deployment Diagrams

Lesson 5.2

Distributed Systems Architecture (DSA) for Deployment

Lesson 5.1

Basic Vocabulary of the Deployment & Development Views

Let’s get started with the first lesson of the module

Reference

Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition). Chapters 21 and 20.

Lesson 5.4

Using Deployment Diagrams to Illustrate the Development View

Is there a systems analysis and design tool that specifically communicates a system’s distributed systems architecture to those who will have to implement and sustain it?

Question of the day is …

UML Deployment Diagram

FIGURE 21.1 in Rozanski and Woods (2011)

This is an open, standard tool in the UML. It is not a profile.

Diagram will usually require extensive use of stereotypes and tags

Some shapes linked to other diagrams to provide details needed by SYSTEM BUILDERS

NOTE: This deployment diagrams does not conform to this course’s class standards

UML Deployment Diagrams (DD)

Basic constructs of Deployment Diagrams

Nodes … a physical location OR a physical computational resource

Examples: A location, specific server(s), or class of clients, or physical device, or appliance

Components … A representation of implemented (or to be implemented) software and database components to an assigned node

Examples: A database assigned to a server, or a software program or services assigned to a client or server

Communication Paths … between nodes

A data flow or network connection that allows messages and data to be exchanged

As always, universal UML constructs are also used

Examples: stereotypes, tags, multiplicity, packages, frames, notes/comments

Full Set of Shapes for Deployment Diagram

Basic Shapes and Constructs for Deployment Diagram

INSTRUCTOR NOTE: In ConceptDraw I had to use an Association line instead of a Communication Path line to add the multiplicity notations

INSTRUCTOR NOTE: For the assignment, use these shapes, connections, and font styles. Instructor recognizes that not all drawing tools support boldfacing.

Representative stereotypes for nodes (use these for assignment)

For the device nodes

<< ________ client>>

Examples (not a full list) <<desktop/laptop client>> <<smartphone client>> <<device>> or <<machine>> <<anywhere>>

<< ________ server>> Examples (not a full list) <<physical ______ server>> <<virtual _______ server>>

<<________ device>> Examples (not a full list) <<san>> <<middleware>> <<firewall>>

<<execution environment>> within a process node

For components inside the nodes

<<legacy app>>

<<legacy commercial app>>

<<legacy homegrown app>>

<<to build>>

<<to acquire>> or <<to buy>>

Some drawing tools default to <<component>> but that has no communication value. I change the default stereotype for component shapes to the above.

Other stereotypes may be approved on an organization-by-organization basis.

Appropriate Tags for nodes and components

Specific hardware product names, possibly including models and numbers

Specific software operating systems and/or utilities, possibly including minimum version numbers {Windows > 10.1+}

Specific software components to be developed or reused, possibly including version numbers {Purdue Supplier Catalog, SAP Financials 9+}

Specific database server technologies, possibly including minimum version numbers {Oracle 10.1+}

Specific web browser or technologies, possibly including minimum version numbers {Firefox >10} {XHTML}

Specific programming languages to be used to construct components, possibly including version numbers {Microsoft Visual C#}

Notice the use of mixed “mixed case” fonts for all tags

Representative tags for connections (not exhaustive)

Location names (general or specific as needed) {West Lafayette Campus} {KNOY Hall} {Indianapolis Data Center}

Network protocols to be used {Ethernet} or {cellular} or {wi-fi} or {bluetooth}

Internet formats to be used pass data {HTML} or {Flash} or {XML}

Other data formats to be used to pass data {DB2 SQL} or {ODBC} or {JDBC} or {comma delimited}

Transmission protocols to be used {RPC} or {RMI} … see Ch 21 in your book

Hardware protocols to be used {USB-C} or {Lightning}

Notice the use of mixed uppercase and lowercase fonts for all stereotypes

Two types of Deployment Diagrams

Business Geography – illustrates geographic locations for the system

Uses arrows with names to show primary data flows needed between locations

Uses tags to indicate general or specific locations of interest to the intended readers

No stereotypes

Technical Architecture – illustrates distributed systems architecture (DSA) consisting of processing nodes, communication paths, and assignment of components to nodes.

The following slide is an example of using a Deployment Diagram to illustrate Business Geography (as defined on previous slide)

The remaining slides are examples of using Deployment Diagrams to illustrate Technical Architecture

The first example is intentionally incomplete and intended only to demonstrate a simple and basic client/server pattern.

The second example is more complete and realistic because it extends a basic client/server pattern to include middleware

This Deployment Diagram depicts a multi-tiered client/server pattern, but only the basic tiers. To be completed, you would need to add middleware and any SAN.

Like the prior slide, this Deployment Diagram depicts a multi-tiered client/server pattern, but it add middleware components for completeness

YOUR TURN!

Lesson 5.3

UML Deployment Diagrams

Lesson 5.2

Distributed Systems Architecture (DSA) for Deployment

Lesson 5.1

Basic Vocabulary of the Deployment & Development Views

Let’s get started with the first lesson of the module

Reference

Rozanski, N. and Woods, E. (2012) Software systems architecture (2nd Edition). Chapters 21 and 20.

Lesson 5.4

Using Deployment Diagrams to Illustrate the Development View

Our design views are based on ISO/IEC Standard 42010

REF: ISO Software Architecture Standard as described by Rozanski and Woods

CONTEXT Views

FUNCTIONAL View

DATA View

TIMING View

DEVELOPMENT View

DELPOYMENT View

(we are here)

OPERATIONAL View

Not a new idea in systems design

Other architectural standards

Kruchten’s 4 + 1 architecture (IBM)

IEEE Standard 1471 that is the basis for your textbook

Zachman’s Framework for Information Systems Architecture

The Development View describes the architecture that supports the systems and software construction process (that follows system design)

The deployment view is about the physical, meaning technical environment

Includes physical system elements (e.g., software, databases, etc. to hardware elements (processing nodes in the network)

Describes how versions of the software are staged in production

Establishes standards for system and software development

Frequently required by auditors who seek to secure data even before the system goes operational

What is the Deployment View of a System’s Design?

The Development View of an Architectural Description

REF: Rozanski and Woods, Chapter 20

Stakeholder Concerns for the Development View

Modular organization of components and dependencies

System and software coding standards

Standardization of testing

Code line organization = configuration and version management

Security and privacy of test data (wasn’t in book; but is driven by configuration management)

Architecture Required to Support System Development

At any given time, you may have multiple components and versions of the same system in existence.

How do you coordinate construction so as to NOT overwrite one another’s development work?

System Planning

System Analysis

System Design

System Construction

System Operation

Possible instances of systems that may need to co-exist

PRODUCTION INSTANCES

Production instance for the current operational version

Training instance for the current operational version

---------------------------------------------------------------------------------------

NON-PRODUCTION INSTANCES

Development instance(s) for constructing and unit testing a future version

Testing instance for final testing of next operational version before it replaces the current production instance

Each “instance” (last slide) typically includes

Its own web server

Its own application servers

Its own database servers

and may use selected some production servers such as

Mail and messaging

Print and fax

Identity management

Unless one of the above presents a risk of crashing those servers. If so, then the instance needs its own.

But usually does not include its own client computers

Typical System Development Life Cycle Instances

Instance Name	Abbreviations	Notes
PRODUCTION (1 or more)	PROD	Runs the currently operational version of the solution. Has to be configured large enough to handle the business workload.
PRODUCTION Disaster Recovery	DR or PROD 2	Not always affordable. Must run on the same hardware models and configuration as PROD. Must run the same operating system software as PROD. Usually configured large enough to handle the business workload.
NON-PRODUCTION SANDBOX/SEED (optional)	SBX or SEED	For “playing with” new technology or developing “proofs of concept”. Does NOT typically have to run the one the same hardware or OS software as PROD.
NON-PRODUCTION DEVELOPMENT	DEV	For system development, unit testing. Should use the same hardware models as PROD, but configured much smaller. Should use the same operating system software as PROD.
NON-PRODUCTION TESTING/QUALITY ASSURANCE	TEST or QA	For system and integration testing. Should use the same hardware models as PROD, but configured larger than DEV, and smaller than PROD. Should use same operating systems software as PROD. Could double as DR if you can’t afford a separate DR instance, but can only do testing or DR at any given time.
NON-PRODUCTION” TRAINING	TRAIN or TRN	For end user training (including training development) Should use same hardware models as PROD, but configured very small. Should use same operating systems software as PROD. Could double as TEST if configured large enough, but can only do one thing at a time.

Together, all instances are said to define the system’s life cycle LANDSCAPE

Sample System Life Cycle Landscape (for a large ERP)

Every system should have a Life Cycle Landscape

The life cycle landscape is called a Development View

See next slide to look inside these UML frames

Each Instance is its own Deployment Diagram