TOGAF 10 Level 1 Friendly Wonder Guide Volume 1: TOGAF 10 Level 1 Friendly Wonder Guide, #1

By Ramki

TOGAF Certification is not Tough. It is NOT difficult, but is different. This author has proved it so to thousands of Certification aspirants, though direct training and through books. Similar books on TOGAF 9.2 Certification by same author are quite popular. Training on TOGAF has been provided to more than 5000 participants by the same author faculty.

 

This book is one among the Series of Volumes which prepares you for the TOGAF 10 Certification. This Certification is known by the name "Enterprise Architecture Certification".  This book with more than 200 questions, not seen with just with answer, but with very detailed explanation of how the answer is arrived is a MUST READ for any TOGAF Level 1 Exam aspirant.

 

This and other volumes in this Series takes you through topics that cover the entire Level 1 Exam syllabus. The highlight of this book Series is inclusion of large number of Non-Conventional multiple choice questions which are a hallmark of TOGAF 10 Exam and was not there hitherto in TOGAF 9.2 Exam. These are tabular in form or some with images (illustrations) from the TOGAF documentation.

 

TOGAF 10 Exam is based not only on the six free-standing documentation of TOGAF 10, but are also on a good number of Series Guides. Question in this book Series cover all these portions adequately. Links to the online documentation of Open Group will lead towards a smooth study experience, without having to refer to anything else.

• Language: English
• Publisher: Ramki
• Release date: Jan 13, 2023
• ISBN: 9798215861639

Ramki

Author :   Ramakrishnan N  (Ramki)   Near 50 years of experience in Software Architecture, Enterprise Architecture Design (UML, others) and Patterns (GOF, Microservices and many more), SOA to Microservices to Cloud Native and few State-of-Art technologies.    Consultant and High-end Trainer to many prestigious International Enterprises   Certified in TOGAF 9 and TOGAF 10   Based at Bangalore, India.       Reachable through : [e-mail]

Book preview

Module 1 :

Introduction and Core concepts of TOGAF

Note that questions do come up with answer choices picked up from other modules beyond these. However correct answer may appear within the Module.

Revisit all questions after revising the whole of TOGAF.

Q 101 Which one of the following best describes TOGAF ?

A. A framework and method for architecture development

B. An architecture pattern

C. A business model

D. A method for developing Technology Architectures

E. A method for IT Governance

Explanation : Why read this ? To be prepared with other similar questions that could come up. Also, as a preparatory work in understanding TOGAF and even be somewhat prepared for Level 2 Certification, which is based on the same overall content.

TOGAF - The Open Group Architecture Framework is a framework - a detailed method and a set of supporting tools - for developing an Enterprise Architecture.

A Framework, because it is an EAF : Enterprise Architecture Framework and in turn contains a method : ADM – Architecture Development Method which is meant for providing the process for developing (Enterprise and Solution) Architectures. 

See : 1. Introduction under Introduction and Core Concepts part of TOGAF Standard Fundamental Content Version 10

We infer therefrom not just answer to this question, but additional pointers to similar questions on :

What is behind an Architectural Framework ? (Hint : It the basic structure for use in the field of IT Architecture. It can be more than one structure and can be of a set of such Architectural structures. Can be used with a larger (broad) set of Architectures : Software, Infrastructure and so on.

TOGAF therefore plays an important role in helping to de-mystify and de-risk the architecture development process and gets into Enterprise Architecture in depth, Solution Architecture to a reasonable depth and into Project Management and Solution Development issues to a reasonable extent.

TOGAF provides a platform for adding value and enables users to build genuinely open systems-based solutions to address their business issues and needs. TOGAF in turn may involve Architectural approaches and Patterns, Business models, Technology and other Architectures as also IT Governance. But by itself TOGAF is large superset of all these things and best be referred to as EA Framework.

Answer : A

Also note from : 1.1 Executive Overview : under Introduction and Core Concepts part of TOGAF Standard Fundamental Content Version 10

What is an architecture framework ?

Why use the TOGAF Standard as a framework for Enterprise Architecture ?

What do we mean by the enterprise operating model concept ? Questions on operational aspects of different departments and functions of the Enterprise may relate to how it helps us understand the way the nature of the Enterprise is aligned with. Or in understanding the overall scope of such functionalities and operations of the Enterprise.

What is the deal with the phrase ‘multiple enterprises’? The Enterprise at large may consist of units and departments, divisions, different verticals of operation or may have subsidiary and ancillary companies as part of it. Under such circumstances the chances are that there is a need to develop a few Enterprise architecture sub-frameworks which are fairly independent of each other.

The scope of EAF may extend to maintaining these differential multiple Enterprises within the larger Enterprise structure. Point to note is that such enterprises may exhibit features common with each other. Look at the way processes and functionalities exist there. Look at their information systems. We may decide that the case exists for a common architecture framework within the larger Enterprise. We may be resorting to store and use common Architectural Building Blocks and even common Solution Blocks. We will decide to have a common and hence shareable Architecture Repository. This will pave the path for appropriate integration between them. This serves the ultimate purpose of re-use of business models, designs, information, and data and all such areas where the Building Blocks exist.

Architecture design happens to be a technically complex process. Be prepared for simple questions pointing to the design to be of heterogeneous (many areas, many technologies as it exists within that Enterprise)

When it comes to the technology issues, do note that multi-vendor architectures are particularly complex. Enterprise Architecture Frameworks such as TOGAF take this into account.

Q 102 Which of the following statements do not describe an Enterprise ?

A. Collection of organization that has a common set of goals

B. HR departments of two competing companies

C. Division of a Corporation

D. HR department of a Corporation

Explanation :

Note the negative tone in the question : ‘do not describe’. In any multiple choice question format, negative questions may form a major lot. Always study the question and make a special note of negative tone, if it appears there.

Two competing enterprises cannot have a common department. See under : 1.1 Executive Overview under Introduction and Core Concepts part of TOGAF Standard Fundamental Content Version 10

(Serious learners are advised to refer to TOGAF documentation of section – such as the one refereed to here - in the online link : https://pubs.opengroup.org/togaf-standard/). Do not get satisfied just with getting the answer right. These cross references to TOGAF standard prepare you too well for Level 1 and Level 2 Certification Exams.

When you see the section : What is an enterprise ?

Points to infer for any similar question will be :

Not just any collection of organizations (means companies or their departments therein) would make an Enterprise unless common goals are found amongst them.

Can a Government agency, say Police, Counties and Municipal units be an Enterprise : Yes

Can a large corporate conglomerate be an Enterprise : Naturally yes. They are referred to here as a whole corporation.

At the same time just one unit or a division of a company can be treated as an Enterprise and proceeded with its own TOGAF treatment.

Can a set of discrete companies (organizations) be taken as an Enterprise : Yes, provide they fit in as : a chain of geographically distant organizations linked together by common ownership. Note every specifically the phrase : common ownership

So, almost any organization, including non-IT related ones can ideally come under TOGAF.

Be prepared for Level 1 question involving any of the above points.

The idea of providing Explanation for each answer is not just to tell you how we arrive at the answer, but also to prepare you for any other question on the topic that is not explicitly listed here.

Answer : B

Q 103 Which one of these may not be an Enterprise as listed in TOGAF 10 ?

A. A whole corporation or a division of a corporation

B. A government agency or a single government department

C. A chain of geographically distant organizations linked together by common ownership

D. Groups of countries, governments, or governmental organizations (such as militaries) working together to create common or shareable deliverables or infrastructures

E. A single project or a group of projects in a company

F. Partnerships and alliances of businesses working together, such as a consortium or supply chain

Explanation :

Answer Choices A), B), C), D), and F) are appearing in 1.1 Executive Overview under Introduction and Core Concepts part of TOGAF Standard Fundamental Content Version 10

A project alone cannot quality as an Enterprise. As seen with other Answer Choices, an Enterprise has to be a comprehensive unit and not an activity or an initiative alone.

Answer : E

Q 104 In TOGAF, what is the difference between an artifact and a deliverable ?

A. An artifact contains one or more deliverables

B. Artifacts and deliverables are synonymous; there is no difference between them

C. Deliverables are prepared by the Project Manager, whereas artifacts are defined by the Architect

D. Deliverables are reusable, whereas artifacts are unique to a given architecture project

E. Deliverables are specified as contractual outputs from a project, whereas artifacts are not

Explanation :

Deliverable : Contractually mandated. Architect delivers, usually not individual artifact, but duly grouped Components.

Artifact : Any piece (element) of Architectural Value. Non-Deliverable Artifacts / Components may be optionally prepared and submitted as part of Architectural work. The Architect may, on own initiative add more Artifacts / Building Blocks and these are not-contractual but added for providing more clarity over the work done. Both categories are Architectural Work Pieces (Work Products). One of them (Deliverable) is compulsory and mandatory.

See under : 3.6 Deliverables, Artifacts, and Building Blocks under Introduction and Core Concepts part of TOGAF Standard Fundamental Content Version 10

Note here, focus points such as : Deliverable - a product of architectural work. It has to be internally specified as a mandatory artifact – (contractually specified). The Deliverable artifacts are to be formally reviewed -mean an official and systematic review (with relevant stakeholders), agreed – with the concurrence of highest Architect who is responsible for that portion of the work, and signed off by the stakeholders -means it ultimately forms part of the relevant Architecture Contract.

This section further clarifies that such Deliverables become the output of architecture work, say architecture projects. What happens to such Deliverables after they are produced, approved and used ? These will be stored for frequent reference during the project duration. Further these are archived at completion of a project.

Some of the Deliverables get into the Architecture Repository even as a reference model; sometimes as internal standard. But, more often as a Architecture Landscape which is the place to land our own outputs.

What do we mean by ‘snapshot of the Architecture Landscape at a point in time’ ? A look into the Architecture Repository at any time will reveal the presence of all such re-usable architectural assets.

Is not an artifact one such architectural work product and one that provides a description of one aspect of the architecture ? Yes, very much so. Wither a single artifact or a grouped component of artifacts do become Deliverable when mandated. But can exist as non-mandated but as additional architectural work product also.

Important to note that TOGAF classifies all artifacts only into three sets : What is mentioned as catalog are more like bullet point - lists of things. We also have matrices which are cross references to show the relationships between one aspect and another. The major artifact group which are the centre of architectural modelling are diagrams.

In case you are still wondering about the difference between an Artifact and Building Block :

Note that re-use possibility is the main aspect that distinguishes a Building Block from (otherwise rarely re-usable) Artifacts. Every Building Block is an Artifact, but the name Building Block is given to the artifact when we realize a re-use potential in it.

Answer : E

Q 105 Which of the TOGAF architecture development phases includes the development of Data and Application Architectures ?

A. Phase A

B. Phase B

C. Phase C

D. Phase D

E. Phase E

Explanation :

This is how TOGAF specified ADM has in its Phase C : Information Systems Architecture

See in TOGAF Documentation : under Architecture Development Method part of TOGAF Standard Fundamental Content Version 10

Chapter 5 : Phase C: Information Systems Architectures

Chapter 6 : Phase C: Information Systems Architectures — Data Architecture

Chapter 7 : Phase C: Information Systems Architectures — Application Architecture

Phase C : Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.

Phase C is both about Data Architecture and Application Architecture. It describes these in the development method of Enterprise Architecture. No other phase is directly about these two.

TOGAF has made both Data and Application Architecture to be part of same Phase C. This is done deliberately since both these domains of architecture are close to each other and need frequent referencing between them doing the design stages.

For more clarity, read  5. Phase C : Information Systems Architectures under Architecture Development Method part of TOGAF Standard Fundamental Content Version 10

Answer : C

Q 106 Which one of the following is the reason why the first execution of an ADM cycle will be more difficult than later cycles ?

A. Because management is not familiar with the ADM process

B. Because there are few architecture assets available

C. Because of lack of governance

D. Because of insufficient trained architecture practitioners

E. Because the Baseline Architecture must be fully defined across the enterprise

Explanation :

If TOGAF is practiced for the first time and ADM cycle starts, there will be zero to very little architectural assets available in the Architecture Repository. When the projects move through ADM phases, gradually assets will get added up. The first execution of the ADM is expected to be the hardest. This is because the architecture assets available for re-use will be relatively scarce. Even at this stage of development, however, there will be architecture assets available from external sources suggested by TOGAF, as well as the IT industry at large, that could be leveraged in support of the effort.

TOGAF refers to a number of Reference materials and others as external references. Still during the start of a fresh TOGAF, there will hardly be any pre-existing architectural works, known as Baseline architecture. 

Of course, only start-up organization will have TOGAF based Enterprise Architecture from its inception. Most of our organizations will have different kind of architectural practices before moving to TOGAF. Still the first execution under TOGAF will be tougher because of the learning curve involved in arranging the available architectures in the right place.

See 1.1 ADM Overview : under Architecture Development Method part of TOGAF Standard Fundamental Content Version 10

Note that the above reference materials are mentioned under Enterprise Continuum and Architecture Repository. This is because the Architecture Repository is needed to store such assets and Architects do reach it through the duly classified Enterprise Continuum

Answer : B

Q 107 Which of the following is a reason to adapt ADM ?

A.  All of the answers below

B.  The use of TOGAF is being integrated with another Framework

C.  The ADM is being used for a purpose other than Enterprise Architecture

D.  The Enterprise is a large Federated Organization

E.  The IT governance model needs to be tailored

Explanation :

TOGAF clearly specifies the reasons why every Enterprise should take TOGAF Documentation a first cut one and duly tailor (customize / adapt) it as an Enterprise-Specific one. Important to get to know them)

See : 1.3 Adapting the ADM appearing in 1. Introduction in Architecture Development Method part of TOGAF Standard Fundamental Content Version 10

Look at each Answer Choice from B) to E) from that angle.

For B) The Architecture Development Method (ADM) is a flexible process that can be used to support the development of architecture as a stand-alone process, or as an extension to other solution development or project management methods. TOGAF never claims to be a stand-alone framework.

For example, an enterprise may wish to use TOGAF and its generic ADM in conjunction with the well-known Zachman Framework, or another Enterprise Architecture framework that has a defined set of deliverables specific to a particular vertical sector : Government, Defence, e-Business, Telecommunications, etc., The ADM has been specifically designed with this potential integration in mind.

For C) The ADM is a generic method for architecture development, which is designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. So, is it that ADM is tied with EA ? Note that TOGAF can be used outside of IT and can be adopted for such non-IT purposes.  

For D) The term enterprise in the context of enterprise architecture can be used to denote both an entire enterprise - encompassing all of its information and technology services, processes, and infrastructure - and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise. ADM is useful here but will need Tailoring. 

For E) TOGAF provides an industry standard framework for architecture that may be used in a wide variety of organizations. However, before TOGAF can be effectively used within an architecture project, it needs adaptation, including in its Governance stipulations.

Answer : A

Q 108 According to TOGAF, which one of the following best describes an enterprise architecture ?

A.  An Architecture of a Commercial Organization

B.  An Architecture that consists of more than one subsidiary company

C.  An Architecture that crosses multiple systems and multiple functional groups within the enterprise

D. The highest level of Architecture that can be achieved in a given organization

Explanation :

Why not A : An architecture of a commercial organization. Because TOGAF can be applied to ANY enterprise. It can be Government, military, private corporate : Just any Enterprise

Why not B : An architecture that consists of more than one subsidiary company. Because TOGAF can apply to a standalone enterprise with or without subsidiaries.

Why not D : The highest level of architecture that can be achieved in a given organization. Because though this statement is true and valid, the question is about description of enterprise Architecture. Not about its level of importance.

TOGAF crosses multiple systems : Say, four Architectural Domains of Business, Data, Application and Technology (Infrastructure). Also note that TOGAF does not consider Security as fifth domain, but as one which has cross-cutting concerns over all four of B D A T.

TOGAF crosses multiple functional groups : Interacts with all