Enterprise architecture framework: Difference between revisions

Content deleted Content added
Monkbot (talk | contribs)
m Task 18 (cosmetic): eval 5 templates: hyphenate params (1×);
Moved "The Open Group Architecture Framework (TOGAF)" and "TOGAF"
Line 14:
[[File:Evolution of Enterprise Architecture Frameworks.jpg|240px|thumb|Overview of Enterprise Architecture Frameworks evolution (1987–2003).<ref name="SM03"/><ref>[[Jaap Schekkerman]] (2004) ''How to Survive in the Jungle of Enterprise Architecture Frameworks''. p.89 gives a similar scheme.</ref> On the left: The [[Zachman Framework]] 1987, [[NIST Enterprise Architecture Model|NIST Enterprise Architecture]] 1989, [[Enterprise Architecture Planning|EAP]] 1992, [[TISAF]] 1997, [[Federal Enterprise Architecture|FEAF]] 1999 and [[Treasury Enterprise Architecture Framework|TEAF]] 2000. On the right: [[TAFIM]] influenced by [[POSIX]], JTA, JTAA, [[TOGAF]] 1995, DoD TRM<ref>US Department of Defense (2001) ''[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.196.5206&rep=rep1&type=pdf Department of Defense Technical Reference Model]''. Version 2.0. 9 April 2001. p. 11, mentioned that also the DoD TRM is influenced by POSIX.</ref> and [[C4ISTAR|C4ISR]] 1996, and [[DoDAF]] 2003.]]
 
The earliest rudiments of the step-wise planning methodology currently advocated by The Open Group Architecture Framework (TOGAF) and other EA frameworks can be traced back to the article of Marshall K. Evans and Lou R. Hague titled "Master Plan for Information Systems"<ref>Evans, M. K. and Hague, L. R. (1962) ''Master Plan for Information Systems'', Harvard Business Review, Vol. 40, No. 1, pp. 92-103.</ref> published in 1962 in Harvard Business Review.<ref name="The_Practice_of_EA">Kotusev, Svyatoslav (2018) ''The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment''. Melbourne, Australia: SK Publishing.</ref>
 
Since the 1970s people working in IS/IT have looked for ways to engage business people – to enable business roles and processes - and to influence investment in business information systems and technologies – with a view to the wide and long term benefits of the enterprise. Many of the aims, principles, concepts and methods now employed in EA frameworks were established in the 1980s, and can be found in IS and IT architecture frameworks published in that decade and the next.<ref name="GB 2013">Graham Berrisford (2008-13) "[http://grahamberrisford.com/A%20brief%20history%20of%20EA.htm A brief history of EA: what is in it and what is not] {{Webarchive|url=https://web.archive.org/web/20130918061630/http://grahamberrisford.com/A%20brief%20history%20of%20EA.htm |date=2013-09-18 }}" on ''grahamberrisford.com'', last update 16/07/2013. Accessed 16/07?2003</ref>
Line 38:
In 1993, Stephen Spewak's book [[Enterprise Architecture Planning]] (EAP) defined a process for defining architectures for the use of information in support of the business and the plan for implementing those architectures. The business mission is the primary driver. Then the data required to satisfy the mission. Then the applications built to store and provide that data. Finally the technology to implement the applications. Enterprise Architecture Planning is a data-centric approach to architecture planning. An aim is to improve data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and cost containment. EAP has its roots in IBM's [[Business Systems Planning]] (BSP).<ref name="HISTORY" />
 
In 1994, the Open Group selected [[TAFIM]] from the US DoD as a basis for development of The Open Group Architecture Framework (TOGAF), where architecture meant IT architecture. TOGAF started out taking a strategic and enterprise-wide, but technology-oriented, view. It emerged from the desire to rationalize a messy IT estate. Right up to version 7, TOGAF was still focused on defining and using a Technical Reference Model (or foundation architecture) to define the platform services required from the technologies that an entire enterprise uses to support business applications.<ref name="GB 2013"/>
 
In 1996, the US ''IT Management Reform Act'', more commonly known as the [[Clinger-Cohen Act]], repeatedly directed that a US federal government agency's investment in IT must be mapped to identifiable business benefits. In addition, it made the agency CIO responsible for, “...developing, maintaining and facilitating the implementation of a sound and integrated IT architecture for the executive agency.”