TOGAF Framework - Research Paper Example

?TOGAF FRAMEWORK TOGAF Framework Affiliation Table of Contents TOGAF FRAMEWORK TOGAF Framework 1 Affiliation1 Date 1 Table of Contents 2 Introduction 3 When a system is built for a very specific purpose, for instance for processing a charge to an account we should be familiar with what we require carrying out and how we need to do it. However, the system architecture could be simple. Seeing that, in corporate applications, many thoughts approach that idea, what we require carrying out and how we need to do it, prior to starting system coding at the initial line. However, normally in large-size development projects, the person performing this idea is generally an IT architect. This person works as an in-charge for interpreting business needs into valuable software requirements. Additionally, in small development projects and small-size companies, this can be an extremely simple task. On the other hand, in large size companies, this could be a very complicated job. Luckily, there are facilitates available for resolving such tasks. In this scenario, the TOGAF (Open Group Architecture Framework) offers a tactic for analyzing a corporate specific state as well as changing it into actionable objects (Chase, 2006). This paper presents a detailed analysis of some of important aspects of TOGAF methodology. This paper will cover pros/cons, uses of TOGAF, TOGAF heritage and corporate applications. 3 An Overview of TOGAF 3 The Open Group Architecture Framework (TOGAF) is a structure that presents a comprehensive technique and a group of supporting systems and tools for building effective enterprise design. Additionally, it can be utilized without any restriction from any corporation desiring to build up enterprise architecture for use inside that association/business/corporate. In addition, this formwork was established by associates of The Open Group, functioning inside the Architecture Forum. However, the first version of TOGAF framework was developed in 1995. In addition, it was foundational upon Technical Architecture Framework for Information Management (TAFIM), built by the United States Department of Defense (DoD). In this scenario, the Department of Defense offered The Open Group open authorization and extensive support to build TOGAF by crafting the TAFIM. Thus, it was the fruit of many years of development attempts as well as a lot of investment comprising million of dollars of US Government. Moreover, by taking the advantage of this powerful base, the members of The Open Group Architecture Forum have built several editions of TOGAF every year and published every one on The Open Group public website (The Open Group, 2011) and (Chase, 2006). 4 TOGAF Heritage 4 As discussed above the Open Group Architecture Forum has built several versions of TOGAF at normal intervals as well as published every one on the web site of The Open Group. Additionally, every form of TOGAF standard is built collaboratively by the members of the design Forum. In addition, at present it consists of approximately 200 corporate members, comprising vendor and customer organizations. In this scenario, the development is carried out by architecture practitioners, with the content foundational upon most excellent practices that developed within the contributing member businesses (Sante & Ermers, 2009) and (The Open Group, 2011). 5 Moreover, TOGAF was one of the primary representations with a powerful focus on procedure approached to structural design in the business. In this scenario, architecture can be considered as a business wide procedure that will be controlled by the business administration, through the support of corporate architect. Thus, the (corporate) planner has consequently become a very important person having organizational sensitivity (Sante & Ermers, 2009) and (The Open Group, 2011). 5 Furthermore, the latest versions of TOGAF involve superior features, which focus on the use of architecture as well as its power. However, it came into view when TOGAF started tackling with other areas of knowledge. At this phase, what an organization has to attain through this arrangement turns out to be TOGAF’s main challenge. In the same way, in other similar developments such as in ITIL, maintaining this facility for the company is very important. In addition, TOGAF’s version 9 is the arrangement that is not the final objective, which a business is aimed at attaining through this architecture. In this scenario, it cannot be conceded as an architect however the possessors and the initiators who can get the advantages of new edition of TOGAF at the system deployment stage. Moreover, the architecture pays more attention on the soft areas of the arrangement as compared to the technical content side (Sante & Ermers, 2009) and (The Open Group, 2011). 6 I have presented below some of the publications of TOGAF 8.1.1. Basically, the Architecture Forum started its efforts on TOGAF V-9 (openly obtainable in Feb-2009). So in an attempt to comply with the requirements of TOGAF clients, a survey was carried out in the beginning of 2007 to verify the needs for the next version. This survey revealed three famous views: (Sante & Ermers, 2009) and (The Open Group, 2011) 6 TOGAF Architecture 7 Use of TOGAF 8 Advantages of TOGAF 9 Issues 11 Conclusion 11 References 12 Introduction When a system is built for a very specific purpose, for instance for processing a charge to an account we should be familiar with what we require carrying out and how we need to do it. However, the system architecture could be simple. Seeing that, in corporate applications, many thoughts approach that idea, what we require carrying out and how we need to do it, prior to starting system coding at the initial line. However, normally in large-size development projects, the person performing this idea is generally an IT architect. This person works as an in-charge for interpreting business needs into valuable software requirements. Additionally, in small development projects and small-size companies, this can be an extremely simple task. On the other hand, in large size companies, this could be a very complicated job. Luckily, there are facilitates available for resolving such tasks. In this scenario, the TOGAF (Open Group Architecture Framework) offers a tactic for analyzing a corporate specific state as well as changing it into actionable objects (Chase, 2006). This paper presents a detailed analysis of some of important aspects of TOGAF methodology. This paper will cover pros/cons, uses of TOGAF, TOGAF heritage and corporate applications. An Overview of TOGAF The Open Group Architecture Framework (TOGAF) is a structure that presents a comprehensive technique and a group of supporting systems and tools for building effective enterprise design. Additionally, it can be utilized without any restriction from any corporation desiring to build up enterprise architecture for use inside that association/business/corporate. In addition, this formwork was established by associates of The Open Group, functioning inside the Architecture Forum. However, the first version of TOGAF framework was developed in 1995. In addition, it was foundational upon Technical Architecture Framework for Information Management (TAFIM), built by the United States Department of Defense (DoD). In this scenario, the Department of Defense offered The Open Group open authorization and extensive support to build TOGAF by crafting the TAFIM. Thus, it was the fruit of many years of development attempts as well as a lot of investment comprising million of dollars of US Government. Moreover, by taking the advantage of this powerful base, the members of The Open Group Architecture Forum have built several editions of TOGAF every year and published every one on The Open Group public website (The Open Group, 2011) and (Chase, 2006). TOGAF Heritage As discussed above the Open Group Architecture Forum has built several versions of TOGAF at normal intervals as well as published every one on the web site of The Open Group. Additionally, every form of TOGAF standard is built collaboratively by the members of the design Forum. In addition, at present it consists of approximately 200 corporate members, comprising vendor and customer organizations. In this scenario, the development is carried out by architecture practitioners, with the content foundational upon most excellent practices that developed within the contributing member businesses (Sante & Ermers, 2009) and (The Open Group, 2011). Moreover, TOGAF was one of the primary representations with a powerful focus on procedure approached to structural design in the business. In this scenario, architecture can be considered as a business wide procedure that will be controlled by the business administration, through the support of corporate architect. Thus, the (corporate) planner has consequently become a very important person having organizational sensitivity (Sante & Ermers, 2009) and (The Open Group, 2011). Furthermore, the latest versions of TOGAF involve superior features, which focus on the use of architecture as well as its power. However, it came into view when TOGAF started tackling with other areas of knowledge. At this phase, what an organization has to attain through this arrangement turns out to be TOGAF’s main challenge. In the same way, in other similar developments such as in ITIL, maintaining this facility for the company is very important. In addition, TOGAF’s version 9 is the arrangement that is not the final objective, which a business is aimed at attaining through this architecture. In this scenario, it cannot be conceded as an architect however the possessors and the initiators who can get the advantages of new edition of TOGAF at the system deployment stage. Moreover, the architecture pays more attention on the soft areas of the arrangement as compared to the technical content side (Sante & Ermers, 2009) and (The Open Group, 2011). I have presented below some of the publications of TOGAF 8.1.1. Basically, the Architecture Forum started its efforts on TOGAF V-9 (openly obtainable in Feb-2009). So in an attempt to comply with the requirements of TOGAF clients, a survey was carried out in the beginning of 2007 to verify the needs for the next version. This survey revealed three famous views: (Sante & Ermers, 2009) and (The Open Group, 2011) An organization needs a closer arrangement to its business Organizations need straightforward application and superior usability The next edition of TOGAF has to be a development rather than a revolution The views discussed above offered the necessary ways to the system developers of TOGAF 9 to get started on the subsequent revision. In addition, rising changes in architecture like that service-oriented architecture and the focus on security were as well recognized by The Open Group visualization of ‘Boundary-less Information Flow’ (Sante & Ermers, 2009) and (The Open Group, 2011). TOGAF Architecture According to (Banerjee, 2011), the main feature of TOGAF is ADM. Here the important thing to keep in mind is that the “A” in ADM is architecture and not application. In the below given diagram, there are ten rings, however ADM is fundamentally a 4 step procedure. In the first step, we need to tailor TOGAF to outfit our requirements and this is a onetime process to be performed previous to our task of starting making use of TOGAF for our business. In the second stage, we need to establish scope of work as well as organize plan intended for rollout. Additionally, this task is performed in 6 separate stages. In the third phase we supervise development and implementation. This phase involves recognizing how the actual system development and implementation is performed inside the scope of TOGAF. In the last phase, we manage post-implementation changes. Some changes will trigger off one more cycle of ADM. In addition, we can have numerous ADM cycles concurrently working for diverse projects operational inside our organization. However, these projects need not be synchronized (Banerjee, 2011). Figure 1TOGAF: The Open Group Architecture Framework version 9, Image Source: http://setandbma.wordpress.com/2011/01/25/what-is-togaf-without-jargon/ Use of TOGAF TOGAF is supported by The Open Group, a business devoted to broadcast open standards in businesses. For instance, it is The Open Group that upholds the UNIX standard. In other words, if we want to place out an "industry-standard UNIX," we must ensure it complies with the conditions established by The Open Group (Chase, 2006) and (The Open Group, 2011). However, the architecture design is not a theoretically simple or straightforward procedure, as well as the design of heterogeneous, multi-vendor arrangements is very complex. In this scenario, TOGAF plays a valuable role in facilitating "de-mystify" the design development procedure and allowing IT clients to build fully open systems based ways for their business requirements. In addition, those IT clients who do not take interest in corporate architecture normally discover themselves pressed undeniably to single-supplier ways to get a built-in solution. However, at that position, despite how apparently "open" some single supplier's products to meet the requirements and standards, the client will be not capable to recognize the possible advantages of actually multi-vendor, heterogeneous open systems (Chase, 2006) and (The Open Group, 2011). IT client, who desires to set their corporate architecture functions on the base of open business arrangements of TOGAF, can be capable of acquiring training, tools and professional services by meeting TOGAF standards. However, the continuation of a qualifications program for TOGAF offers a powerful inducement for associations (both in public and private sector) to regulate this open technique for enterprise architecture, and accordingly keep away from lock-in to proprietary techniques. In addition, it can be a significant step for making enterprise architecture an effectively recognized arrangement, and for initiating severity into the purchase of services and tools for enterprise architecture (The Open Group 2, 2011). Advantages of TOGAF As TOGAF is advantageous thus it is significant for the corporate IT designer. At the present time, businesses no longer want to spend enough money to produce isolated systems that carry out single jobs and do not communicate with other systems. Nor can they overlook the result that real business circumstances enclose on their technology needs. In this scenario, enterprise architecture could be beneficial in establishing connection between a company and its technology arrangements, as well as TOGAF provides a standard method along with most excellent practices to help establish that link. In addition, the developers and architects who desired to be architects are able to influence TOGAF now, making their efforts more fruitful and more practical in industry both at the present and in future (Chase, 2006). Moreover, the clients who design and applied enterprise architectures through TOGAF get guarantee of a design and a procurement conditions that will really make this implementation simple, as well as will offer the advantages of open systems to accumulate to their businesses with minimum threat (Chase, 2006) and (OpenGroup3, 2011). The advantage of architectural domination comprises: (TOGAF, 2011) It increases simplicity of responsibility, as well as informed designation of authority Protection of existing advantages base by making use of existing architectural parts Practical control, administration and monitoring methods Concept or process and component use again all through the entire organizational business divisions Increases values throughout measuring, monitoring, feedback and evaluation Increases visibility facilitating internal procedures as well as external parties' necessities It also increases the visibility of decision-making at lesser levels makes sure omissions at a suitable level inside the corporate of decisions that can encompass far-reaching tactical outcomes for the organization. Especially, enterprise architecture more and more represents the foundational scholar property of the corporate. Implemented using available procedures and methodologies as well as complements functionality by incorporating control potentials Issues The Open Group is a not-for-profit corporation that is aimed at achieving better business competence by bringing together buyers and suppliers of information systems to diminish the obstructions of incorporating latest technology into the corporate. In other words, its objective is to understand the vision of boundary-less information flow. In this scenario, TOGAF is a main fraction of its policy intended for attaining this objective, and The Open Group desires TOGAF to be taken up as well as utilized in practical architecture projects, and the experience from its feedback to help improve it. In addition, the Open Group issues TOGAF on its public web server, and allows its demonstration and utilization free-of-charge to a number of organization desiring to utilize it to develop an enterprise arrangement (The Open Group, 2011). Conclusion This paper has presented a detailed analysis of some of the important aspects of TOGAF framework. The Open Group Architecture Framework (TOGAF) is a structure that presents a comprehensive technique and a group of supporting systems and tools for building effective enterprise design. Additionally, it can be utilized without any restriction from any corporation desiring to build up enterprise architecture for use inside that association/business/corporate. The Open Group Architecture Forum has built several versions of TOGAF at normal intervals as well as published every one on the web site of The Open Group. The latest versions of TOGAF involve superior features, which focus on the use of architecture as well as its power. TOGAF plays a valuable role in facilitating "de-mystify" the design development procedure and allowing IT clients to build fully open systems based ways for their business requirements. IT client, who desires to set their corporate architecture functions on the base of open business arrangements of TOGAF, can be capable of acquiring training, tools and professional services by meeting TOGAF standards. References Banerjee, U. (2011, January 25). What is TOGAF – without jargon. Retrieved July 22, 2011, from http://setandbma.wordpress.com/2011/01/25/what-is-togaf-without-jargon/ Chase, N. (2006, February 14). Introducing The Open Group Architecture Framework (TOGAF), Part 1: Understand TOGAF and IT architecture in today's world. Retrieved July 26, 2011, from IBM.com: http://www.ibm.com/developerworks/library/ar-togaf1/ OpenGroup3. (2011). Welcome to TOGAF™ -- The Open Group Architecture Framework. Retrieved July 25, 2011, from http://pubs.opengroup.org/architecture/togaf8-doc/arch/ Sante, T. v., & Ermers, J. (2009, September). TOGAF™ 9 and ITIL® V3: Two Frameworks Whitepaper. Retrieved July 25, 2011, from http://www.best-management-practice.com/gempdf/white_paper_togaf_9_itil_v3_sept09.pdf The Open Group 2. (2011). Welcome to TOGAF® Version 9 "Enterprise Edition". Retrieved July 22, 2011, from http://www.opengroup.org/architecture/togaf/ The Open Group. (2011). Introduction. Retrieved July 25, 2011, from http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap01.html TOGAF. (2011). TOGAF as an Enterprise Architecture Framework. Retrieved July 26, 2011, from http://www.togaf.info/togaf8/chap02.html Read More