TOGAF 9.2 Training

TOGAF 9.2 Training TOGAF Standard 9.2 : A Complete Guide Back Home Categories Online Courses Mock Interviews Webinars NEW Community Write for Us Categories Artificial Intelligence AI vs Machine Learning vs Deep LearningMachine Learning AlgorithmsArtificial Intelligence TutorialWhat is Deep LearningDeep Learning TutorialInstall TensorFlowDeep Learning with PythonBackpropagationTensorFlow TutorialConvolutional Neural Network TutorialVIEW ALL BI and Visualization What is TableauTableau TutorialTableau Interview QuestionsWhat is InformaticaInformatica Interview QuestionsPower BI TutorialPower BI Interview QuestionsOLTP vs OLAPQlikView TutorialAdvanced Excel Formulas TutorialVIEW ALL Big Data What is HadoopHadoop ArchitectureHadoop TutorialHadoop Interview QuestionsHadoop EcosystemData Science vs Big Data vs Data AnalyticsWhat is Big DataMapReduce TutorialPig TutorialSpark TutorialSpark Interview QuestionsBig Data TutorialHive TutorialVIEW ALL Blockchain Blockchain TutorialWhat is BlockchainHyperledger FabricWhat Is EthereumEthereum TutorialB lockchain ApplicationsSolidity TutorialBlockchain ProgrammingHow Blockchain WorksVIEW ALL Cloud Computing What is AWSAWS TutorialAWS CertificationAzure Interview QuestionsAzure TutorialWhat Is Cloud ComputingWhat Is SalesforceIoT TutorialSalesforce TutorialSalesforce Interview QuestionsVIEW ALL Cyber Security Cloud SecurityWhat is CryptographyNmap TutorialSQL Injection AttacksHow To Install Kali LinuxHow to become an Ethical Hacker?Footprinting in Ethical HackingNetwork Scanning for Ethical HackingARP SpoofingApplication SecurityVIEW ALL Data Science Python Pandas TutorialWhat is Machine LearningMachine Learning TutorialMachine Learning ProjectsMachine Learning Interview QuestionsWhat Is Data ScienceSAS TutorialR TutorialData Science ProjectsHow to become a data scientistData Science Interview QuestionsData Scientist SalaryVIEW ALL Data Warehousing and ETL What is Data WarehouseDimension Table in Data WarehousingData Warehousing Interview QuestionsData warehouse architectureTalend T utorialTalend ETL ToolTalend Interview QuestionsFact Table and its TypesInformatica TransformationsInformatica TutorialVIEW ALL Databases What is MySQLMySQL Data TypesSQL JoinsSQL Data TypesWhat is MongoDBMongoDB Interview QuestionsMySQL TutorialSQL Interview QuestionsSQL CommandsMySQL Interview QuestionsVIEW ALL DevOps What is DevOpsDevOps vs AgileDevOps ToolsDevOps TutorialHow To Become A DevOps EngineerDevOps Interview QuestionsWhat Is DockerDocker TutorialDocker Interview QuestionsWhat Is ChefWhat Is KubernetesKubernetes TutorialVIEW ALL Front End Web Development What is JavaScript â€" All You Need To Know About JavaScriptJavaScript TutorialJavaScript Interview QuestionsJavaScript FrameworksAngular TutorialAngular Interview QuestionsWhat is REST API?React TutorialReact vs AngularjQuery TutorialNode TutorialReact Interview QuestionsVIEW ALL Mobile Development Android TutorialAndroid Interview QuestionsAndroid ArchitectureAndroid SQLite DatabaseProgramming ArchitectureTOGAF Stand ard 9.2 : A Complet... TOGAF Certification Program Training (1 Blogs)TOGAF Standard 9.2 : A Complete Guide Published on Nov 28,2019 657 Views Upasana Research Analyst, Tech Enthusiast, Currently working on Azure IoT Data Science... Research Analyst, Tech Enthusiast, Currently working on Azure IoT Data Science with previous experience in Data Analytics Business Intelligence. BookmarkIn a long line of enterprise architecture frameworks, TOGAF is not the first and its unlikely to be the last. But it is one thats endured for nearly two decades, with worldwide usage an impressive feat in todays technology landscape.TOGAF is the acronym for The Open Group Architecture Framework and it was developed by The Open Group, a not-for-profit technology industry consortium that continues to update and reiterate the TOGAF.This article will focus on familiarizing beginners with TOGAF and the following is the outline of this article;Understanding enterprise architectureWhat is Architecture in the Context of TOGAF?What Kind of Architecture Does TOGAF Deal With?TOGAF history and factsThe TOGAF approach to EAFsArchitecture Development MethodDeliverables, Artifacts, and Building BlocksEnterprise ContinuumArchitecture RepositoryEstablishing and Maintaining an Enterprise Architecture CapabilityEstablishing the Architecture Capability as an Operational EntityThe Open Group CertificationsBenefits of using TOGAFUsing TOGAF with Other FrameworksTOGAF Document Categorization ModelSuccess and CriticismUnderstanding enterprise architectureTOGAF is an architecture framework The Open Group Architecture Framework. TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.Enterprise architecture refers to the holistic view and approach of software and other technology across an entire comp any, or enterprise.Typically, enterprise architecture isnt just a structure for organizing all sorts of internal infrastructures. Instead, the goal is to provide real solutions to business needs through analyzing, designing, planning and implementing the right technology in the right ways.What is Architecture in the Context of TOGAF?ISO/IEC 42010:2007 defines architecture as: The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. TOGAF embraces but does not strictly adhere to the given terminology. In TOGAF, architecture has two meanings depending upon the context:A formal description of a system, or a detailed plan of the system at component level to guide its implementationThe structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over timeIn TOGAF you, basically, endeavour to strike a balan ce between promoting the concepts and terminology ensuring that your usage of said terms is consistent with the standard and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership.What Kind of Architecture Does TOGAF Deal With?There are four architecture domains that are commonly accepted as subsets of overall enterprise architecture, all of which TOGAF is designed to support:TheBusiness Architecturedefines the business strategy, governance, organization, and key business processes.TheData Architecturedescribes the structure of an organizations logical and physical data assets and data management resources.TheApplication Architectureprovides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.TheTechnology Architecturedescribes the logical software and hardware capabilities that are required to support the deployment of busine ss, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.More and more, enterprise architecture also encompasses additional business needs like business process management and data analytics. The goal of organized enterprise architecture, then, is to successfully execute business strategy with efficiency, efficacy, agility, and security.If all this sounds like it can be complicated designing and implementing a clear, long-term solution to all enterprise software in a way that solves business needs its because it is. Thats why enterprise architecture frameworks (EAFs) started emerging informally and formally, as long as five decades ago.TOGAF history and factsAs a subset of computer architecture, enterprise architecture as a field dates back to the mid-1960s. IBM among other companies and universities spearheaded some explicit ways to build enterprise architecture, knowing that all the pieces involved to r un on a network are complicated.Over the next few decades, technology only became more complicated: today, most companies, regardless of size or product, utilize the internet to make their business processes easier, quicker, and sometimes more transparent. Today, enterprise architecture is a necessary process to make sense of various hardware and software options, on-premise and in the cloud, and to ensure security when sharing data across multiple platforms.The TOGAF was initially developed in 1995. As was common in the field of enterprise architecture by then, newer versions or models offered improved iterations and theories. Likewise, TOGAF took a lot of inspiration from the U.S. Department of Defenses own EAF, called the Technical Architecture Framework for Information Management, or TAFIM for short. Interestingly, the USDoD stopped using the TAFIM within a couple of years of the emergence of TOGAF. Still, TOGAF implementation and success continues worldwide today, more than 20 years later.The TOGAF approach to EAFsThe Open Groupdefinesthe TOGAF as the de facto global standard for enterprise architecture. The framework is intended to help enterprises organize and address all critical business needs through four goals:Ensuring all users, from key stakeholders to team members, speak the same language. This helps everyone understand the framework, content, and goals in the same way and gets the entire enterprise on the same page, breaking down any communication barriers.Avoiding being locked-in to proprietary solutions for enterprise architecture. As long as the company is using the TOGAF internally and not towards commercial purposes, the framework is free.Saving time and money and utilizing resources more effectively.Achieving a demonstrable return on investment (ROI).3 Pillars of TOGAFIf the four goals are the theoretical outcome of using TOGAF, then the three pillars are the way to achieve the goals. These pillars help create a systematic process to organ ize and put software technology to use in a structured way that aligns with governance and business objectives. Because software develop relies on collaboration across various business departments inside and outside of IT, TOGAFs goal of speaking the same language encourages and assists the various stakeholders to get on the same page, something that may not otherwise happen in business environments.The TOGAF is divided intothree main pillars:Enterprise architecture domains.These divide the architecture into four key areas:Business architecture,which defines business strategy and organization, key business processes, and governance and standards.Applications architecture,which provides a blueprint for deploying individual systems, including the interactions among application systems as well as their relationships to essential business processes.Data architecture,which documents the structure of logical and physical data assets and any related data management resources.Technical arch itecture(also known as technology architecture), which describes the hardware, software, and network infrastructure necessary to support the deployment of mission-critical applications.Architecture Development Model(ADM). This iterative cycle uses performance engineering to develop an actual enterprise architecture. Importantly, it can be customized to the enterprises needs, so its not a one-size-fits-all approach. Once an architecture is developed, the enterprise can roll it out to all teams or departments in iterative cycles, ensuring minimal errors and further helping the company communicate cohesively.Enterprise Continuum.This classification system tracks architecture solutions on a range, starting at generic, industry-standard options and including customized enterprise-specific solutions.Proponents say thatADM is the heart of TOGAF its this pillar that makes TOGAF both very effective and a standout from other frameworks. The Architecture Development Method offers eight steps a s guidance to figure out where the enterprise currently is and determine where the enterprise wants and needs to be in each of the four enterprise architecture domains.Once business processes are established through the entire lifecycle, the ADM helps the enterprise identify the gaps between current status and long-term goals, and then collates these gaps into smaller actionable and understandable packages that the team can then implement.Two other areas are sometimes included in TOGAFs main pillars: TOGAF certified tools and qualifications.Architecture Development MethodThe 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:ThePreliminary Phasedescribes the preparation and initiation activities required to prepare to meet the business directive for new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles.PhaseA: Architecture Visiondescribes the initial phase of an architecture development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.PhaseB: Business Architecturedescribes the development of a Business Architecture to support an agreed Architecture Vision.PhaseC: Information Systems Architecturesdescribes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.PhaseD: Technology Architecturedescribes the development of the Technology Architecture for an architecture project.PhaseE: Opportunities Solutionsconducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.PhaseF: Migration Planningaddresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan.PhaseG: Implementation Governanceprovides architectural oversight of the implementation.PhaseH: Architecture Change Managementestablishes procedures for managing change to the new architecture.Requirements Managementexamines the process of managing architecture requirements throughout the ADM.Deliverables, Artifacts, and Building BlocksArchitects executing the 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 TOGAF Architecture Content Framework (see Part IV,Introdu ction) provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented.The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:Adeliverableis a work product that is contractually specified and in turn, formally reviewed, agreed, and signed off by the stakeholders. Deliverables are basically the output of projects in documentation form. It is typically archived at the completion of a project or moved into an Architecture Repository as a reference model, for the Architecture Landscape at a point in time.Anartefactis a more granular architectural work product. It describes an architecture from a specific point of view. For instance, a network diagram, a server specification, a use-case specification, a list of architectural requirements, or a business interaction matrix. An artefact is generally classified as;a catalogue or a list of thingsmatrices depicting relationships between thingsdiagramsAn architectural deliverable may contain many artefacts and artefacts will form the content of the Architecture Repository.Abuilding blockrepresents a potentially re-usable component of the business. It could refer to IT, or architectural capability that can be combined with other similar building blocks to deliver solutions. Hence, these building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached.Architecture Building Blocks (ABBs)typically describe the required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software.Solution Building Blocks (SBBs)represent components that will be used to implement the required capability. For example, a network is a building block tha t can be described through complementary artefacts and then put to use to realize solutions for the enterprise.Enterprise ContinuumTOGAF includes the concept of the Enterprise Continuum, which sets the broader context for an architect and explains how generic solutions can be leveraged and specialized in order to support the requirements of an individual organization. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artefacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum. Architecture RepositorySupporting the Enterprise Continuum is the concept of an Architecture Repository which can be used to store different classes of architectural output at different levels of abstraction, created by the ADM. In this way, TOGAF facilitates understanding and co-operation between stakeholders and practitioners at different levels.By means of the Enterprise Continuum and Architecture Repository, architects are encouraged to leverage all other relevant architectural resources and assets in developing an Organization-Specific Architecture.In this context, the TOGAF ADM can be regarded as describing a process lifecycle that operates at multiple levels within the organization, operating within a holistic governance framework and producing aligned outputs that reside in an Architecture Repository. The Enterprise Continuum provides a valuable context for understanding architectural models: it shows building blocks and their relationships to each other, and the constraints and requirements on a cycle of architecture development.The major components within an Architecture Repository are as follows:TheArchitecture Metamodeldescribes the organizationally tailored application of an architecture framework, including a metamodel for architecture c ontent.TheArchitecture Capabilitydefines the parameters, structures, and processes that support governance of the Architecture Repository.TheArchitecture Landscapeshows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives.TheStandards Information Base(SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.TheReference Libraryprovides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.TheGovernance Logprovides a record of governance activity across the enterprise.Establishing and Maintaining an Enterprise Architecture Capabili tyIn order to carry out the architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes. Establishing the Architecture Capability as an Operational EntityBarring architecture capabilities set up to purely support change delivery programs, it is increasingly recognized that a successful enterprise architecture practice must sit on a firm operational footing. In effect, an enterprise architecture practice must be run like any other operational unit within a business; i.e., it should be treated like a business. To this end, and over and above the core processes defined within the ADM, an enterprise architecture practice should establish capabilities in the following areas: Financial ManagementPerformance ManagementService ManagementRisk ManagementResource ManagementCommunications and Stakeholder ManagementQuality ManagementSup plier ManagementConfiguration ManagementEnvironment ManagementCentral to the notion of operating an ongoing architecture is the execution of well-defined and effective governance, whereby all architecturally significant activity is controlled and aligned within a single framework.The Open Group CertificationsThe Open Group offerstwo certificationsfor individuals: the first level is known as the Foundation, teaching basic tenets of enterprise architecture and rolling out TOGAF, and Level 2 Certified involves business analysis and application. The Open Group also certifies tools that align with TOGAF from eight organizations.Benefits of using TOGAFThe benefits of ADM are that it is customizable to organizational need theres no need to create a structure that doesnt serve your business. These smaller packages are also scalable, so if one team rolls it out, it can successfully be rolled out to other teams without much tweaking. This helps the enterprise establish a process with multipl e checkpoints so that there are few errors the wider the architecture is implemented.There can also be benefits to individuals who certify in TOGAF. A study of industry employees indicates that enterprise architects, software architects, and IT directors, among others, who choose to earn a certification in TOGAF often see an average yearly pay bump of $10,000 $20,000 over similarly placed colleagues who arent certified.Some experts in enterprise architecture point out that while TOGAF may appear very logical, its actually quite a shakeup to traditionally educated technology consultants today but perhaps this will change has TOGAF adoption continues along steadily.As governance has become an increasingly visible requirement for organizational management, the inclusion of governance within TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligat ions.The benefits of architecture governance include: Increased transparency of accountability, and informed delegation of authorityControlled risk managementProtection of the existing asset base through maximizing re-use of existing architectural componentsProactive control, monitoring, and management mechanismsProcess, concept, and component re-use across all organizational business unitsValue creation through monitoring, measuring, evaluation, and feedbackIncreased visibility supporting internal processes and external parties requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organizationGreater shareholder value; in particular, enterprise architecture increasingly represents the core intellectual property of the enterprise studies have demonstrated a correlation between increased shareholder value and well-gover ned enterprisesIntegrates with existing processes and methodologies and complements functionality by adding control capabilitiesUsing TOGAF with Other FrameworksTwo of the key elements of any enterprise architecture framework are:A definition of the deliverables that the architecting activity should produceA description of the method by which this should be doneWith some exceptions, the majority of enterprise architecture frameworks focus on the first of these the specific set of deliverables and are relatively silent about the methods to be used to generate them (intentionally so, in some cases).Because TOGAF is a generic framework and intended to be used in a wide variety of environments, it provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced or extended by a more specific set, defined in any other framework that the architect considers relevant.In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP.As a generic framework and method for enterprise architecture, TOGAF also complements other frameworks that are aimed at specific vertical business domains, specific horizontal technology areas (such as the likes of security or manageability), or specific application areas (the likes of e-Commerce).TOGAF Document Categorization ModelA TOGAF document categorization model exists to structure the release management of the TOGAF specification. It is not intended to serve as an implementation guide for practitioners.Within the model, the content of the TOGAF document is categorized according to the following four categories:TOGAF Coreconsists of the fundamental concepts that form the essence of TOGAF.TOGAF Mandatedconsists of the normative parts of the TOGAF specification. These elements of TOGAF are central to its usage and without them the framework would not be recognizably TOGAF. Strong consideration must be given to these elements when applying TOGAF.TOGAF Recommendedconsists of a pool of resources that are specifically referenced in TOGAF as ways in which the TOGAF Core and Mandated processes can be accomplished (e.g., the SEI Architecture Trade-Off Analysis Method or business scenarios).TOGAF Supportingconsists of additional resources that are not referenced in the other three TOGAF categories itself but provide valuable assistance.Success and CriticismAccording to the Open Group, TOGAF is employed in more than 80 per cent of Global 50 companies and more than 60 per cent of Fortune 500 companies. Though criticism of the framework is often that it is too complicated or theoretical to be applicable, it seems that plenty of companies are using the structure.Companies who have successfully implemented the framework admit that failings do happen because this frameworkcannot be a cure-all for enterprise issues. While the issue can be TOGAF principles or the enterprise architecture itself, others argue that sometimes key stakeholders and C-level management dont always take the time to set up important factors, such as key performance indicators (KPIs), to make the architecture team successful.This lack of complete buy-in may sometimes be due to the complicated nature of this framework when looked at in its entirety. Indeed, even when the framework feels overwhelming, the best advice may be to pick what works best for your company.One must understand that TOGAF is no miracle tool. But it definitely can provide structure to help teams and upper-level managemen t from having to reinvent the wheel each time the company wants to incorporate new technology.Many understand that TOGAF is a work in progress marked by new releases every few years. Even sceptics of TOGAFand enterprise architecture frameworks, in general, find that the applied use of TOGAF is often successful simply because it is better than doing nothing.When companies want to jump on board a new technology, it often requires building out the right tech team from scratch and then tracking down all sorts of data. It gets messy and the rapid pace that technology shifts and improves, these requests occur a lot more often than they used to. This can explain, in part, the bustling IT and architecture teams that are always busy yet somehow always seem behind.As its widespread use indicates, TOGAF can help enterprises of any size and any industry but those who employ it are probably best served by understanding its pros and cons first, and then applying the parts that make particular sense for their own company. Edureka offers theTOGAF 9.2 Certification;TOGAF Foundation (Level 1) and TOGAF Certified (Level 2)that gives you access to instructor-led, live online classes with high-quality, learning content accredited by The Open Group and designed byindustry experts.Recommended videos for you Design Patterns:Tailor-made Solutions for Software Development Watch Now Design Patterns : Tailor Made Solutions for Software Development Watch Now Design Patterns : The Ultimate Blueprint for Software Watch Now Design Patterns: Solution to Software Design Problems Watch Now Design Patterns : The Ultimate Blueprint for Software-I Watch NowRecommended blogs for you TOGAF Standard 9.2 : A Complete Guide Read Article Important Java Design Patterns You Need to Know About Read Article Design Pattern Exposed: Strategy Pattern Read Article Design Pattern Exposed: Factory Pattern Read Article Comments 0 Comments Trending Courses in Systems Architecture Design Patterns Certificatio n Training3k Enrolled LearnersWeekend/WeekdaySelf Paced Reviews 5 (1100)