As day goes by, the information and technology rapidly have been developing and growing around the world. Information Technology based programs which are called as IT, started and need to be professioned in order to make technology more efficient, active and reliable.
Enterprise Architecture is one of an IT (Information Technologies) terms whose goal is to help us to determine the target architecture of IT strategy. Changes according to customer needs and enables the application of IT solutions and services. That reason Enterprise Architecture has an important place in software life cycle.
First of all, we discuss the history of Enterprise Architecture. The birth of the architectures published in the article of the IBM Systems Journal in 1987, titled \"A framework for information systems architecture\" by J. A. Zachman . Later, Zachman renamed his \"information systems\" framework to be an \"enterprise architecture\" framework. Today, this framework is known as the Zachman Framework.
In 1994, the United States Department of Defense first introduced the Technical Architecture Framework for Information Management (TAFIM) . TAFIM was announced to be the new enterprise architectural standard for all defense work. TAFIM went through several iterations before it was finally stopped in 2000.
TAFIM was short time for a period, some pieces were adopted as known The Open Group Architectural Framework (TOGAF). TOGAF is an \"open source\" framework controlled by The Open Group, and it is now in version 8.1 . TOGAF is the most popular enterprise architecture framework in today, and then Zachman follows it.
In 1996, enterprise architectures rules have been developed in the U.S. Congress. In that year, Congress passed the Clinger/Cohen act, also known as the Information Technology Management Reform Act (ITMRA). This act gave the Office of Management and Budget (OMB) widespread authority to dictate standards for \"analyzing, tracking, and evaluating the risks and results of all major capital investments made by an executive agency for information systems.\" 
Clinger/Cohen establish a Chief Information Officer who was responsible for \"developing, maintaining, and facilitating the implementation of a[n] ... integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency\'s strategic goals and information resources management goals\". 
Clinger/Cohen has not even happened again for the concept of an enterprise architecture. But, the OMB interpreted this behavior as a task for US government. This framework is also known as the Federal Enterprise Architectural Framework (FEAF) . In these days, the Department of Justice, the Department of Homeland Security, the Department of Agriculture and every institution need an enterprise architecture created by OMB. For this reason, the result of Clinger / Cohen’s work done by the US Government or the US Government is subordinated to a single common corporate architecture. Secondly, to give information about the enterprise architect. Enterprise Architect provides information and manage the objectives, structure, function and systems used in the companies. As stated in this article of Carnegie Mellon University, an enterprise architecture is:
A means for describing business structures and processes that connect business structures.  This definition of article, has neither high cost nor business relevance associated with the development of an Enterprise Architect. Wikipedia provides the definition of enterprise architecture as:
The practice of applying a comprehensive and rigorous method for describing a current or future structure for an organization\'s processes, information systems, personnel and
organizational sub-units, so that they align with the organization\'s core goals and strategic direction. 
The Wikipedia definition is more relevant to today\'s enterprise architectural methodologies.
U.S. Government\'s Office of the CIO defines Enterprise Architect as:
A strategic information asset base, which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to the changing business needs.  It is inferred that; the aim of Enterprise Architect is to bring everything together in an environment that is proper and flexible.
Thirdly, mentions of Enterprise Architect discusses positive sides and advantages of Enterprise Architect. Let’s look at the failures of the various enterprise architecture methodologies, we need to understand what characteristics are shared by all of the failed attempts at creating enterprise architectures.
There is only one characteristic shared by systems, which is complexity. All of systems are highly complex. Major weakness of FEAF, TOGAF, and Zachman is probably their failure to manage system complexity.
Unfortunately, complexity is a big role. There are three cases that we can make about the future of IT:
Complexity is going to get bad.
If we don\'t find approaches to manage complexity, we are doomed to fail.
The existing approaches don\'t work.
As Richard Murch article published in InformIT:
To let IT infrastructures and architectures become increasingly complex with no action is unacceptable and irresponsible. If we simply throw more skilled programmers and others at this problem, chaos will be the order of the day...Until IT vendors and users alike solve the problem of complexity, the same problems will be repeated and will continue to plague the industry. 
Software development is complex and difficult processes require the synthesis of many disciplines. For modelling and design to code, project management, testing etc. enterprise architect has an important role to manage this complexity using UML, SysML, BPMN and other open standards. Enterprise Architect that helps you manage complexity include:
Diagrams for modelling strategic and business level concepts
Domain-specific profiles and reusable model patterns
Role based security to help the right people contribute truly.
Some typical errors in enterprise architectures are:
Platform—Many organizations attempt to define a standard software platform, having endless debating such as Microsoft .NET, IBM\'s WebSphere, or BEA\'s WebLogic. This effort is misplaced. Platform is an implementation decision, and it has no bearing on how the applications on those platforms will work together. As long as the platform meets the organization\'s interoperability requirements, the application team should be choosing the best platform for their application\'s needs.
Data—Many organizations attempt to define a single data layer that will be shared by all applications in the organizations. This effort is costly and rarely successful. Data storage should be treated as an implementation detail of an application.
Business Intelligence—Most organizations treat data and business intelligence interchangeably. Whereas data (such as how a customer is stored in a database) is an implementation detail business, intelligence (such as what business we have conducted
with a given customer) is an organizational asset. It is appropriate to decide how business intelligence will be shared. It is not appropriate to decide (at the enterprise level) how applications will keep track of the data that feeds this intelligence.
Code Sharing—Many organizations believe that reuse is achieved through code sharing. It is somewhat amazing that this belief persists, despite decades of failure to achieve this result. The best way to reduce the amount of code a project needs is through delegation of functionality (as in the case of Web services) not through code sharing.
Web Service APIs—Many organizations support that the use of Web services is critical to achieve interoperability. They think that the way applications use the Web service APIs should be standardized. The Web service APIs are far below the level of concern of applications. Applications typically make use of a buffering layer that is vendor-specific—for example, the Windows Communications Framework layer provided by the Microsoft .NET platform. The purpose of this layer is to insulate applications to understand the intricacies of the Web service APIs. This buffering layer is specific to the platform therefore it is the implementation details of the application
Now, let’s look at positive side and advantages of the Enterprise Architect. Enterprise Architect has a multi-user, graphical tool to build strong and continuously systems and using high quality for that reason you can truly shared easily.
According to the researches made by the users, Enterprise Architect has a fast performer and it is usable for extremely large models. Enterprise Architect easily includes large teams sharing the view of the enterprise and provides teams to collaborate efficiently on shared everything in their projects.
Business and IT systems
Software and systems engineering
Real-time and embedded development
Enterprise Architect helps individual, groups and large companies model and manage complex information and build verifiable model of what-is or what-will-be besides it provides stronger document and reporting tools with a full WYS/WYG template editor and also supports many languages like:
C and C++
Enterprise Architecture can be an important resource in helping an organization to find better ways to use technology to support its critical business processes. Unfortunately, many organizations spend tremendous attempting to create enterprise architectures, only to get limited, or even negative, value from the effort. Many million dollars failures are happened common across both the public and the private sectors.
Approaches to enterprise architectures based on partitioned iteration have several advantages over those based on recursion. Some of these advantages can be summarized as:
Better use of technology to solve pressing business problems.
Dramatic reductions in the cost of building complex systems.
Faster delivery of high-business-value technical projects.
Better control of overall system costs.
Improved accuracy in prediction of delivery dates.
Improved probability of overall system success.
An Enterprise Architect’s role is multi-faceted and extremely dynamic. Not only they keep track of IT concerns, but also those of the business. Through the work performed on strategic initiative, Enterprise Architect’s strive to make alignment between IT and the business more transparent.
Being an individual contributor with no alignment to the business or technology LOB group, often requires that an Enterprise Architect must call more on negotiation skills than technology skills. In this way, Enterprise Architect should be able to use an ability to influence the organization to do the right thing.
It is important to remember that enterprise architecture is about fostering community by providing reusable frameworks for decision making, repeatable processes, and assistance on mission-critical projects.
Enterprise Architect use by several project managers. The reasons can be:
Assigning resources to elements
Measuring risk and effort
Estimating project size and capacity
Implement change control and maintenance procedures.
Many enterprise-architectural methodologies have changed in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:
The Zachman Framework for Enterprise Architectures—Although self-described as a framework, it is more accurately defined as a taxonomy
The Open Group Architectural Framework (TOGAF)—Although called a framework, is more accurately defined as a process
The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
The Gartner Methodology—Can be described as an enterprise architectural practice In conclusion, Enterprise Architect provides information about and manage the objectives, structure, function, development processes and systems used in the companies that are important for software.
REFERENCES REFERENCES REFERENCES
 A framework for information systems architecture, by J.A. Zachman in The IBM Systems Journal, 1987, volume 26, number 3, pages 276–292.
 U.S. Department Of Defense. Technical Architecture Framework For Information Management (TAFIM) Volumes 1–8, Version 2.0. Reston, VA: DISA Center for Architecture, 1994.
 TOGAF (The Open Group Architectural Framework) Version 8.1 \"Enterprise Edition\" available at www.opengroup.org.
 Information Technology Management Reform Act of the One Hundred Fourth Congress of the United States at the Second Session.
 A Practical Guide to Federal Enterprise Architecture available at http://www.gao.gov/bestpractices/bpeaguide.pdf.
 Carnegie Mellon University, www.sei.cmu.edu/architecture/glossary.html.
 Wikipedia, http://en.wikipedia.org/wiki/Enterprise_architecture.
 Managing Complexity in IT, Part 1: The Problem by Richard Murch in InformIT, Oct 1, 2004.
MSDN Enterprise Architecture Center at http://msdn.microsoft.com/architecture/EA
...(download the rest of the essay above)