|
Enterprise architecture
|
|
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.[1] 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[2] have also applied enterprise architecture to improve their business
architectures as well as to improve business performance and productivity.
|
|
Enterprise Architecture is the formal organization (design or layout) of the components,
structures and processes required or relevant to the attainment of the goals and
visions invested or envisioned in an enterprise. 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: Business: Strategy maps, goals, corporate policies,
Operating Model Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational
models Business processes Organization cycles, periods and timing Suppliers of hardware,
software, and services Applications: Application software inventories and diagrams
Interfaces between applications - that is: events, messages and data flows Intranet,
Extranet, Internet, eCommerce, EDI links with parties within and outside of the
organization Information: Metadata Data models: conceptual, logical, and physical
Technology: Hardware, platforms, and hosting: servers, and where they are kept Local
and wide area networks, Internet connectivity diagrams Operating System Infrastructure
software: Application servers, DBMS 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.[citation needed] 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.
|
|
