Enterprise architects are practitioners of enterprise architecture; an information technology discipline that operates within large enterprises.

Role of enterprise architects

Enterprise architects operate across organizational and computing "silos" to drive common approaches and expose information assets and processes across the enterprise. Their goal is to deliver an architecture that supports the most efficient and secure IT environment meeting a company's business needs.

Enterprise architects are like city planners, providing the roadmaps and regulations that a city uses to manage its growth and provide services to its citizens. In this analogy, it is possible to differentiate the role of the system architect, who plans one or more buildings; software architects, who are responsible for something analogous to the HVAC (Heating, Ventilation and Air Conditioning) within the building; network architects, who are responsible for something like the plumbing within the building, and the water and sewer infrastructure between buildings or parts of a city. The enterprise architect however, like a city planner, both frames the city-wide design, and choreographs other activities into the larger plan.

Delivered successfully, an enterprise architecture has the potential to allow both the Business and IT strategies to enable and drive each other. Therefore, effective enterprise architecture may be regarded as one of the key means to achieving competitive advantage through information technology.

Responsibilities of enterprise architects

• Alignment of IT strategy and planning with company's business goals.
• Optimization of information management approaches through an understanding of evolving business needs and technology capabilities.
• Long-term strategic responsibility for the company's IT systems.
• Promotion of shared infrastructure and applications to reduce costs and improve information flows. Ensure that projects do not duplicate functionality or diverge from each other and business and IT strategies.
• Work with solution architects to provide a consensus based enterprise solution that is scalable, adaptable and in sync with ever changing business needs.
• Management of the risks associated with information and IT assets through appropriate standards and security policies.
• Direct or indirect involvement in the development of policies, standards and guidelines that direct the selection, development, implementation and use of Information Technology within the enterprise.
• Build employee knowledge and skills in specific areas of expertise.

Skills and knowledge

• Systems Thinking - the ability to see how parts interact with the whole (big picture thinking)
• Knowledge of the business for which the enterprise architecture is being developed
• Interpersonal and leadership skills - servant leadership, collaboration, facilitation, and negotiation skills
• Emotional intelligence - self awareness, confidence, ability to manage conflict, empathy
• Communication skills, both written and spoken
• Ability to explain complex technical issues in a way that non-technical people may understand
• Knowledge of IT governance and operations
• Comprehensive knowledge of hardware, software, application, and systems engineering
• Project and program management planning and organizational skills
• Knowledge of financial modeling as it pertains to IT investment
• Customer service orientation
• Time management and prioritization

Collaboration

• Business analyst
• System analyst
• Software architect
• Systems architect
• Application developer
• Release deployer
• IT Administrator
• Project manager
• Project management office
• CIO
• Business Leads

To be successful in large organizations, enterprise architecture requires a top-level mandate, executive buy-in, tools, deliverables, formal structures and governance, and resourcing. Other factors for success include business unit stakeholder buy-in, a non-centralist approach (federated effort with central coordination only), a strong theoretical base (get the basics right), a practical focus (avoid dogma), adaptable tools (evolve constantly), user and “business owner” feedback loops, as well as reinforcement through measurement.

See also

• Enterprise architecture

References

• IBM Developer Works: Article on SOA user roles
• Daljit Banger Rise of the Enterprise Architect, British Computer Society, March 2006

External links

Enterprise architecture is a term used to describe the practice of documenting the elements of business strategy, business case, business model and supporting technologies, policies and infrastructures that make up an enterprise. There are multiple architecture frameworks that describe Enterprise Architecture. Enterprise Architecture can be described as 1: documentation describing the structure and behaviour of an enterprise and its information systems, usually in a number of architecture domains. Or 2: a process for describing an enterprise and its information systems and planning changes to improve the integrity and flexibility of the enterprise.

It is the highest level, widest scope, longest term kind of architecture related to how information systems support the business processes of an enterprise. Thus, it is distinguishable from solution architecture and software architecture or enterprise application architecture, though it shares some general principles and techniques with architecture at those lower levels.

It describes the logical organisation of business processes and IT infrastructure. It reflects the integration and standardization requirements of the firm's operating model. Practitioners are called "enterprise architects". The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investments are aligned. As such, enterprise architecture allows traceability from the business strategy down to the underlying technology.

The general practice has gradually come to include a broad category of activities that help decision makers to understand, justify, optimize and communicate the structure and relationships between various business entities and elements. Among these latter practices are business architecture, performance management, organizational structure and process architecture.

Modelling the architecture of enterprises is becoming a common practice within the U.S. Federal Government in the context of the Capital Planning and Investment Control (CPIC) process. The Federal Enterprise Architecture (FEA) reference models serve as a framework to guide Federal agencies in the development of their architectures. Companies such as BP, Independence Blue Cross, Intel and Volkswagen AG have also applied enterprise architecture to improve their business architectures as well as to improve business performance and productivity.

Methodology

Often used in the context of information system's applications in an enterprise, Enterprise Architecture is really concerned with all aspects of an enterprise with information technology as a sub-context.

Enterprise architecture involves developing an architecture framework to describe a series of "current", "intermediate" and "target" reference architectures and applying them to align change within the enterprise. Another set of terms for these are "as-is", "migration plan" and "to-be".

A subtly different alternative approach (and use of terminology) begins with the development of an unconstrained "should be" strategic architecture which may be thought of as a "stretch view". The target architecture then becomes an intermediate step towards this idealized, unconstrained strategic architecture for a specific change initiative. It results from the real-world trade-offs between the "should be" desired state versus affordability, business policies and so on. Therefore, under this approach there is a subtle but important difference in the meaning of "target architecture": it is not the ultimate goal, but rather an achievable, planned state with a delivery date. A possible advantage of this approach is that the trade-offs become more explicit than if one simply deals with "as is" and "to be", without considering the "should be" stretch view provided by the strategic architecture. Reference architecture is often confused with strategic architecture, but encompasses the strategic architecture (the point on the horizon) and the other strategic building blocks, which may of course have become realised, that act as points of reference for each individual change initiative.

These frameworks detail all relevant structure within the organization including business, applications, technology and data. This framework will provide a rigorous taxonomy and ontology that clearly identifies what processes a business performs and detailed information about how those processes are executed. The end product is a set of artifacts that describes in varying degrees of detail exactly what and how a business operates and what resources are required. These artifacts are often graphical.

Given these descriptions whose levels of detail will vary according to affordability and other practical considerations, decision makers can make informed decisions about where to invest resources, where to realign organizational goals and processes and what policies and procedures will support core missions or business functions.

A strong enterprise architecture process helps to answer basic questions like:

• Is the current architecture supporting and adding value to the organization?
• How might an architecture be modified so that it adds more value to the organization?
• Based on what we know about what the organization wants to accomplish in the future, will the current architecture support or hinder that?

A value-based approach to implementing an enterprise architecture is recommended in order to realize quick wins, most notably when the team is first being formed. An analysis of key questions as listed above that provides the most value in an organization should lead the enterprise architecture team towards their highest priority tasks. Teams that spend too much time documenting the plan, without providing real value to decision makers, will be at risk of being disbanded.

Implementing enterprise architecture generally starts with documenting the organization's strategy and goals. One part of this work is the company's operating model, which describes how the company wants to operate. What are the requirements for business process standardization and integration.

The architecture process addresses documenting and understanding the discrete enterprise structural components, typically within the following four categories:

1. Business:
1. Strategy maps, goals, corporate policies, Operating Model
2. Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational models
3. Business processes
4. Organization cycles, periods and timing
5. Suppliers of hardware, software, and services
2. Applications:
1. Application software inventories and diagrams
2. Interfaces between applications - that is: events, messages and data flows
3. Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization
3. Information:
1. Metadata
2. Data models: conceptual, logical, and physical
4. Technology:
1. Hardware, platforms, and hosting: servers, and where they are kept
2. Local and wide area networks, Internet connectivity diagrams
3. Operating System
4. Infrastructure software: Application servers, DBMS
5. Programming Languages, etc..

Wherever possible, all of the above should be related explicitly to the organization's strategy, goals, and operations for planning and decision-making needs. The enterprise architecture is most useful when documenting the current state of the technical components listed above, as well as an ideal-world desired future state (Reference Architecture) and finally a "Target" future state which is the result of tradeoffs and compromises vs. the ideal state. Special software is available and becoming increasingly mature to handle the complex task of mapping the enterprise structure.

Such exhaustive mapping of IT dependencies has notable overlaps with both Metadata in the general IT sense, and with the ITIL concept of the configuration management database. Maintaining the accuracy of such data can be a significant challenge. Such databases are for managing the current state effectively, while EA repositories are employed for corporate project and strategic planning exercises.

Governance is the key process to keep organizational changes on target for meeting articulated goals and strategies defining the future state of the enterprise. Governance can be applied in various strengths from strongly enforced policies, to more subtle means such as the agreement and declaration of IT principles.

Enterprise Architecture requires appropriate positioning in the organization to be successful. One such analogy of city-planning is often referenced for enterprise architecture groups. A common issue for groups that are granted too much authority is becoming known as an "ivory tower" group, alienating the teams involved in following architectural governance. A combination of a federated and a small enterprise team can be the most successful implementation, with a focus on democratic instead of authoritarian team involvement.

An intermediate outcome of implementing an enterprise architecture process is a comprehensive inventory of business strategy, business processes, organizational charts, technical inventories, system and interface diagrams, and network topologies, and the explicit relationships between them. The inventories and diagrams are tools to support decision making at all levels of the organization. It is key that the information remain current to be relevant and useful; a process must exist to keep the information "evergreen."

The organization must design and implement processes that ensure continual movement from the current state to the future state, keeping the details current. The future state planning will generally be a combination of one or more:

• Closing gaps that are present between the current organization strategy and the ability of the IT organization to support it
• Closing gaps that are present between the desired future organization strategy and the ability of the IT organization to support it
• Necessary upgrades and replacements that must be made to the IT infrastructure using lifecycle management practices for infrastructure and technologies employed, to address ever changing regulatory requirements, and other initiatives not driven explicitly by any single team in the organization's functional management. One such example is Service Oriented Architecture, an ideal candidate for enterprise architecture team leadership.

Relationship to other disciplines

The following image from the 2006 FEA Practice Guidance of US OMB sheds light on the relationship between enterprise architecture and segment(BPR) or solution architectures. (From this figure and a bit of thinking one can see that software architecture is truly a solution architecture discipline, for example.)

Activities such as software architecture, network architecture, database architecture may be seen as partial contributions to a solution architecture, or at a lower level below solution architecture if you like.

Enterprise architecture frameworks

Artifacts

See also

• ANSI/IEEE 1471-2000 - Recommended Practice for Architecture Description of Software-Intensive Systems on the ISO/IEC 25961 standards track
• CLEAR Framework for Enterprise Architecture Atos Origin's Enterprise Architecture Framework
• DoDAF
• IDEAS Group A four-nation effort to develop a common ontology for architecture interoperability
• EABOK - The Guide to the Enterprise Architecture Body of Knowledge - U.S. Federal-funded guide to EA in the context of legislative and strategic business requirements.
• Executive Information System
• Federal Enterprise Architecture or FEA
• Enterprise Information Security Architecture - (EISA) can give a better understanding of the positioning of security within Enterprise Architecture.
• Enterprise Architecture Management
• Information Systems Audit and Control Association - the body that produces IT governance standards used by many governments
• Information technology
• IT Governance
• IT Portfolio Management
• IT Service Management
• MODAF The UK Ministry of Defence Architecture Framework
• OBASHI The OBASHI Business & IT methodology and framework
• RM-ODP ISO/IEC and ITU-T Reference Model of Open Distributed Processing
• Service-Oriented Architecture (SOA)
• TOGAF The Open Group Architecture Framework
• Zachman framework Zachman Enterprise Architecture Framework
• service-oriented modeling Bell Enterprise Architecture Modeling Framework (SOMF)
• [[EISSAF]Enterprise security architectural framework and metrics: Application to secure electronic voting systems

References