My Repository 2


Get Started. It's Free
or sign up with your email address
My Repository 2 by Mind Map: My Repository 2

1. AWS

1.1. 1 Introduction to AWS

1.1.1. 1. Region 1. region is a named set of AWS resources in the same geographical area. 2. A region comprises at least two Availability Zones.

1.1.2. 2. AZ 1. Availability Zone is a distinct location within a region that is insulated from failures in other Availability Zones and 2. provides inexpensive, low-latency network connectivity to other Availability Zones in the same region.

1.1.3. 3. Deployment 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. 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 provides lowcost archival storage.

1.2.2. S3 4. key characteristics of s3 All objects have a URL. S3 can store unlimited amounts of data. S3 uses a REST (Representational State Transfer) Application Program Interface (API). 3. appropriates use cases for s3 Storing web content Storing backups for a relational database Storing logs for analytics 2. Objects are stored in buckets, and objects contain both data and metadata. 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 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 CloudWatch is a monitoring service for AWS Cloud resources and the applications organizations run on AWS. CloudWatch metrics provide hypervisor visible metrics.

1.5.2. 2. Auto Scaling 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. Auto Scaling Group default EC2 capacity (20) for new region. launches instances from an AMI specified in the launch configuration associated with the Auto Scaling group enforces a minimum number of instances in the min-size parameter of the Auto Scaling group. launch configurations May use instances Supported Plans Auto Scaling is designed to scale out based on an event like increased traffic while being cost effective when not needed. Auto Scaling responds to changing conditions by adding or terminating instances

1.5.3. ELB Websites behind ELB 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. When Amazon EC2 instances fail the requisite number of consecutive health checks, the load balancer stops sending traffic to the Amazon EC2 instance. ELB Health Checks A ping A connection attempt A page request Connection Draining When connection draining is enabled, the load balancer will stop sending requests to a deregistered or unhealthy instance attempt to complete in-flight requests until a connection draining timeout period is reached, which is 300 seconds by default. supported types of load balancer Internet-facing Internal HTTPS using SSL

1.6. 6 IAM

1.6.1. IAM Policies Service Name Action

1.6.2. IAM Security Features MFA

1.6.3. Actions Authorized by IAM Launching a Linux EC2 instance

1.6.4. EC2 roles Key rotation is not necessary.

1.6.5. temporary security tokens

1.7. 7 Databases and AWS

1.7.1. 1. Databases 1. DynamoDB 1. non-relational database 2. fully managed, fast, and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale. 3. DynamoDB tables 2. RDS 1. OLTP 2. RDS provides managed relational databases. 3. increase resiliency 4. RDS supports Microsoft SQL Server Enterprise edition and the license is available only under the BYOL model 5. MySQL 3. Redshift 1. best suited for traditional Online Analytics Processing (OLAP) transactions

1.7.2. 2. read replicas 1. to increase performance, use read replicas to scale out the database and thus maximize read performance 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. can be used to restore a complete copy of the database at a specific point in time 2. DB snapshots allow you to back up and recover your data

1.7.4. 4. Multi-AZ supported db engines 1. MS SQL Server, MySQL, Aurora, PostgreSQL, Oracle...

1.7.5. 5. database failover 1. Force a Multi-AZ failover from one Availability Zone to another by rebooting the primary instance using the Amazon RDS console. 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. Add a read replica DB instance, and configure the client’s application logic to use a read-replica. 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. 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. 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. 2. SQS visibility timeout 1. max 12 hours 2. default 30 sec 3. properties 1. Message ID 2. Body

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

1.8.3. 3. SNS 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. Publishers 2. Subscribers 3. Topics 1. ARN created

1.8.5. 1. Supported Protocols 1. HTTPS 2. AWS Lambda 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 Definitions TOGAF Enterprise Architecture Why do we need Enterprise Architecture? 1. Lower costs – development, maintenance, support 2. Reduced complexity 3. Reduced risk 4. Simpler to add new systems 5. Faster purchase and implementation What is an Architecture Framework? Def 1 Def 2 Core Concepts 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 Intro Overview Architecture Development Cycle Scoping the Architecture Architecture Development Cycle The ADM is iterative, over the whole process, between phases and within phases For each iteration of the ADM, a fresh decision must be taken as to These decisions should be based on a 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. Phases Preliminary Phase Phase A: Architecture Vision Phase B: Business Architecture Phase C: Information Systems Architecture Phase D: Technology Architecture Phase E: Opportunities and Solutions Phase F: Migration Planning Phase H: Architecture Change Management Requirements Management

2.1.3. Part 3: ADM Guidelines and Techniques 1. Applying Iteration to the ADM Iteration Cycles Classes of Architecture Engagement Approaches to Architecture Development 2. Applying the ADM at different Enterprise Levels Strategic Architectures (executive level) Segment Architectures (program or portfolio level) Capability Architectures 3. Security Architecture and the ADM How to adapt the ADM for security Accepted areas of concern for the security architect Typical security architecture artifacts 4. Using TOGAF to Define & Govern SOAs A style of architecture that looks at all the functions of the system as services. Services Using TOGAF for SOA 5. Architecture Principles Principle Components Qualities Two key domains inform the development and utilization of architecture: Example Set of Architecture Principles (BDAT) 6. Architecture Stakeholder Management Stakeholder Technique Approach to Stakeholder Management 7. Architecture Patterns A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in other 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. 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. 8. Business Scenarios Introduction Benefits of Business Scenarios Creating the Business Scenario Contents of a Business Scenario Contributions to the Business Scenario Business Scenarios and the TOGAF ADM Developing Business Scenarios Business Scenario Documentation Guidelines on Goals and Objectives 9. Gap Analysis Business domain gaps: Data domain gaps: Applications impacted, eliminated, or created Technologies impacted, eliminated, or created 10. Migration Planning Techniques Matries Tables 5. Business Value Assessment Technique 11. Interoperability Requirements Definitions Categories Enterprise Operating Model Refining Interoperability Determining Interoperability Requirements Reconciling Interoperability Requirements with Potential Solutions Summary 12. Business Transformation Readiness Assessment Introduction Recommended Activities Business Transformation Enablement Program (BTEP) Determine Readiness Factors Present Readiness Factors Assess Readiness Factors Readiness and Migration Planning Marketing the Implementation Plan 13. Risk Management Intro Risk Classification Risk Identification Initial Risk Assessment Risk Mitigation and Residual Risk Assessment Conduct Residual Risk Assessment Risk Monitoring and Governance (Phase G) Initial Risk Assessment 14. Capability-Based Planning Overview Capability-Based Planning Paradigm Concept of Capability-Based Planning Capabilities in an Enterprise Architecture Context Summary Old Links

2.1.4. Part 4: Architecture Content Framework Intro. 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 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. 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 Content Metamodel 1. Overview 2. Content Metamodel Vision and Concepts 3. Content Metamodel in Detail 4. Content Metamodel Extensions 5. Content Metamodel Entities 6. Content Metamodel Attributes 7. Metamodel Relationships Architectural Artifacts Classifications Artifacts Architecture Deliverables 1. Architecture Building Blocks 2. Architecture Contract 3. Architecture Definition Document 4. Architecture Principles 5. Architecture Repository 6. Architecture Requirements Specification 7. Architecture Roadmap 8. Architecture Vision 9. Business Principles, Business Goals, and Business Drivers 10. Capability Assessment 11. Communications Plan 12. Compliance Assessment 13. Implementation and Migration Plan 14. Implementation Governance Model 15. Organizational Model for Enterprise Architecture 16. Request for Architecture Work 17. Change Request 18. Requirements Impact Assessment 19. Solution Building Blocks 20. Statement of Architecture Work 21. Tailored Architecture Framework Building Blocks Characteristics A good building block has the following characteristics: Architecture Building Blocks Solution Building Blocks Building Block Specification Process in the ADM

2.1.5. Part 5: Enterprise Continuum and Tools Architecture Continuum Foundation Architecture Common Systems Architecture Industry Architecture Organization-Specific Architecture Architecture Repository Architecture SIB Reference Library Governance Log Solutions Continuum Foundation Solutions Common Systems Solutions Industry Solutions Organization-Specific Solutions Architecture Partitioning Reasons Architectural Landscape: Integration Risks: What is needed: Explanation

2.1.6. Part 6 TOGAF Reference Models Foundation Architecture: TRM Intro TRM SIB Integrated Information Infrastructure Reference Model) III-RM Boundaryless Information Flow

2.1.7. Part 7: Architecture Capability Framework Overview 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. Part VII: Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function. Establishing an Architecture Capability Can be supported by the TOGAF Architecture Development Method (ADM). Require the design of the four domain architectures Architecture Board Responsibilities Role Setting Up the Architecture Board Architecture Compliance Terminology Architecture Compliance Reviews Architecture Contracts Architecture Contracts are the joint agreements between development partners and sponsors on the: Successful implementation of these agreements will be delivered through effective architecture governance Architecture Governance Hierarchy of Governance: Characteristics of Governance Architecture Governance Framework Architecture Maturity Models Capability Maturity Models (CMMs) Architecture Skills Framework Provide a view of the competency levels required for specific roles Goals Enterprise Architecture Role and Skill Categories Enterprise Architecture Role and Skill Categories

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

2.2.1. ADM Input/Output & Steps 0 : Preliminary Inputs Outputs Steps A: Architecture Vision Inputs Outputs Steps B C D: Business/Information Systems/Technology Architecture Inputs Outputs Steps E: Opportuneties and Solutions Inputs Outputs Steps F: Migration Planning Inputs Outputs Steps G: Implementation Governance Inputs Outputs Steps H: Architecture Change Management Inputs Outputs Steps

2.2.2. ADM Objectives, Approach & Process Preliminary Objectives Approach steps A Architecture vision Objectives Approach Steps B. Business architecture Objectives Approach Steps C. Information systems Data Applications D. technology architecture Objectives Approach Process E. Opportunity/solutions Objectives Approach Steps F, Migration planning Objectives Steps G. Implementation governance Objectives Approach Steps Architecture requirements mgmg Objectives Approach H. Architecture change mgmt Objectives Approach Steps

2.2.3. Artifacts 0: Preliminary Principles Catalog A: Architecture Vision Stakeholder Map Matrix Value Chain Diagram Solution Concept Diagram B: Business Architecture Organization/Actor Catalog Driver/Goal/Objective Catalog Role Catalog Business Service/Function Catalog Location Catalog Process/Event/Control/Product Catalog Contract/Measure Catalog Business Interaction Matrix Actor/Role Matrix Business Footprint Diagram Business Service/Information Diagram Functional Decomposition Diagram Product Lifecycle Diagram Goal/Objective/Service Diagram Business Use-Case Diagram Organization Decomposition Diagram Process Flow Diagram Event Diagram C: Information Systems Architecture Data Application D: Technology Architecture Technology Standards Catalog Technology Portfolio Catalog Application/Technology Matrix Environments and Locations Diagram Platform Decomposition Diagram Processing Diagram Networked Computing/Hardware Diagram Communications Engineering Diagram E: Opportunities and Solutions Project Context Diagram Benefits Diagram

2.2.4. Summary Resources ADM Steps Reference Architectural Artifacts TOGAF 9 certification preparation advices & exam tips Togaf Modeling Exams Level 1 Level 2 TOGAF 9.2 brief Move to Modular Why ADM Vision and Business Phases Content Metamodel Summary

2.2.5. EA Operating Model

2.3. Exams

2.3.1. Part 1 Part 1 Exam Questions and Answers 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. مميزات يقدم أداء عالي ومتوافق مع جميع الألعاب، ويدعم عدد إطارات عالي، وبالإضافة لدعمه عدد كبير من برامج تحسين الأداء. تصميم جديد وواجهة مستخدم جديدة مشرقة والتعامل معها سهل. أعادة تصميم عدد كبير من البرامج لتعطي أداء أفضل. إمكانية ربط الهاتف مع نظام التشغيل والتحكم به. استقرار النظام وتوافقه مع أجهزة وقطع الكمبيوتر بشكل أفضل وأسرع. إضافة مساعدات إضافية وعدد كبير من الاختصارات لسهولة الوصول والتحكم بكل شيء في ويندوز 10. التحديثات المستمرة والتلقائية لنظام التشغيل، والتي تشكل تحديثات التطبيقات والتحديثات الأمنية المهمة. إضافة مساعد شخصي ذو ذكاء اصطناعي مفيد جدًا في حل المشاكل والتعامل مع البيانات والمعلومات.

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

3.2. Apple Mac

3.2.1. Mac OS 12 / 2021

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

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

3.3. Linux

3.3.1. التوزيعات Ubuntu 21 / 2021 Fedora 35 /2021 SUSE 4.0 / 2019

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

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

4. DevOps

4.1. DevOps Ecosystem

4.1.1. Product Life Cycle Continuous integration Jenkins Travis CI Circle CI Shippable Team Foundation Server Perforce Testing Plugins Configuration Management Chef Puppet CFEngine SaltStack Ansible Product Management Jira Basecamp Rally Pivotal Tracker Teamwork PM Daptiv Workfront (atTask) Version One Taiga Waffle Source Control Management Github Stash BitBucket Mercurial Subversion Google Project Hosting Perforce Gogs Git Lab

4.1.2. Managed Service Customer service desk Zendesk Zoho Support Freshdesk Scheduling & Incident management Pager Duty VictorOps Ops Genie Monitoring Boundary Data Dog Nagios Ruxit Stackify Scout Rollbar Security Auditing Evident.IO Tripwire Metasploit Nexpose Kali Nessus BeyondSaas Retina Core Insight Dome9 Alien Vault Alert Logic Analytics New Relic Librato Log Management Loggly Splunk ELK stack SumoLogic Logentries

4.2. DevOps Concept

4.2.1. Storage Architecture/Functional scope Fundamentals Traditional storage solution: SAN, NAS, DAS Distributed storage solution: NFS, GlusterFS, Lustree, DRBD. Practice: vSAN, vNAS, NFS, GlusterFS Access-layer storage solution: Block, Object, File Block Storage Ceph Object Storage OpenStack Swift

4.2.2. Infra Architecture Sizing Monitoring Monitoring metrics understanding Monitoring scope Monitoring solution Logging Profiling/Benchmarking Profiling metrics understanding Architecture Design Pattern DevOps mindset Upgrade/Update

4.2.3. Appliance Architecture Software Design Pattern specific in Cloud environment Event Sourcing/CQRS Circuit Breaker Retry CI/CD/Testing SOA/Micro-services DevOps Mindset Upgrade/Update

4.2.4. Networking IPv4/IPv6 Fundamentals OSI, TCP/IP DHCP/DNS Firewall (IPTables) Flat, Overlay (VLAN, VxLAN, GRE) Bridge, NAT QoS Routing Linux Bridge/OpenvSwitch Architecture/Functional scope Pros/Cons in Comparison Network Namespace Bonding/Teaming Veth Macvlan, Macvtap, Ipvlan, Tun/Tap Tunnels QoS Practice in KVM OpenStack Neutron Architecture/Functional scope Deployment models (practice with DevStack) Tuning Scaling

4.2.5. Virtualization Hypervisor Hypervisor type QEMU KVM XEN PCI/USB pass-through Lab with KVM-XEN (QEMU) in distributed environment Container OpenStack Nova Architecture/Functional scope Deployment models (practice with DevStack) Tuning Scaling Advance with KeyStone Advance with Cinder Advance with Neutron

4.2.6. Authentication/Authorization LDAP (AD), Kerberos Token PKI/PKIz Fernet UUID token Multi-factor authenticate RBAC OpenStack KeyStone Architecture/Functional scope Deployment models (practice with DevStack) Tuning Scaling

4.2.7. Fundamental about Linux

4.2.8. Fundamental about Distributed Computing

4.3. DevOps Technologies

4.3.1. Queue Redis Kafka RabbitMQ

4.3.2. Configuration Management Tool Ansible Puppet Chef

4.3.3. API Languages NodeJS PHP Golang Java Python

4.3.4. Architecture MVC Microservices

4.3.5. Convention Code Convention Git Flow

4.3.6. Documentation System Document API Documents Swagger Slate User Guides

4.3.7. Testing Functional Test Unit Test End-to-End Testing Performance Test Gatling Jmeter Locustio

4.3.8. Databases SQL MySQL MariaDB Postgres NoSQL MongoDB Cassandra ElasticSearch

4.3.9. Monitoring system Nagios Munin TIG, ...

4.3.10. Logging system ELK Sentry

4.3.11. Load balancer Nginx HAProxy

4.3.12. CI/CD GItlab CI Jenkins Fabric

4.3.13. Infrastructure Docker Clustering VM Virtualbox Vagrant Cloud Provider AWS Google Azure VPS

4.4. DevOps Intro

4.4.1. 3 Key principles Flow: We want fast flow from left to right. Accelerate Delivery of work from Dev to Operations to customers Make Work Visible Limit WIP Reduce Batch Sizes Reduce Number Of Handoffs Continually Identify & Elevate Constraints Eliminate Waste Feedback. We want fast and constant feedback from right to left to achieve quality, reliability and safety. Create safer systems of work by creating fast, frequent high quality information flow throughout the value stream and org Complex Systems Continual Learning and Experimentation foster high trust culture, and scientific approach to Org improvement and risk taking as part of daily work Learning Organization & Safety Culture Build In Improvements of Daily work Transform Local Discoveries into Global Improvements Inject Resilience Patterns into Daily work 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. Agile Manifesto lightweigh values and principles- to address heavywigh SLDC processes like waterfall. Agile Infrastructure Continuous Delivery Movement Pioneered by Jez Humble and David Farley ability to get changes into production safely quickly and in a sustainable way Key Tenets Toyota Production System Continuos Learning Andon Chord Work Important more important that the work itself The Lean movement Projects vs Products Key Tenets: Value Stream Mapping Kanban Boards

4.4.4. Benefits IT Improvements More Reliability Higher Throughput Company Improvements More productivity Increased Market Share More profitability More Market Cap growth

4.4.5. Job of IT. Deliver fast uniterupted flow of planned work that delivers value minimizing impact and disruption provide stable predictable and secure IT services

4.5. DevOps Learning

4.5.1. Module 1 Topic DevOps Concepts, Source Code Management & OS Basics Description DevOps Concepts: *Understanding the DevOps Movement *The DevOps Lifecycle *Tools and Technologies Source Code: *Introduction to Version Control Systems *Branching, Merge Conflicts & Resolution 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 Links LinkedIn Udemy

4.5.2. Module 2 Topic Continuous Improvement & Continuous Deployment Description *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 Links Udemy

4.5.3. Module 3 Topic Containerization Platform Description 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 Kubernetes: *Kubernetes fundamentals *Kubernetes Installation/configuration *CI/CD for Kubernetes Links Udemy

4.5.4. Module 4 Topic Cloud computing Description *Understanding Cloud Computing *AWS Basics *Azure Basics *GCP Essentials Links Udemy

4.5.5. Optional Topics Using GitHub Udemy : Git with github bootcamp Udemy : GitHub Ultimate: Master Git and GitHub - Beginner to Expert CI / CD using Docker Udemy : Learn DevOps: CI/CD with Jenkins using Pipelines and Docker Learn DevOps: Infrastructure Automation With Terraform Udemy : Learning DevOps with Terraform Infrastructure Automation Course Advanced Terraform Udemy : HashiCorp Certified: Terraform Associate 2020 Advance Shell Scripting Udemy : Linux Shell Scripting: Learning Projects for Beginners Installing and Configuring Chef/Puppet (Optional in case your project uses it) Udemy : Chef for the Absolute Beginners - DevOps Udemy : Chef Fundamentals: A Recipe for Automating Infrastructure Udemy : Puppet for the Absolute Beginners - Hands-on - DevOps Udemy : Learning Path: Automation with Ansible, Puppet, and Salt

4.6. Essential DevOps Tools (

4.6.1. Configuration Management Chef berkshelf chef delivery Foodcritic Rubocop Chef DK Chefspec Puppet Mcollective Gepetto r10k Ansible Ansible Tower Saltstack Cfengine blueprint juju

4.6.2. Continuous Integration / Deployment Version Control (SCM) Git SVN Deployment Capistrano Octopus Deploy Integration Jenkins/Hudson Buildbot Bamboo Cruise Control Rundeck Travis CI TeamCity Artifacts Artifactory Nexus Build Gradle Maven

4.6.3. Containers Docker Kubernetes Mesos CoreOS Fig Swarm Docker Registry Compose OpenVZ Rocket

4.6.4. Virtual Dev Environments Vagrant Packer Veewee

4.6.5. Cloud Private Cloud Openstack OpenNebula Eucalyptus Public Cloud Amazon Web Services (AWS) Google Compute Engine (GCE) Microsoft Azure Rackspace Joyent Digital Ocean

4.6.6. Monitoring Nagios Icinga Sensu Zenoss Groundworks Munin Zabbix Cacti Observium Cabot Riemann Bosun

4.6.7. Graphing and Visualization New Relic Ganglia Graphite Dynatrace Dashing

4.6.8. Log Monitoring and Analysis ELK Stack Elasticsearch Logstash Kibana Graylog2 Loggly Splunk Airbrake rsyslog

4.6.9. Automated Testing Junit SonarQube Infrastructure Testing Serverspec Test Kitchen Cucumber

4.6.10. Service Discovery etcd skydns consul zookeeper

4.6.11. Sysops Utilities Performance Analysis ps sar top iostat memstat vmstat troubleshooting lsos -i nmon iptraf netstat dig nslookup tcpdump telnet

4.6.12. Scripting bash powershell perl python ruby

4.6.13. Automated Provisioning Foreman Cobbler Razor

4.7. DevOps Landscape

4.7.1. Process Basics Focus on thinking like a "product" team, not a project team project team product team product team Developers make build Run tests app tests infrastructure tests promote build to staging deploy on "cold" inf. run all tests production re-route production to "cold" inf. you can rollback to previous one database upgrades microservices with microservices, you design things so that data upgrades are less of a problem feedback collection operational metrics to see if app is performing business metrics to see if app is doing the right thing

4.7.2. Considerations Find things that are unique or critical to DevOps Not just programming and systems management constructs

4.7.3. Coding IDEs Languages Frameworks Middleware Datastores

4.7.4. ALM tools Project management Bug tracking Requirement tracking Kanban board

4.7.5. Configuration & Release management Automation tools Packaging tools

4.7.6. Platforms PaaS IaaS cluster management schemes Plain old Linux Operational middleware Monitoring things like caches, accelerators, stuff used in production?

4.7.7. Continious delivery build QA running

4.7.8. Feedback Analytics

5. Digital Transformation

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

5.1.1. WHY why do we need digital transformation why digital transformation why digital transformation needs a heart why digital transformation should be a strategic priority why digital transformation fails why digital transformation matters why digital transformation is important

5.1.2. WHAT digital transformation what it is and how to get there what is digital business transformation what is a digital transformation manager what does digital transformation mean what digital transformation means for business

5.1.3. HOW how do you define digital transformation digital transformation how how should csps approach digital transformation how to achieve digital transformation how to manage digital transformation how to measure digital transformation how digital is enabling transformation in life sciences how digital transformation can innovate and creative

5.1.4. WHERE digital transformation where to start


5.2. Digital Transformation Strategy

5.2.1. Techniques Porters 5 Forces Industry Rivalry Supplier Power Demand Power Substitution Barriers to entry Resources/Capabillites Imitability Appropriated Relevant Durable Architecture Reputation Innovation Operational Models (POLISM) Process Organisation Locations IT Suppliers Management Systems Value Chain Analysis Each activity in the chain What factors drive the cost Benchmark against competition Warley Value Chain Mapping Business Context Political Economic Social Technical Legal Environment

5.2.2. Innovation Process Wide net Challenges based on strategic needs Open Innovation Creating an energised change culture Avoid progress traps Test & realise benefits Innovation that sustains or disrupts architecture/networks

5.2.3. Disruption Disruption doesn't respect size or success Belief in abundance is an illusion Disruption Is a certainty Progress can be a trap Focusing on your customer could be counter productive. Remaps the value chain and ecosystem Digitising Analog Process is not enough Could doesn't mean should.  Understand consequences

5.2.4. Qualities Shared vales Trust Stakeholder engagement Collaborative Open

5.2.5. Lee Suker, Vaquita-Digital

6. Enterprise Architecture

6.1. EA Intro

6.1.1. Enterprise Architecture Model for Government Applications EA Framework Zachman Framework Designing Applications E-Gov EA using the Zachman Framework Objective and Scope Enterprise Model System Model

6.1.2. Updating The Enterpise Architecture Planning Model The Need To Update EAP Change To The EAP model Planning Initiation Business Modeling Current Systems & Technology Data Architecture App Arch The New EAP Model

6.1.3. Enterprise Architecture Modeling for Business and IT Alignment Research Approach Relevant Theories from the Problem Domains Business and IT alignment Participative Enterprise Modeling Preliminary Results 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 Method Rules of Fulfilling The Method: Step by Step Anchor Cells Tool Information Repository Proposed Artifacts Support Multi-Dimensional Analysis Alignment

6.1.5. Coherency Management: Using Enterprise Architecture for Alignment, Agility, and Assurance Foundation Architecture Extended Architecture Embedded Architecture ASSESSING ENTERPRISE COHERENCE

6.2. EA Frameworks

6.2.1. Contoh Framework EAP Initiation Planning Preliminary business model ; Enterprise survey Current systems and technology architecture Data architecture Application architecture Technology architecture Implementation plan Planning conclusion Transition to implementation TOGAF Preliminary Architecture vision Business Architecture IS Architecture Technology Architecture Opportunities and Solutions Migration Planning Implementation Governance Architecture Change Management DODAF Capability Data and Information Operational Project Services Standards Systems Gartner Business Owners Information Specialists The Technology Implementers. FEA Architectural Analysis Architectural Definition Investment and Funding Strategy Program-Management Plan and Execute Projects

6.2.2. Konsep SOA pada Enterprise Architecture (EA) Framework SOA Suatu cara untuk mengembangkan sistem dengan menyusun software agar layanan / function dapat saling terintegrasi Service-Oriented Enterprise Architecture (SOEA) Sinergi antara SOA dan EA yang memungkinkan keduanya untuk menyelesaikan satu sama lain agar lebih baik untuk mendukung kebutuhan bisnis perspective SOA The business perspective The architecture perspective The implementation perspective Komponen SOA The service directory The service provider The service requester that uses the service directory to find an appropriate service Standart SOA SOAP (Simple Object Access Protocol) WSDL (Web Services Description Language) UDDI (Universal Description, Discovery, and Integration)

6.2.3. Framework SOEA Architectural layers - Business Architecture - Application architecture - Infrastructure architecture Proposed Project Phases - Project Planning - As-Is Architecture - Analysis of As-Is Architecture - To-Be Architecture - Migration Plan Project management recommendations - Project Management Plan (PMP) - Readiness Assessment - Change Management and learning - Portfolio of experts

6.2.4. Migrasi data dengan TOGAF Metode pengembangan dari TOGAF dapat menyediakan kerangka kerja untuk mengatasi masalah migrasi data yang paling umum. 4 Dimensi Organizational dimension Procedural standards Business dimension Technical dimension 12 Phase Project, quality and risk management Migration strategy Data analysis Migration concept Transformation definition Program adaption System preparation Load and test Approval Productive migration 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 Methodology Patterns (M-Pattern) Viewpoint Patterns (V-Pattern) Information Model Patterns (I-Pattern) Business application Business process Business Support Migration Business support provider Introduction Organizational unit Project Project task Retirement Support relationship 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 First Iteration Level 1-2 of decomposition Second Iteration adding 2-3 addition levels of decomposition, the Conceptual Data Model to the BCM (Separate artefact Service Business Capability Model - add service container boundaries to the architectural level model and includes mapping the Logical Model to the BCM Design Principles What not how or who Wholistic covering the complete business Independent of a particular organizational or job design Enterprise approaches are adopted Generic design approaches are adopted Maximum Depth of level 5 Planning and Design views Capability Naming Standards nouns not verbs, capability name only occurs once, use localized terminology General Approach gather information pattern recognition produce draft diagram Map conceptual data model to the draft BCM Issue draft diagram and review and reissue if changed produce starting point capability descriptions issue starting point capability descriptions to owners of capability and askthem to loalize it update all descriptions based on the feedback BCM Background modular programming 80s functional decomposition late 80/90s component based development 90s/00s

6.3.4. Service Based Architecture SOA/SBA Introduction User Interface Business Process Layer Service Layer Service Based Solution Layer Technology Layer Benefits faster time to market, reduced cost, business adaptability, Business Process Management discipline initial process design, implementation, control, analytics and improvement BPMS - realtime visibility monitoring, optimization, e2e, auto and manual process Case for BPM/SOA Case studies

6.3.5. ABCD Technique Background Rationale: outcomes driven, lean principles, clear scope, traceable and realistic outcomes, multi disciplined team, collaboration. 4 Places of Thought Where are we now? Where do we want to go? What do we need to get there? How do we make it happen? ABCD Perspectives A Issues, B outcomes used for

6.3.6. vision of where you want to go

6.3.7. Operating Model How we will complete Focus on Values and purpose of what you will and won't do - the guiding operating philosophies and principles Competitive Triangle (Product, Service, Cost) - compete in 2 but not 3 ie: Apple What is your Mission - Why, How & What Model Operating Model Replication - ie: Shake Shack same fanchise everywhere Diversification - ie. Conglomerates of autonomous profit centers Unifications - standard services Qantas, Dow Corning 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 Architecture Implications Corporate Values Value proposition an innovation, service or product intended to make the org attractive to the market Agile Including Operating Model the organization must understand its operating model Matrix of of Business Operating Model

6.3.8. enterprise architecture Agile Adaptable Flexible Responsive Integrated Architecture Framework Business Intent Business Design People Design Technology Design Business Capability Model BPM Overview Target State Solutions Architecture - what do we need to get there? Strategic Planning/Roadmap Development Process

6.3.9. STP - straight through processing - process with no humans at all. 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 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 The History and Making of the Facade The Idea of Security What it is What it should be

7.1.2. Enterprise Security Challenges Shortcomings of Current Security Architecture Communicating Information Security The Cost of Information Security The Conflicting Message of Information Security

7.1.3. Proving A Negative

7.1.4. The Roadmap to Securing the Enterprise Roadmap Components Defining Users Defining Applications Defining Data Defining Roles Defining Processes Defining Policies and Standards Defining Network Architecture

7.2. Chapter 02: Security Architectures

7.2.1. Redefining the Network Edge Drivers for Redefinition Feature Rich Web Apps Business Partner Services Misc 3rd Party Services BYOX Management Cloud Initiatives

7.2.2. Security Architecture Models Defining Trust Model Building Blocks Defining Data In A Trust Model Defining Processes In A Trust Model Defining Applications In A Trust Model Defining Roles In A Trust Model Defining Users In A Trust Model Defining Policies and Standards Enterprise Trust Models Business Roles IT Roles Micro Architectures Data Risk Centric Architectures

7.3. Chapter 03: Security As A Process

7.3.1. Risk Analysis BYOx Initiatives Bring Your Own Device Bring Your Own PC What is risk analysis? Assessing Threats Assessing Impact Assessing Probability Assessing Risk Applying Risk Analysis To Trust Models Deciding on A Risk Analysis Methodology Other Thoughts on Risk and New Enterprise Endeavors

7.3.2. Policies and Standards Understanding Proper Security Policy Development Common Enterprise Security Policies Information Security Policy Acceptable Use Policy Technology Use Policy Remote Access Policy Data Classification Policy Data Handling Policy Data Destruction Policy Data Retention Policy Policies for Emerging Technologies Policy Considerations Emerging Technology Challenges Developing Enterprise Security Standards Common IT Security Standards

7.3.3. Security Review of Changes Perimeter Security Data Access Changes Network Architectural Changes

7.3.4. Security Exceptions

7.3.5. Vulnerability MGT

7.3.6. SDLC

7.3.7. Appendix Resources for Risk Analysis Resources for Policies and Standards 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 Benefits of the NGFW Application Awareness IPS Advanced Malware Mitigation

7.4.3. Intrusion Detection and Prevention Intrusion Detection Intrusion Prevention Detection Methods Behavioural Analysis Anomaly Detection Signature-Based

7.4.4. Advanced Persistent Threat Detection and Mitigation

7.4.5. Securing Network Services DNS DNS Resolution DNS Zone Transfer DNS Records DNSSEC Email SPAM Filtering SPAM Relaying File Transfer Implementation Considerations User Internet Access Websites Secure Coding NGFW IPS Web App Firewall Database Encryption

7.4.6. Network Segmentation Network Segmentation Strategy Asset Identification Security Mechanisms

7.4.7. Applying Security Architecture to the Network Security Architecture in the DMZ Security Architecture in the Internal Network Security Architecture and Network Segmentation

7.5. Chapter 05: Securing Systems

7.5.1. System Classification Implementation Considerations System Management Asset Inventory Labels System Patching

7.5.2. File Integrity Monitoring FIM Implementation Challenges Implementing File Integrity Monitoring Real-time File Integrity Monitoring Manual Mode File Integrity Monitoring

7.5.3. Application Whitelisting Application Whitelisting Implementation Challenges

7.5.4. Host Intrusion Detection Challenges to HIPS Implementation

7.5.5. Host Firewall Challenges to Host Firewall Implementation

7.5.6. Anti-virus Signature Based Anti-virus Heuristic Anti-virus Challenges of Anti-virus

7.5.7. User Account Management User Roles and Permissions User Account Auditing

7.5.8. Policy Enforcement

7.5.9. Summary

7.6. Chapter 06: Securing Data

7.6.1. Data Classification Identifying Enterprise Data Data Types Data Locations Automating Discovery Assign Data Owners Assign Data Classification

7.6.2. Data Loss Prevention Data In Storage Data In Use Data In Transit DLP Implementation DLP Network DLP Email and Web DLP Discover DLP Endpoint

7.6.3. Encryption and Hashing Format Preserving Encryption Key Management Salting Hashing Encryption and Hashing Explained 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 Unique SSID Wireless Authentication Shared Key 802.1x Wireless Encryption WEP WPA WPA2

7.7.3. Wireless Network Implementation Wireless Network Range End System Configuration Wireless Encryption and Authentication Recommendations Client-Side Certificates EAP-TLS Unique System Check

7.7.4. Wireless Segmentation 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 Electronic Communication Methods SPAM Email Social Media In-Person Methods Mitigating In-Person Methods Phone Methods Mitigating Phone Methods Business Networking Sites Mitigating Business Network Site Attacks Job Posting Sites Mitigating Job Posting Based Attacks

7.8.2. Security Awareness Training Training Materials Computer Based Training Classroom Training Associate Surveys Common Knowledge Specialized Material Affective Training Continued Education and Checks

7.8.3. Access Denied

7.8.4. Administrator Access System Administrator Data Administrator Application Administrator

7.8.5. Physical Security

7.8.6. Conclusion

7.9. Chapter 09: Security Monitoring

7.9.1. Monitor Strategies Monitoring Based on Trust Models Data Monitoring Process Monitoring Application Monitoring User Monitoring Monitoring Based on Network Boundary Monitoring Based on Network Segment

7.9.2. SIEM

7.9.3. Privileged User Access Privileged Data Access Privileged System Access Privileged Application Access

7.9.4. Systems Monitoring Operating System Monitoring Host Intrusion Detection System

7.9.5. Network Security Monitoring Next Generation Firewalls Data Loss Prevention Malware Detection and Analysis 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 Security Event Versus Incident

7.10.2. Developing Supporting Processes Security Incident Detection and Determination Physical Security Incidents Network Based Security Incidents

7.10.3. Getting Enterprise Support

7.10.4. Building the Incident Response Team

7.10.5. Taking Action In-house Incident Response 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 Enterprise Governance of Information and Technology (EGIT) Information and technology (I&T) is not limited to IT departments Focus: I&T for enterprise risk management and value generation EGIT is an integral part of corporate governance. It is exercised by the board Benefits of Information and Technology Governance Three main outcomes can be expected after successful adoption of EGIT: COBIT as an I&T Governance Framework 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. What Is COBIT and What Is It Not? What COBIT is: What COBIT is not: Intended Audience for COBIT Internal Stakeholders External Stakeholders

8.1.2. 2 Principles Six Principles for a Governance System 1. Provide Stakeholder Value 2. Holistic Approach 3. Dynamic Governance System 4. Governance Distinct From Management 5. Tailored to Enterprise Needs 6. End-to-End Governance System Three Principles for a Governance Framework 1. Based on Conceptual Model 2. Open and Flexible 3. Aligned to Major Standards

8.1.3. 3 Governance System and Components Governance and Management Objectives Governance or management objective Governance objective The governance and management objectives in COBIT are grouped into five domains. Components of the Governance System Processes Organizational structures Principles, policies and frameworks Information Culture, ethics and behavior People, skills and competencies Services, infrastructure and applications Focus Areas describes a certain governance topic, domain or issue that can be addressed by a collection of governance and management objectives and their components. Examples include: small and medium enterprises, cybersecurity, digital transformation, cloud computing, privacy, and DevOps. Design Factors are factors that can influence the design of an enterprise’s governance system and position it for success in the use of I&T. Design factors include any combination of the following Goals Cascade IT Supports enterprise goals, which is one of the key design factors for a governance system It supports prioritization of management objectives based on prioritization of enterprise goals. COBIT Goals Cascade

8.1.4. 4 Governance and Management Objectives Purpose of each 40 governance and management objectives. Evaluate, Direct and Monitor (EDM) Align, Plan and Organize (APO) Build, Acquire and Implement (BAI) Deliver, Service and Support (DSS) Deliver, Service and Support (DSS) Monitor, Evaluate and Assess (MEA)

8.1.5. 5 Performance Management Definition of Performance management represents a general term for all activities and methods. 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. It includes concepts and methods such as capability levels and maturity levels. COBIT uses the term COBIT performance management (CPM) to describe these activities, and the concept is an integral part of the COBIT framework. COBIT Performance Management Principles 1. The CPM should be simple to understand and use. 2. The CPM should be consistent with, and support, the COBIT conceptual model. 3. The CPM should provide reliable, repeatable and relevant results. 4. The CPM must be flexible. 5. The CPM should support different types of assessment, COBIT Performance Management Overview The CPM model (figure 6.1) largely aligns to and extends CMMI® Development V2.0 concepts: Process Capability Levels COBIT® 2019 supports a CMMI-based process capability scheme. Ranging from 0 to 5. Rating Process Activities Fully Largely Partially Not Focus Area Maturity Levels 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. Performance Management of Information Items Information Quality Criteria

8.1.6. 6 Designing a Tailored Governance System Impact of Design Factors 1. Management Objective Priority and Target Capability Levels 2. Component Variations 3. Need for Specific Focus Areas Stages and Steps in the Design Process Figure 7.2 illustrates the proposed flow for designing a tailored governance system.

8.1.7. 7 Business Case Business Case Common business practice dictates preparing a business case to analyze and justify the initiation of a large project and/or financial investment. Structure recommended Executive Summary Background Business Challenges Gap Analysis and Goal Alternatives Considered Proposed Solution

8.1.8. 8 Implementation COBIT Implementation Approach

8.2. COBIT 2019 implementation

8.2.1. 7. How to keep the momentum gooing

8.2.2. 1. Introduction EGIT - Enterprise Governance for I&T Outcomes of adoption of EGIT Distinction between Governance & Mgmt

8.2.3. 2. COBIT Principles Distinction between Governance System and Gov Framework Gov System Gov Framework

8.2.4. 3. Governance and Management Objectives Consists of Process and Componenets 40 Processes and 7 Components Always relate to 1 process and a series of related components Goverenance Objj relates to a Gov process. Mgmt Obj relates to a Mgmt process Read through the GMOs for each Gov and Mgmt objectives from the guide - specifically pay attention to the focus areas of each Gov Objectives - 5 : EDM - Evaluate, Direct, Monitor Management Objectives - 35 APO (14 process) - Align, Plan and Organize BAI (11) - Build, Acquire, Implement DSS (6) - Deliver, Service and Support MEA (4) - Monitor, Evaluate, Assess Components They satisfy governance, management objectives enterprises need to build systems Components Interact with each other 7 Components in all

8.2.5. 4. Design Factors 11 Design factors in all Enterprise Strategy They are further classified in to 4 balance score card dimensions Enterprise Goals 13 EGs - Read through them from the manual A couple of questions around the balance socre card will be asked Risk Profile Talks about the current risk profile of the enterprise - there are 19 different risk areas I&T Related Issues Talks about the possibility of any risk area that has turned in to an issue - 20 different issue profiles Threat landscape Normal, High Compliance Requirements high, Normal, Low - Talks about external compliance requirements that the enterprise has to adhere to Role of IT One question will be asked on this Support - IT not critical for biz continuity Factory - Immediate impact on biz cont when IT fails Turnaround - IT seen as a driver for innovation but no impact on RUN Strategic - Important for both Innovation and RUn Sourcing model for IT Outsourcing, Cloud, Insourced, Hybrid IT Implementation methods Agile, DevOps, Traditional, Hybrid Technology adoption strategy First Mover, Follwer, Slow adopter Enterprise Size Large, Small, Medium

8.2.6. 5. Goals Cascade Is used to align Stakeholder Needs to Enterprise Goals to Alignment Goals to GMOs Alignment Goals - Read about them from the manual

8.2.7. 6. Performance Management Cobit has its own performance management system (Cobit Per Mgmet) based on CMMI5 Each GMO and Component has a capability score score are from 0 -5 Each focus area (collection of GMOs / Components ) have a maturity score The maturity score is same as the capability score if all the GMOs and components of the focus area have the same capability score Measuring Subjective components 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 3 factors impact design Management Obj and priority Specific focus areas Component variations Follows a 4 step process 1. Understand enterprise context and strategy 2. Determine initial scope of the governance system 3. Refine the scope of the governance system 4. Conclude the Gov System design

8.2.9. 8. Implementing Governance 1. What are the drivers 7 Stages of implementation 2. Where are we now 3. Where do we want to be 4. What needs to be done 5. How do we get there 6. Did we get there 3 rings of the roadmap Program Roadmap (outermost ring) Change enablement (Middle ring) COntinous improvement (inner ring) The seven stages are mapped to activities under each of these 3 rings All the stages of 7 - Designing are mapped to the first 3 stages of implementation

8.2.10. 9. Business Case for Implementation Business cases have the following sections Executive Summary Background Business Challenges Gap Analysis and Goal Alternatives considered Proposed SOlution

9. ITIL v3

9.1. ITIL V3 Core

9.1.1. Service Design 1. Intro 2. SM as a practice What is service management? What are services? Functions and processes across the lifecycle SD fundamentals 3. SD principles Goals Identifying service requirements Design activities Design aspects The subsequent design activities Design constraints SOA Business Service Management SD models 4. SD processes Service Catalogue Management Service Level Management Capacity Management Availability Management IT Service Continuity Management Information Security Management Supplier Management 5. SD technology-related activities Requirements engineernig Data and Information management Application Management 6. Organizing for SD Functional roles analysis Activity analysis Skills and attributes Roles and responsibilities 7. Technology considerations SD tools SM tools 8. Implementing SD Business Impact Analysis Service Level Requirements Risks to the servicess and processes Implementing SD Measurement of SD 9. Challenges, CSFs and risks Challenges Risks Untitled

9.1.2. Service Operation 1. Intro Achieve a desired steady state of managing services on a day to day basis Focuses on the delivery and control process activities V2 Service Support and Service Delivery Processes form a major part of this volume 2. SM as a practice What is service management? What are services? Functions and processes across the lifecycle SO fundamentals 3. SO Principles Functions, groups, Teams, depts, and divisions Achieving Balance in SO Providing Service Operation staff involvement in Service Design (SD) and Service Transition (ST) Documentation 4. Service Operation processes Event Management Incident Management Request Fullfilment Problem Management Access Management Operational activities of processes covered in other lifecycle phases 5. Common Service Operation activities Monitoring and control IT Operations Mainframe Management Server Management and Support Network Management Storage and Archive DB Administration Directory services anagement Desktop Support Middleware Management Internet/Web Management Facilities and Data Centre Management Information Security Management and Service Operation Improvement of operational activities 6. Organizing for Service Operation Functions Service Desk Technical Management IT Operations Management Application Management SO roles and responsibilities SO Org. Structures 7. Technology Considerations Generic requirements Event Management Incident Management Request Fulfillment Problem Management Access Management Service Desk 8. Implementing Service Operation Managing Change in SO SO and Project Management Assesing and managnig risk in SO Operational Staff in SD and ST Planing and implementing SM technologies 9. Challenges, CSFs, and Risks Challenges CSFs Risks AA Complementary Industry Guidance COBIT CMMI BSC QM OSI Framework AB Communication in SO Routine operational communication Communication between shifts Performance reporting Communication in projects Communication in Changes Communication in Exceptions Communication in Emergencies Communication with users and customers AC Kepner and Tregoe Defining the problem Describing the problem Establishing possible cause Testing the most probable cause Verifying the true cause AD Ishikawa Diagrams AE Detailed Description of Facilities Management Building Management Equipment hosting Power Management Environmental Conditioning and Alert Systems Safety Physical Access Control Shipping and Receiving Involvement in Contract Management Maintenance AF Physical Access Control

9.1.3. Service Transition 1. Intro 2. SM as a practice What is service management? What are services? Functions and processes across the lifecycle ST fundamentals 3. ST principles Principles supporting ST Policies for ST 4. ST processes Transition planning and support Change Management Service Asset and Configuration Management Release and Delpoyment Management Service Validation and Testing Evaluation Knowledge Management 5. ST common operation activities Managing communications and commitment Managing organization and stakeholder change Stakeholder management 6. Organizing for ST Generic roles Organiaztional context for transitioning a service Organization models to support ST ST relations with other lifecycle stages 7. Technology considerations Knowledge Management tools Collaboration Configuration Management System 8. Implementnig ST Stages of introducing ST 9. Challenges, CSFs and risks Challenges CSFs ST under difficult conditions

9.1.4. Continual Service Improvement 1. Intro 2. SM as a practice What is service management? What are services? Functions and processes across the lifecycle CSI fundamentals 3. CSI Principles CSI and organizational change Ownership Role definitions External and internal drivers SLM The Deming Cycle Service Measurement Knowledge management Benchmarks Governance Frameworks, models, standards and quality systems 4. CSI Processes The 7-Step improvement process Service Reporting Service Measurement ROI for CSI Business questions for CSI SLM 5. CSI methods and techniques Methods and techniques Assesments Benchmarking Measurement and reporting frameworks The Deming Cycle CSI and other SM processes Summary 6. Organizing for CSI Roles and responsibilities that support CSI The authority matrix Summary 7. Technology considerations Tools to support CSI activities Summary 8. Implementing CSI Critical considerations for implementing CSI Where do I start? Governance CSI and organizational change Communication strategy and plan Summary 9. Challenges, CSFs and risks Challenges Critical success factors Risks Summary

9.1.5. Service Strategy 1. Overview 2. Service Management as a practice What is SM? What are services? The business process Principles of SM The Service Lifecycle Functions and processes across the lifecycle 3. Service strategy principles Value creation Service assets Service provider types Service structures SS fundamentals 4. Service Strategy Define the market Develop the offerings Develop strategic assets Prepare for execution 5. Service economics Financial management ROI Service Portfolio Management Service Portfolio Management Methods Demand Management 6. Strategy and organization Organizatioonal development Organizational departmentalization Organizational design Organizational culture Sourcing strategy 7. Strategy, tactics and operations Implementation through the lifecycle Strategy and design Strategy and operations Strategy and improvement 8. Technology and strategy Service automation Service interfaces Tools for service strategy 9. Challenges, CSFs and risks Complexity Coordination and control Preserving value Effectiveness in measurement Risks

9.2. ITIL Framework

9.2.1. Service Strategy Strategy Management for IT Services Sub-Processes Definitions Roles | Responsibility Service Portfolio Management Sub-Processes Definitions Roles | Responsibility Financial Management for IT Services Sub-Processes Definitions Roles | Responsibility Demand Management Sub-Processes Definitions Roles | Responsibility Business Relationship Management Sub-Processes Definition Role | Responsibility

9.2.2. Service Design Design Coordination Sub-Processes Definitions Roles | Responsibility Service Catalog Management Sub-Processes Definitions Roles | Responsibility Service Level Management Sub-Processes Definitions Roles | Responsibility Risk Management Sub-Processes Definitions Roles | Responsibility Capacity Management Sub-Processes Definitions Roles | Responsibility Availability Management Sub-Processes Definitions Roles | Responsibility IT Service Continuity Management Sub-Processes Definitions Roles | Responsibility Information Security Management Sub-Processes Definitions Roles | Responsibility Compliance Management Sub-Processes Definitions Roles | Responsibility Architecture Management Sub-Processes Definitions Roles | Responsibility Supplier Management Sub-Processes Definitions Roles | Responsibility

9.2.3. Service Transition Change Management Sub-Processes Definitions Roles | Responsibility Change Evaluation Sub-Processes Definitions Roles | Responsibility Project Management Sub-Processes Definitions Roles | Responsibility Application Development Sub-Processes Definitions Roles | Responsibility Release and Deployment Management Sub-Processes Definitions Roles | Responsibility Service Validation and Testing Sub-Processes Definitions Roles | Responsibility Service Asset and Configuration Management Sub-Processes Definitions Roles | Responsibility Knowledge Management Sub-Processes Definitions Roles | Responsibility

9.2.4. Service Operation Event Management Sub-Processes Definitions Roles | Responsibility Incident Management Sub-Processes Definitions Roles | Responsibility Request Fulfilment Sub-Processes Definitions Roles | Responsibility Access Management Sub-Processes Definitions Roles | Responsibility Problem Management Sub-Processes Definitions Roles | Responsibility IT Operations Control Sub-Processes Definitions Roles | Responsibility Facillities Management No sub-processes are specified No definitions are specified Roles | Responsibility Application Managment No sub-processes are specified Definitions Roles | Responsibility Technical Management No sub-processes are specified No definitions are specified Roles | Responsibility

9.2.5. Continual Service Improvement (CSI) Service Review Sub-Processes Definitions Roles | Responsibility Process Evaluation Sub-Processes Definitions Roles | Responsibility Definition of CSI Initiatives Sub-Processes Definitions Roles | Responsibility Monitoring of CSI Initiatives Sub-Processes Definitions Roles | Responsibility

10. Microservices

10.1. Microservices Intro

10.1.1. architecture style for applications composed of small services easy to think of it as a bunch of "components" with RESTful APIs tries to avoid centralized components driven by cloud deployment options cluster things that change together often benefits draw-backs teams are orginized around "business function," or clusters of capabilities each of these then becomes a "services" cluster playing into Conway's Law "you build it, you run it" protocols and such focuses on dumb pipes with smart end-points RESTful Lightweight messaging buses decentralized each running in it's own process little programatic governance other than convetion little central database problems using RESTful APIs to communicate with each other lends self to containerization, it seems probably needs to be stateless services definitions component libraries services follow-up ideas this is a way to describe doing RESTful API services this is a way of describing The Amazon two pizza team, Google Platform Rant style

10.1.2. 12 Factor Apps Codebase There's a single codebase per applications Many instances, of application Each developer can deploy has a copy running on their "local developer environment" Code used by multiple apps should be factored out to stand-along libraries, etc. Dependency Management Not depending on things being on your deploy envoirnment Declaring the dependencies needed to the maximum Using tools to suck in these dependencies This mostly seems like a reaction to typeless systems Configuration All of the stuff that's different between deploys, mostly settings and such Strictly stored seperatly from code Use environment variables Backing Services Often third party services Also "middleware" like databases and memcase Treat access to remote backing services the same as access to local services Build, release, run The important part here is that configuration is all that's touched by release build is compiling, building, etc. release applies the instance specific configuration to the build there is no revising of past builds, just making new builds use a release management product that allows for easy rollbacks [Stateless] Processes Each process should be stateless, only using local memory or disk for "transactions," acting on data Store state in database backing services Don't use "sticky sessions," and instead use a backing service of memcache or Redis to store user sessions Port Binding A bit unclear about breadth of this one Focus on binding a service to a URL, with port This is basically a large part of "do microservices" This implies that you not focus on deploying "inside" Tomcat or HTTPD, but instead of backing a URL (with port) with whatever you want Once again, the configuration lets you swap this stuff in and out Concurrency with stateless, single process per [thingy], scale out works better but, the DB then just need to scale? This is kind of unclear, and seems to be a consequence of other things Disposablity Write processes so that they can be killed Queues will return work to queue to be finished by others "Crash only design" Dev/prod parity avoid using different backing services and implementations in development and production introduces too much chance to break things it used to be hard to use "heavy weight" production tools in development, now it's less hard Logs Each component is a process, right? So, the process just writes its logs out to STDOUT Not concerned with doing its own log files, log system, etc. Use some log management things and feed that into stuff like Splunk Remove "efficiency" of common logging as seen in Java, but so be it. Admin processes Sort of a style of doing admin tasks 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...? "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." Other stuff A Java guy asking how this applies to Java, answers not too detailed Hacker News thread

10.2. Microservices concept

10.2.1. Pattern language Reusable solution to a problem occurring in a particular context Name Context Problem Forces Solution Resulting context Related patterns Great framework to describe and discuss about tech

10.2.2. What? Microservices = SOA done right

10.2.3. When? In the beginning (startup)? You don't need it It will slow you down Later on? You need it Refactoring is painful Microservices are necessary but insufficient MS-based app arhitecture Deployment People

10.2.4. How? Art of scalability Scale by splitting different things (Y) - functional decomposition Scale by splitting similar things (Z) Horizontal duplication (X) Partitioning Partitioning strategies How to enforce consistency without 2PC? How many services? Anti-pattern: distributed monolith Deployment Forces Multiple service instances per host Service per VM Service per container

10.2.5. Monolithic Simple to... Develop Test Deploy Scale Long-term commitment to a tech stack Successful applications have a habit of growing <=> big, complex monolithic apps Not so simple anymore Overloads your IDE and development Agile dev and deployment becomes impossible

10.2.6. Why? What's the deployment architecture? Business must innovate faster <=> develop more complex higher-quality software faster Benefits Smaller, simpler apps Scales development: develop, deploy, scale independently Improve fault isolation Eliminates long-term commitment to a single tech stack Drawbacks Complexity of developing a distributed system Multiple DBs & transaction management Complexity of testing a distributed system Complexity of deploying and operating a distributed system Developing and deploying features that span multiple services requires careful coordination

10.2.7. Chassis Cross-cutting concerns Time consuming External configs Logging Service discovery Circuit breakers Health checks Metrics Framework that simplifies the initial setup Spring Boot + Sprint Cloud Dropwizard

10.2.8. Event-driven Forces Update data owned by multiple services Join data owned by multiple services Different storage requirements between services DBs replicated and sharded for scalability Loosely coupled services Shared database Benefits Drawbacks DB per service Schema updates Multi data center, distributed DB Scalable Approaches Benefits Drawbacks Problems Eventually consistent business logic? Atomically update database and publish an event? Options Update and publish using 2PC Transaction log tailing Application created events Event sourcing

10.2.9. Migrate from monolith A Big Bang rewrite Incremental rewrite Stop digging Split front-end and back-end Extract services

10.3. Microservices Ecosystem

10.3.1. Aynchronous /Interservices communication in microservices Rabbit MQ Active MQ

10.3.2. sourceControl/Build GIT Maven

10.3.3. Config Server

10.3.4. Service Discovery Eureka Consul

10.3.5. Continuous Integration Jenkins

10.3.6. Testing(BDD) Cucumber

10.3.7. Database SQL MySql Nosql Mongodb

10.3.8. API Gateway Zuul

10.3.9. Fault tolerance/Graceful degradation Hystrix

10.3.10. Infra./deployment Automation Kubernates

10.3.11. Docker Registry Library of images Client Docker pull Docker build Docker run Host Daemon images container Daemon

10.3.12. Visualize logs Kibana Filestash

10.3.13. DSL Apache Camel