My Repository 2

1. AWS

1.1. 1 Introduction to AWS

1.1.1. 1. Region

1.1.1.1. 1. region is a named set of AWS resources in the same geographical area.

1.1.1.2. 2. A region comprises at least two Availability Zones.

1.1.2. 2. AZ

1.1.2.1. 1. Availability Zone is a distinct location within a region that is insulated from failures in other Availability Zones and

1.1.2.2. 2. provides inexpensive, low-latency network connectivity to other Availability Zones in the same region.

1.1.3. 3. Deployment

1.1.3.1. 1. hybrid deployment is a way to connect infrastructure and applications between cloud-based resources and existing resources that are not located in the cloud.

1.1.3.2. 2. An all-in deployment refers to an environment that exclusively runs in the cloud.

1.2. 2 S3 and Glacier Storage

1.2.1. 1. Glacier

1.2.1.1. provides lowcost archival storage.

1.2.2. S3

1.2.2.1. 4. key characteristics of s3

1.2.2.1.1. All objects have a URL.

1.2.2.1.2. S3 can store unlimited amounts of data.

1.2.2.1.3. S3 uses a REST (Representational State Transfer) Application Program Interface (API).

1.2.2.2. 3. appropriates use cases for s3

1.2.2.2.1. Storing web content

1.2.2.2.2. Storing backups for a relational database

1.2.2.2.3. Storing logs for analytics

1.2.2.3. 2. Objects are stored in buckets, and objects contain both data and metadata.

1.2.2.3.1. objects are private by default

1.3. 3 EC2 and EBS

1.3.1. 1. EBS provides persistent block-level storage volumes for use with Amazon EC2 instances on the AWS Cloud.

1.4. 4 VPC

1.4.1. 1. VPC

1.4.1.1. VPC lets organizations provision a logically isolated section of the AWS Cloud where they can launch AWS resources in a virtual network that they define.

1.5. 5 ELB, CloudWatch and Auto Scaling

1.5.1. 1. CloudWatch

1.5.1.1. CloudWatch is a monitoring service for AWS Cloud resources and the applications organizations run on AWS.

1.5.1.2. CloudWatch metrics provide hypervisor visible metrics.

1.5.2. 2. Auto Scaling

1.5.2.1. helps maintain application availability and allows organizations to scale Amazon Elastic Compute Cloud (Amazon EC2) capacity up or down automatically according to conditions defined for the particular workload. Not only can it be used to help ensure that the desired number of Amazon EC2 instances are running, but it also allows resources to scale in and out to match the demands of dynamic workloads.

1.5.2.2. Auto Scaling Group

1.5.2.2.1. default EC2 capacity (20) for new region.

1.5.2.2.2. launches instances from an AMI specified in the launch configuration associated with the Auto Scaling group

1.5.2.2.3. enforces a minimum number of instances in the min-size parameter of the Auto Scaling group.

1.5.2.2.4. launch configurations

1.5.2.2.5. May use instances

1.5.2.2.6. Supported Plans

1.5.2.3. Auto Scaling is designed to scale out based on an event like increased traffic while being cost effective when not needed.

1.5.2.4. Auto Scaling responds to changing conditions by adding or terminating instances

1.5.3. ELB

1.5.3.1. Websites behind ELB

1.5.3.1.1. An SSL certificate must specify the name of the website in either the subject name or listed as a value in the Subject Alternative Name SAN extension of the certificate in order for connecting clients tonot receive a warning.

1.5.3.2. When Amazon EC2 instances fail the requisite number of consecutive health checks, the load balancer stops sending traffic to the Amazon EC2 instance.

1.5.3.3. ELB Health Checks

1.5.3.3.1. A ping

1.5.3.3.2. A connection attempt

1.5.3.3.3. A page request

1.5.3.4. Connection Draining

1.5.3.4.1. When connection draining is enabled, the load balancer will stop sending requests to a deregistered or unhealthy instance

1.5.3.4.2. attempt to complete in-flight requests until a connection draining timeout period is reached, which is 300 seconds by default.

1.5.3.5. supported types of load balancer

1.5.3.5.1. Internet-facing

1.5.3.5.2. Internal

1.5.3.5.3. HTTPS using SSL

1.6. 6 IAM

1.6.1. IAM Policies

1.6.1.1. Service Name

1.6.1.2. Action

1.6.2. IAM Security Features

1.6.2.1. MFA

1.6.3. Actions Authorized by IAM

1.6.3.1. Launching a Linux EC2 instance

1.6.4. EC2 roles

1.6.4.1. Key rotation is not necessary.

1.6.5. temporary security tokens

1.7. 7 Databases and AWS

1.7.1. 1. Databases

1.7.1.1. 1. DynamoDB

1.7.1.1.1. 1. non-relational database

1.7.1.1.2. 2. fully managed, fast, and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale.

1.7.1.1.3. 3. DynamoDB tables

1.7.1.2. 2. RDS

1.7.1.2.1. 1. OLTP

1.7.1.2.2. 2. RDS provides managed relational databases.

1.7.1.2.3. 3. increase resiliency

1.7.1.2.4. 4. RDS supports Microsoft SQL Server Enterprise edition and the license is available only under the BYOL model

1.7.1.2.5. 5. MySQL

1.7.1.3. 3. Redshift

1.7.1.3.1. 1. best suited for traditional Online Analytics Processing (OLAP) transactions

1.7.2. 2. read replicas

1.7.2.1. 1. to increase performance, use read replicas to scale out the database and thus maximize read performance

1.7.2.2. 2. read replicas and a Multi-AZ deployment allow you to replicate your data and reduce the time to failover

1.7.3. 3. DB Snapshots

1.7.3.1. 1. can be used to restore a complete copy of the database at a specific point in time

1.7.3.2. 2. DB snapshots allow you to back up and recover your data

1.7.4. 4. Multi-AZ supported db engines

1.7.4.1. 1. MS SQL Server, MySQL, Aurora, PostgreSQL, Oracle...

1.7.5. 5. database failover

1.7.5.1. 1. Force a Multi-AZ failover from one Availability Zone to another by rebooting the primary instance using the Amazon RDS console.

1.7.5.1.1. 1. rebooting the primary instance using the Amazon RDS console.

1.7.6. 6. General Purpose (SSD) volumes are generally the right choice for databases that have bursts of activity

1.7.7. 7. offload read requests

1.7.7.1. 1. Add a read replica DB instance, and configure the client’s application logic to use a read-replica.

1.7.7.2. 2. Create a caching environment using ElastiCache to cache frequently used data. Update the application logic to read/write from the cache.

1.7.8. 8. securing the database

1.7.8.1. 1. requires a multilayered approach that secures the infrastructure, the network, and the database itself

1.8. 8 SQS, SWF, and SNS

1.8.1. 1. SQS

1.8.1.1. 1. SQS is a fast, reliable, scalable, fully managed message queuing service that allows organizations to decouple the components of a cloud application. With Amazon SQS, organizations can transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available.

1.8.1.2. 2. SQS visibility timeout

1.8.1.2.1. 1. max 12 hours

1.8.1.2.2. 2. default 30 sec

1.8.1.3. 3. properties

1.8.1.3.1. 1. Message ID

1.8.1.3.2. 2. Body

1.8.2. 2. SWF

1.8.2.1. helps developers build, run, and scale background jobs that have parallel or sequential steps.

1.8.3. 3. SNS

1.8.3.1. provides a messaging bus complement to Amazon SQS; however, it doesn’t provide the decoupling of components necessary for this scenario.

1.8.4. 2. SNS features

1.8.4.1. 1. Publishers

1.8.4.2. 2. Subscribers

1.8.4.3. 3. Topics

1.8.4.3.1. 1. ARN created

1.8.5. 1. Supported Protocols

1.8.5.1. 1. HTTPS

1.8.5.2. 2. AWS Lambda

1.8.5.3. 3. Email-JSON

1.9. 9 DNS and Route 53

1.9.1. 1. Route 53 provides a highly available and scalable cloud Domain Name System (DNS) web service.

1.10. 10 ElastiCache

1.10.1. 1. ElastiCache is a service that provides in-memory cache in the cloud.

1.11. 11 Additional Key Services

1.11.1. 1. CloudFront is a web service that provides a CDN to speed up distribution of your static and dynamic web content—for example, .html, .css, .php, image, and media files—to end users. Amazon CloudFront delivers content through a worldwide network of edge locations.

1.11.2. 2. CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources.

1.11.3. 3. CloudTrail records AWS API calls, and Amazon Redshift is a data warehouse, neither of which would be useful as an architecture component for decoupling components.

1.12. 12 Security on AWS

1.13. 13 AWS Risk and Compliance

1.14. 14 Architecture Best Practices

2. TOGAF 9.2

2.1. Publications

2.1.1. Part 1: Introduction

2.1.1.1. Definitions

2.1.1.1.1. TOGAF

2.1.1.1.2. Enterprise

2.1.1.1.3. Architecture

2.1.1.2. Why do we need Enterprise Architecture?

2.1.1.2.1. 1. Lower costs – development, maintenance, support

2.1.1.2.2. 2. Reduced complexity

2.1.1.2.3. 3. Reduced risk

2.1.1.2.4. 4. Simpler to add new systems

2.1.1.2.5. 5. Faster purchase and implementation

2.1.1.3. What is an Architecture Framework?

2.1.1.3.1. Def 1

2.1.1.3.2. Def 2

2.1.1.4. Core Concepts

2.1.1.4.1. Establishing the Architecture Capability as an Operational Entity, an enterprise architecture practice should establish capabilities in the following areas

2.1.2. Part 2: ADM

2.1.2.1. Intro

2.1.2.1.1. Overview

2.1.2.1.2. Architecture Development Cycle

2.1.2.1.3. Scoping the Architecture

2.1.2.2. Architecture Development Cycle

2.1.2.2.1. The ADM is iterative, over the whole process, between phases and within phases

2.1.2.2.2. For each iteration of the ADM, a fresh decision must be taken as to

2.1.2.2.3. These decisions should be based on a

2.1.2.2.4. As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs.

2.1.2.3. Phases

2.1.2.3.1. Preliminary Phase

2.1.2.3.2. Phase A: Architecture Vision

2.1.2.3.3. Phase B: Business Architecture

2.1.2.3.4. Phase C: Information Systems Architecture

2.1.2.3.5. Phase D: Technology Architecture

2.1.2.3.6. Phase E: Opportunities and Solutions

2.1.2.3.7. Phase F: Migration Planning

2.1.2.3.8. Phase H: Architecture Change Management

2.1.2.3.9. Requirements Management

2.1.3. Part 3: ADM Guidelines and Techniques

2.1.3.1. 1. Applying Iteration to the ADM

2.1.3.1.1. Iteration Cycles

2.1.3.1.2. Classes of Architecture Engagement

2.1.3.1.3. Approaches to Architecture Development

2.1.3.2. 2. Applying the ADM at different Enterprise Levels

2.1.3.2.1. Strategic Architectures (executive level)

2.1.3.2.2. Segment Architectures (program or portfolio level)

2.1.3.2.3. Capability Architectures

2.1.3.3. 3. Security Architecture and the ADM

2.1.3.3.1. How to adapt the ADM for security

2.1.3.3.2. Accepted areas of concern for the security architect

2.1.3.3.3. Typical security architecture artifacts

2.1.3.4. 4. Using TOGAF to Define & Govern SOAs

2.1.3.4.1. A style of architecture that looks at all the functions of the system as services.

2.1.3.4.2. Services

2.1.3.4.3. Using TOGAF for SOA

2.1.3.5. 5. Architecture Principles

2.1.3.5.1. Principle Components

2.1.3.5.2. Qualities

2.1.3.5.3. Two key domains inform the development and utilization of architecture:

2.1.3.5.4. Example Set of Architecture Principles (BDAT)

2.1.3.6. 6. Architecture Stakeholder Management

2.1.3.6.1. Stakeholder

2.1.3.6.2. Technique

2.1.3.6.3. Approach to Stakeholder Management

2.1.3.7. 7. Architecture Patterns

2.1.3.7.1. A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in other

2.1.3.7.2. In TOGAF, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable solution to a problem.

2.1.3.7.3. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

2.1.3.8. 8. Business Scenarios

2.1.3.8.1. Introduction

2.1.3.8.2. Benefits of Business Scenarios

2.1.3.8.3. Creating the Business Scenario

2.1.3.8.4. Contents of a Business Scenario

2.1.3.8.5. Contributions to the Business Scenario

2.1.3.8.6. Business Scenarios and the TOGAF ADM

2.1.3.8.7. Developing Business Scenarios

2.1.3.8.8. Business Scenario Documentation

2.1.3.8.9. Guidelines on Goals and Objectives

2.1.3.9. 9. Gap Analysis

2.1.3.9.1. Business domain gaps:

2.1.3.9.2. Data domain gaps:

2.1.3.9.3. Applications impacted, eliminated, or created

2.1.3.9.4. Technologies impacted, eliminated, or created

2.1.3.10. 10. Migration Planning Techniques

2.1.3.10.1. Matries

2.1.3.10.2. Tables

2.1.3.10.3. 5. Business Value Assessment Technique

2.1.3.11. 11. Interoperability Requirements

2.1.3.11.1. Definitions

2.1.3.11.2. Categories

2.1.3.11.3. Enterprise Operating Model

2.1.3.11.4. Refining Interoperability

2.1.3.11.5. Determining Interoperability Requirements

2.1.3.11.6. Reconciling Interoperability Requirements with Potential Solutions

2.1.3.11.7. Summary

2.1.3.12. 12. Business Transformation Readiness Assessment

2.1.3.12.1. Introduction

2.1.3.12.2. Recommended Activities

2.1.3.12.3. Business Transformation Enablement Program (BTEP)

2.1.3.12.4. Determine Readiness Factors

2.1.3.12.5. Present Readiness Factors

2.1.3.12.6. Assess Readiness Factors

2.1.3.12.7. Readiness and Migration Planning

2.1.3.12.8. Marketing the Implementation Plan

2.1.3.13. 13. Risk Management

2.1.3.13.1. Intro

2.1.3.13.2. Risk Classification

2.1.3.13.3. Risk Identification

2.1.3.13.4. Initial Risk Assessment

2.1.3.13.5. Risk Mitigation and Residual Risk Assessment

2.1.3.13.6. Conduct Residual Risk Assessment

2.1.3.13.7. Risk Monitoring and Governance (Phase G)

2.1.3.13.8. Initial Risk Assessment

2.1.3.14. 14. Capability-Based Planning

2.1.3.14.1. Overview

2.1.3.14.2. Capability-Based Planning Paradigm

2.1.3.14.3. Concept of Capability-Based Planning

2.1.3.14.4. Capabilities in an Enterprise Architecture Context

2.1.3.14.5. Summary

2.1.3.14.6. Old

2.1.3.14.7. Links

2.1.4. Part 4: Architecture Content Framework

2.1.4.1. Intro.

2.1.4.1.1. This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables

2.1.4.1.2. Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc.

2.1.4.1.3. The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented

2.1.4.2. Content Metamodel

2.1.4.2.1. 1. Overview

2.1.4.2.2. 2. Content Metamodel Vision and Concepts

2.1.4.2.3. 3. Content Metamodel in Detail

2.1.4.2.4. 4. Content Metamodel Extensions

2.1.4.2.5. 5. Content Metamodel Entities

2.1.4.2.6. 6. Content Metamodel Attributes

2.1.4.2.7. 7. Metamodel Relationships

2.1.4.3. Architectural Artifacts

2.1.4.3.1. Classifications

2.1.4.3.2. Artifacts

2.1.4.4. Architecture Deliverables

2.1.4.4.1. 1. Architecture Building Blocks

2.1.4.4.2. 2. Architecture Contract

2.1.4.4.3. 3. Architecture Definition Document

2.1.4.4.4. 4. Architecture Principles

2.1.4.4.5. 5. Architecture Repository

2.1.4.4.6. 6. Architecture Requirements Specification

2.1.4.4.7. 7. Architecture Roadmap

2.1.4.4.8. 8. Architecture Vision

2.1.4.4.9. 9. Business Principles, Business Goals, and Business Drivers

2.1.4.4.10. 10. Capability Assessment

2.1.4.4.11. 11. Communications Plan

2.1.4.4.12. 12. Compliance Assessment

2.1.4.4.13. 13. Implementation and Migration Plan

2.1.4.4.14. 14. Implementation Governance Model

2.1.4.4.15. 15. Organizational Model for Enterprise Architecture

2.1.4.4.16. 16. Request for Architecture Work

2.1.4.4.17. 17. Change Request

2.1.4.4.18. 18. Requirements Impact Assessment

2.1.4.4.19. 19. Solution Building Blocks

2.1.4.4.20. 20. Statement of Architecture Work

2.1.4.4.21. 21. Tailored Architecture Framework

2.1.4.5. Building Blocks

2.1.4.5.1. Characteristics

2.1.4.5.2. A good building block has the following characteristics:

2.1.4.5.3. Architecture Building Blocks

2.1.4.5.4. Solution Building Blocks

2.1.4.5.5. Building Block Specification Process in the ADM

2.1.5. Part 5: Enterprise Continuum and Tools

2.1.5.1. Architecture Continuum

2.1.5.1.1. Foundation Architecture

2.1.5.1.2. Common Systems Architecture

2.1.5.1.3. Industry Architecture

2.1.5.1.4. Organization-Specific Architecture

2.1.5.2. Architecture Repository

2.1.5.2.1. Architecture

2.1.5.2.2. SIB

2.1.5.2.3. Reference Library

2.1.5.2.4. Governance Log

2.1.5.3. Solutions Continuum

2.1.5.3.1. Foundation Solutions

2.1.5.3.2. Common Systems Solutions

2.1.5.3.3. Industry Solutions

2.1.5.3.4. Organization-Specific Solutions

2.1.5.4. Architecture Partitioning

2.1.5.4.1. Reasons

2.1.5.4.2. Architectural Landscape:

2.1.5.4.3. Integration Risks:

2.1.5.4.4. What is needed:

2.1.5.4.5. Explanation

2.1.6. Part 6 TOGAF Reference Models

2.1.6.1. Foundation Architecture: TRM

2.1.6.1.1. Intro

2.1.6.1.2. TRM

2.1.6.1.3. SIB

2.1.6.2. Integrated Information Infrastructure Reference Model) III-RM

2.1.6.2.1. Boundaryless Information Flow

2.1.7. Part 7: Architecture Capability Framework

2.1.7.1. Overview

2.1.7.1.1. In order to successfully operate an architecture function within an enterprise, it is necessary to put in place appropriate organization structures, processes, roles, responsibilities, and skills to realize the Architecture Capability.

2.1.7.1.2. Part VII: Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.

2.1.7.2. Establishing an Architecture Capability

2.1.7.2.1. Can be supported by the TOGAF Architecture Development Method (ADM).

2.1.7.2.2. Require the design of the four domain architectures

2.1.7.3. Architecture Board

2.1.7.3.1. Responsibilities

2.1.7.3.2. Role

2.1.7.3.3. Setting Up the Architecture Board

2.1.7.4. Architecture Compliance

2.1.7.4.1. Terminology

2.1.7.4.2. Architecture Compliance Reviews

2.1.7.5. Architecture Contracts

2.1.7.5.1. Architecture Contracts are the joint agreements between development partners and sponsors on the:

2.1.7.5.2. Successful implementation of these agreements will be delivered through effective architecture governance

2.1.7.6. Architecture Governance

2.1.7.6.1. Hierarchy of Governance:

2.1.7.6.2. Characteristics of Governance

2.1.7.6.3. Architecture Governance Framework

2.1.7.7. Architecture Maturity Models

2.1.7.7.1. Capability Maturity Models (CMMs)

2.1.7.8. Architecture Skills Framework

2.1.7.8.1. Provide a view of the competency levels required for specific roles

2.1.7.8.2. Goals

2.1.7.8.3. Enterprise Architecture Role and Skill Categories

2.1.7.8.4. Enterprise Architecture Role and Skill Categories

2.2. TOGAF 9.2 (I/O, Artifacts, Approach)

2.2.1. ADM Input/Output & Steps

2.2.1.1. 0 : Preliminary

2.2.1.1.1. Inputs

2.2.1.1.2. Outputs

2.2.1.1.3. Steps

2.2.1.2. A: Architecture Vision

2.2.1.2.1. Inputs

2.2.1.2.2. Outputs

2.2.1.2.3. Steps

2.2.1.3. B C D: Business/Information Systems/Technology Architecture

2.2.1.3.1. Inputs

2.2.1.3.2. Outputs

2.2.1.3.3. Steps

2.2.1.4. E: Opportuneties and Solutions

2.2.1.4.1. Inputs

2.2.1.4.2. Outputs

2.2.1.4.3. Steps

2.2.1.5. F: Migration Planning

2.2.1.5.1. Inputs

2.2.1.5.2. Outputs

2.2.1.5.3. Steps

2.2.1.6. G: Implementation Governance

2.2.1.6.1. Inputs

2.2.1.6.2. Outputs

2.2.1.6.3. Steps

2.2.1.7. H: Architecture Change Management

2.2.1.7.1. Inputs

2.2.1.7.2. Outputs

2.2.1.7.3. Steps

2.2.2. ADM Objectives, Approach & Process

2.2.2.1. Preliminary

2.2.2.1.1. Objectives

2.2.2.1.2. Approach

2.2.2.1.3. steps

2.2.2.2. A Architecture vision

2.2.2.2.1. Objectives

2.2.2.2.2. Approach

2.2.2.2.3. Steps

2.2.2.3. B. Business architecture

2.2.2.3.1. Objectives

2.2.2.3.2. Approach

2.2.2.3.3. Steps

2.2.2.4. C. Information systems

2.2.2.4.1. Data

2.2.2.4.2. Applications

2.2.2.5. D. technology architecture

2.2.2.5.1. Objectives

2.2.2.5.2. Approach

2.2.2.5.3. Process

2.2.2.6. E. Opportunity/solutions

2.2.2.6.1. Objectives

2.2.2.6.2. Approach

2.2.2.6.3. Steps

2.2.2.7. F, Migration planning

2.2.2.7.1. Objectives

2.2.2.7.2. Steps

2.2.2.8. G. Implementation governance

2.2.2.8.1. Objectives

2.2.2.8.2. Approach

2.2.2.8.3. Steps

2.2.2.9. Architecture requirements mgmg

2.2.2.9.1. Objectives

2.2.2.9.2. Approach

2.2.2.10. H. Architecture change mgmt

2.2.2.10.1. Objectives

2.2.2.10.2. Approach

2.2.2.10.3. Steps

2.2.3. Artifacts

2.2.3.1. 0: Preliminary

2.2.3.1.1. Principles Catalog

2.2.3.2. A: Architecture Vision

2.2.3.2.1. Stakeholder Map Matrix

2.2.3.2.2. Value Chain Diagram

2.2.3.2.3. Solution Concept Diagram

2.2.3.3. B: Business Architecture

2.2.3.3.1. Organization/Actor Catalog

2.2.3.3.2. Driver/Goal/Objective Catalog

2.2.3.3.3. Role Catalog

2.2.3.3.4. Business Service/Function Catalog

2.2.3.3.5. Location Catalog

2.2.3.3.6. Process/Event/Control/Product Catalog

2.2.3.3.7. Contract/Measure Catalog

2.2.3.3.8. Business Interaction Matrix

2.2.3.3.9. Actor/Role Matrix

2.2.3.3.10. Business Footprint Diagram

2.2.3.3.11. Business Service/Information Diagram

2.2.3.3.12. Functional Decomposition Diagram

2.2.3.3.13. Product Lifecycle Diagram

2.2.3.3.14. Goal/Objective/Service Diagram

2.2.3.3.15. Business Use-Case Diagram

2.2.3.3.16. Organization Decomposition Diagram

2.2.3.3.17. Process Flow Diagram

2.2.3.3.18. Event Diagram

2.2.3.4. C: Information Systems Architecture

2.2.3.4.1. Data

2.2.3.4.2. Application

2.2.3.5. D: Technology Architecture

2.2.3.5.1. Technology Standards Catalog

2.2.3.5.2. Technology Portfolio Catalog

2.2.3.5.3. Application/Technology Matrix

2.2.3.5.4. Environments and Locations Diagram

2.2.3.5.5. Platform Decomposition Diagram

2.2.3.5.6. Processing Diagram

2.2.3.5.7. Networked Computing/Hardware Diagram

2.2.3.5.8. Communications Engineering Diagram

2.2.3.6. E: Opportunities and Solutions

2.2.3.6.1. Project Context Diagram

2.2.3.6.2. Benefits Diagram

2.2.4. Summary

2.2.4.1. Resources

2.2.4.1.1. ADM Steps Reference

2.2.4.1.2. Architectural Artifacts

2.2.4.1.3. TOGAF 9 certification preparation advices & exam tips

2.2.4.1.4. Togaf Modeling

2.2.4.2. Exams

2.2.4.2.1. Level 1

2.2.4.2.2. Level 2

2.2.4.3. TOGAF 9.2 brief

2.2.4.3.1. Move to Modular

2.2.4.3.2. Why

2.2.4.3.3. ADM Vision and Business Phases

2.2.4.3.4. Content Metamodel

2.2.4.3.5. Summary

2.2.5. EA Operating Model

2.3. Exams

2.3.1. Part 1

2.3.1.1. Part 1 Exam

2.3.1.2. Questions and Answers

2.3.1.3. Part 1 online Sample Tests

2.3.2. Part 2

3. Operating Systems

3.1. Microsoft Windows

3.1.1. Windows 11 / 2021

3.1.2. مميزات

3.1.2.1. يقدم أداء عالي ومتوافق مع جميع الألعاب، ويدعم عدد إطارات عالي، وبالإضافة لدعمه عدد كبير من برامج تحسين الأداء. تصميم جديد وواجهة مستخدم جديدة مشرقة والتعامل معها سهل. أعادة تصميم عدد كبير من البرامج لتعطي أداء أفضل. إمكانية ربط الهاتف مع نظام التشغيل والتحكم به. استقرار النظام وتوافقه مع أجهزة وقطع الكمبيوتر بشكل أفضل وأسرع. إضافة مساعدات إضافية وعدد كبير من الاختصارات لسهولة الوصول والتحكم بكل شيء في ويندوز 10. التحديثات المستمرة والتلقائية لنظام التشغيل، والتي تشكل تحديثات التطبيقات والتحديثات الأمنية المهمة. إضافة مساعد شخصي ذو ذكاء اصطناعي مفيد جدًا في حل المشاكل والتعامل مع البيانات والمعلومات.

3.1.3. عيوب

3.1.3.1. الخصوصية القليلة حيث يستطيع المساعد الشخصي الوصول إلى كل بيانات ومعلومات المستخدم بسهولة عالية. التحديثات الإجبارية التي لا يمكن ايقافها. حدوث بعض المشاكل في النظام والبرامج فيه، والتي تؤثر على عمل البرامج الأخرى.

3.2. Apple Mac

3.2.1. Mac OS 12 / 2021

3.2.2. مميزات

3.2.2.1. الوزن الصغير جدًا والسمك غير المسبوق في أي من أنواع أجهزة اللاب توب والكمبيوتر المحمول الأخرى . يأتي الماك بوك بشاشة كبيرة و واضحة جدًا وبها درجة غير عادية من السطوع والوضوح والتي تجعل متابعة ومشاهدة الصور ومقاطع الفيديو وأي شيء آخر على الشاشة أكثر متعة ووضوح وهو ما يُعتبر ميزة هامة جدًا لكافة المصممين والمصورين .

3.2.3. عيوب

3.2.3.1. فيما يخص عيوب جهاز ماك بوك ؛ فهي قليلة جدًا ، ولم يُمثل الجهاز منذ طرحه أي اراء أو تعليقات سلبية من قبل المستخدمين والتجار ، ولكن يبقى العيب الأساسي والمسيطر على جميع منتجات شركة ابل وهو السعر المرتفع جدًا ، وهذا ما يجعل فئة ليست بالقليلة من المستخدمين يلجئون إلى استخدام الأجهزة الأخرى الأقل سعرًا .

3.3. Linux

3.3.1. التوزيعات

3.3.1.1. Ubuntu 21 / 2021

3.3.1.2. Fedora 35 /2021

3.3.1.3. SUSE 4.0 / 2019

3.3.2. عيوب

3.3.2.1. مفتوح المصدر أكثر أمانًا كفاءة في الأداء نظام مرن مجاني

3.3.3. عيوب

3.3.3.1. الواجهة الرسومية ليست جيدة محركات الأجهزة قليلة منحنى التعليم صعب البرامج غير متوفرة قلة الألعاب

4. DevOps

4.1. DevOps Ecosystem

4.1.1. Product Life Cycle

4.1.1.1. Continuous integration

4.1.1.1.1. Jenkins http://jenkins-ci.org/

4.1.1.1.2. Travis CI https://travis-ci.org/

4.1.1.1.3. Circle CI https://circleci.com/

4.1.1.1.4. Shippable https://www.shippable.com/

4.1.1.1.5. Team Foundation Server https://msdn.microsoft.com/en-us/vstudio/ff637362.aspx https://msdn.microsoft.com/en-us/library/hh395023%28v=vs.110%29.aspx

4.1.1.1.6. Perforce http://www.perforce.com/continuous-delivery-solutions

4.1.1.1.7. Testing Plugins

4.1.1.2. Configuration Management

4.1.1.2.1. Chef https://www.chef.io/

4.1.1.2.2. Puppet https://puppetlabs.com/

4.1.1.2.3. CFEngine http://cfengine.com/

4.1.1.2.4. SaltStack http://saltstack.com/

4.1.1.2.5. Ansible http://www.ansible.com/

4.1.1.3. Product Management

4.1.1.3.1. Jira https://www.atlassian.com/software/jira/?clicked=j.a.com_introduction

4.1.1.3.2. Basecamp https://basecamp.com/

4.1.1.3.3. Rally https://www.rallydev.com/

4.1.1.3.4. Pivotal Tracker http://www.pivotaltracker.com/

4.1.1.3.5. Teamwork PM https://www.teamwork.com/

4.1.1.3.6. Daptiv http://www.daptiv.com/

4.1.1.3.7. Workfront (atTask) http://www.workfront.com/

4.1.1.3.8. Version One http://www.versionone.com/

4.1.1.3.9. Taiga https://taiga.io/

4.1.1.3.10. Waffle https://waffle.io

4.1.1.4. Source Control Management

4.1.1.4.1. Github https://github.com/

4.1.1.4.2. Stash https://www.atlassian.com/software/stash

4.1.1.4.3. BitBucket https://bitbucket.org/

4.1.1.4.4. Mercurial http://mercurial.selenic.com/

4.1.1.4.5. Subversion https://subversion.apache.org/

4.1.1.4.6. Google Project Hosting https://code.google.com/projecthosting/

4.1.1.4.7. Perforce http://www.perforce.com/

4.1.1.4.8. Gogs http://gogs.io/

4.1.1.4.9. Git Lab https://about.gitlab.com/

4.1.2. Managed Service

4.1.2.1. Customer service desk

4.1.2.1.1. Zendesk https://www.zendesk.com/

4.1.2.1.2. Zoho Support https://www.zoho.com/support/

4.1.2.1.3. Freshdesk http://freshdesk.com/

4.1.2.2. Scheduling & Incident management

4.1.2.2.1. Pager Duty http://www.pagerduty.com/

4.1.2.2.2. VictorOps http://victorops.com/

4.1.2.2.3. Ops Genie http://www.opsgenie.com/

4.1.2.3. Monitoring

4.1.2.3.1. Boundary http://www.boundary.com/

4.1.2.3.2. Data Dog http://www.datadoghq.com/

4.1.2.3.3. Nagios http://www.nagios.org/

4.1.2.3.4. Ruxit https://www.ruxit.com/

4.1.2.3.5. Stackify http://stackify.com/

4.1.2.3.6. Scout https://scoutapp.com/

4.1.2.3.7. Rollbar https://rollbar.com/

4.1.2.4. Security Auditing

4.1.2.4.1. Evident.IO https://evident.io/

4.1.2.4.2. Tripwire http://www.tripwire.com/

4.1.2.4.3. Metasploit http://www.metasploit.com/

4.1.2.4.4. Nexpose http://www.rapid7.com/products/nexpose/index.jsp

4.1.2.4.5. Kali http://docs.kali.org/ https://aws.amazon.com/marketplace/pp/B00HW50E0M

4.1.2.4.6. Nessus http://www.tenable.com/products/nessus-vulnerability-scanner

4.1.2.4.7. BeyondSaas http://www.beyondtrust.com/Products/BeyondSaaS/

4.1.2.4.8. Retina http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/

4.1.2.4.9. Core Insight http://www.coresecurity.com/core-insight

4.1.2.4.10. Dome9 http://www.dome9.com/

4.1.2.4.11. Alien Vault https://www.alienvault.com/

4.1.2.4.12. Alert Logic http://www.alertlogic.com/

4.1.2.5. Analytics

4.1.2.5.1. New Relic http://newrelic.com/

4.1.2.5.2. Librato https://www.librato.com/

4.1.2.6. Log Management

4.1.2.6.1. Loggly https://www.loggly.com/

4.1.2.6.2. Splunk http://www.splunk.com/

4.1.2.6.3. ELK stack http://www.elasticsearch.org/overview/elasticsearch/ http://logstash.net/ http://www.elasticsearch.org/overview/kibana/

4.1.2.6.4. SumoLogic https://www.sumologic.com/

4.1.2.6.5. Logentries https://logentries.com/

4.2. DevOps Concept

4.2.1. Storage

4.2.1.1. Architecture/Functional scope

4.2.1.2. Fundamentals

4.2.1.2.1. Traditional storage solution: SAN, NAS, DAS

4.2.1.2.2. Distributed storage solution: NFS, GlusterFS, Lustree, DRBD.

4.2.1.2.3. Practice: vSAN, vNAS, NFS, GlusterFS

4.2.1.3. Access-layer storage solution: Block, Object, File

4.2.1.4. Block Storage

4.2.1.4.1. Ceph

4.2.1.5. Object Storage

4.2.1.5.1. OpenStack Swift

4.2.2. Infra Architecture

4.2.2.1. Sizing

4.2.2.2. Monitoring

4.2.2.2.1. Monitoring metrics understanding

4.2.2.2.2. Monitoring scope

4.2.2.2.3. Monitoring solution

4.2.2.3. Logging

4.2.2.4. Profiling/Benchmarking

4.2.2.4.1. Profiling metrics understanding

4.2.2.5. Architecture Design Pattern

4.2.2.6. DevOps mindset

4.2.2.7. Upgrade/Update

4.2.3. Appliance Architecture

4.2.3.1. Software Design Pattern specific in Cloud environment

4.2.3.1.1. Event Sourcing/CQRS

4.2.3.1.2. Circuit Breaker

4.2.3.1.3. Retry

4.2.3.2. CI/CD/Testing

4.2.3.3. SOA/Micro-services

4.2.3.4. DevOps Mindset

4.2.3.5. Upgrade/Update

4.2.4. Networking

4.2.4.1. IPv4/IPv6

4.2.4.2. Fundamentals

4.2.4.2.1. OSI, TCP/IP

4.2.4.2.2. DHCP/DNS

4.2.4.2.3. Firewall (IPTables)

4.2.4.2.4. Flat, Overlay (VLAN, VxLAN, GRE)

4.2.4.2.5. Bridge, NAT

4.2.4.2.6. QoS

4.2.4.2.7. Routing

4.2.4.3. Linux Bridge/OpenvSwitch

4.2.4.3.1. Architecture/Functional scope

4.2.4.3.2. Pros/Cons in Comparison

4.2.4.3.3. Network Namespace

4.2.4.3.4. Bonding/Teaming

4.2.4.3.5. Veth

4.2.4.3.6. Macvlan, Macvtap, Ipvlan, Tun/Tap

4.2.4.3.7. Tunnels

4.2.4.3.8. QoS

4.2.4.3.9. Practice in KVM

4.2.4.4. OpenStack Neutron

4.2.4.4.1. Architecture/Functional scope

4.2.4.4.2. Deployment models (practice with DevStack)

4.2.4.4.3. Tuning

4.2.4.4.4. Scaling

4.2.5. Virtualization

4.2.5.1. Hypervisor

4.2.5.1.1. Hypervisor type

4.2.5.1.2. QEMU

4.2.5.1.3. KVM

4.2.5.1.4. XEN

4.2.5.1.5. PCI/USB pass-through

4.2.5.1.6. Lab with KVM-XEN (QEMU) in distributed environment

4.2.5.2. Container

4.2.5.3. OpenStack Nova

4.2.5.3.1. Architecture/Functional scope

4.2.5.3.2. Deployment models (practice with DevStack)

4.2.5.3.3. Tuning

4.2.5.3.4. Scaling

4.2.5.3.5. Advance with KeyStone

4.2.5.3.6. Advance with Cinder

4.2.5.3.7. Advance with Neutron

4.2.6. Authentication/Authorization

4.2.6.1. LDAP (AD), Kerberos

4.2.6.2. Token

4.2.6.2.1. PKI/PKIz

4.2.6.2.2. Fernet

4.2.6.2.3. UUID token

4.2.6.3. Multi-factor authenticate

4.2.6.4. RBAC

4.2.6.5. OpenStack KeyStone

4.2.6.5.1. Architecture/Functional scope

4.2.6.5.2. Deployment models (practice with DevStack)

4.2.6.5.3. Tuning

4.2.6.5.4. Scaling

4.2.7. Fundamental about Linux

4.2.8. Fundamental about Distributed Computing

4.3. DevOps Technologies

4.3.1. Queue

4.3.1.1. Redis

4.3.1.2. Kafka

4.3.1.3. RabbitMQ

4.3.2. Configuration Management Tool

4.3.2.1. Ansible

4.3.2.2. Puppet

4.3.2.3. Chef

4.3.3. API

4.3.3.1. Languages

4.3.3.1.1. NodeJS

4.3.3.1.2. PHP

4.3.3.1.3. Golang

4.3.3.1.4. Java

4.3.3.1.5. Python

4.3.4. Architecture

4.3.4.1. MVC

4.3.4.2. Microservices

4.3.5. Convention

4.3.5.1. Code Convention

4.3.5.2. Git Flow

4.3.6. Documentation

4.3.6.1. System Document

4.3.6.2. API Documents

4.3.6.2.1. Swagger

4.3.6.2.2. Slate

4.3.6.3. User Guides

4.3.7. Testing

4.3.7.1. Functional Test

4.3.7.1.1. Unit Test

4.3.7.1.2. End-to-End Testing

4.3.7.2. Performance Test

4.3.7.2.1. Gatling

4.3.7.2.2. Jmeter

4.3.7.2.3. Locustio

4.3.8. Databases

4.3.8.1. SQL

4.3.8.1.1. MySQL

4.3.8.1.2. MariaDB

4.3.8.1.3. Postgres

4.3.8.2. NoSQL

4.3.8.2.1. MongoDB

4.3.8.2.2. Cassandra

4.3.8.2.3. ElasticSearch

4.3.9. Monitoring system

4.3.9.1. Nagios

4.3.9.2. Munin

4.3.9.3. TIG, ...

4.3.10. Logging system

4.3.10.1. ELK

4.3.10.2. Sentry

4.3.11. Load balancer

4.3.11.1. Nginx

4.3.11.2. HAProxy

4.3.12. CI/CD

4.3.12.1. GItlab CI

4.3.12.2. Jenkins

4.3.12.3. Fabric

4.3.13. Infrastructure

4.3.13.1. Docker

4.3.13.1.1. Clustering

4.3.13.2. VM

4.3.13.2.1. Virtualbox

4.3.13.2.2. Vagrant

4.3.13.3. Cloud Provider

4.3.13.3.1. AWS

4.3.13.3.2. Google

4.3.13.3.3. Azure

4.3.13.3.4. VPS

4.4. DevOps Intro

4.4.1. 3 Key principles

4.4.1.1. Flow: We want fast flow from left to right.

4.4.1.1.1. Accelerate Delivery of work from Dev to Operations to customers

4.4.1.1.2. Make Work Visible

4.4.1.1.3. Limit WIP

4.4.1.1.4. Reduce Batch Sizes

4.4.1.1.5. Reduce Number Of Handoffs

4.4.1.1.6. Continually Identify & Elevate Constraints

4.4.1.1.7. Eliminate Waste

4.4.1.2. Feedback. We want fast and constant feedback from right to left to achieve quality, reliability and safety.

4.4.1.2.1. Create safer systems of work by creating fast, frequent high quality information flow throughout the value stream and org

4.4.1.2.2. Complex Systems

4.4.1.3. Continual Learning and Experimentation

4.4.1.3.1. foster high trust culture, and scientific approach to Org improvement and risk taking as part of daily work

4.4.1.3.2. Learning Organization & Safety Culture

4.4.1.3.3. Build In Improvements of Daily work

4.4.1.3.4. Transform Local Discoveries into Global Improvements

4.4.1.3.5. Inject Resilience Patterns into Daily work

4.4.1.3.6. Leadership reinforcing a learning culture

4.4.2. Decreased Change Failure Rate

4.4.3. Genesis. Dev Ops is the result of applying trusted proven lean manufacturing principles of physical items to the technology/IT value stream.

4.4.3.1. Agile Manifesto

4.4.3.1.1. lightweigh values and principles- to address heavywigh SLDC processes like waterfall.

4.4.3.2. Agile Infrastructure

4.4.3.3. Continuous Delivery Movement

4.4.3.3.1. Pioneered by Jez Humble and David Farley

4.4.3.3.2. ability to get changes into production safely quickly and in a sustainable way

4.4.3.3.3. Key Tenets

4.4.3.4. Toyota Production System

4.4.3.4.1. Continuos Learning

4.4.3.4.2. Andon Chord

4.4.3.4.3. Work Important more important that the work itself

4.4.3.5. The Lean movement

4.4.3.5.1. Projects vs Products

4.4.3.5.2. Key Tenets:

4.4.3.5.3. Value Stream Mapping

4.4.3.5.4. Kanban Boards

4.4.4. Benefits

4.4.4.1. IT Improvements

4.4.4.1.1. More Reliability

4.4.4.1.2. Higher Throughput

4.4.4.2. Company Improvements

4.4.4.2.1. More productivity

4.4.4.2.2. Increased Market Share

4.4.4.2.3. More profitability

4.4.4.2.4. More Market Cap growth

4.4.5. Job of IT.

4.4.5.1. Deliver fast uniterupted flow of planned work that delivers value

4.4.5.2. minimizing impact and disruption

4.4.5.3. provide stable predictable and secure IT services

4.5. DevOps Learning

4.5.1. Module 1

4.5.1.1. Topic

4.5.1.1.1. DevOps Concepts, Source Code Management & OS Basics

4.5.1.2. Description

4.5.1.2.1. DevOps Concepts: *Understanding the DevOps Movement *The DevOps Lifecycle *Tools and Technologies

4.5.1.2.2. Source Code: *Introduction to Version Control Systems *Branching, Merge Conflicts & Resolution

4.5.1.2.3. OS Basics: *Understands Linux/Unix operating system *Basic shell scripting *Commands to monitor linux system performance *Understands TCP/IP and networking basics Firewall basics - Iptables

4.5.1.3. Links

4.5.1.3.1. LinkedIn

4.5.1.3.2. Udemy

4.5.2. Module 2

4.5.2.1. Topic

4.5.2.1.1. Continuous Improvement & Continuous Deployment

4.5.2.2. Description

4.5.2.2.1. *Installing Jenkins and the Jenkins Dashboards *Configuring Java & Maven in Jenkins to Build Job for Java Application with Maven *Configuring and Authenticating Source Code on GitHub *Configuring Build Job and JUnit *The Dashboard View Plugin – Overview and Usage *Managing Nodes *Sending E-mail Notifications Based on build status *Integrating Jenkins and Sonar

4.5.2.3. Links

4.5.2.3.1. Udemy

4.5.3. Module 3

4.5.3.1. Topic

4.5.3.1.1. Containerization Platform

4.5.3.2. Description

4.5.3.2.1. Containers: *Understanding the Difference Between Virtual Machines and Containers *Installing and Configuring Docker on CentOS *Creating Your First Docker Container *Understanding the Client-Server Architecture of Docker *Managing Containers *Creating a Docker Image from Docker file

4.5.3.2.2. Kubernetes: *Kubernetes fundamentals *Kubernetes Installation/configuration *CI/CD for Kubernetes

4.5.3.3. Links

4.5.3.3.1. Udemy

4.5.4. Module 4

4.5.4.1. Topic

4.5.4.1.1. Cloud computing

4.5.4.2. Description

4.5.4.2.1. *Understanding Cloud Computing *AWS Basics *Azure Basics *GCP Essentials

4.5.4.3. Links

4.5.4.3.1. Udemy

4.5.5. Optional Topics

4.5.5.1. Using GitHub

4.5.5.1.1. Udemy : Git with github bootcamp

4.5.5.1.2. Udemy : GitHub Ultimate: Master Git and GitHub - Beginner to Expert

4.5.5.2. CI / CD using Docker

4.5.5.2.1. Udemy : Learn DevOps: CI/CD with Jenkins using Pipelines and Docker

4.5.5.3. Learn DevOps: Infrastructure Automation With Terraform

4.5.5.3.1. Udemy : Learning DevOps with Terraform Infrastructure Automation Course

4.5.5.4. Advanced Terraform

4.5.5.4.1. Udemy : HashiCorp Certified: Terraform Associate 2020

4.5.5.5. Advance Shell Scripting

4.5.5.5.1. Udemy : Linux Shell Scripting: Learning Projects for Beginners

4.5.5.6. Installing and Configuring Chef/Puppet (Optional in case your project uses it)

4.5.5.6.1. Udemy : Chef for the Absolute Beginners - DevOps

4.5.5.6.2. Udemy : Chef Fundamentals: A Recipe for Automating Infrastructure

4.5.5.6.3. Udemy : Puppet for the Absolute Beginners - Hands-on - DevOps

4.5.5.6.4. Udemy : Learning Path: Automation with Ansible, Puppet, and Salt

4.6. Essential DevOps Tools (www.schoolofdevops.com)

4.6.1. Configuration Management

4.6.1.1. Chef

4.6.1.1.1. berkshelf

4.6.1.1.2. chef delivery

4.6.1.1.3. Foodcritic

4.6.1.1.4. Rubocop

4.6.1.1.5. Chef DK

4.6.1.1.6. Chefspec

4.6.1.2. Puppet

4.6.1.2.1. Mcollective

4.6.1.2.2. Gepetto

4.6.1.2.3. r10k

4.6.1.3. Ansible

4.6.1.3.1. Ansible Tower

4.6.1.4. Saltstack

4.6.1.5. Cfengine

4.6.1.6. blueprint

4.6.1.7. juju

4.6.2. Continuous Integration / Deployment

4.6.2.1. Version Control (SCM)

4.6.2.1.1. Git

4.6.2.1.2. SVN

4.6.2.2. Deployment

4.6.2.2.1. Capistrano

4.6.2.2.2. Octopus Deploy

4.6.2.3. Integration

4.6.2.3.1. Jenkins/Hudson

4.6.2.3.2. Buildbot

4.6.2.3.3. Bamboo

4.6.2.3.4. Cruise Control

4.6.2.3.5. Rundeck

4.6.2.3.6. Travis CI

4.6.2.3.7. TeamCity

4.6.2.4. Artifacts

4.6.2.4.1. Artifactory

4.6.2.4.2. Nexus

4.6.2.5. Build

4.6.2.5.1. Gradle

4.6.2.5.2. Maven

4.6.3. Containers

4.6.3.1. Docker

4.6.3.1.1. Kubernetes

4.6.3.1.2. Mesos

4.6.3.1.3. CoreOS

4.6.3.1.4. Fig

4.6.3.1.5. Swarm

4.6.3.1.6. Docker Registry

4.6.3.1.7. Compose

4.6.3.2. OpenVZ

4.6.3.3. Rocket

4.6.4. Virtual Dev Environments

4.6.4.1. Vagrant

4.6.4.2. Packer

4.6.4.3. Veewee

4.6.5. Cloud

4.6.5.1. Private Cloud

4.6.5.1.1. Openstack

4.6.5.1.2. OpenNebula

4.6.5.1.3. Eucalyptus

4.6.5.2. Public Cloud

4.6.5.2.1. Amazon Web Services (AWS)

4.6.5.2.2. Google Compute Engine (GCE)

4.6.5.2.3. Microsoft Azure

4.6.5.2.4. Rackspace

4.6.5.2.5. Joyent

4.6.5.2.6. Digital Ocean

4.6.6. Monitoring

4.6.6.1. Nagios

4.6.6.2. Icinga

4.6.6.3. Sensu

4.6.6.4. Zenoss

4.6.6.5. Groundworks

4.6.6.6. Munin

4.6.6.7. Zabbix

4.6.6.8. Cacti

4.6.6.9. Observium

4.6.6.10. Cabot

4.6.6.11. Riemann

4.6.6.12. Bosun

4.6.7. Graphing and Visualization

4.6.7.1. New Relic

4.6.7.2. Ganglia

4.6.7.3. Graphite

4.6.7.4. Dynatrace

4.6.7.5. Dashing

4.6.8. Log Monitoring and Analysis

4.6.8.1. ELK Stack

4.6.8.1.1. Elasticsearch

4.6.8.1.2. Logstash

4.6.8.1.3. Kibana

4.6.8.2. Graylog2

4.6.8.3. Loggly

4.6.8.4. Splunk

4.6.8.5. Airbrake

4.6.8.6. rsyslog

4.6.9. Automated Testing

4.6.9.1. Junit

4.6.9.2. SonarQube

4.6.9.3. Infrastructure Testing

4.6.9.3.1. Serverspec

4.6.9.3.2. Test Kitchen

4.6.9.3.3. Cucumber

4.6.10. Service Discovery

4.6.10.1. etcd

4.6.10.1.1. skydns

4.6.10.2. consul

4.6.10.3. zookeeper

4.6.11. Sysops Utilities

4.6.11.1. Performance Analysis

4.6.11.1.1. ps

4.6.11.1.2. sar

4.6.11.1.3. top

4.6.11.1.4. iostat

4.6.11.1.5. memstat

4.6.11.1.6. vmstat

4.6.11.2. troubleshooting

4.6.11.2.1. lsos -i

4.6.11.2.2. nmon

4.6.11.2.3. iptraf

4.6.11.2.4. netstat

4.6.11.2.5. dig

4.6.11.2.6. nslookup

4.6.11.2.7. tcpdump

4.6.11.2.8. telnet

4.6.12. Scripting

4.6.12.1. bash

4.6.12.2. powershell

4.6.12.3. perl

4.6.12.4. python

4.6.12.5. ruby

4.6.13. Automated Provisioning

4.6.13.1. Foreman

4.6.13.2. Cobbler

4.6.13.3. Razor

4.7. DevOps Landscape

4.7.1. Process Basics

4.7.1.1. Focus on thinking like a "product" team, not a project team

4.7.1.1.1. project team

4.7.1.1.2. product team

4.7.1.1.3. product team

4.7.1.2. Developers make build

4.7.1.3. Run tests

4.7.1.3.1. app tests

4.7.1.3.2. infrastructure tests

4.7.1.4. promote build to staging

4.7.1.4.1. deploy on "cold" inf.

4.7.1.4.2. run all tests

4.7.1.5. production

4.7.1.5.1. re-route production to "cold" inf.

4.7.1.5.2. you can rollback to previous one

4.7.1.5.3. database upgrades

4.7.1.6. microservices

4.7.1.6.1. with microservices, you design things so that data upgrades are less of a problem

4.7.1.7. feedback collection

4.7.1.7.1. operational metrics to see if app is performing

4.7.1.7.2. business metrics to see if app is doing the right thing

4.7.2. Considerations

4.7.2.1. Find things that are unique or critical to DevOps

4.7.2.2. Not just programming and systems management constructs

4.7.3. Coding

4.7.3.1. IDEs

4.7.3.2. Languages

4.7.3.3. Frameworks

4.7.3.4. Middleware

4.7.3.5. Datastores

4.7.4. ALM tools

4.7.4.1. Project management

4.7.4.2. Bug tracking

4.7.4.3. Requirement tracking

4.7.4.4. Kanban board

4.7.5. Configuration & Release management

4.7.5.1. Automation tools

4.7.5.2. Packaging tools

4.7.6. Platforms

4.7.6.1. PaaS

4.7.6.2. IaaS

4.7.6.3. cluster management schemes

4.7.6.4. Plain old Linux

4.7.6.5. Operational middleware

4.7.6.5.1. Monitoring

4.7.6.5.2. things like caches, accelerators, stuff used in production?

4.7.7. Continious delivery

4.7.7.1. build

4.7.7.2. QA running

4.7.8. Feedback Analytics

5. Digital Transformation

5.1. "Digital Transformation" The US Version (02/17)

5.1.1. WHY

5.1.1.1. why do we need digital transformation

5.1.1.2. why digital transformation

5.1.1.3. why digital transformation needs a heart

5.1.1.4. why digital transformation should be a strategic priority

5.1.1.5. why digital transformation fails

5.1.1.6. why digital transformation matters

5.1.1.7. why digital transformation is important

5.1.2. WHAT

5.1.2.1. digital transformation what it is and how to get there

5.1.2.2. what is digital business transformation

5.1.2.3. what is a digital transformation manager

5.1.2.4. what does digital transformation mean

5.1.2.5. what digital transformation means for business

5.1.3. HOW

5.1.3.1. how do you define digital transformation

5.1.3.2. digital transformation how

5.1.3.3. how should csps approach digital transformation

5.1.3.4. how to achieve digital transformation

5.1.3.5. how to manage digital transformation

5.1.3.6. how to measure digital transformation

5.1.3.7. how digital is enabling transformation in life sciences

5.1.3.8. how digital transformation can innovate and creative

5.1.4. WHERE

5.1.4.1. digital transformation where to start

5.1.5. www.mind-mapping-decision.com

5.2. Digital Transformation Strategy

5.2.1. Techniques

5.2.1.1. Porters 5 Forces

5.2.1.1.1. Industry Rivalry

5.2.1.1.2. Supplier Power

5.2.1.1.3. Demand Power

5.2.1.1.4. Substitution

5.2.1.1.5. Barriers to entry

5.2.1.2. Resources/Capabillites

5.2.1.2.1. Imitability

5.2.1.2.2. Appropriated

5.2.1.2.3. Relevant

5.2.1.2.4. Durable

5.2.1.2.5. Architecture

5.2.1.2.6. Reputation

5.2.1.2.7. Innovation

5.2.1.3. Operational Models (POLISM)

5.2.1.3.1. Process

5.2.1.3.2. Organisation

5.2.1.3.3. Locations

5.2.1.3.4. IT

5.2.1.3.5. Suppliers

5.2.1.3.6. Management Systems

5.2.1.4. Value Chain Analysis

5.2.1.4.1. Each activity in the chain

5.2.1.4.2. What factors drive the cost

5.2.1.4.3. Benchmark against competition

5.2.1.4.4. Warley Value Chain Mapping

5.2.1.5. Business Context

5.2.1.5.1. Political

5.2.1.5.2. Economic

5.2.1.5.3. Social

5.2.1.5.4. Technical

5.2.1.5.5. Legal

5.2.1.5.6. Environment

5.2.2. Innovation

5.2.2.1. Process

5.2.2.2. Wide net

5.2.2.3. Challenges based on strategic needs

5.2.2.4. Open Innovation

5.2.2.5. Creating an energised change culture

5.2.2.6. Avoid progress traps

5.2.2.7. Test & realise benefits

5.2.2.8. Innovation that sustains or disrupts architecture/networks

5.2.3. Disruption

5.2.3.1. Disruption doesn't respect size or success

5.2.3.2. Belief in abundance is an illusion

5.2.3.3. Disruption Is a certainty

5.2.3.4. Progress can be a trap

5.2.3.5. Focusing on your customer could be counter productive.

5.2.3.6. Remaps the value chain and ecosystem

5.2.3.7. Digitising Analog Process is not enough

5.2.3.8. Could doesn't mean should.  Understand consequences

5.2.4. Qualities

5.2.4.1. Shared vales

5.2.4.2. Trust

5.2.4.3. Stakeholder engagement

5.2.4.4. Collaborative

5.2.4.5. Open

5.2.5. Lee Suker, Vaquita-Digital

6. Enterprise Architecture

6.1. EA Intro

6.1.1. Enterprise Architecture Model for Government Applications

6.1.1.1. EA Framework

6.1.1.2. Zachman Framework

6.1.1.3. Designing Applications E-Gov EA using the Zachman Framework

6.1.1.3.1. Objective and Scope

6.1.1.3.2. Enterprise Model

6.1.1.3.3. System Model

6.1.2. Updating The Enterpise Architecture Planning Model

6.1.2.1. The Need To Update EAP

6.1.2.2. Change To The EAP model

6.1.2.2.1. Planning Initiation

6.1.2.2.2. Business Modeling

6.1.2.2.3. Current Systems & Technology

6.1.2.2.4. Data Architecture

6.1.2.2.5. App Arch

6.1.2.3. The New EAP Model

6.1.3. Enterprise Architecture Modeling for Business and IT Alignment

6.1.3.1. Research Approach

6.1.3.2. Relevant Theories from the Problem Domains

6.1.3.2.1. Business and IT alignment

6.1.3.2.2. Participative Enterprise Modeling

6.1.3.3. Preliminary Results

6.1.3.3.1. EA Focal Areas in the Context of BITA (Relevant and Sufficient)

6.1.4. A Method to Define an Enterprise Architecture using the Zachman Framework

6.1.4.1. Method

6.1.4.1.1. Rules of Fulfilling

6.1.4.1.2. The Method: Step by Step

6.1.4.1.3. Anchor Cells

6.1.4.2. Tool

6.1.4.2.1. Information Repository

6.1.4.2.2. Proposed Artifacts Support

6.1.4.2.3. Multi-Dimensional Analysis

6.1.4.2.4. Alignment

6.1.5. Coherency Management: Using Enterprise Architecture for Alignment, Agility, and Assurance

6.1.5.1. Foundation Architecture

6.1.5.2. Extended Architecture

6.1.5.3. Embedded Architecture

6.1.5.4. ASSESSING ENTERPRISE COHERENCE

6.2. EA Frameworks

6.2.1. Contoh Framework

6.2.1.1. EAP

6.2.1.1.1. Initiation Planning

6.2.1.1.2. Preliminary business model

6.2.1.1.3. ; Enterprise survey

6.2.1.1.4. Current systems and technology architecture

6.2.1.1.5. Data architecture

6.2.1.1.6. Application architecture

6.2.1.1.7. Technology architecture

6.2.1.1.8. Implementation plan

6.2.1.1.9. Planning conclusion

6.2.1.1.10. Transition to implementation

6.2.1.2. TOGAF

6.2.1.2.1. Preliminary

6.2.1.2.2. Architecture vision

6.2.1.2.3. Business Architecture

6.2.1.2.4. IS Architecture

6.2.1.2.5. Technology Architecture

6.2.1.2.6. Opportunities and Solutions

6.2.1.2.7. Migration Planning

6.2.1.2.8. Implementation Governance

6.2.1.2.9. Architecture Change Management

6.2.1.3. DODAF

6.2.1.3.1. Capability

6.2.1.3.2. Data and Information

6.2.1.3.3. Operational

6.2.1.3.4. Project

6.2.1.3.5. Services

6.2.1.3.6. Standards

6.2.1.3.7. Systems

6.2.1.4. Gartner

6.2.1.4.1. Business Owners

6.2.1.4.2. Information Specialists

6.2.1.4.3. The Technology Implementers.

6.2.1.5. FEA

6.2.1.5.1. Architectural Analysis

6.2.1.5.2. Architectural Definition

6.2.1.5.3. Investment and Funding Strategy

6.2.1.5.4. Program-Management Plan and Execute Projects

6.2.2. Konsep SOA pada Enterprise Architecture (EA) Framework

6.2.2.1. SOA

6.2.2.1.1. Suatu cara untuk mengembangkan sistem dengan menyusun software agar layanan / function dapat saling terintegrasi

6.2.2.2. Service-Oriented Enterprise Architecture (SOEA)

6.2.2.2.1. Sinergi antara SOA dan EA yang memungkinkan keduanya untuk menyelesaikan satu sama lain agar lebih baik untuk mendukung kebutuhan bisnis

6.2.2.3. perspective SOA

6.2.2.3.1. The business perspective

6.2.2.3.2. The architecture perspective

6.2.2.3.3. The implementation perspective

6.2.2.4. Komponen SOA

6.2.2.4.1. The service directory

6.2.2.4.2. The service provider

6.2.2.4.3. The service requester that uses the service directory to find an appropriate service

6.2.2.5. Standart SOA

6.2.2.5.1. SOAP (Simple Object Access Protocol)

6.2.2.5.2. WSDL (Web Services Description Language)

6.2.2.5.3. UDDI (Universal Description, Discovery, and Integration)

6.2.3. Framework SOEA

6.2.3.1. Architectural layers

6.2.3.1.1. - Business Architecture

6.2.3.1.2. - Application architecture

6.2.3.1.3. - Infrastructure architecture

6.2.3.2. Proposed Project Phases

6.2.3.2.1. - Project Planning

6.2.3.2.2. - As-Is Architecture

6.2.3.2.3. - Analysis of As-Is Architecture

6.2.3.2.4. - To-Be Architecture

6.2.3.2.5. - Migration Plan

6.2.3.3. Project management recommendations

6.2.3.3.1. - Project Management Plan (PMP)

6.2.3.3.2. - Readiness Assessment

6.2.3.3.3. - Change Management and learning

6.2.3.3.4. - Portfolio of experts

6.2.4. Migrasi data dengan TOGAF

6.2.4.1. Metode pengembangan dari TOGAF dapat menyediakan kerangka kerja untuk mengatasi masalah migrasi data yang paling umum.

6.2.4.2. 4 Dimensi

6.2.4.2.1. Organizational dimension

6.2.4.2.2. Procedural standards

6.2.4.2.3. Business dimension

6.2.4.2.4. Technical dimension

6.2.4.3. 12 Phase

6.2.4.3.1. Project, quality and risk management

6.2.4.3.2. Migration strategy

6.2.4.3.3. Data analysis

6.2.4.3.4. Migration concept

6.2.4.3.5. Transformation definition

6.2.4.3.6. Program adaption

6.2.4.3.7. System preparation

6.2.4.3.8. Load and test

6.2.4.3.9. Approval

6.2.4.3.10. Productive migration

6.2.4.3.11. Data cleansing

6.2.5. Struktur untuk penyelarasan bisnis dan TI dalam perusahaan

6.2.6. Tujuan utama dari EA adalah untuk menyediakan sistem informasi yang tepat berdasarkan tuntutan bisnis perusahaan.

6.2.7. Jenis Pola Manajemen EA

6.2.7.1. Methodology Patterns (M-Pattern)

6.2.7.2. Viewpoint Patterns (V-Pattern)

6.2.7.3. Information Model Patterns (I-Pattern)

6.2.7.3.1. Business application

6.2.7.3.2. Business process

6.2.7.3.3. Business Support Migration

6.2.7.3.4. Business support provider

6.2.7.3.5. Introduction

6.2.7.3.6. Organizational unit

6.2.7.3.7. Project

6.2.7.3.8. Project task

6.2.7.3.9. Retirement

6.2.7.3.10. Support relationship

6.2.7.4. Anti-Pattern

6.3. Enterprise Architecture Fundamentals

6.3.1. Key Shifts from Fragile to Agile

6.3.2. Digital Transformation (DX)

6.3.3. Business Capability Model

6.3.3.1. First Iteration Level 1-2 of decomposition

6.3.3.2. Second Iteration adding 2-3 addition levels of decomposition, the Conceptual Data Model to the BCM (Separate artefact

6.3.3.3. Service Business Capability Model - add service container boundaries to the architectural level model and includes mapping the Logical Model to the BCM

6.3.3.4. Design Principles

6.3.3.4.1. What not how or who

6.3.3.4.2. Wholistic covering the complete business

6.3.3.4.3. Independent of a particular organizational or job design

6.3.3.4.4. Enterprise approaches are adopted

6.3.3.4.5. Generic design approaches are adopted

6.3.3.4.6. Maximum Depth of level 5

6.3.3.4.7. Planning and Design views

6.3.3.5. Capability Naming Standards

6.3.3.5.1. nouns not verbs, capability name only occurs once, use localized terminology

6.3.3.6. General Approach

6.3.3.6.1. gather information

6.3.3.6.2. pattern recognition

6.3.3.6.3. produce draft diagram

6.3.3.6.4. Map conceptual data model to the draft BCM

6.3.3.6.5. Issue draft diagram and review and reissue if changed

6.3.3.6.6. produce starting point capability descriptions

6.3.3.6.7. issue starting point capability descriptions to owners of capability and askthem to loalize it

6.3.3.6.8. update all descriptions based on the feedback

6.3.3.7. BCM Background

6.3.3.7.1. modular programming 80s

6.3.3.7.2. functional decomposition late 80/90s

6.3.3.7.3. component based development 90s/00s

6.3.4. Service Based Architecture

6.3.4.1. SOA/SBA Introduction

6.3.4.1.1. User Interface

6.3.4.1.2. Business Process Layer

6.3.4.1.3. Service Layer

6.3.4.1.4. Service Based

6.3.4.1.5. Solution Layer

6.3.4.1.6. Technology Layer

6.3.4.2. Benefits

6.3.4.2.1. faster time to market, reduced cost, business adaptability,

6.3.4.3. Business Process Management

6.3.4.3.1. discipline initial process design, implementation, control, analytics and improvement

6.3.4.3.2. BPMS - realtime visibility monitoring, optimization, e2e, auto and manual process

6.3.4.4. Case for BPM/SOA

6.3.4.5. Case studies

6.3.5. ABCD Technique

6.3.5.1. Background

6.3.5.2. Rationale: outcomes driven, lean principles, clear scope, traceable and realistic outcomes, multi disciplined team, collaboration.

6.3.5.3. 4 Places of Thought

6.3.5.3.1. Where are we now?

6.3.5.3.2. Where do we want to go?

6.3.5.3.3. What do we need to get there?

6.3.5.3.4. How do we make it happen?

6.3.5.4. ABCD Perspectives

6.3.5.4.1. A Issues, B outcomes used for

6.3.6. vision of where you want to go

6.3.7. Operating Model

6.3.7.1. How we will complete

6.3.7.1.1. Focus on Values and purpose of what you will and won't do - the guiding operating philosophies and principles

6.3.7.1.2. Competitive Triangle (Product, Service, Cost) - compete in 2 but not 3 ie: Apple

6.3.7.1.3. What is your Mission - Why, How & What Model

6.3.7.2. Operating Model

6.3.7.2.1. Replication - ie: Shake Shack same fanchise everywhere

6.3.7.2.2. Diversification - ie. Conglomerates of autonomous profit centers

6.3.7.2.3. Unifications - standard services Qantas, Dow Corning

6.3.7.2.4. Co-ordination - some capabilities are standardized across BUs others are unique ie. all Banks were forced to move from diversification to Co-ordination by regulators

6.3.7.3. Architecture Implications

6.3.7.4. Corporate Values

6.3.7.5. Value proposition

6.3.7.5.1. an innovation, service or product intended to make the org attractive to the market

6.3.7.6. Agile Including Operating Model

6.3.7.6.1. the organization must understand its operating model

6.3.7.7. Matrix of of Business Operating Model

6.3.8. enterprise architecture

6.3.8.1. Agile

6.3.8.1.1. Adaptable

6.3.8.1.2. Flexible

6.3.8.1.3. Responsive

6.3.8.2. Integrated Architecture Framework

6.3.8.2.1. Business Intent

6.3.8.2.2. Business Design

6.3.8.2.3. People Design

6.3.8.2.4. Technology Design

6.3.8.3. Business Capability Model

6.3.8.3.1. BPM Overview

6.3.8.4. Target State Solutions Architecture - what do we need to get there?

6.3.8.4.1. Strategic Planning/Roadmap Development Process

6.3.9. STP - straight through processing - process with no humans at all.

6.3.9.1. exception based - design as an STP and work queues for manual process.

6.3.10. EAs only ask what it is, and if its unknown and help facilitate the decision making process.

6.3.11. Centralized and Decentralized and different from standardization

6.3.12. Complex Event Processing

6.3.12.1. Inference processing: An event processing that process multiple simple observable events to identify meaningful complex events

7. Enterprise Security Architecture

7.1. Chapter 01: Enterprise Security Overview

7.1.1. The Idea and Facade of Enterprise Security

7.1.1.1. The History and Making of the Facade

7.1.1.2. The Idea of Security

7.1.1.2.1. What it is

7.1.1.2.2. What it should be

7.1.2. Enterprise Security Challenges

7.1.2.1. Shortcomings of Current Security Architecture

7.1.2.2. Communicating Information Security

7.1.2.3. The Cost of Information Security

7.1.2.4. The Conflicting Message of Information Security

7.1.3. Proving A Negative

7.1.4. The Roadmap to Securing the Enterprise

7.1.4.1. Roadmap Components

7.1.4.1.1. Defining Users

7.1.4.1.2. Defining Applications

7.1.4.1.3. Defining Data

7.1.4.1.4. Defining Roles

7.1.4.1.5. Defining Processes

7.1.4.1.6. Defining Policies and Standards

7.1.4.1.7. Defining Network Architecture

7.2. Chapter 02: Security Architectures

7.2.1. Redefining the Network Edge

7.2.1.1. Drivers for Redefinition

7.2.1.1.1. Feature Rich Web Apps

7.2.1.1.2. Business Partner Services

7.2.1.1.3. Misc 3rd Party Services

7.2.1.1.4. BYOX Management

7.2.1.1.5. Cloud Initiatives

7.2.2. Security Architecture Models

7.2.2.1. Defining Trust Model Building Blocks

7.2.2.1.1. Defining Data In A Trust Model

7.2.2.1.2. Defining Processes In A Trust Model

7.2.2.1.3. Defining Applications In A Trust Model

7.2.2.1.4. Defining Roles In A Trust Model

7.2.2.1.5. Defining Users In A Trust Model

7.2.2.1.6. Defining Policies and Standards

7.2.2.2. Enterprise Trust Models

7.2.2.2.1. Business Roles

7.2.2.2.2. IT Roles

7.2.2.3. Micro Architectures

7.2.2.4. Data Risk Centric Architectures

7.3. Chapter 03: Security As A Process

7.3.1. Risk Analysis

7.3.1.1. BYOx Initiatives

7.3.1.1.1. Bring Your Own Device

7.3.1.1.2. Bring Your Own PC

7.3.1.2. What is risk analysis?

7.3.1.2.1. Assessing Threats

7.3.1.2.2. Assessing Impact

7.3.1.2.3. Assessing Probability

7.3.1.2.4. Assessing Risk

7.3.1.3. Applying Risk Analysis To Trust Models

7.3.1.4. Deciding on A Risk Analysis Methodology

7.3.1.5. Other Thoughts on Risk and New Enterprise Endeavors

7.3.2. Policies and Standards

7.3.2.1. Understanding Proper Security Policy Development

7.3.2.2. Common Enterprise Security Policies

7.3.2.2.1. Information Security Policy

7.3.2.2.2. Acceptable Use Policy

7.3.2.2.3. Technology Use Policy

7.3.2.2.4. Remote Access Policy

7.3.2.2.5. Data Classification Policy

7.3.2.2.6. Data Handling Policy

7.3.2.2.7. Data Destruction Policy

7.3.2.2.8. Data Retention Policy

7.3.2.3. Policies for Emerging Technologies

7.3.2.3.1. Policy Considerations

7.3.2.3.2. Emerging Technology Challenges

7.3.2.4. Developing Enterprise Security Standards

7.3.2.4.1. Common IT Security Standards

7.3.3. Security Review of Changes

7.3.3.1. Perimeter Security

7.3.3.2. Data Access Changes

7.3.3.3. Network Architectural Changes

7.3.4. Security Exceptions

7.3.5. Vulnerability MGT

7.3.6. SDLC

7.3.7. Appendix

7.3.7.1. Resources for Risk Analysis

7.3.7.2. Resources for Policies and Standards

7.3.7.3. Resources for System Hardening

7.4. Chapter 04: Securing the Network

7.4.1. Overview of Securing the Network

7.4.2. Next Generation Firewalls

7.4.2.1. Benefits of the NGFW

7.4.2.1.1. Application Awareness

7.4.2.1.2. IPS

7.4.2.1.3. Advanced Malware Mitigation

7.4.3. Intrusion Detection and Prevention

7.4.3.1. Intrusion Detection

7.4.3.2. Intrusion Prevention

7.4.3.3. Detection Methods

7.4.3.3.1. Behavioural Analysis

7.4.3.3.2. Anomaly Detection

7.4.3.3.3. Signature-Based

7.4.4. Advanced Persistent Threat Detection and Mitigation

7.4.5. Securing Network Services

7.4.5.1. DNS

7.4.5.1.1. DNS Resolution

7.4.5.1.2. DNS Zone Transfer

7.4.5.1.3. DNS Records

7.4.5.1.4. DNSSEC

7.4.5.2. Email

7.4.5.2.1. SPAM Filtering

7.4.5.2.2. SPAM Relaying

7.4.5.3. File Transfer

7.4.5.3.1. Implementation Considerations

7.4.5.4. User Internet Access

7.4.5.5. Websites

7.4.5.5.1. Secure Coding

7.4.5.5.2. NGFW

7.4.5.5.3. IPS

7.4.5.5.4. Web App Firewall

7.4.5.5.5. Database Encryption

7.4.6. Network Segmentation

7.4.6.1. Network Segmentation Strategy

7.4.6.1.1. Asset Identification

7.4.6.1.2. Security Mechanisms

7.4.7. Applying Security Architecture to the Network

7.4.7.1. Security Architecture in the DMZ

7.4.7.2. Security Architecture in the Internal Network

7.4.7.3. Security Architecture and Network Segmentation

7.5. Chapter 05: Securing Systems

7.5.1. System Classification

7.5.1.1. Implementation Considerations

7.5.1.2. System Management

7.5.1.2.1. Asset Inventory Labels

7.5.1.2.2. System Patching

7.5.2. File Integrity Monitoring

7.5.2.1. FIM Implementation Challenges

7.5.2.2. Implementing File Integrity Monitoring

7.5.2.2.1. Real-time File Integrity Monitoring

7.5.2.2.2. Manual Mode File Integrity Monitoring

7.5.3. Application Whitelisting

7.5.3.1. Application Whitelisting Implementation Challenges

7.5.4. Host Intrusion Detection

7.5.4.1. Challenges to HIPS Implementation

7.5.5. Host Firewall

7.5.5.1. Challenges to Host Firewall Implementation

7.5.6. Anti-virus

7.5.6.1. Signature Based Anti-virus

7.5.6.2. Heuristic Anti-virus

7.5.6.3. Challenges of Anti-virus

7.5.7. User Account Management

7.5.7.1. User Roles and Permissions

7.5.7.2. User Account Auditing

7.5.8. Policy Enforcement

7.5.9. Summary

7.6. Chapter 06: Securing Data

7.6.1. Data Classification

7.6.1.1. Identifying Enterprise Data

7.6.1.1.1. Data Types

7.6.1.1.2. Data Locations

7.6.1.1.3. Automating Discovery

7.6.1.1.4. Assign Data Owners

7.6.1.2. Assign Data Classification

7.6.2. Data Loss Prevention

7.6.2.1. Data In Storage

7.6.2.2. Data In Use

7.6.2.3. Data In Transit

7.6.2.4. DLP Implementation

7.6.2.4.1. DLP Network

7.6.2.4.2. DLP Email and Web

7.6.2.4.3. DLP Discover

7.6.2.4.4. DLP Endpoint

7.6.3. Encryption and Hashing

7.6.3.1. Format Preserving Encryption

7.6.3.2. Key Management

7.6.3.3. Salting

7.6.3.4. Hashing

7.6.3.5. Encryption and Hashing Explained

7.6.3.5.1. Encryption

7.6.4. Tokenization

7.6.5. Data Masking

7.6.6. Authorization

7.6.7. Developing Supporting Processes

7.6.8. Summary

7.7. Chapter 07: Wireless Network Security

7.7.1. Security and Wireless Networks

7.7.2. Securing Wireless Networks

7.7.2.1. Unique SSID

7.7.2.2. Wireless Authentication

7.7.2.2.1. Shared Key

7.7.2.2.2. 802.1x

7.7.2.3. Wireless Encryption

7.7.2.3.1. WEP

7.7.2.3.2. WPA

7.7.2.3.3. WPA2

7.7.3. Wireless Network Implementation

7.7.3.1. Wireless Network Range

7.7.3.2. End System Configuration

7.7.3.3. Wireless Encryption and Authentication Recommendations

7.7.3.3.1. Client-Side Certificates

7.7.3.3.2. EAP-TLS

7.7.3.3.3. Unique System Check

7.7.4. Wireless Segmentation

7.7.4.1. Wireless Network Integration

7.7.5. Wireless Network Intrusion Prevention

7.7.6. Summary

7.8. Chapter 08: The Human Element of Security

7.8.1. Social Engineering

7.8.1.1. Electronic Communication Methods

7.8.1.1.1. SPAM Email

7.8.1.1.2. Social Media

7.8.1.2. In-Person Methods

7.8.1.2.1. Mitigating In-Person Methods

7.8.1.3. Phone Methods

7.8.1.3.1. Mitigating Phone Methods

7.8.1.4. Business Networking Sites

7.8.1.4.1. Mitigating Business Network Site Attacks

7.8.1.5. Job Posting Sites

7.8.1.5.1. Mitigating Job Posting Based Attacks

7.8.2. Security Awareness Training

7.8.2.1. Training Materials

7.8.2.1.1. Computer Based Training

7.8.2.1.2. Classroom Training

7.8.2.1.3. Associate Surveys

7.8.2.2. Common Knowledge

7.8.2.3. Specialized Material

7.8.2.4. Affective Training

7.8.2.5. Continued Education and Checks

7.8.3. Access Denied

7.8.4. Administrator Access

7.8.4.1. System Administrator

7.8.4.2. Data Administrator

7.8.4.3. Application Administrator

7.8.5. Physical Security

7.8.6. Conclusion

7.9. Chapter 09: Security Monitoring

7.9.1. Monitor Strategies

7.9.1.1. Monitoring Based on Trust Models

7.9.1.1.1. Data Monitoring

7.9.1.1.2. Process Monitoring

7.9.1.1.3. Application Monitoring

7.9.1.1.4. User Monitoring

7.9.1.2. Monitoring Based on Network Boundary

7.9.1.3. Monitoring Based on Network Segment

7.9.2. SIEM

7.9.3. Privileged User Access

7.9.3.1. Privileged Data Access

7.9.3.2. Privileged System Access

7.9.3.3. Privileged Application Access

7.9.4. Systems Monitoring

7.9.4.1. Operating System Monitoring

7.9.4.2. Host Intrusion Detection System

7.9.5. Network Security Monitoring

7.9.5.1. Next Generation Firewalls

7.9.5.2. Data Loss Prevention

7.9.5.3. Malware Detection and Analysis

7.9.5.4. Intrusion Prevention

7.9.6. SIEM

7.9.7. Predictive Behaviorial Analysis

7.9.8. Conclusion

7.10. Chapter 10: Security Incidents

7.10.1. Defining a Security Incident

7.10.1.1. Security Event Versus Incident

7.10.2. Developing Supporting Processes

7.10.2.1. Security Incident Detection and Determination

7.10.2.1.1. Physical Security Incidents

7.10.2.1.2. Network Based Security Incidents

7.10.3. Getting Enterprise Support

7.10.4. Building the Incident Response Team

7.10.5. Taking Action

7.10.5.1. In-house Incident Response

7.10.5.2. Contracted Incident Response

7.11. Chapter 11: Selling Security to the C-Suite

7.11.1. Enterprise Accounting Overview

7.11.2. Presenting the Case for Security

7.11.3. Strategies for Securing the Enterprise

7.12. Security As a Service

7.12.1. Penetration Testing

7.12.2. Identity and Access Administration

7.12.3. Security Event Management

7.12.4. Security Incident Response

8. Corporate Governance

8.1. COBIT 2019 Foundation

8.1.1. 1 Framework Introduction

8.1.1.1. Enterprise Governance of Information and Technology (EGIT)

8.1.1.1.1. Information and technology (I&T) is not limited to IT departments

8.1.1.1.2. Focus: I&T for enterprise risk management and value generation

8.1.1.1.3. EGIT is an integral part of corporate governance.

8.1.1.1.4. It is exercised by the board

8.1.1.2. Benefits of Information and Technology Governance

8.1.1.2.1. Three main outcomes can be expected after successful adoption of EGIT:

8.1.1.3. COBIT as an I&T Governance Framework

8.1.1.3.1. COBIT® has developed into a broader and more comprehensive I&T governance and management framework and continues to establish itself as a generally accepted framework for I&T governance.

8.1.1.4. What Is COBIT and What Is It Not?

8.1.1.4.1. What COBIT is:

8.1.1.4.2. What COBIT is not:

8.1.1.5. Intended Audience for COBIT

8.1.1.5.1. Internal Stakeholders

8.1.1.5.2. External Stakeholders

8.1.2. 2 Principles

8.1.2.1. Six Principles for a Governance System

8.1.2.1.1. 1. Provide Stakeholder Value

8.1.2.1.2. 2. Holistic Approach

8.1.2.1.3. 3. Dynamic Governance System

8.1.2.1.4. 4. Governance Distinct From Management

8.1.2.1.5. 5. Tailored to Enterprise Needs

8.1.2.1.6. 6. End-to-End Governance System

8.1.2.2. Three Principles for a Governance Framework

8.1.2.2.1. 1. Based on Conceptual Model

8.1.2.2.2. 2. Open and Flexible

8.1.2.2.3. 3. Aligned to Major Standards

8.1.3. 3 Governance System and Components

8.1.3.1. Governance and Management Objectives

8.1.3.1.1. Governance or management objective

8.1.3.1.2. Governance objective

8.1.3.1.3. The governance and management objectives in COBIT are grouped into five domains.

8.1.3.2. Components of the Governance System

8.1.3.2.1. Processes

8.1.3.2.2. Organizational structures

8.1.3.2.3. Principles, policies and frameworks

8.1.3.2.4. Information

8.1.3.2.5. Culture, ethics and behavior

8.1.3.2.6. People, skills and competencies

8.1.3.2.7. Services, infrastructure and applications

8.1.3.3. Focus Areas

8.1.3.3.1. describes a certain governance topic, domain or issue that can be addressed by a collection of governance and management objectives and their components.

8.1.3.3.2. Examples include: small and medium enterprises, cybersecurity, digital transformation, cloud computing, privacy, and DevOps.

8.1.3.4. Design Factors

8.1.3.4.1. are factors that can influence the design of an enterprise’s governance system and position it for success in the use of I&T.

8.1.3.4.2. Design factors include any combination of the following

8.1.3.5. Goals Cascade

8.1.3.5.1. IT Supports enterprise goals, which is one of the key design factors for a governance system

8.1.3.5.2. It supports prioritization of management objectives based on prioritization of enterprise goals.

8.1.3.5.3. COBIT Goals Cascade

8.1.4. 4 Governance and Management Objectives

8.1.4.1. Purpose of each 40 governance and management objectives.

8.1.4.1.1. Evaluate, Direct and Monitor (EDM)

8.1.4.1.2. Align, Plan and Organize (APO)

8.1.4.1.3. Build, Acquire and Implement (BAI)

8.1.4.1.4. Deliver, Service and Support (DSS)

8.1.4.1.5. Deliver, Service and Support (DSS)

8.1.4.1.6. Monitor, Evaluate and Assess (MEA)

8.1.5. 5 Performance Management

8.1.5.1. Definition of Performance management

8.1.5.1.1. represents a general term for all activities and methods.

8.1.5.1.2. expresses how well the governance and management system and all the components of an enterprise work, and how they can be improved to achieve the required level.

8.1.5.1.3. It includes concepts and methods such as capability levels and maturity levels.

8.1.5.1.4. COBIT uses the term COBIT performance management (CPM) to describe these activities, and the concept is an integral part of the COBIT framework.

8.1.5.2. COBIT Performance Management Principles

8.1.5.2.1. 1. The CPM should be simple to understand and use.

8.1.5.2.2. 2. The CPM should be consistent with, and support, the COBIT conceptual model.

8.1.5.2.3. 3. The CPM should provide reliable, repeatable and relevant results.

8.1.5.2.4. 4. The CPM must be flexible.

8.1.5.2.5. 5. The CPM should support different types of assessment,

8.1.5.3. COBIT Performance Management Overview

8.1.5.3.1. The CPM model (figure 6.1) largely aligns to and extends CMMI® Development V2.0 concepts:

8.1.5.4. Process Capability Levels

8.1.5.4.1. COBIT® 2019 supports a CMMI-based process capability scheme.

8.1.5.4.2. Ranging from 0 to 5.

8.1.5.5. Rating Process Activities

8.1.5.5.1. Fully

8.1.5.5.2. Largely

8.1.5.5.3. Partially

8.1.5.5.4. Not

8.1.5.6. Focus Area Maturity Levels

8.1.5.6.1. Maturity levels are associated with focus areas (i.e., a collection of governance and management objectives and underlying components) and a certain maturity level is achieved if all the processes contained in the focus area achieve that particular capability level.

8.1.5.7. Performance Management of Information Items

8.1.5.7.1. Information Quality Criteria

8.1.6. 6 Designing a Tailored Governance System

8.1.6.1. Impact of Design Factors

8.1.6.1.1. 1. Management Objective Priority and Target Capability Levels

8.1.6.1.2. 2. Component Variations

8.1.6.1.3. 3. Need for Specific Focus Areas

8.1.6.2. Stages and Steps in the Design Process

8.1.6.2.1. Figure 7.2 illustrates the proposed flow for designing a tailored governance system.

8.1.7. 7 Business Case

8.1.7.1. Business Case

8.1.7.1.1. Common business practice dictates preparing a business case to analyze and justify the initiation of a large project and/or financial investment.

8.1.7.2. Structure recommended

8.1.7.2.1. Executive Summary

8.1.7.2.2. Background

8.1.7.2.3. Business Challenges

8.1.7.2.4. Gap Analysis and Goal

8.1.7.2.5. Alternatives Considered

8.1.7.2.6. Proposed Solution

8.1.8. 8 Implementation

8.1.8.1. COBIT Implementation Approach

8.2. COBIT 2019 implementation

8.2.1. 7. How to keep the momentum gooing

8.2.2. 1. Introduction

8.2.2.1. EGIT - Enterprise Governance for I&T

8.2.2.1.1. Outcomes of adoption of EGIT

8.2.2.1.2. Distinction between Governance & Mgmt

8.2.3. 2. COBIT Principles

8.2.3.1. Distinction between Governance System and Gov Framework

8.2.3.1.1. Gov System

8.2.3.1.2. Gov Framework

8.2.4. 3. Governance and Management Objectives

8.2.4.1. Consists of Process and Componenets

8.2.4.1.1. 40 Processes and 7 Components

8.2.4.2. Always relate to 1 process and a series of related components

8.2.4.3. Goverenance Objj relates to a Gov process. Mgmt Obj relates to a Mgmt process

8.2.4.3.1. Read through the GMOs for each Gov and Mgmt objectives from the guide - specifically pay attention to the focus areas of each

8.2.4.4. Gov Objectives - 5 : EDM - Evaluate, Direct, Monitor

8.2.4.5. Management Objectives - 35

8.2.4.5.1. APO (14 process) - Align, Plan and Organize

8.2.4.5.2. BAI (11) - Build, Acquire, Implement

8.2.4.5.3. DSS (6) - Deliver, Service and Support

8.2.4.5.4. MEA (4) - Monitor, Evaluate, Assess

8.2.4.6. Components

8.2.4.6.1. They satisfy governance, management objectives enterprises need to build systems

8.2.4.6.2. Components Interact with each other

8.2.4.6.3. 7 Components in all

8.2.5. 4. Design Factors

8.2.5.1. 11 Design factors in all

8.2.5.2. Enterprise Strategy

8.2.5.2.1. They are further classified in to 4 balance score card dimensions

8.2.5.3. Enterprise Goals

8.2.5.3.1. 13 EGs - Read through them from the manual

8.2.5.4. A couple of questions around the balance socre card will be asked

8.2.5.5. Risk Profile

8.2.5.5.1. Talks about the current risk profile of the enterprise - there are 19 different risk areas

8.2.5.6. I&T Related Issues

8.2.5.6.1. Talks about the possibility of any risk area that has turned in to an issue - 20 different issue profiles

8.2.5.7. Threat landscape

8.2.5.7.1. Normal, High

8.2.5.8. Compliance Requirements

8.2.5.8.1. high, Normal, Low - Talks about external compliance requirements that the enterprise has to adhere to

8.2.5.9. Role of IT

8.2.5.9.1. One question will be asked on this

8.2.5.9.2. Support - IT not critical for biz continuity

8.2.5.9.3. Factory - Immediate impact on biz cont when IT fails

8.2.5.9.4. Turnaround - IT seen as a driver for innovation but no impact on RUN

8.2.5.9.5. Strategic - Important for both Innovation and RUn

8.2.5.10. Sourcing model for IT

8.2.5.10.1. Outsourcing, Cloud, Insourced, Hybrid

8.2.5.11. IT Implementation methods

8.2.5.11.1. Agile, DevOps, Traditional, Hybrid

8.2.5.12. Technology adoption strategy

8.2.5.12.1. First Mover, Follwer, Slow adopter

8.2.5.13. Enterprise Size

8.2.5.13.1. Large, Small, Medium

8.2.6. 5. Goals Cascade

8.2.6.1. Is used to align Stakeholder Needs to Enterprise Goals to Alignment Goals to GMOs

8.2.6.2. Alignment Goals - Read about them from the manual

8.2.7. 6. Performance Management

8.2.7.1. Cobit has its own performance management system (Cobit Per Mgmet) based on CMMI5

8.2.7.2. Each GMO and Component has a capability score

8.2.7.2.1. score are from 0 -5

8.2.7.3. Each focus area (collection of GMOs / Components ) have a maturity score

8.2.7.3.1. The maturity score is same as the capability score if all the GMOs and components of the focus area have the same capability score

8.2.7.4. Measuring Subjective components

8.2.7.4.1. Some components such as Information, People, Culture cannot be measured objectively - they are measured subjectively. COBIT provides guidance on how they can be measured

8.2.8. 7 - Designing a tailored governance system

8.2.8.1. 3 factors impact design

8.2.8.1.1. Management Obj and priority

8.2.8.1.2. Specific focus areas

8.2.8.1.3. Component variations

8.2.8.2. Follows a 4 step process

8.2.8.2.1. 1. Understand enterprise context and strategy

8.2.8.2.2. 2. Determine initial scope of the governance system

8.2.8.2.3. 3. Refine the scope of the governance system

8.2.8.2.4. 4. Conclude the Gov System design

8.2.9. 8. Implementing Governance

8.2.9.1. 1. What are the drivers

8.2.9.2. 7 Stages of implementation

8.2.9.2.1. 2. Where are we now

8.2.9.2.2. 3. Where do we want to be

8.2.9.2.3. 4. What needs to be done

8.2.9.2.4. 5. How do we get there

8.2.9.2.5. 6. Did we get there

8.2.9.3. 3 rings of the roadmap

8.2.9.3.1. Program Roadmap (outermost ring)

8.2.9.3.2. Change enablement (Middle ring)

8.2.9.3.3. COntinous improvement (inner ring)

8.2.9.3.4. The seven stages are mapped to activities under each of these 3 rings

8.2.9.4. All the stages of 7 - Designing are mapped to the first 3 stages of implementation

8.2.10. 9. Business Case for Implementation

8.2.10.1. Business cases have the following sections

8.2.10.1.1. Executive Summary

8.2.10.1.2. Background

8.2.10.1.3. Business Challenges

8.2.10.1.4. Gap Analysis and Goal

8.2.10.1.5. Alternatives considered

8.2.10.1.6. Proposed SOlution

9. ITIL v3

9.1. ITIL V3 Core

9.1.1. Service Design

9.1.1.1. 1. Intro

9.1.1.2. 2. SM as a practice

9.1.1.2.1. What is service management?

9.1.1.2.2. What are services?

9.1.1.2.3. Functions and processes across the lifecycle

9.1.1.2.4. SD fundamentals

9.1.1.3. 3. SD principles

9.1.1.3.1. Goals

9.1.1.3.2. Identifying service requirements

9.1.1.3.3. Design activities

9.1.1.3.4. Design aspects

9.1.1.3.5. The subsequent design activities

9.1.1.3.6. Design constraints

9.1.1.3.7. SOA

9.1.1.3.8. Business Service Management

9.1.1.3.9. SD models

9.1.1.4. 4. SD processes

9.1.1.4.1. Service Catalogue Management

9.1.1.4.2. Service Level Management

9.1.1.4.3. Capacity Management

9.1.1.4.4. Availability Management

9.1.1.4.5. IT Service Continuity Management

9.1.1.4.6. Information Security Management

9.1.1.4.7. Supplier Management

9.1.1.5. 5. SD technology-related activities

9.1.1.5.1. Requirements engineernig

9.1.1.5.2. Data and Information management

9.1.1.5.3. Application Management

9.1.1.6. 6. Organizing for SD

9.1.1.6.1. Functional roles analysis

9.1.1.6.2. Activity analysis

9.1.1.6.3. Skills and attributes

9.1.1.6.4. Roles and responsibilities

9.1.1.7. 7. Technology considerations

9.1.1.7.1. SD tools

9.1.1.7.2. SM tools

9.1.1.8. 8. Implementing SD

9.1.1.8.1. Business Impact Analysis

9.1.1.8.2. Service Level Requirements

9.1.1.8.3. Risks to the servicess and processes

9.1.1.8.4. Implementing SD

9.1.1.8.5. Measurement of SD

9.1.1.9. 9. Challenges, CSFs and risks

9.1.1.9.1. Challenges

9.1.1.9.2. Risks

9.1.1.9.3. Untitled

9.1.2. Service Operation

9.1.2.1. 1. Intro

9.1.2.1.1. Achieve a desired steady state of managing services on a day to day basis

9.1.2.1.2. Focuses on the delivery and control process activities

9.1.2.1.3. V2 Service Support and Service Delivery Processes form a major part of this volume

9.1.2.2. 2. SM as a practice

9.1.2.2.1. What is service management?

9.1.2.2.2. What are services?

9.1.2.2.3. Functions and processes across the lifecycle

9.1.2.2.4. SO fundamentals

9.1.2.3. 3. SO Principles

9.1.2.3.1. Functions, groups, Teams, depts, and divisions

9.1.2.3.2. Achieving Balance in SO

9.1.2.3.3. Providing Service

9.1.2.3.4. Operation staff involvement in Service Design (SD) and Service Transition (ST)

9.1.2.3.5. Documentation

9.1.2.4. 4. Service Operation processes

9.1.2.4.1. Event Management

9.1.2.4.2. Incident Management

9.1.2.4.3. Request Fullfilment

9.1.2.4.4. Problem Management

9.1.2.4.5. Access Management

9.1.2.4.6. Operational activities of processes covered in other lifecycle phases

9.1.2.5. 5. Common Service Operation activities

9.1.2.5.1. Monitoring and control

9.1.2.5.2. IT Operations

9.1.2.5.3. Mainframe Management

9.1.2.5.4. Server Management and Support

9.1.2.5.5. Network Management

9.1.2.5.6. Storage and Archive

9.1.2.5.7. DB Administration

9.1.2.5.8. Directory services anagement

9.1.2.5.9. Desktop Support

9.1.2.5.10. Middleware Management

9.1.2.5.11. Internet/Web Management

9.1.2.5.12. Facilities and Data Centre Management

9.1.2.5.13. Information Security Management and Service Operation

9.1.2.5.14. Improvement of operational activities

9.1.2.6. 6. Organizing for Service Operation

9.1.2.6.1. Functions

9.1.2.6.2. Service Desk

9.1.2.6.3. Technical Management

9.1.2.6.4. IT Operations Management

9.1.2.6.5. Application Management

9.1.2.6.6. SO roles and responsibilities

9.1.2.6.7. SO Org. Structures

9.1.2.7. 7. Technology Considerations

9.1.2.7.1. Generic requirements

9.1.2.7.2. Event Management

9.1.2.7.3. Incident Management

9.1.2.7.4. Request Fulfillment

9.1.2.7.5. Problem Management

9.1.2.7.6. Access Management

9.1.2.7.7. Service Desk

9.1.2.8. 8. Implementing Service Operation

9.1.2.8.1. Managing Change in SO

9.1.2.8.2. SO and Project Management

9.1.2.8.3. Assesing and managnig risk in SO

9.1.2.8.4. Operational Staff in SD and ST

9.1.2.8.5. Planing and implementing SM technologies

9.1.2.9. 9. Challenges, CSFs, and Risks

9.1.2.9.1. Challenges

9.1.2.9.2. CSFs

9.1.2.9.3. Risks

9.1.2.10. AA Complementary Industry Guidance

9.1.2.10.1. COBIT

9.1.2.10.2. CMMI

9.1.2.10.3. BSC

9.1.2.10.4. QM

9.1.2.10.5. OSI Framework

9.1.2.11. AB Communication in SO

9.1.2.11.1. Routine operational communication

9.1.2.11.2. Communication between shifts

9.1.2.11.3. Performance reporting

9.1.2.11.4. Communication in projects

9.1.2.11.5. Communication in Changes

9.1.2.11.6. Communication in Exceptions

9.1.2.11.7. Communication in Emergencies

9.1.2.11.8. Communication with users and customers

9.1.2.12. AC Kepner and Tregoe

9.1.2.12.1. Defining the problem

9.1.2.12.2. Describing the problem

9.1.2.12.3. Establishing possible cause

9.1.2.12.4. Testing the most probable cause

9.1.2.12.5. Verifying the true cause

9.1.2.13. AD Ishikawa Diagrams

9.1.2.14. AE Detailed Description of Facilities Management

9.1.2.14.1. Building Management

9.1.2.14.2. Equipment hosting

9.1.2.14.3. Power Management

9.1.2.14.4. Environmental Conditioning and Alert Systems

9.1.2.14.5. Safety

9.1.2.14.6. Physical Access Control

9.1.2.14.7. Shipping and Receiving

9.1.2.14.8. Involvement in Contract Management

9.1.2.14.9. Maintenance

9.1.2.15. AF Physical Access Control

9.1.3. Service Transition

9.1.3.1. 1. Intro

9.1.3.2. 2. SM as a practice

9.1.3.2.1. What is service management?

9.1.3.2.2. What are services?

9.1.3.2.3. Functions and processes across the lifecycle

9.1.3.2.4. ST fundamentals

9.1.3.3. 3. ST principles

9.1.3.3.1. Principles supporting ST

9.1.3.3.2. Policies for ST

9.1.3.4. 4. ST processes

9.1.3.4.1. Transition planning and support

9.1.3.4.2. Change Management

9.1.3.4.3. Service Asset and Configuration Management

9.1.3.4.4. Release and Delpoyment Management

9.1.3.4.5. Service Validation and Testing

9.1.3.4.6. Evaluation

9.1.3.4.7. Knowledge Management

9.1.3.5. 5. ST common operation activities

9.1.3.5.1. Managing communications and commitment

9.1.3.5.2. Managing organization and stakeholder change

9.1.3.5.3. Stakeholder management

9.1.3.6. 6. Organizing for ST

9.1.3.6.1. Generic roles

9.1.3.6.2. Organiaztional context for transitioning a service

9.1.3.6.3. Organization models to support ST

9.1.3.6.4. ST relations with other lifecycle stages

9.1.3.7. 7. Technology considerations

9.1.3.7.1. Knowledge Management tools

9.1.3.7.2. Collaboration

9.1.3.7.3. Configuration Management System

9.1.3.8. 8. Implementnig ST

9.1.3.8.1. Stages of introducing ST

9.1.3.9. 9. Challenges, CSFs and risks

9.1.3.9.1. Challenges

9.1.3.9.2. CSFs

9.1.3.9.3. ST under difficult conditions

9.1.4. Continual Service Improvement

9.1.4.1. 1. Intro

9.1.4.2. 2. SM as a practice

9.1.4.2.1. What is service management?

9.1.4.2.2. What are services?

9.1.4.2.3. Functions and processes across the lifecycle

9.1.4.2.4. CSI fundamentals

9.1.4.3. 3. CSI Principles

9.1.4.3.1. CSI and organizational change

9.1.4.3.2. Ownership

9.1.4.3.3. Role definitions

9.1.4.3.4. External and internal drivers

9.1.4.3.5. SLM

9.1.4.3.6. The Deming Cycle

9.1.4.3.7. Service Measurement

9.1.4.3.8. Knowledge management

9.1.4.3.9. Benchmarks

9.1.4.3.10. Governance

9.1.4.3.11. Frameworks, models, standards and quality systems

9.1.4.4. 4. CSI Processes

9.1.4.4.1. The 7-Step improvement process

9.1.4.4.2. Service Reporting

9.1.4.4.3. Service Measurement

9.1.4.4.4. ROI for CSI

9.1.4.4.5. Business questions for CSI

9.1.4.4.6. SLM

9.1.4.5. 5. CSI methods and techniques

9.1.4.5.1. Methods and techniques

9.1.4.5.2. Assesments

9.1.4.5.3. Benchmarking

9.1.4.5.4. Measurement and reporting frameworks

9.1.4.5.5. The Deming Cycle

9.1.4.5.6. CSI and other SM processes

9.1.4.5.7. Summary

9.1.4.6. 6. Organizing for CSI

9.1.4.6.1. Roles and responsibilities that support CSI

9.1.4.6.2. The authority matrix

9.1.4.6.3. Summary

9.1.4.7. 7. Technology considerations

9.1.4.7.1. Tools to support CSI activities

9.1.4.7.2. Summary

9.1.4.8. 8. Implementing CSI

9.1.4.8.1. Critical considerations for implementing CSI

9.1.4.8.2. Where do I start?

9.1.4.8.3. Governance

9.1.4.8.4. CSI and organizational change

9.1.4.8.5. Communication strategy and plan

9.1.4.8.6. Summary

9.1.4.9. 9. Challenges, CSFs and risks

9.1.4.9.1. Challenges

9.1.4.9.2. Critical success factors

9.1.4.9.3. Risks

9.1.4.9.4. Summary

9.1.5. Service Strategy

9.1.5.1. 1. Overview

9.1.5.2. 2. Service Management as a practice

9.1.5.2.1. What is SM?

9.1.5.2.2. What are services?

9.1.5.2.3. The business process

9.1.5.2.4. Principles of SM

9.1.5.2.5. The Service Lifecycle

9.1.5.2.6. Functions and processes across the lifecycle

9.1.5.3. 3. Service strategy principles

9.1.5.3.1. Value creation

9.1.5.3.2. Service assets

9.1.5.3.3. Service provider types

9.1.5.3.4. Service structures

9.1.5.3.5. SS fundamentals

9.1.5.4. 4. Service Strategy

9.1.5.4.1. Define the market

9.1.5.4.2. Develop the offerings

9.1.5.4.3. Develop strategic assets

9.1.5.4.4. Prepare for execution

9.1.5.5. 5. Service economics

9.1.5.5.1. Financial management

9.1.5.5.2. ROI

9.1.5.5.3. Service Portfolio Management

9.1.5.5.4. Service Portfolio Management Methods

9.1.5.5.5. Demand Management

9.1.5.6. 6. Strategy and organization

9.1.5.6.1. Organizatioonal development

9.1.5.6.2. Organizational departmentalization

9.1.5.6.3. Organizational design

9.1.5.6.4. Organizational culture

9.1.5.6.5. Sourcing strategy

9.1.5.7. 7. Strategy, tactics and operations

9.1.5.7.1. Implementation through the lifecycle

9.1.5.7.2. Strategy and design

9.1.5.7.3. Strategy and operations

9.1.5.7.4. Strategy and improvement

9.1.5.8. 8. Technology and strategy

9.1.5.8.1. Service automation

9.1.5.8.2. Service interfaces

9.1.5.8.3. Tools for service strategy

9.1.5.9. 9. Challenges, CSFs and risks

9.1.5.9.1. Complexity

9.1.5.9.2. Coordination and control

9.1.5.9.3. Preserving value

9.1.5.9.4. Effectiveness in measurement

9.1.5.9.5. Risks

9.2. ITIL Framework

9.2.1. Service Strategy

9.2.1.1. Strategy Management for IT Services

9.2.1.1.1. Sub-Processes

9.2.1.1.2. Definitions

9.2.1.1.3. Roles | Responsibility

9.2.1.2. Service Portfolio Management

9.2.1.2.1. Sub-Processes

9.2.1.2.2. Definitions

9.2.1.2.3. Roles | Responsibility

9.2.1.3. Financial Management for IT Services

9.2.1.3.1. Sub-Processes

9.2.1.3.2. Definitions

9.2.1.3.3. Roles | Responsibility

9.2.1.4. Demand Management

9.2.1.4.1. Sub-Processes

9.2.1.4.2. Definitions

9.2.1.4.3. Roles | Responsibility

9.2.1.5. Business Relationship Management

9.2.1.5.1. Sub-Processes

9.2.1.5.2. Definition

9.2.1.5.3. Role | Responsibility

9.2.2. Service Design

9.2.2.1. Design Coordination

9.2.2.1.1. Sub-Processes

9.2.2.1.2. Definitions

9.2.2.1.3. Roles | Responsibility

9.2.2.2. Service Catalog Management

9.2.2.2.1. Sub-Processes

9.2.2.2.2. Definitions

9.2.2.2.3. Roles | Responsibility

9.2.2.3. Service Level Management

9.2.2.3.1. Sub-Processes

9.2.2.3.2. Definitions

9.2.2.3.3. Roles | Responsibility

9.2.2.4. Risk Management

9.2.2.4.1. Sub-Processes

9.2.2.4.2. Definitions

9.2.2.4.3. Roles | Responsibility

9.2.2.5. Capacity Management

9.2.2.5.1. Sub-Processes

9.2.2.5.2. Definitions

9.2.2.5.3. Roles | Responsibility

9.2.2.6. Availability Management

9.2.2.6.1. Sub-Processes

9.2.2.6.2. Definitions

9.2.2.6.3. Roles | Responsibility

9.2.2.7. IT Service Continuity Management

9.2.2.7.1. Sub-Processes

9.2.2.7.2. Definitions

9.2.2.7.3. Roles | Responsibility

9.2.2.8. Information Security Management

9.2.2.8.1. Sub-Processes

9.2.2.8.2. Definitions

9.2.2.8.3. Roles | Responsibility

9.2.2.9. Compliance Management

9.2.2.9.1. Sub-Processes

9.2.2.9.2. Definitions

9.2.2.9.3. Roles | Responsibility

9.2.2.10. Architecture Management

9.2.2.10.1. Sub-Processes

9.2.2.10.2. Definitions

9.2.2.10.3. Roles | Responsibility

9.2.2.11. Supplier Management

9.2.2.11.1. Sub-Processes

9.2.2.11.2. Definitions

9.2.2.11.3. Roles | Responsibility

9.2.3. Service Transition

9.2.3.1. Change Management

9.2.3.1.1. Sub-Processes

9.2.3.1.2. Definitions

9.2.3.1.3. Roles | Responsibility

9.2.3.2. Change Evaluation

9.2.3.2.1. Sub-Processes

9.2.3.2.2. Definitions

9.2.3.2.3. Roles | Responsibility

9.2.3.3. Project Management

9.2.3.3.1. Sub-Processes

9.2.3.3.2. Definitions

9.2.3.3.3. Roles | Responsibility

9.2.3.4. Application Development

9.2.3.4.1. Sub-Processes

9.2.3.4.2. Definitions

9.2.3.4.3. Roles | Responsibility

9.2.3.5. Release and Deployment Management

9.2.3.5.1. Sub-Processes

9.2.3.5.2. Definitions

9.2.3.5.3. Roles | Responsibility

9.2.3.6. Service Validation and Testing

9.2.3.6.1. Sub-Processes

9.2.3.6.2. Definitions

9.2.3.6.3. Roles | Responsibility

9.2.3.7. Service Asset and Configuration Management

9.2.3.7.1. Sub-Processes

9.2.3.7.2. Definitions

9.2.3.7.3. Roles | Responsibility

9.2.3.8. Knowledge Management

9.2.3.8.1. Sub-Processes

9.2.3.8.2. Definitions

9.2.3.8.3. Roles | Responsibility

9.2.4. Service Operation

9.2.4.1. Event Management

9.2.4.1.1. Sub-Processes

9.2.4.1.2. Definitions

9.2.4.1.3. Roles | Responsibility

9.2.4.2. Incident Management

9.2.4.2.1. Sub-Processes

9.2.4.2.2. Definitions

9.2.4.2.3. Roles | Responsibility

9.2.4.3. Request Fulfilment

9.2.4.3.1. Sub-Processes

9.2.4.3.2. Definitions

9.2.4.3.3. Roles | Responsibility

9.2.4.4. Access Management

9.2.4.4.1. Sub-Processes

9.2.4.4.2. Definitions

9.2.4.4.3. Roles | Responsibility

9.2.4.5. Problem Management

9.2.4.5.1. Sub-Processes

9.2.4.5.2. Definitions

9.2.4.5.3. Roles | Responsibility

9.2.4.6. IT Operations Control

9.2.4.6.1. Sub-Processes

9.2.4.6.2. Definitions

9.2.4.6.3. Roles | Responsibility

9.2.4.7. Facillities Management

9.2.4.7.1. No sub-processes are specified

9.2.4.7.2. No definitions are specified

9.2.4.7.3. Roles | Responsibility

9.2.4.8. Application Managment

9.2.4.8.1. No sub-processes are specified

9.2.4.8.2. Definitions

9.2.4.8.3. Roles | Responsibility

9.2.4.9. Technical Management

9.2.4.9.1. No sub-processes are specified

9.2.4.9.2. No definitions are specified

9.2.4.9.3. Roles | Responsibility

9.2.5. Continual Service Improvement (CSI)

9.2.5.1. Service Review

9.2.5.1.1. Sub-Processes

9.2.5.1.2. Definitions

9.2.5.1.3. Roles | Responsibility

9.2.5.2. Process Evaluation

9.2.5.2.1. Sub-Processes

9.2.5.2.2. Definitions

9.2.5.2.3. Roles | Responsibility

9.2.5.3. Definition of CSI Initiatives

9.2.5.3.1. Sub-Processes

9.2.5.3.2. Definitions

9.2.5.3.3. Roles | Responsibility

9.2.5.4. Monitoring of CSI Initiatives

9.2.5.4.1. Sub-Processes

9.2.5.4.2. Definitions

9.2.5.4.3. Roles | Responsibility

10. Microservices

10.1. Microservices Intro

10.1.1. architecture style for applications

10.1.1.1. composed of small services

10.1.1.1.1. easy to think of it as a bunch of "components" with RESTful APIs

10.1.1.1.2. tries to avoid centralized components

10.1.1.1.3. driven by cloud deployment options

10.1.1.1.4. cluster things that change together often

10.1.1.1.5. benefits

10.1.1.1.6. draw-backs

10.1.1.2. teams are orginized around "business function," or clusters of capabilities

10.1.1.2.1. each of these then becomes a "services" cluster

10.1.1.2.2. playing into Conway's Law

10.1.1.2.3. "you build it, you run it"

10.1.1.3. protocols and such

10.1.1.3.1. focuses on dumb pipes with smart end-points

10.1.1.3.2. RESTful

10.1.1.3.3. Lightweight messaging buses

10.1.1.4. decentralized

10.1.1.4.1. each running in it's own process

10.1.1.4.2. little programatic governance other than convetion

10.1.1.4.3. little central database

10.1.1.4.4. problems

10.1.1.5. using RESTful APIs to communicate with each other

10.1.1.6. lends self to containerization, it seems

10.1.1.7. probably needs to be stateless services

10.1.1.8. definitions

10.1.1.8.1. component

10.1.1.8.2. libraries

10.1.1.8.3. services

10.1.1.9. follow-up ideas

10.1.1.9.1. this is a way to describe doing RESTful API services

10.1.1.9.2. this is a way of describing The Amazon two pizza team, Google Platform Rant style

10.1.2. 12 Factor Apps

10.1.2.1. Codebase

10.1.2.1.1. There's a single codebase per applications

10.1.2.1.2. Many instances, of application

10.1.2.1.3. Each developer can deploy has a copy running on their "local developer environment"

10.1.2.1.4. Code used by multiple apps should be factored out to stand-along libraries, etc.

10.1.2.2. Dependency Management

10.1.2.2.1. Not depending on things being on your deploy envoirnment

10.1.2.2.2. Declaring the dependencies needed to the maximum

10.1.2.2.3. Using tools to suck in these dependencies

10.1.2.2.4. This mostly seems like a reaction to typeless systems

10.1.2.3. Configuration

10.1.2.3.1. All of the stuff that's different between deploys, mostly settings and such

10.1.2.3.2. Strictly stored seperatly from code

10.1.2.3.3. Use environment variables

10.1.2.4. Backing Services

10.1.2.4.1. Often third party services

10.1.2.4.2. Also "middleware" like databases and memcase

10.1.2.4.3. Treat access to remote backing services the same as access to local services

10.1.2.5. Build, release, run

10.1.2.5.1. The important part here is that configuration is all that's touched by release

10.1.2.5.2. build is compiling, building, etc.

10.1.2.5.3. release applies the instance specific configuration to the build

10.1.2.5.4. there is no revising of past builds, just making new builds

10.1.2.5.5. use a release management product that allows for easy rollbacks

10.1.2.6. [Stateless] Processes

10.1.2.6.1. Each process should be stateless, only using local memory or disk for "transactions," acting on data

10.1.2.6.2. Store state in database backing services

10.1.2.6.3. Don't use "sticky sessions," and instead use a backing service of memcache or Redis to store user sessions

10.1.2.7. Port Binding

10.1.2.7.1. A bit unclear about breadth of this one

10.1.2.7.2. Focus on binding a service to a URL, with port

10.1.2.7.3. This is basically a large part of "do microservices"

10.1.2.7.4. This implies that you not focus on deploying "inside" Tomcat or HTTPD, but instead of backing a URL (with port) with whatever you want

10.1.2.7.5. Once again, the configuration lets you swap this stuff in and out

10.1.2.8. Concurrency

10.1.2.8.1. with stateless, single process per [thingy], scale out works better

10.1.2.8.2. but, the DB then just need to scale?

10.1.2.8.3. This is kind of unclear, and seems to be a consequence of other things

10.1.2.9. Disposablity

10.1.2.9.1. Write processes so that they can be killed

10.1.2.9.2. Queues will return work to queue to be finished by others

10.1.2.9.3. "Crash only design"

10.1.2.10. Dev/prod parity

10.1.2.10.1. avoid using different backing services and implementations in development and production

10.1.2.10.2. introduces too much chance to break things

10.1.2.10.3. it used to be hard to use "heavy weight" production tools in development, now it's less hard

10.1.2.11. Logs

10.1.2.11.1. Each component is a process, right?

10.1.2.11.2. So, the process just writes its logs out to STDOUT

10.1.2.11.3. Not concerned with doing its own log files, log system, etc.

10.1.2.11.4. Use some log management things and feed that into stuff like Splunk

10.1.2.11.5. Remove "efficiency" of common logging as seen in Java, but so be it.

10.1.2.12. Admin processes

10.1.2.12.1. Sort of a style of doing admin tasks

10.1.2.12.2. Check out your copy of the code, configure it like production (so it uses all the backing services used in production), then update the DB...?

10.1.2.12.3. "Having console access to a production system is a critical administrative and debugging tool, and every major language/framework provides it. No excuses for sloppiness here."

10.1.2.13. Other stuff

10.1.2.13.1. A Java guy asking how this applies to Java, answers not too detailed

10.1.2.13.2. Hacker News thread

10.2. Microservices concept

10.2.1. Pattern language

10.2.1.1. Reusable solution to a problem occurring in a particular context

10.2.1.1.1. Name

10.2.1.1.2. Context

10.2.1.1.3. Problem

10.2.1.1.4. Forces

10.2.1.1.5. Solution

10.2.1.1.6. Resulting context

10.2.1.1.7. Related patterns

10.2.1.2. Great framework to describe and discuss about tech

10.2.2. What?

10.2.2.1. Microservices = SOA done right

10.2.3. When?

10.2.3.1. In the beginning (startup)?

10.2.3.1.1. You don't need it

10.2.3.1.2. It will slow you down

10.2.3.2. Later on?

10.2.3.2.1. You need it

10.2.3.2.2. Refactoring is painful

10.2.3.3. Microservices are necessary but insufficient

10.2.3.3.1. MS-based app arhitecture

10.2.3.3.2. Deployment

10.2.3.3.3. People

10.2.4. How?

10.2.4.1. Art of scalability

10.2.4.1.1. Scale by splitting different things (Y) - functional decomposition

10.2.4.1.2. Scale by splitting similar things (Z)

10.2.4.1.3. Horizontal duplication (X)

10.2.4.2. Partitioning

10.2.4.2.1. Partitioning strategies

10.2.4.2.2. How to enforce consistency without 2PC?

10.2.4.2.3. How many services?

10.2.4.2.4. Anti-pattern: distributed monolith

10.2.4.3. Deployment

10.2.4.3.1. Forces

10.2.4.3.2. Multiple service instances per host

10.2.4.3.3. Service per VM

10.2.4.3.4. Service per container

10.2.5. Monolithic

10.2.5.1. Simple to...

10.2.5.1.1. Develop

10.2.5.1.2. Test

10.2.5.1.3. Deploy

10.2.5.1.4. Scale

10.2.5.2. Long-term commitment to a tech stack

10.2.5.3. Successful applications have a habit of growing <=> big, complex monolithic apps

10.2.5.3.1. Not so simple anymore

10.2.5.3.2. Overloads your IDE and development

10.2.5.3.3. Agile dev and deployment becomes impossible

10.2.6. Why?

10.2.6.1. What's the deployment architecture?

10.2.6.2. Business must innovate faster <=> develop more complex higher-quality software faster

10.2.6.3. Benefits

10.2.6.3.1. Smaller, simpler apps

10.2.6.3.2. Scales development: develop, deploy, scale independently

10.2.6.3.3. Improve fault isolation

10.2.6.3.4. Eliminates long-term commitment to a single tech stack

10.2.6.4. Drawbacks

10.2.6.4.1. Complexity of developing a distributed system

10.2.6.4.2. Multiple DBs & transaction management

10.2.6.4.3. Complexity of testing a distributed system

10.2.6.4.4. Complexity of deploying and operating a distributed system

10.2.6.4.5. Developing and deploying features that span multiple services requires careful coordination

10.2.7. Chassis

10.2.7.1. Cross-cutting concerns

10.2.7.1.1. Time consuming

10.2.7.1.2. External configs

10.2.7.1.3. Logging

10.2.7.1.4. Service discovery

10.2.7.1.5. Circuit breakers

10.2.7.1.6. Health checks

10.2.7.1.7. Metrics

10.2.7.2. Framework that simplifies the initial setup

10.2.7.2.1. Spring Boot + Sprint Cloud

10.2.7.2.2. Dropwizard

10.2.8. Event-driven

10.2.8.1. Forces

10.2.8.1.1. Update data owned by multiple services

10.2.8.1.2. Join data owned by multiple services

10.2.8.1.3. Different storage requirements between services

10.2.8.1.4. DBs replicated and sharded for scalability

10.2.8.1.5. Loosely coupled services

10.2.8.2. Shared database

10.2.8.2.1. Benefits

10.2.8.2.2. Drawbacks

10.2.8.3. DB per service

10.2.8.3.1. Schema updates

10.2.8.3.2. Multi data center, distributed DB

10.2.8.3.3. Scalable

10.2.8.3.4. Approaches

10.2.8.3.5. Benefits

10.2.8.3.6. Drawbacks

10.2.8.4. Problems

10.2.8.4.1. Eventually consistent business logic?

10.2.8.4.2. Atomically update database and publish an event?

10.2.8.5. Options

10.2.8.5.1. Update and publish using 2PC

10.2.8.5.2. Transaction log tailing

10.2.8.5.3. Application created events

10.2.8.5.4. Event sourcing

10.2.9. Migrate from monolith

10.2.9.1. A Big Bang rewrite

10.2.9.2. Incremental rewrite

10.2.9.2.1. Stop digging

10.2.9.2.2. Split front-end and back-end

10.2.9.2.3. Extract services

10.3. Microservices Ecosystem

10.3.1. Aynchronous /Interservices communication in microservices

10.3.1.1. Rabbit MQ

10.3.1.2. Active MQ

10.3.2. sourceControl/Build

10.3.2.1. GIT

10.3.2.2. Maven

10.3.3. Config Server

10.3.4. Service Discovery

10.3.4.1. Eureka

10.3.4.2. Consul

10.3.5. Continuous Integration

10.3.5.1. Jenkins

10.3.6. Testing(BDD)

10.3.6.1. Cucumber

10.3.7. Database

10.3.7.1. SQL

10.3.7.1.1. MySql

10.3.7.2. Nosql

10.3.7.2.1. Mongodb

10.3.8. API Gateway

10.3.8.1. Zuul

10.3.9. Fault tolerance/Graceful degradation

10.3.9.1. Hystrix

10.3.10. Infra./deployment Automation

10.3.10.1. Kubernates

10.3.11. Docker

10.3.11.1. Registry

10.3.11.1.1. Library of images

10.3.11.2. Client

10.3.11.2.1. Docker pull

10.3.11.2.2. Docker build

10.3.11.2.3. Docker run

10.3.11.3. Host

10.3.11.3.1. Daemon

10.3.11.3.2. images

10.3.11.3.3. container

10.3.11.3.4. Daemon

10.3.12. Visualize logs

10.3.12.1. Kibana

10.3.12.2. Filestash

10.3.13. DSL

10.3.13.1. Apache Camel