TOGAF Knowledges Collection

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.

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 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 vs other Architectures

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)

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

via Blogger http://blog.51sec.org/2023/01/togaf-knowledges-collection.html
January 03, 2023 at 10:17PM Architecture