| IFEAD is
an independent research and information exchange organization
working on the future state of Enterprise Architecture.
|
|
|
|
Enterprise
Architecture Methods
| Extended
Enterprise Architecture [IFEAD] |
| 
STREAM
(Speedy,
Traceable,
Result
driven, Enterprise,
Architecture,
Management)
a Successful and Pragmatic 'Managed Diversity'
Enterprise Architecture Approach
So
how do you create a pragmatic managed diversity
Enterprise Architecture program driven by the
business?
Describing
and selling an EA program to any organization
is a challenge. Translating the “EA language”
into your organization’s jargon will add
credibility to your program. First, your organization’s
knowledge workers will understand the program’s
impact and value to their jobs. If they just
shake their heads, but don’t understand
the message, your credibility as a Lead Enterprise
Architect can be lost immediately.
This
instantly labels the Lead Enterprise Architect
as the book smart academic that can’t
apply EA into real world scenarios.
So
you need another approach like the successful
STREAM
(Speedy,
Traceable,
Result-driven,
Enterprise,
Architecture,
Management)
approach developed by the Institute For Enterprise
Architecture Developments in cooperation with
Logica Business Consulting that has proven its
value in real world scenarios.
The
STREAM Approach
This
STREAM approach is focused on balancing the
need for a set of standards with the need for
a diversity of solutions to increase innovation,
business growth and competitive advantage and
the need to deliver concrete added value in
an agile way.
The characteristics of the STREAM approach are:
• The Results
must be Traceable … in
order to add value: Start at the business side
and make all choices and decisions traceable
to the sources.
• The Process
must be Pragmatic ... in order
to add value: Focus only on those elements that
directly contribute to the goals & objectives.
Make a difference between EA thinking and EA
doing.
• The trajectory
must be Rapid ... in order to
add value: Most STREAM EA transformation / rationalisation
trajectories are delivering their results within
a 4 to 5 months timeframe.
• The Process
must be Productive ... in order
to add value: STREAM EA transformation / rationalisation
trajectories are delivering predefined type
of results, related to the goals & objectives.
• The Results
must be Relevant ... in order
to add value: STREAM EA transformation / rationalisation
/ legacy trajectories are always starting at
the business site and are delivering significant
added value due to the focus to contribute to
organisations strategic objectives & direction.
The
STREAM phases are based on the characteristics
of a managed diversity EA approach focused on
balancing the need for a set of standards with
the need for a diversity of solutions to increase
innovation, business growth and competitive
advantage in an agile way.
More
Info:
Are
you interested in the STREAM approach, then
download the STREAM
Paper or download the STREAM
Presentation.
|
|
The
Extended Enterprise Architecture (E2A) in the
world of organizations and Technology is addressing
3 major elements at a holistic way: The element
of construction, the element of function and
the element of style. Style is reflecting the
culture, values, norms and principles of an
organization. Most of the time, the term enterprise
architecture is dealing with construction and
function, without any attention of the style
aspect, while the style aspect reflects the
cultural behavior, values, norms and principles
of that organization in such a way that it reflects
the corporate values of that organization. At
the same time, the Enterprise Architecture addresses
the aspects of Business, Information, Information-Systems
and Technology Infrastructure in a holistic
way covering the organization and its environment
at zoning plan and city plan level.
Some
Enterprise Architecture
Guiding Principles
- No
Strategic Vison, No EA; If
you know where you are, but you don't know
where to go. Don't plan a journey.
- Good
is Good Enough;
An
Enterprise Architect knows he has achieved
the perfect solution not when there is nothing
left to add, but when there is, nothing left
to take away.
- The
Only Constant is Dynamics;
Dynamics is the only constant while adaptiveness
is the natural variable, so plan for this
constant.
- Pure
Logic is the ruin of the Spirit; Pure
logic is the ruin of the spirit and creativity
delivers unexpected opportunities, so use
your creativity.
- Be
Enterprising; If you want to create
an Enterprise Architecture, don't drum up
the architects to collect information and
don't assign them tasks and work, but rather
teach them to long for the endless value creating
possibilities of the enterprise.
Some
major EA principles from IFEAD's Best Practices
The
First Enterprise Architecture Guide that addresses
almost all the aspects of Implementing the Enterprise
Architecture Function.
The
purpose of this guide is to provide guidance
to organization's in initiating, developing,
using, and maintaining their enterprise architecture
(EA) practice. This guide offers a set of Enterprise
Architecture Good Practices that have proven
their benefits to organizations and that addresses
an end-to-end process to initiate, implement,
and sustain an EA program, and describes the
necessary roles and associated responsibilities
for a successful EA program.
EA
Good Practices Guide
SubTitle:
How
to Manage the Enterprise Architecture Practice
Trafford
Publishing, USA
ISBN:
1-4251-5687-8
by
Jaap Schekkerman
A
386 pages; quality trade paperback (softcover);
catalogue #07-2553; ISBN 1-4251-5687-8;
Price: US$73.12, C$73.12, EUR49.95, £37.75
This
Enterprise Architecture Good Practices Guide
is based on IFEAD's well known sets of EA guides
that are published over the years and enhanced
on feedback from users.
About
the Book: Enterprise
Architecture Good Practices Guide
The
purpose of this guide is to provide guidance
to organization's in initiating, developing,
using, and maintaining their enterprise architecture
(EA) practice. This guide offers a set of Enterprise
Architecture Good Practices that have proven
their benefits to organizations and that addresses
an end-to-end process to initiate, implement,
and sustain an EA program, and describes the
necessary roles and associated responsibilities
for a successful EA program.
Enterprise
Architecture is a complete expression of the
enterprise; a master plan which “acts
as a collaboration force” between aspects
of business planning such as goals, visions,
strategies and governance principles; aspects
of business operations such as business terms,
organization structures, processes and data;
aspects of automation such as information systems
and databases; and the enabling technological
infrastructure of the business such as computers,
operating systems and networks.
While
EA frameworks and models provide valuable guidance
on the content of enterprise architectures,
there is literally no guidance how to successfully
manage the process of creating, changing, and
using Enterprise Architecture.
This
guidance is crucially important. Without it,
it is highly unlikely that an organization can
successfully produce a complete and enforceable
EA for optimizing its business value and mission
performance of its systems. For example, effective
development of a complete EA needs a corporate
commitment with senior management sponsorship.
Enterprise Architecture development should be
managed as a formal program by an Enterprise
Architecture Department that is held accountable
for success.
Since
that EA facilitates change based upon the changing
business environment of the organization, the
enterprise architect is the organization’s
primary change agent.
Effective
implementation requires establishment of business
and system compliance with the enterprise architecture,
as well as continuous assessment and enforcement
of compliance. Waiver of these requirements
may occur only after careful, thorough, and
documented business case analysis. Without these
commitments, responsibilities, and tools, the
risk is great that business changes or new systems
will not meet organizations business needs,
will be incompatible, will perform poorly, and
will cost more to develop, integrate, and maintain
than is warranted.
For
more info about this go to the book webpage.
Download
book index here: Book index
For
ordering the book directly at the Publisher,
go to: http://bookstore.trafford.com/Products/SKU-000163288/Enterprise-Architecture-Good-Practices-Guide.aspx
Ordering
this guide directly at the website of the Publisher
is the easiest and fastest way of getting this
guide.
|
Another
View at Extended Enterprise Architecture
Viewpoints
This
article is trying to explain the important
role of Extended Enterprise Architecture
Viewpoints in the context of today's social-economic
circumstances.
It
describes and shows another view at Extended
Enterprise Architecture Viewpoints and
how to deal with the (extended) enterprise
stakeholders concerns. Based on the ideas
described in IEEE 1471-2000 about views
and viewpoints, a transformation of these
concepts into the Enterprise architecture
domain delivers another view at viewpoints
and views.
Looking
from the outside world to an Enterprise,
several groups of (extended) enterprise
stakeholders are influencing the goals,
objectives and behavior of the Enterprise.
Even so these groups of Enterprise stakeholders
have different concerns and therefore
different sets of viewpoints when we analyze
these extended enterprise stakeholders.
Clustering
their concerns in four generic categories
is showing the drivers of the Enterprise
and delivers the understanding of what
motivates your (extended) enterprise stakeholders.
Download
this article 370KB PDF
|
|
Version
1.5
Extended
Enterprise Architecture Framework Essentials
Guide
Extended
Enterprise Architecture (E2A)
Framework SM
Extended
Enterprise Architecture is dealing with the
processes and activities of extending the Enterprise
Architecture beyond its original boundaries,
defining a collaborative environment for all
entities involved in a collaborative process.
Download
the A0 format full version of the E2A framework
Version 1.4 (115Kb) 
Enterprise
Architecture Definition:
'Enterprise
Architecture is about understanding all of the
different elements that go to make up the enterprise
and how those elements interrelate'.
A
good definition of "enterprise"
in this context is any collection of organizations
that has a common set of goals/principles and/or
single bottom line. In that sense, an enterprise
can be a whole corporation, a division of a
corporation, a government organization, a single
department, or a network of geographically distant
organizations linked together by common objectives.
A
good definition of "elements"
in this context is all the elements that enclose
the areas of People, Processes, Business and
Technology. In that sense, examples of elements
are: strategies, business drivers, principles,
stakeholders, units, locations, budgets, domains,
functions, activities, processes, services,
products, information, communications, applications,
systems, infrastructure, etc.
Integrating the business as well as information aspects at a holistic
way, guarantees a natural alignment of Business
and Technology.
So, my statement is that you can't speak about Enterprise Architecture,
when the Business and Information aspects are
not incorporated in the approach at a holistic
way, aligning the needs of the Business with
the possibilities of the Technology.
 There
are a lot of organization today speaking and
writing about Enterprise Architecture, however
most of the time they only address the Technological
aspects of the Enterprise. Enterprise Architects
who are able to address all the aspects of the
Enterprise at a holistic way, will get the trust
of the top management for supporting change
of the organization by reducing and managing
the complexity and creating an atlas for change
in all aspect areas.
So
Enterprise Architects are not Techies with a
blind focus on technology, but very experienced
people with a broad Business and Technology
vision, able to create Enterprise value by translating
business opportunities and technology possibilities
at a holistic way into a continously change
cycle guided by the Extended Enterprise Architecture.
Enterprise
Architecture Process Cycle
The
Enterprise Architecture Process Cycle is describing
the stakeholders Win-Win processes and the role
of the Enterprise Architect in an ever challanging
environment, based on the use of an Enterprise
Architecture Framework. This article is written
in 2001 and has to be updated, however several
requests from readers forced us to publish the
original article again.
|
|
Enterprise
Architecture Deliverables Guide
Version 2.6
The
Enterprise Architecture Deliverables Guide is
giving an overview of the most common used EA
deliverables and models and is used in combination
with the EA Implementation Guide to implement
the EA function in organizations.
This
guide is not available as a for free publication
but is part of IFEAD's EA implementation strategy
and is used by our researchers and partners,
supporting organisations with the implementation
of EA preventing them for the pitfalls and mistakes
that unexperienced organisations often will
make. Verdonck, Klooster & Associates is
one of the partners of IFEAD that delivers EA
implementation services based on our books &
guides. |
|
|
 
Enterprise
Architecture Validation SM
Recent
Surveys of CEO's, CIO's and other executives
provide some evidence of the growing importance
of Enterprise Architecture over the last few
years. In one of the most recent studies of
the Institute For Enterprise Architecture Developments
(IFEAD), Enterprise Architecture was ranked
near the top of the list of most important issues
considered by top management, CEO's and CIO's.
The
precise, high-quality information an EA program
provides also make it much easier for the organization
to respond to the forces of change and make
better decisions. And finally, because an EA
program enables organizations to reduce duplication
and inconsistencies in information, they can
dramatically improve ROI for future Business
& IT implementations.
Download
the full version of the 'Enterprise Architecture
Validation' article (1.420 Kb PDF) |
|
Enterprise
Architecture Assessment Guide
Version
2.2
Today
the area of (enterprise) architecture in the
virtual digital world will become more and more
full-grown. So the focus is changing to the
quality of the work of enterprise architects.
How can we review the results of the work of
(enterprise) architects and how can we review
their process. Can we define quality criteria
to validate the products and results from other
architects?
This
document describes the main line of a methodology
/ approach in by several organisation to assess
the activities and results of enterprise architects.
The
effect of knowing that the results will be reviewed
is that enterprise architects are taking more
time and effort to implement and manage their
enterprise architecture processes effectively
as well as the take more attention to the quality
of their results and decision-making. |
 |
| European
Union - IDABC & European Interoperability
Framework |
| 
IDABC
stands for Interoperable Delivery of European
eGovernment Services to public Administrations,
Businesses and Citizens. It uses the opportunities
offered by information and communication technologies
to encourage and support the delivery of cross-border
public sector services to citizens and enterprises
in Europe, to improve efficiency and collaboration
between European public administrations and
to contribute to making Europe an attractive
place to live, work and invest.
IDABC
has published a set of 9 Horizontal Measures
fact sheets. The fact sheets provide
information on a series of key IDABC Infrastructure
Services such as CIRCA, eLink, Machine Translation,
PKI, eProcurement, eServices Toolkit and TESTA.
Two forerunners of the future European eGovernment
Services, Your Europe and IPM complete the series.
The fact sheets are available as a set or as
individual projects and free copies can be requested
by sending an e-mail to idabc@cec.eu.int. French,
German, Italian and Spanish translations are
being prepared and will be available in the
following months.
The
'European Interoperability Framework
for pan-European eGovernment Services now available
The EIF is the reference document on interoperability
for the IDABC programme. It is the result of
an extensive consultation process with the Member
States and thus represents the highest ranking
module for the implementation of European e-government
services.
This first version provides a series of recommendations
and defines generic standards with regard to
organizational, semantic and technical aspects
of interoperability, offering a comprehensive
set of principles for European co-operation
in e-government. The EIF will be periodically
revised to take into account the latest developments.
The EIF is the first publication using the logo
and visual identity of the new IDABC programme.
Download
the EIF Publication
EIF
publication (PDF) [1449 Kb]
Free copies of the EIF can be requested at idabc@cec.eu.int
More
information on about the EIF related activities
of the IDABC programme can be found at:
http://europa.eu.int/idabc/en/document/2319/5644
What
are ARCHITECTURE GUIDELINES?
The
Architecture Guidelines are an IDABC service
offering a framework for the establishment of
other IDA services, namely TESTA, CIRCA
and PKI,
and for users who wish to interoperate with
IDA and IDABC networks. It also offers general
advice on issues related to interoperability
between these services and with national applications
of the Member States.
The
Guidelines supplement the generic rules and
specifications of the European
Interoperability Framework (EIF)
on a technical level.
The
IDA
Architecture Guidelines describe
concepts and references to standards and specifications
for a trans-European eGovernment service built
on a well-defined common architecture. This
architecture is the basis for a trans-European
infrastructure that will enable easy and reliable
interchange of data and achieve a high interoperability
within and across different administrative sectors
and, also, with the private sector and the citizens.
The guidelines are regularly updated changing
along with the constantly evolving architecture
and its components. The current version 7.1
offers a large amount of information on middleware
technologies, an area that will be further extended
in the next version. As a central platform and
publishing tool, the guidelines offer access
to a variety of information sources and documents
that are related to the architecture. As HTML
and PDF formats, these references are facilitated
by hyperlinks. Divided into a number of sections,
part 1 (Main document) contains general guidance
and part 2 (Annexes) is the technical handbook
.
Download
the Architecture Guidelines:
|
|
| Business
Process Management Initiative (BPMI.ORG) |
| 
http://www.bpmi.org
BPML
The Business Process Modeling Language (BPML)
is a meta-language for the modeling of business
processes, just as XML is a meta-language for
the modeling of business data. BPML provides
an abstracted execution model for collaborative
& transactional business processes based
on the concept of a transactional finite-state
machine. More on BPML...
Download
the BPML 1.0 Specification (335Kb) 
BPMN
The Business Process Modeling Notation (BPMN)
specification provides a graphical notation
for expressing business processes in a Business
Process Diagram (BPD). The BPMN specification
also provides a binding between the notation's
graphical elements and the constructs of block-structured
process execution languages, including BPML
and BPEL4WS. The first draft of BPMN was made
available to the public on November 13, 2002.
Download
the BPMN 1.0 Draft Specification (1260Kb)
BPQL
The Business Process Query Language (BPQL) defines
a standard interface to forthcoming Business
Process Management Systems (BPMS). It allows
system administrators to manage the BPMS and
business analysts to query the instances of
business processes it executes. The Business
Process Query Language (BPQL) is a management
interface to a business process management infrastructure
that includes a process execution facility (Process
Server) and a process deployment facility (Process
Repository).
The
BPQL interface to a Process Server enables business
analysts to query the state and control the
execution of process instances managed by the
Process Server. This interface is based on the
Simple Object Access Protocol (SOAP).
The
BPQL interface to a Process Repository enables
business analysts to manage the deployment of
process models managed by the Process Repository.
This interface is based on the Distributed Authoring
and Versioning Protocol (WebDAV).
Process
models managed by the Process Repository through
the BPQL interface can be exposed as UDDI services
for process registration, advertising, and discovery
purposes.
|
|
|
OMB
releases EA Assessment
The
Office of Management and Budget has the second
version of its Enterprise Architecture Assessment
Framework. Agencies have until Feb. 28 2006
to submit their EA materials under this guideline,
according to a memo issued by Richard Burk,
director of the Federal Enterprise Architecture
Program Management Office.
Last
year, OMB announced it would evaluate
how well agencies complete and utilize their
EAs to save money, improve services and meet
their missions overall. OMB will use this
assessment to evaluate agency EAs as part
of the second quarter 2006. President’s
Management Agenda Scorecard.
Version
2.0 of the assessment framework supersedes
Version 1.5, published last year. While Version
1.5 focused on gauging how well agencies completed
their baseline EAs, Version 2 looks at how
well an agency actually uses its EA, and what
results the agency gets from the EA.
Download
OMB EA Assessment Framework Version 2.0 here. |
| 
WHAT
IS THE USA FEDERAL ENTERPRISE ARCHITECTURE(FEA)
To facilitate
efforts to transform theUSA Federal Government
to one that is citizen-centered, results-oriented,
and market-based, the Office of Management and
Budget (OMB) is developing the Federal Enterprise
Architecture (FEA), a business-based framework
for Government-wide improvement. The FEA is
being constructed through a collection of interrelated
"reference models" designed to facilitate cross-agency
analysis and the identification of duplicative
investments, gaps, and opportunities for collaboration
within and across Federal Agencies.
These models are defined as:
|
 |
US-NASCIO
Enterprise
Architecture Assessment Tour Report
USA-NASCIO’s Architecture Working Group
(AWG) conducted an assessment tour to facilitate
the evaluation of government enterprise architecture
programs and create opportunities for collaboration.
The NASCIO Enterprise Architecture Maturity
Model was used as the basis for evaluating
the enterprise programs in ten states, one
county, and one federal agency. This report
summarizes the tour and presents some of the
highlights from the presentations and discussions
that took place during the assessment visits.
This
report includes a list of lessons learned
along with links to websites and NASCIO’s
SMART resource library which contain most
of the documentation shared during these visits.
Download
the Enterprise Architecture Assessment Tour
Report
|
US
Federal Enterprise Architecture
Program Management Office Announce
the New
DATA REFERENCE MODEL (DRM)
The
Data Reference Model (DRM) describes,
at an aggregate level, the data
and information that support government
program and business line operations.
This model enables agencies to describe
the types of interaction and exchanges
that occur between the Federal Government
and citizens.
The
DRM categorizes government information
into greater levels of detail. It
also establishes a classification
for Federal data and identifies
duplicative data resources. A common
data model will streamline information
exchange processes within the Federal
government and between government
and external stakeholders.
Volume
One of the DRM provides a high-level
overview of the structure, usage,
and data-identification constructs.
This document:
-
Provides an introduction and high-level
overview of the contents that
will be detailed in Volumes 2-4
of the model;
-
Encourages
Community of Interest development
of the remaining volumes; and
-
Provides
the basic concepts, strategy,
and structure to be used in future
development.
The
DRM is the starting point from which
data architects should develop modeling
standards and concepts. This volume
establishes the foundation, which
describes essential components,
for subsequent DRM Volumes. These
combined volumes support data classification
- thus enabling horizontal and vertical
information sharing.
Download
here DRM Volume 1 (727Kb Pdf)
|
USA-OMB
releases EA Performance Reference Model
The
performance framework, defines four measurement
areas that will apply to the fiscal 2005 budget
formulation process:
Mission
and business results, for the outcomes
developed through the Government Performance
and Results Act strategic-planning process
Customer
results, for measuring the quality, accessibility
and timeliness of the services agencies provide
Processes
and activities, for rating the outcomes
of IT initiatives in terms of finances, productivity,
security, privacy and innovation
Technology,
for gauging costs and savings, quality, efficiency,
standardization, reliability and effectiveness
of the IT projects themselves.
Ultimately,
the Performance Reference Model will cover
human capital and other fixed assets, but
those two measurement areas will not be covered
in the performance framework for the fiscal
2005 budget.
Each
area contains measurement categories with
generic measurement indicators that agencies
can tailor to their own missions and IT projects.
|
| Federal
Enterprise Architecture Framework
The
Federal Enterprise Architecture Framework provides
an organized structure and a collection of common
terms by which Federal segments can integrate
their respective architectures into the Federal
Enterprise Architecture. The CIO Council developed
the Framework, which is nonrestrictive and easily
adaptable to all Federal Agencies especially
those with existing architectures.
Federal
Enterprise Architecture Framework (pdf 1817Kb)
 |
 |
|
PERFORMANCE
REFERENCE MODEL (PRM)
The
PRM is a "reference model" or standardized
framework to measure the performance of major
IT investments and their contribution to program
performance. The PRM has three main purposes:
Help produce enhanced performance information
to improve strategic and daily decision-making;
Improve the alignment-and better articulate
the contribution of-inputs to outputs and outcomes,
thereby creating a clear "line of sight"
to desired results; and
Identify performance improvement opportunities
that span traditional organizational structures
and boundaries.
The PRM attempts to leverage the best of existing
approaches to performance measurement in the
public and private sectors, including the Balanced
Scorecard, Baldrige Criteria, Value Measurement
Methodology, program logic models, the value
chain, and the theory of constraints. In addition,
the PRM was informed by what agencies are currently
measuring through PART assessments, GPRA, Enterprise
Architecture, and Capital Planning and Investment
Control. Agencies' use of the PRM will populate
the model over time. The PRM is currently comprised
of four measurement areas:
Download
the PRM version 2 (668Kb pdf)
Download
the DoD PRM v2 Supplement (40KB pdf)
|
Mission
and Business Results
The Mission and Business Results Measurement
Area of the PRM is intended to capture the
out-comes that agencies seek to achieve. These
outcomes are usually developed during the
agency budget and strategic planning process
prescribed under GPRA.
Customer Results
The Customer Results Measurement Area of the
PRM is intended to capture how well an agency
or specific process within an agency is serving
its customers. This is a critical aspect of
successful E-Government.
Processes and Activities
The Processes and Activities Measurement Area
is intended to capture the outputs that are
the direct result of the process that an IT
initiative supports. These outputs are much
more under the control of federal programs
and generally contribute to or influence outcomes
that are Mission and Business Results and
Customer Results. This Measurement Area also
captures key aspects of processes or activities
that need to be monitored and/or improved.
Technology
The Technology Measurement Area is designed
to capture key elements of performance that
directly relate to the IT initiative. An IT
initiative generally can include applications,
infrastructure, or services provided in support
of a process or program.
|
|
|
Federal
Enterprise Architecture Guide
This
guide builds upon, complements, and is directly
linked to the GAO Information Technology Investment
Management (ITIM) framework that was developed
to provide a common structure for discussing
and assessing IT capital planning and investment
control (CPIC) practices at Federal Agencies.
ITIM enhances earlier Federal IT investment
management guidance by extending the Select/Control/Evaluate
approach, mandated by the Clinger-Cohen Act,
into a growth and maturity framework. It is
also directly linked to the Federal Enterprise
Architecture Framework.
Federal
Enterprise Architecture Guide v1 (pdf 700Kb)
|
|
On
Enterprise Architectures, White House is
Leading
When
it comes to enterprise architectures, the
White House is leading by example.
In
a recent report, the General Accounting
Office rated the Executive Office of the
President’s modernization blueprint
as complete and at Stage 5 of GAO’s
tiered EA framework.
GAO
said the agency was the only one of 93 surveyed
that was wholly using an enterprise architecture
that met all the criteria of the audit agency’s
Version 1.1 maturity model.
Overall,
GAO found the government’s overall
progress stagnant when it comes to the development
and use of enterprise architectures. To
help agencies, GAO has over the past three
years issued two versions of an EA framework
that defines the pertinent features of crafting
a workable enterprisewide IT plan.
|
|
| The
Open Group Architecture Framework TOGAF |
The
new XML-based standard for IT architecture
interoperability
ADML
provides interoperability of architecture
information, both between architecture tools
and throughout the systems lifecycle.
|
| Object
Management Group - Model Driven Architecture |
| Zachman
Enterprise Architecture Framework |
|
The
Zachman Framework is a framework providing a
view of the subjects and models needed to develop
a complete Enterprise architecture. A picture
of this framework is available at the Zachman International web site.
The
Zachman Framework is a widely used approach
for developing and/or documenting an enterprise-wide
information systems architecture. Zachman based
his framework on practices in traditional architecture
and engineering. This resulted in an approach
which on the vertical axis provides multiple
perspectives of the overall architecture, and
on the horizontal axis a classification of the
various artifacts of the architecture.
The
purpose of the framework is to provide a basic
structure which supports the organization, access,
integration, interpretation, development, management,
and changing of a set of architectural representations
of the organization's information systems. Such
objects or descriptions of architectural representations
are usually referred to as artifacts.
The
framework, then, can contain global plans as
well as technical details, lists and charts
as well as natural language statements. Any
appropriate approach, standard, role, method,
technique, or tool may be placed in it. In fact,
the framework can be viewed as a tool to organize
any form of metadata for the enterprise. |
|
| Defense
/ C4ISR Architecture Framework |
|
The
acronym C4ISR stands for Command,
Control, Computers,
Communications (C4),
Intelligence, Surveillance,
and Reconnaissance (ISR).
The C4ISR Architecture Framework Version 2.0
is a framework giving comprehensive architectural
guidance for all of these related Defense and
DoD domains, in order to ensure interoperable
and cost effective military systems.
The
Framework is under revision to generalize it
to apply to all functional areas of the Department
of Defense. It is already being used in government
areas beyond the Defense sector.
The
impetus for the Framework was the realization
within the US Department of Defense that DoD
organizations across the world were developing
architectures representing specific contributions
and relationships with respect to overall DoD
operations, but that significant differences
in content and formats were inhibiting the ability
to rationalize or compare different architecture
descriptions. In turn, disparate and unrelatable
architecture products were leading to non-integrated,
non-interoperable, and non-cost effective capabilities
in the field.
The
C4ISR Architecture Framework is intended to
ensure that the architecture descriptions developed
by the various Commands, Services, and Agencies
within DoD are interrelatable between and among
each organization’s operational, systems, and
technical architecture views, and are comparable
and integratable across Joint and multi-national
organizational boundaries.
In
particular, the Framework:
- Assures
that architectures are integratable across
the Defense community
- Establishes
linkages or threads that tie together the
operational, systems, and technical views
of an architecture
- Provides
the basis for an audit trail that relates
current and postulated systems to measures
of effectiveness for mission operations
Download
C4ISR Version 2 Architecture Framework (3459Kb)
Other
NATO countries developed simular C3I or C4ISR
frameworks for their Enterprise Architecture
activities. |
Enterprise
Architecture Tools for Delivering Combat and
Business Capabilities |
|
|
|
Extended Enterprise
Architecture Framework / E2AF &
Extended Enterprise Architecture Maturity Model / E2AMM are Service Marks
(SM) registered by IFEAD |
