[Cybersecurity Architecture] TOGAF Knowledges Collection

TOGAF®, an Open Group standard, is a proven enterprise architecture methodology and framework used by the world's leading organizations to improve business efficiency. TOGAF® helps practitioners avoid being locked into proprietary methods, utilize resources more efficiently and effectively, and realize a greater return on investment.

TOGAF® is an industry-standard architecture framework that may be used freely by your organization to develop an information systems architecture. This is a highly interactive, BYOD course that requires classroom students to bring a notebook computer or tablet in order to access digital components of the courseware. Digital components include the ADM application, practice exams, module summary e-Learning content, and some course materials.

[Cybersecurity Architecture] 

• Risk Management
• TOGAF Knowledges Collection
• Governance Overview
• Architecture Practice
• Architecture Category
  
• Architecture Knowledge Overview

The TOGAF® Standard, 10th Edition makes adoption of best practices easier. It will show you where to find enduring and universal concepts and proven best practice and it will also underscore where to look for new emerging ideas. Together universal concepts, best practice guidance, and emerging ideas are how you adapt the TOGAF Standard for your configured Enterprise Architecture practice. 

•  The TOGAF Standard is used by small, medium, and large commercial businesses, as well as government departments, non-government public organizations, and defense agencies
• With greatly expanded guidance and how-to material, it enables organizations to operate in an efficient and effective way across a broad range of use-cases, including agile enterprises and Digital Transformation
• The TOGAF Standard is designed for the dichotomy of common universal concepts and variable detailed configuration
• The structure focuses on what most architects want – more, better, and topical guidance on how to deliver the best Enterprise Architecture that supports their stakeholders and their organization
• It is divided into the TOGAF Fundamental Content and the TOGAF Series Guides; the TOGAF Fundamental Content provides the core concepts and practices, and the TOGAF Series Guides advise on configuration of the Fundamental Content

Architecture Types

• Business Architecture (Business, Processes, Organation, People)
• Application Architecture (Services)
• Data Architecture (Data, Information)
• Technology Architecture (Hardware, Software, Network)

An Enterprise Architecture is only as good as the decision making framework that is establised around it "Goverance" framework

•  Good Goverance Framework depends on
• Clear authority structuer
• Who is responsible
• The right participants
• Who is involved
• Who is accountable

Architecture Frameworks/Models

Let’s start by reviewing enterprise architecture frameworks; there are too many to name here, so we will stick to the most well-known. Numerous architecture frameworks exist today, such as TOGAF, Zachman Framework, NIST, SOA. A brief summary of each framework is outlined below (this is not a comprehensive definition, just a brief outline for awareness and context).

• TOGAF. The most popular enterprise architecture framework; over time TOGAF has evolved through several maturations and formal training and certification elements have grown up around it.  TOGAF organizes enterprise architecture into four architecture pillars (business, data, application, technical), and describes a vocabulary, methods, and tools for defining and (equally important) maintaining enterprise architecture.
• Zachman Framework. Its primary intent is to provide structured guidance on how to progress from abstract concepts to real-world implementations, primarily by leveraging a matrix that organizes decisions for core elements (who, what, when, where, etc.) across the spectrum from abstract to physical implementation, wherein tools/artifacts are prescribed to assist with the intersection of each element.  Used collectively, these tools and artifacts provide the foundation of enterprise architecture and can be used for guiding ongoing architecture and design decisions.
• NIST. More of an enterprise architecture model rather than a framework, NIST describes an enterprise architecture as being comprised of five primary architecture layers (business processes, information flows, applications, data descriptions, technology infrastructure) that are all interrelated.  Over time, the NIST model was referenced by several prominent organizations to develop a NIST-based framework (e.g. DOE, FDIC, NWS).
• SOA. A service-oriented architecture model wherein all components and processes are integrated to form and deliver numerous services.  Many of these services are back-office services (e.g. identity management services) that support end-user services (e.g. submitting an automated request to be provisioned a particular application).  The SOA backbone is a service catalog that includes the designation of a service owner who is accountable for all elements of the service (i.e. integration of the people, processes, and technologies that comprise the service).

System Design

Different deisgn will be used for different purpose of each stage of project, also will be trageted for different type of audiences.

 
A Systems Architect responsibilities includes the ability to create, review, and update (don't forget this last one!) designs or blueprints to provide an overall direction for the system, project, department, or enterprise.

Contextual Design  ( Where you want to go: mission/vision)

This the domain or the context in which your problem exists or manifests and you want to solve it. Mostly it is the 20,000 foot level.

Typically it shall be going from
Contextual —-> Conceptual —–> Logical ——> Physical.

Conceptual Design  (flesh out the context into concepts ) 

A conceptual design is an abstract or high level design which includes only the most important components and entities. The main goal of a conceptual design is to provide an understandable picture of the overall purpose of the proposed solution. Components may include major technology systems, external systems that are required for integration or overall functionality, high level data flow, and system functionality. Think of this as the "black box" diagram where portions of the diagram may be simply a technology component to-be-named-later but is identified with its role and purpose.

Logical Design  ( Group them under a bucket/functionality etc)

A logical design is a more detailed design which includes all major components and entities plus their relationships

. The data flows and connections are detailed in this stage. The target audience is typically developers or other systems architects. However, it is possible to create logical designs for business purposes to ensure that all components and functionality is accounted and well understood. Logical designs do not include physical server names or addresses. They do include any business services, application names and details, and other relevant information for development purposes.

Physical Design  ( Leave it to Implementation)

A physical design has all major components and entities identified within specific physical servers and locations or specific software services, objects, or solutions. Include all known details such as operating systems, version numbers, and even patches that are relevant. Any physical constraints or limitations should also be identified within the server components, data flows, or connections. This design usually precludes or may be included and extended by the final implementation team into an implementation design.

The UML (Unified Modeling Language) is also another method that can be explored for design and definition for these and other designs. There are several diagram types within the UML which could be developed at each one of these design stages. I'd be interested to hear about your interest or experiences with development of these designs or others similar to it. Also, some believe there should be various focus areas such as the Microsoft Architecture  format with business, application, technology, and information views of each of these stages. This will depend on the maturity of your company's architecture program and also the project scope and target audience for your designs.

Tools:

• Lucid Charts -- my go-to solution
• Orbus Software — supports Conceptual, Logical, Physical diagrams (https://www.orbussoftware.com/enterprise-architecture/archimate/how-to-use-architecture-levels-effectively)
• C4 model -- for visualizing software architecture (modeling not diagraming, another approach) -- https://c4model.com/
• ArchiMate — model driven
• MEGA -- BPMN modeling

Architecture vs Design 

Architecture focuses on what and design focuses on how; the key distinction between architecture and design is overall scope and level of detail (and thus intended usage)

TOGAF Document

Structure of the TOGAF Document

There are four main parts to the TOGAF document:

PART I :

(Introduction) This Part provides a high-level introduction to some of the key concepts behind enterprise architecture and in particular the TOGAF approach.

PART II :

(Architecture Development Method) This is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) - a step-by-step approach to developing an enterprise architecture.

PART III :

(Enterprise Continuum) This Part describes the TOGAF Enterprise Continuum, a virtual repository of architecture assets, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).

PART IV :

(Resources) This Part comprises the TOGAF Resource Base - a set of tools and techniques available for use in applying TOGAF and the TOGAF ADM.

Four Commom Architectuer Using TOGAF

There are four types of architecture that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support:

• A Business (or Business Process) Architecture - this defines the business strategy, governance, organization, and key business processes.
• A Data Architecture - this describes the structure of an organization's logical and physical data assets and data management resources.
• An Applications Architecture - this kind of architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
• A Technology Architecture - this describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

TOGAF Main Parts

TOGAF provides a common-sense, practical, prudent, and effective method of developing an enterprise architecture.

TOGAF consists of three main parts:

1. The TOGAF Architecture Development Method (ADM), which explains how to derive an organization-specific enterprise architecture that addresses business requirements. The ADM provides:
   • A reliable, proven way of developing the architecture
   • Architecture views which enable the architect to ensure that a complex set of requirements are adequately addressed
   • Linkages to practical case studies
   • Guidelines on tools for architecture development
2. The Enterprise Continuum, which is a "virtual repository" of all the architecture assets - models, patterns, architecture descriptions, etc. - that exist both within the enterprise and in the IT industry at large, which the enterprise considers itself to have available for the development of architectures. At relevant places throughout the TOGAF ADM, there are reminders to consider which architecture assets from the Enterprise Continuum the architect should use, if any. TOGAF itself provides two reference models for consideration for inclusion in an enterprise's own Enterprise Continuum:
   1. The TOGAF Foundation Architecture - an architecture of generic services and functions that provides a foundation on which specific architectures and Architecture Building Blocks (ABBs) can be built. This Foundation Architecture in turn includes:
      • The TOGAF Technical Reference Model (TRM), which provides a model and taxonomy of generic platform services
      • The TOGAF Standards Information Base (SIB), which is a database of open industry standards that can be used to define the particular services and other components of an enterprise-specific architecture
   2. The Integrated Information Infrastructure Reference Model (III-RM), which is based on the TOGAF Foundation Architecture, and is specifically aimed at helping the design of architectures that enable and support the vision of Boundaryless Information Flow.
3. The TOGAF Resource Base, which is a set of resources - guidelines, templates, background information, etc. - to help the architect in the use of the ADM.

Six TOGAF 9 Main Components:

1. ADM
2. Architecture Content Framework
3. Reference Models
4. ADM Guidelines & Techniques
5. Enterprise Continuum
6. Architecture Capability Framework

ADM

 Architecture Development Method

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.

All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities.

Phases within the ADM are as follows:

• The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of the TOGAF framework and definition of Architecture Principles
• Phase A: Architecture Vision describes the initial phase of an architecture development cycle

  It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development.

• Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision
• Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision
• Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision
• Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases
• Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan
• Phase G: Implementation Governance provides an architectural oversight of the implementation
• Phase H: Architecture Change Management establishes procedures for managing change to the new architecture
• Requirements Management examines the process of managing architecture requirements throughout the ADM

Videos

 

References

• Logical architecture versus physical architecture
• Virtual Design Master: Conceptual, Logical, Physical
• Going from Blue Print to Brick and Mortar – Architect On the Job
• The Tao of Technology Architecture – Part 1
• An Introduction to the TOGAF® Standard, 10th Edition
• FREE Enterprise Architecture certification exam 9.2 training - CRACK TOGAF exam in 11 days