INTRODUCTION TO SYSTEMS

INTEGRATION AND ENTERPRISE

ARCHITECTURE
 00. Overview

01. Importance of IT in Organizations

CONTENTS

Defining Systems Integration

02.
Defining Enterprise Architecture

03.
 OVERVIEW

The Role of IT in an organization is very important especially in enabling business

processes.
The organization should act as a single “big brain” always making best globally and locally
optimized business and IT decisions.
Systems/Enterprise integration is a progressive process; furthermore, its objectives have
changed with the increase of computerization in the society.
Enterprise architecture is the process by which organizations standardize and organize IT
infrastructure to align with business goals
 IMPORTANCE OF IT IN
ORGANIZATIONS
Most organizations nowadays are critically dependent on the daily operations of
Information Technology (IT). Large Companies/Organizations often to run and maintain
thousands of various IT systems to enable their business processes. The influence of IT
systems on business models is continuously increasing.
The role of IT in an organizations has evolved from purely technical and supporting
action to a more strategic or even business-enabling function. Information systems often
become a backbone of major organizational changes and transformations.
The capital investment in IT systems, IT budgets and infrastructure are steadily
increasing over time. The computing power and storage capacity of IT systems are
exponentially increasing.The relative price of IT systems are getting affordable making it
more accessible.
 People Trainings and Education to
system users

THREE BROAD Processes Introducing new improved

business processes enabled

ORGANIZATIONA by system

Decision Making procedures

L ASPECTS and rules

Technology Setting up new IT systems and

required infrastructure.

Providing Technical and

helpdesk support to users.
 INFORMATION SYSTEMS CAN HELP
ORGANIZATION EXECUTES THEIR BUSINESS
STRATEGIES AND GAIN COMPETITIVE
ADVANTAGES IN TERMS:

Operational Product Customer Intimacy

Excellence and differentiation and and focus
Cost Leadership leadership
 DEFINING SYSTEMS INTEGRATION

System integration is closely related to enterprise integration, which “is concerned

with facilitating information, control, and material flows across organizational
boundaries by connecting all the necessary functions and heterogeneous functional
entities (information systems, devices applications, and people) in order to improve
communication, cooperation and coordination within this enterprise so that the
enterprise behaves as an integrated whole, therefore enhancing its overall productivity,
flexibility, and capacity for management of change (or reactivity)”.
 ENTERPRISE APPLICATION
INTEGRATION (EAI)

one of the first architectural concepts to bring together the various

heterogeneous applications and information systems of an enterprise. The
goal was to integrate the various platforms, tools, and applications spread
across various departments and areas separated by organizational boundaries,
so that they could access the same data and communicate using a common
protocol.
 SYSTEM INTEGRATION 01. Interconnectivity
FOUR STAGES OF

02. Functional Interoperability

Semantic Interoperability
03.
Optimization and Innovation
04.
 01 Advances in computer
networks and information
processing.

DRIVERS FOR 02 Globalization

03 Need for organizational

SYSTEMS agility to cope with
competition and rapid

INTEGRATION development

04 Market positioning through

the customization of products
and services

05 Regulatory compliance
 ISSUES IN ENTERPRISE/SYSTEM
INTEGRATION

Nature of the The difficulties of The security threat

networking standardization to institutions and
technology individuals
 DEFINING ENTERPRISE
ARCHITECTURE

Enterprise architecture (EA) is the practice of analyzing, designing, planning

and implementing enterprise analysis to successfully execute on business
strategies. EA helps businesses structure IT projects and policies to achieve
desired business results and to stay on top of industry trends and disruptions
using architecture principles and practices, a process also known as enterprise
architectural planning (EAP).
 HISTORY

Professor Dewey Walker and his student, John Zachman formulated documents into the
more structured format of EA.

The EA framework came as a response to the increase of business technology, especially

in the 1980s when computer systems were just taking hold in the workplace. Companies
soon realized they would need a plan and long-term strategy to support the rapid growth
of technology and that remains true today.

Modern EA strategies now extend this philosophy to the entire business, not just IT, to
ensure the business is aligned with digital transformation strategies and technological
growth. EA is especially useful for large businesses going through digital transformation,
because it focuses on bringing legacy processes and applications together to form a more
 BENEFITS OF ENTERPRISE
ARCHITECTURE

EA can offer support for re-designs and re-organization, especially during major
organizational changes, mergers or acquisitions. It’s also useful for bringing more
discipline into the organization by standardizing and consolidating processes for more
consistency.

EA is also used in system development, IT management and decision-making, and IT

risk management to eliminate errors, system failures and security breaches. It can also
help businesses navigate complex IT structures or to make IT more accessible to other
business units.
 01 Allowing more open collaboration between IT
and business units
02 Giving business the ability to prioritize
investments
03 Making it easier to evaluate existing
architecture against long-term goals

BIGGEST 04 Establishing processes to evaluate and

procure technology

BENEFITS OF 05 Giving comprehensive view of IT

architecture to all business units outside of

EAP IT
05 Providing a benchmarking framework to
compare results against other organizations
or standards
 ENTERPRISE ARCHITECTURE
METHODOLOGIES

Enterprise architecture as a framework can be vague since it’s meant to address the
entire organization, instead of individual needs, problems or business units.
Therefore, several frameworks exist to help companies effectively implement and
track EAP.
FOUR LEADING ENTERPRISE
ARCHITECT PLANNING (EAP)
METHODOLOGIES
TOGAF provides principles for
designing, planning, implementing and THE
governing enterprise IT architecture.
The TOGAF framework helps OPEN
businesses create a standardized
approach to EA with a common GROUP ARCHITECTURAL
vocabulary, recommended standards,
compliance methods, suggested tools FRAMEWORK (TOGAF)
and software and a method to define
best practices. The TOGAF framework
is widely popular as an enterprise
architect framework, and according to
The Open Group it’s been adopted by
more than 80 percent of the world’s
leading enterprises.
 The Zachman framework is named after
one of the original founders of enterprise

THE architecture and it’s another popular EA

methodology. It’s better understood as a
ZACHMAN FRAMEWORK
“taxonomy,” according to CompTIA, and
FOR ENTERPRISE it spans six architectural focal points and

ARCHITECTURE six primary stakeholders to help

standardize and define the IT architecture
components and outputs
FEAF was introduced in 1996 as
a response to the Clinger-Cohen
act, which introduced mandates FEDERAL ENTERPRISE
for IT effectiveness in federal
ARCHITECTURE
agencies. It’s designed for the
U.S. government, but it can also FRAMEWORK (FEAF)
be applied to private companies
that want to use the framework.
 After acquiring The Meta Group in
2005, Gartner established best practices
for EAP and adapted them into the
company’s general consulting practices.
While it’s not an individual framework,
GARTNER CompTIA recognizes it as a “practical”
methodology that focuses on business
outcomes with “few explicit steps or
components.”
 ENTERPRISE ARCHITECT ROLE

Enterprise architects typically report to the CIO or other IT managers. They’re

responsible for analyzing business structures and processes to see that they align with
business goals effectively and efficiently. As an enterprise architect, you’ll also be
responsible for ensuring these structures and processes are agile and durable, so they
can swiftly adapt and withstand major change.
THANK YOU!
ISYSTEMS INTEGRATION AND ARCHITECTURE

Module 2: Overview of
Enterprise Architecture
Frameworks
 A Framework can be defined as a real or concept structure intended to

serve as a support or guide for the building of something that expands the

structure into something useful. In computer systems, a framework is often

a layered structure indicating the kind of programs can or should be built

Overview and how they would interrelate. The layered structure mentioned is

described as a vertical layer where at the top you want to see the most

abstract and at the bottom is more of real infrastructure hardware and

components. This Model documents the architecture-centric concepts

associated with enterprise development.

The Enterprise Architecture
Framework
A framework is a formal structure of giving you a list of the key elements that key factors we
use in enterprise architecture.
 Skeleton/Structure
• It is an outline when you practice Enterprise Architecture.

Classification of Schema or Ontology

Four Characteristics • Classification of Schema is the way of describing the object,

of Enterprise components that makes up and EA and group it together

based on its characteristics.
• Ontology is a set of concepts and categories in a subject

Architecture area or enterprise architecture that shows their properties

and the relations between them.
Thinking Tool
Framework It helps to think about the Enterprise Architecture, on how to
develop it on the future. It provides you different options and
ways to configure or implement your enterprise architecture

Management Tool
The EA is a management tool, it helps us to evolve the
Enterprise Architecture. It also helps you to move it from current
state to a target state. It gives you the capabilities that the
business requires
IEEE 14071:2000

The enterprise architecture was based

from a construction or civil architecture.
This has become a basis of most
software intensive systems such as
information system, embedded systems
and composites. And also this is
adopted by most framework of
enterprise architecture.
Different Views (i.e. Business Services View) are collected by the System Architecture.

An organization desiring to produce an architecture framework for a particular domain can do so

by specifying a set of viewpoints and making the selection of those viewpoints normative for any
Architectural Description claiming conformance to the domain-specific architectural framework.

This standard provides a conceptual framework which meant to explain how the key terms relate
to each other in a conceptual model for architectural descriptions. It also tackles the role of
stakeholders in the creation of architectural description. It also provide a number of scenarios for
the architectural activities during the life cycle.
 The Zachman Framework
for Enterprise Architecture

Enterprise architecture was developed by John Zachman while with IBM in the 1980 s
after observing the building and airplane construction industries and the IT industry. He
saw similarities between the construction of buildings, airplanes, and the information
systems used by an enterprise
 Roles
• Owner
• Designer
• Builder

These industries manage the design, construction, and maintenance

of complex products by considering the needs of different people. The
figure above illustrates the owner in the building industry, who uses
architect’s drawings to decide that the building addresses specific
requirements. For airplane manufacture, the owner uses the
high-level work breakdown structure of the plane to determine
requirements. For information systems, the owner uses a model of
the business to determine the enterprise needs.
The designer, however, needs a different set of diagrams: architect’s
plans for the building, sets of engineering design diagrams for the
plane, or information system models for the enterprise.
The builder relies on still different types of diagrams: contractor’s
plans for construction of the building, a manufacturing engineering
design for plane construction, or technology models for information
Abstractions
• What (material) is made of
• How (process) it works
• Where (geometry)
What is needed is important to know. This is represented in Figure above
by material, such as bills of materials for buildings and planes, and data
models for information systems. How these are used is indicated by
functions, such as functional specifications for buildings and planes, and
functional models for information systems. Where is also important, as
indicated by location—in drawings for building and plane construction
and in network models for information systems.
To complete the Zachman Framework for enterprise architecture,
additional interrogatives added (Who, When, and Why). Bringing these
concepts together, the result is a matrix of five rows and six columns.
These represent the perspectives of the planner, the owner, the
designer, the builder, and the subcontractor, who are all interested in
what, how, where, who, when, and why.
The last row addresses the functioning enterprise. The sixth row is not
 Easy to understand.
It provides a holistic perspective on the whole enterprise while at
the same time allowing to focus on certain aspects of the object.
Thus, informed decision making with regards to creating,

Advantages of the operating, and transforming the enterprise is enabled.

It addresses the enterprise as a whole, it is

Zachman framework defined independently of tools or methodologies,
and any issues can be mapped against it to
understand where they fit
 1 The large number of cells, which is an obstacle for the
practical applicability of the framework

Drawback of the 2 The relations between the different cells are not that
well specified
Zachman
3 Does not give a step-by-step process for creating a new

framework architecture

4 Does not give much help in deciding if the future

architecture we are creating is the best architecture
possible
5 Does not give an approach to show a need for a future
architecture
The Open TOGAF Framework

The Open Group Architecture Framework (TOGAF) is a framework with a detailed method
and a set of supporting tools - for developing an enterprise architecture. It may be used freely
by any organization wishing to develop an enterprise architecture for use within that
organization.

TOGAF is developed and maintained by members of The Open Group, working within the
Architecture Forum (www.opengroup.org/architecture).
History
The original development of TOGAF Version 1 in 1995 was based on the Technical
Architecture Framework for Information Management (TAFIM), developed by the US
Department of Defense (DoD). The DoD gave The Open Group explicit permission and
encouragement to create TOGAF by building on the TAFIM, which itself was the result
of many years of development effort and many millions of dollars of US Government
investment.

Starting from this sound foundation, the members of The Open Group Architecture
Forum have developed successive versions of TOGAF and published each one on The
Open Group public web site.

Using TOGAF as the architecture framework will allow architectures to be developed

that are consistent, reflect the needs of stakeholders, employ best practice, and give
due consideration both to current requirements and to the likely future needs of the
business.

Architecture design is a technically complex process, and the design of heterogeneous,

multi-vendor architectures is particularly complex. TOGAF plays an important role in
helping to "de-mystify" and de?risk the architecture development process. TOGAF
 Architecture Capability Framework

This part discusses the organization, processes, skills, roles, and

responsibilities required to establish and operate an architecture
practice within an enterprise

Architecture Development Method

This is the core of the TOGAF framework. It describes the
TOGAF TOGAF Architecture Development Method (ADM) – a
step-by-step approach to developing an Enterprise Architecture.

consists Architecture Content Framework

This part describes the TOGAF content framework, including a
structured metamodel for architectural artifacts, the use of
re-usable architecture building blocks, and an overview of typical
architecture deliverables.
Enterprise Continuum & Tool
This part discusses appropriate taxonomies and tools to
categorize and store the outputs of architecture activity within an
enterprise
 Benefits of TOGAF
Any organization undertaking, or planning to undertake, the design and implementation
of an enterprise architecture for the support of mission-critical business applications will
benefit from use of TOGAF.

Organizations seeking Boundary-less Information Flow can use TOGAF to define and
implement the structures and processes to enable access to integrated information
within and between enterprises.

Organizations that design and implement enterprise architectures using TOGAF are
assured of a design and a procurement specification that can facilitate an open systems
implementation, thus enabling the benefits of open systems with reduced risk.
Components of
Enterprise
Architecture
Overview
An enterprise’s architecture is the
engineering and structure of the enterprise’s
mission, organizations, functions and
database domains so that they can be
extended and/or integrated with other more
technical architectures such as hardware,
business information systems, and business
events. It describes the contents of the
enterprise’s architecture and its high level
model that tells how it is created.

The enterprise architecture model comprises

architectural components that serves as a key
for identification of the Resources and their
The Four
Primary • Enterprise Business Architecture
• Enterprise Information Architecture

components • Enterprise Solution Architecture

• Enterprise Technology Architecture

of Enterprise
Architecture
The Enterprise Business Architecture (EBA)
documents the business strategy, governance,
organization and business functions. EBA also
establishes a baseline that defines which organizations
perform these functions.

It also provides a holistic view of our state

government from a business perspective. It answers
questions like, Who we are?, What we do?, and
Where we want to go?
Enterprise
It is gives a common reference model of citizens, Business
businesses, members of General Assembly, current
and future administrations, and other interested parties Architecture
that helps define the business of state of government.
Enterprise EIA provides a framework, model, and method
to enhance each agency’s to quickly discover

Information access, and understand data, while creating

information needed to support critical agency

Architecture business function decisions.

 The EIA framework must have three
components that contain information
about the enterprise’s data assets
Data Sharing (How do Data Description (What Data Context (How do
I exchange the data?) does the data mean?) I find the data and
• Information Exchange and access it?)
Query Points – Information • Structured- Organized • Subject Area - Broad
generated/required by a description of data to convey Categories of data that
Unit of work and is semantic understanding supports business processes.

subsequently passed to usually through an entity • Information Class - Groupings

relationship diagram. of lines of business or
another unit of work.
• Semi Structured- Data that has community of interest.
characteristics of both
Structured and Unstructured
such email.
• Unstructured – data that is
more free-form format such as
Enterprise Solution
Architecture
ESA is the collection of information
systems supporting or related to the
business functions defined by EBA and
the enterprise business model, including
applications and components that are
purchased or custom-developed. Also
known as Enterprise Application
Architecture.
ESA includes:
Inventory Solutions, Analysis of current/baseline
applications, and components solutions, and current technology
currently used to support tools supporting existing
business functions in an automated solutions.
enterprise.

ESA governance and

Future-state recommendations of
implementation requirements.
automated solutions and related
tools.
 Enterprise Technical
Architecture
ETA is a consistent set ETA domains:
of IT standards and • Security
• Enterprise system Management
models that: • Information
• Reflect and support EBA, EIA, and ESA • Database
components. • Applications
• Guides the engineering of emerging IS • Integration
and technology infrastructure. • Platform
• Networking and Telecommunications.
SYSTEM INTEGRATIONS AND ENTERPRISE ARCHITECTURE

Enterprise Information
Architecture Concepts
 The heart of IA is information and knowledge, and we need to build on that
foundation. EIA’s should better understand their organization’s business
strategy and integrate the strategic vision in order to contribute to the
development of business strategy. This can be done with a good IT governance
framework.

Conceptual as well as on the Logical Layer, both represent well-defined layers

describing the EIA Reference Architecture. The architecture decisions that we
Overview then use to drill-down from the conceptual view to the logical view. The
component model of the EIA Reference Architecture is covering the relevant
services with its descriptions and interfaces to describe the functional
components in terms of their roles and responsibilities, their relationships and
interactions to other components, and the required collaboration to allow the
implementation of specified deployment and customer use case scenarios. The
operational?modeling approach provides a view on how physical nodes can be
derived from logical components of the component model and related
deployment scenarios. This uses of operational patterns on how Information
Services can be constructed to achieve functional and nonfunctional
requirements.
EIA Data Domains, Information
Governance, and Information
Security
 01 Metadata Domain
Data Domains Defined as “data about the data.” Metadata is the information that
Data domains classifies information assets used describes the characteristics of each piece of corporate data asset
for specific purposes where the purpose identifies and other entities.
02 Master Data Domain
usage patterns with a dedicated set of capabilities.
Refers to instances of data describing the core business entities,
such as customer or product data.
Certain types of data might be used
03 Operational Data Domain
enterprise-wide and others might be used only
Also referred to as transactional data capturing data, which is
locally within a department or a Line of Business
derived from business transactions.
(LOB). The data might be structured (for 04 Unstructured Data Domain
example, an order) or unstructured (for example, Also known as content, typically managed by an enterprise content
a scanned contract document). The data might management application.
also differ from a retention perspective indicating 05 Analytical Data Domain
how long the data must be stored. Usually derived through transformation from operational systems
to address specific requirements of decision support applications.
 IT Governance and Information
Governance
IT Governance is the key to deriving architectural decisions. Rather than
trying to define what good architectural decisions are (nearly impossible
because it is problem and context specific), we describe a typical governance
framework to help drive architectural principles, policies, and decisions that
can be agreed and policed by all relevant parties
Standard of IT 01 IT principles
High-level statements about how IT will be used to create business

Governance
For IT Governance, many standards do exist but
value and a generic information-centric set

02 IT architecture
one common example is the COBIT standard
The set of technical choices that guide the enterprise in satisfying
(Control Objectives for Information and related
business needs.
Technology), which is owned by the IT
Governance Institute. From the COBIT 03 IT infrastructure strategies
perspective, IT Governance is considered a Describes the approach to building shared and standard IT services
framework to govern IT assets over their across the enterprise
lifecycle.
04 Functional business requirements
Good IT Governance ensures that the IT group Refers to applications that need to be acquired or built
supports and extends the company strategies and
business objectives. The decision making process 05 Prioritization of IT investments
on how information systems are planned and The whole process of IT investments, including where they should

organized, acquired and implemented, delivered be focused and the procedures for progressing initiatives, their
and supported, as well as monitored and justification, approval, and accountability.
evaluated. It should therefore be just another
 Information Governance
Information Governance is defined as the orchestration of people, processes, and
technology to enable an organization to leverage information as an enterprise asset. It
specifically details the area associated with managing issues such as incomplete data,
poor or untimely access to data, lack of or poor Metadata, and managing and resolving
duplicate (or similar) data.

The key objectives of an Information Governance program need to first establish a

culture that recognizes the value of information as an enterprise asset. This requires real
discipline and possibly the creation of new roles within the business that didn’t exist
previously (for example, Information Stewards for information assets).
The development of effective Information Governance drives value into companies in many ways, including:

01 Compliance and regulatory adherence satisfies auditors and regulators by developing data management environments
leveraging technology and process to ensure adherence to specific requirements.

02 Enhanced BI capabilities using high-quality information drives new opportunities for organic growth (for example, by
identifying opportunities for increased effectiveness in cross-selling and retaining existing customers)

03 Enhanced alignment of IT initiatives with business strategies drives more value and enables the business through data
availability and enrichment, which enables insightful strategic planning and execution.

04 Improved platforms measure, monitor, and improve business performance by tying operational metrics to business
performance measures and facilitating reporting and management of critical processes.

05 Reduced environmental complexity improves business flexibility and accelerates strategic initiatives by providing
comprehensive and predictable information environments that support effective business decision making.
Information Security and Information
Privacy
Information Security and Information Privacy is another aspect of managing
and controlling the information assets which are exposed to a growing number
of security threats today. This is focus for our business information, and then
we look at the potential areas in which information could be seen to be under
risk in a typical enterprise information scenario.
Trends around the security aspects of business systems:

01 Across the globe there has been a growing number of attacks on major enterprises with (internal inspired) threats still
high.
02 Business infrastructures, such as utility networks for water or electricity, are increasingly equipped with sensors to
capture information. The information is used, for example, to predict peak consumptions.
03 The Cloud Computing delivery model requires new means to federate identities across internal and external systems to
protect data from unauthorized access.

04 Regulatory compliance pressures around the world across all industries demand strict enforcement of data access and
Information Privacy.

05 Access by partners to internal systems is ever increasing as the new trends to distributed solutions and cooperation across
business boundaries take place.

06 As systems design leads to more consolidated data sets (around core enterprise-wide DW and MDM capabilities), the
opportunity to hack one’s critical resource can actually increase.
There are many areas in which we must address Information Security in our business.

01 Business Security Services

Defined as security aspects of the business that must be specified, owned, and managed for successful and secure
operations of an enterprise. These are driven by regulatory concerns, partnerships, competitive influences, and more.

02 IT Security Services
Form the core technical components that must be designed and deployed around our data domains to deliver the security
functions as defined in the Business Security Services layer. This means that the IT Security Services layer is responsible
for addressing how the business security services are physically deployed.

03 Security Policy Management

Defined as a set of policies and principles that ensure that the Business Security Services are managed in a consistent
manner with IT. Therefore, the Security Policy Management links the business-related and IT-related security services
together
Data masking is rapidly gaining prominence 01 Meet regulatory compliance needs.
when dealing with data such as test databases 02 Enhance data security.
and the requirement to enable structurally 03 Protect against internal or external attacks as the data has little or
integral data sets without exposing live data to no external value.
the developers or designers. 04 Enable the use of production data within exposing private,
As defined by IBM, data masking is the process sensitive or confidential data to any non-trusted party.
of identifying sensitive data and overlaying
values that masks the sensitive data, but does not
compromise the functional integrity of an
application. By enabling data masking in the
business, it seeks to manage the following issues
in today’s businesses:
There are two techniques in Data masking:

01 Extract-Mask-Transform-Load (EMTL)
Uses an enhancement to the well-known Extract-Transform-Load (ETL) mechanism often used with Data Warehouse
environments. This is the process of extracting data from production into flat files while masking the data and finally
loading the data into multiple different environments.

02 In-Place Data Masking

Data is first copied from production into multiple environments and then masked in place.
 Conceptual and Logical View of
Enterprise Information Architecture

The conceptual and logical layers are the first elements for a solution design with the latter fleshing out the
former. Both represent well-defined layers describing the EAI Reference Architecture.
For the Conceptual Layer, the EIA Reference Architecture is necessary because of its capabilities for in the
context of the architecture terms and the Enterprise Information Model. An Architecture Overview Diagram
(AOD) shows the various required capabilities in a consistent, conceptual overview for the EIA Reference
Architecture. By introducing architecture principles, we guide the further design of the EIA Reference
Architecture. We apply them to drill-down in a first step from the Conceptual to the Logical Layer. We show
the Logical View as a first graphical representation of the logical architecture and explain key Architecture
Building Blocks (ABB).
 Conceptual Architecture Overview

An EIA provides an information-centric view on the overall Enterprise Architecture. Thus, any instantiation of the EIA
Reference Architecture enables an enterprise to create, maintain, use, and govern all information assets throughout their
lifecycle from a bottom-up perspective. From a top-down perspective, business users and technical users articulate their
information needs in the context of business processes shaping the business and application architecture based on the role
they perform. We develop the EIA Reference Architecture from a top-down perspective.

We look at information from an end user perspective working with or operating on it to achieve certain goals. Key
functional and technical capabilities provide and enable the set of operations on information required by the user
community of an enterprise. Thus, we approach the Conceptual View of the EIA Reference Architecture presented in an
AOD by introducing from a business Perspective the required functional and technical capabilities.
The EIA must cover all five data domains with appropriate capabilities as required by each individual
domain. Furthermore, there are several capabilities required that span across either some or all data
domains. Building an EIA Reference Architecture that satisfies the more advanced business requirements
of today and the upcoming ones in the future, we see the need for the following additional capabilities:

01 Predictive Analytics and Real Time Analytics

• Predictive Analytics are capabilities allowing the prediction of certain values and events in the future. For example,
based on the electricity consumption patterns of the past, an energy provider would like to predict spikes in
consumption in the future to optimize energy creation and to reduce loss in the infrastructure.
• Real Time Analytics are capabilities to address the need to analyze large-scale volumes of data in real time. Real
Time Analytics capabilities consist of the ability of real time trickle feeds into the DW, the ability of complex
reporting queries executing in real time within the DW, and the ability of real time delivery of analytical insight to
front-line applications.
02 Business Performance Management
• Define the Key Performance Indicators (KPI) for the business.
• Monitor and measure against the defined KPIs on an ongoing basis.
• Visualize the measurements in a smart way enabling rapid decision making.
• Complement the visualization with trust indices about the quality of the underlying data putting the results in context
regarding their trustworthiness.
• Intelligently act if the measurement of the KPIs indicates a need to act.
• Trigger events and notifications to business users if there are abnormalities in the data.
• This capability often depends on strong analytical application capabilities.
03 Enterprise Information Integration (EII)
• Provides abilities to understand, cleanse, transform, and deliver data throughout its lifecycle.
• Data harmonization from various Operational Data sources into an enterprise-wide DW.
• For cost and flexibility reasons, hiding complexity in the various, heterogeneous data sources of new applications
should not be implemented in such a way that they are tied to specific versions of these data sources. Thus federated
access must be available.
• Re-use of certain data cleansing functions such as standardization services in an SOA to achieve data consistency and
improve data quality on data entry must be supported. This requires deploy capabilities of data quality functions as
services.
04 Mashup
• Mashup capabilities enable a business to quickly build web-based, situational applications at low cost for typically
small user groups (for example, all members of a department). The Mashup capability must allow non-technical users
to create new value and insight from the combined information by mashing together information from various
sources.
05 Information Governance

06 Information Security and Information Privacy

• A crucial part for the design, deployment, and control processes of any instantiation of the EIA throughout its life
cycle. The Information Governance capability enables a business to manage and govern its information as strategic
assets. More specifically it:
• Aligns people, processes, and technology for the implementation of an enterprise-wide strategy to implement policies
governing the creation and use of information.
• Assigns Information Stewards to govern information assets throughout their life cycle. The Information Stewards
govern each information asset in the scope of defined policies, which might be automated regarding enforcement or
might require a human being executing a task.
• Assigns a balance sheet describing the value of the information and the impact of loss or improper management from
a data quality perspective.
07 Cloud Computing
• Cloud computing capability is necessary for many enterprises today and represents a new delivery model for IT.
However, the Cloud Computing delivery model is more than just a new way of billing for IT resources. A new set of
IT capabilities has been developed and significant changes to existing IT components have been applied. Not
surprisingly, the Cloud Computing delivery model also affects the Information Management domain and therefore
the EIA within an enterprise. Thus, we briefly introduce functional and technical capabilities relevant for the Cloud
Computing delivery model
⚬ Multi-Tenancy capabilities
⚬ Self-Service capabilities
⚬ Full Automation capabilities
⚬ Virtualization capabilities
⚬ Elastic Capacity capabilities
⚬ Metering capabilities
⚬ Pricing capabilities
⚬ Billing capabilities
⚬ Monitoring capabilities
 EIA Reference Architecture
In the Architecture Overview Diagram (AOD), you can see various candidates
for Architecture Building Block (ABB) representing the discussed capabilities.
Note that Information Governance is not shown explicitly, because only parts
of Information Governance are technology based.
A framework characteristic of the EIA Reference Architecture represented by
the AOD is its industry-agnostic nature. Therefore, for any deployment for a
company in a specific industry adaptation to industry-specific requirements
must be done. For example, if the EIA Reference Architecture is used by a
government to define the EIA for a homeland security solution, integration
with external supply chain participants might not be needed, whereas
third-party data providers such as terrorist blacklists must be integrated.
 Architecture Principle of EIA
Architecture principles are a set of logically consistent and easily understood
guidelines that direct the design and engineering of IT solutions and services
in the enterprise. These principles provide an outline of the tasks, resources,
and potential costs to the business for their implementation, and they also
provide valuable input that can be used to justify why certain decisions have to
be made.

Architecture principles should enable the EIA Reference Architecture as a tool

that can help you map between the organization’s business goals, business
architecture, IT landscape, and the solution delivery, and help the Enterprise
Information Architecture to be the conduit to understand the implications of
planned new business requirements.
The following are the 22 Architecture Principles:
• Deploy enterprise-wide Metadata strategies and techniques.
• Exploit analytics to the finest levels of granularity.
• Exploit Real Time and Predictive Analytics for business optimization.
• Enable KPI-based Business Performance Management (BPM).
• De-couple data from applications enabling the creation of trusted information which can be shared across business processes in a timely manner.
• Strive to deploy an enterprise-wide search capability.
• Compliance with all Information Security requirements.
• Compliance with all relevant regulations and Information Privacy legislation.
• Deliver de-coupled, trusted information through Information as a Service (IaaS) so that information services in a SOA are reusable and shareable
services for the business like other business services.
• Deploy new levels of information lifecycle management creating actionable information.
• Apply Cloud Computing delivery model to Information Services.
• Improve cost efficiency of the IT infrastructure, possibly now also using Green IT techniques.
• Deliver information with appropriate data quality.
• End-to-end inter- and cross-enterprise information integration.
• Develop an EII strategy with optimization of data transport, federation, and placement.
• Virtualize information whenever possible.
• Deliver operational reliability and serviceability to meet business SLA to ensure access to Structured and Unstructured Data at all times.
• EIA should reduce complexity and redundancy and enable re-use.
• EIA should be based on open standards.
• Enterprise information assets must have a business owner and be part of end-to-end Information Governance.
 Logical View of EIA Reference
Architecture
This diagram and the AOD described previously can be used to start the
discussion about how one actually deploys these information components out
into an enterprise. We depict each of the major areas of the EIA Reference
Architecture, including the general system and infrastructure components
needed to operate and manage any IT landscape. In addition, a set of common
requirements that straddle all the layers of the information
architecture—Business Process Orchestration and Collaboration capabilities,
comprehensive Connectivity and Interoperability capabilities, and security-
related requirements—all needed to manage and run any solution developed.
 Component Model and Operational
Model of Enterprise Information
Architecture

The Component Model specifically describes how these functional aspects can be assembled to add value in
any solution stack, and the Operational Model details how these functional components can be deployed onto
physical assets to deliver the requirements (functional and non-functional) of the design. We now introduce
each layer with a brief description.
 The Component Model
To delve deeper into the architecture description of the EIA, another term is needed:
component.
A component represents a logically grouped set of specific capabilities to deliver
particular software functionality.
The Component Model is the heart of the EIA. It describes the functional components in
terms of their roles and responsibilities, their relationships and interactions to other
components, and the required collaboration that enables the implementation of specified
deployment and customer use case scenarios. Each component is a relatively independent
part of the architecture, where its characteristics are described by its functions,
responsibilities, usage aspects, and interfaces. Their usages depend on the required
solution capabilities and deployment scenarios.
Component Relationship Diagram
This diagram is a depiction of the components, interfaces, and relationships that are a part of the Component Model. The interfaces and
relationships can be described at different levels. They simply describe directional flows of data between two components. On a more
ambitious level, they describe the information content and the usage of protocols to exchange the information content between components.
We call this the static relationship between the components.

For the Component Relationship Diagram presentation, we applied the following color codes:

01 The dark gray boxes represent the information services components for the metadata, data, content, master data, and
analytical data domain.

02 The gray boxes represent information service-related components such as the EII Component, the Mashup Hub
Component, and IT Service & Compliance Management Services Component.

03 The light gray boxes are components that are not part of the previous two categories and are typically found in a solution
based on the EIA.
 The Component
Relationship Diagram
Component Descriptions
Aside from a high-level description, it include a detailed description of the main functionalities and the responsibilities of each component.
Depending on the nature and functional scope of the component, it also includes the service description and implementation aspects. These
implementation aspects might be characterized by various design and service patterns. The component interactions, interfacing capabilities,
and functional and non-functional requirements complete the Component Descriptions.

Those key functional components are described using the following structure (depending on concrete project needs, a more enriched
structure might be needed):

01 ID
• For easy identification
02 Name
• Applying intuitive naming convention
03 High-level description
• Short paragraph for quick understanding
04 Service description
• Focus on service, including service patterns
05 Interfaces
• Component interactions and interface standards (such as XML)
Service Description
Component Interaction Diagrams

These diagrams depict how components dynamically collaborate to support various required business scenarios. These diagrams capture the
most significant dynamic relationships between components. It focuses on the interactions between components and illustrate the derived
flow of functionality in the context of a specific deployment scenario. Depending on the deployment scenario and required business scope, an
appropriate subset of the functionality of each component might be required. Any customer use case scenario can be easily mapped to the
Component Model using the corresponding Component Interaction Diagram.

Each step in a scenario is indicated with a number. We now begin with the first scenario. Here we assume the user (a customer) bought a
consumer product (e.g. shoes, mobile phone, PDA, and so on) in a store.
 Walkthrough for the
information-centric
application deployment
scenario
The Operational Model
The Operational model is the definition and distribution of an IT system’s components onto geographically distributed nodes. It
predominately targeted at enterprise architects, information architects, and system architects; however, it can also be used as a reference for
IT experts from different skill domains. The key concepts of operational modeling provide an understanding of how physical nodes can be
derived from logical components of the Component Model.

According to the IBM Architecture Description Standard (ADS), the Enterprise Architecture can be presented at different levels. One of the
principles that guides the development of an ADS is the recognition that infrastructure design is a specialized skill and that its exponents deal
with concepts, entities, and methods that are different from those known in the area of application development. The EIA Reference
Architecture is subdivided into three parts: a Conceptual Level, a Logical Level, and a Physical Level
Forms of Operational Mode Levels
01 Logical Operational Model (LOM)
• The LOM identifies the required technical services, develops the connections, and refines the technical
specifications. It describes:
⚬ Placement of specified components onto specified nodes
⚬ Specified connections between those nodes necessary to support the interactions between specified components
⚬ Non-functional characteristics of those nodes and connections, acquired from the placed specified components
and their interactions
02 Physical Operational Model (POM)
• It is the hardware and software technologies needed to deliver the Operational Model’s characteristics and
capabilities are identified and configured. It documents the overall configuration of the technologies and products
necessary to deliver the functional requirements and NFRs of the IT system. In particular, it describes:
⚬ Hardware and software technology and product selection for computers and networks
⚬ Hardware specifications, such as processor speed and disk configuration, or network bandwidth and latency
⚬ Overall hardware configurations, such as “fail-over” or “scalable” arrangements
￭ o Software product specifications (such as version) and detailed configuration, such as the need for multiple
instances of a software product (operating system, middleware, and communication element or application
system) on a computer
Operational Model Concepts and Notations
01 Node
• The central concept of an Operational Model.
⚬ A platform on which software executes. During early stages of the design process, a node represents a potential
platform, before decisions have been made about how to map it to actual platforms. Each node has a name and

02
optionally the number of instances.
Connections
• It represent physical data paths between nodes and show the shape of the network.
03 Deployment units (DU)
• Items placed on the nodes.
⚬ It is the smallest unit of software or data for which an architect makes a placement decision. Deployment units
are shown as named items on each node. A deployment unit consists of one or more components.

04 Execution deployment units (EDU)

• It represents the installation and execution of components.
05 Locations
• Group of nodes.
⚬ It is a geographical entity (such as a zone or building type) and is shown by pictorial elements around one or
more nodes.
 Key Design Concepts within
Operational Modeling

When implementing Information Services, various design and development tasks must
meet the operational requirements of the IT system. The major conceptual work items
are:

• The placement and grouping of components into deployment units

• The application of walkthroughs confirming operational aspects.
• The consideration of constraints and quality requirements
• The physical configuration for a set of technologies
 Context of Operational Model Design
Techniques
The Operational Model derives from the Component Model and it details functional component interactions and deployment
scenarios. The process of operational modeling means the partitioning and aggregation of logical components to DUs.
The placement of DUs on physical nodes, the related locations and zoning capabilities, specified the node-to-node connections, and
analyze the supported range of NFRs, the selected delivery model, and the scope of integration needed to meet the business context
and related use cases.
However, the generalized Operational Model allows to select, customize, and integrate pre-developed architectural patterns for our
needs. For this reason, a collection of predefined node types, connection types, location types, and DU placements is provided.
Furthermore, relevant IT service management node types, specified technical components, and topology patterns are selected
carefully. Inter-location border types and interrelationships of specified nodes for the most common distribution scenarios of
logical components are also provided.
With these operational design techniques, we can maximize the reuse of robust solution outlines by selectable architectural patterns
in the context of the EIA Reference Architecture. For operational modeling purposes, it is important to understand that NFRs can
be derived from affected data domains such as Operational or Analytical Data.
Generalized Operational
Models
 Operational Model Relationship
Diagram
Operational Model design techniques and service qualities are needed to satisfy a certain
business scenario. The Operational Model relationship diagram is a depiction of nodes,
locations, and correlating connections separately documented as the design proceeds. The
relationship of those elements is developed to verify the way in which the Operational
Model supports crucial use case scenarios.

We introduce the generalized level of the LOM and POM to convey the application of
patterns and reuse. Generalization means we provide a collection of standard node types,
pre-defined connection types, location types, and deployment unit placements for specific
business scenarios. It is important to recognize that the standards provided are a
representation of typical IT landscapes over which the system is distributed. They represent
the “design building blocks” that will be used when deciding upon the detailed physical
configuration for a set of technologies.
Basic Location Types:
• External Business Partners Location
• Public Service Providers Location
• Disaster Recovery Site Location
• Branch Systems Location
⚬ Branch Systems Location

Inter-Location Border Types:

• Corporate WAN
⚬ Corporate wide area network
• Branch LAN
⚬ Internal local area network (LAN within a branch)
• Head Office LAN
⚬ Internal local area network (within head office)
• Internet Link
⚬ Internet link and access to the external business partner’s organization
 Access Mechanisms

In order to describe how the component model is implemented across IT systems, the
Operational Model documents the access mechanisms used by all users of the system. In
operational terms, people (and systems) can use and access the system components in a
variety of access mechanisms according to the defined use cases.

Well-known standard access mechanisms include:

• System Support and Management
• File Download (from file producers)
• File Upload (to file consumers)
• Message Receipt (from message producers)
• Message Sending (to message consumers)
• Socket Request (from socket requestors)
• Socket Response (from socket responders)
 Standards of Specified Nodes

Specified nodes do not represent actual computing resources. Rather, they provide a formal
mechanism for enabling the specification of the location for the solution’s application and
underlying technical components across the geographic landscape. Using standard specified
nodes for the EIA Reference Architecture, we examine the patterns of how Information
Services can be constructed and instantiated. Node relationship provides node-to-node
connections and fleshing out exemplary topology views to meet particular service-level
characteristics. This leads to the categorization of common capabilities in layers.

The classification is done in four layers:

• Information Services
• Application Platform Layer for Information Services
• Technology Layer for Information Services.
⚬ IT Service & Compliance Management Services.
 Standard node types and
their categorization in layers
 Example of a populated
Logical Operational Model
Relationship Diagram
 Framework of Operational Patterns

The framework of operational patterns is a repository of recurring solution elements based from previous
experiences. It is a good practice to capture and reuse the experience of past engagements. The lessons
learned applying Information Services, you can consider the “scope of integration” which is determined
by typical deployment scenarios of these services. The scope of integration impacts the requirements for
availability, resiliency, security, and, to a certain extent, scalability.

The scope of integration can be categorized in three ways:

• Discrete solution scope
⚬ Predominately applies to the use of services in a single Line of Business (LOB)
• Integrated solution scope
⚬ Typically signifies the use of services as shared services across the enterprise
• Cross-domain solution scope
⚬ Applies to the use of services in a multi-enterprise context, typically through the interconnection
with partners or third-party providers
 Different Derived Operational Patterns
(Selections and Reuse)
Near-Real-Time Business Intelligence Pattern
• Provides access to information about business actions as soon after the fact as is justifiable based on the
requirements. The implementation of near-real-time BI involves the integration of a number of activities required in
any DW or BI implementation.
Data Integration and Aggregation Runtime Pattern
• Provides solutions for transparently managing both the volume and diversity of data that exists in enterprises across
the LOBs. It builds a solid foundation of existing data management solutions.
Enterprise Service Bus (ESB) Runtime for Guaranteed Data Delivery Pattern
• The integration of various technologies such as message-based communication mechanisms, guaranteed delivery of
messages over the network, assurance of once-only delivery of messages, different communications protocols,
dynamically distributed workloads across available resources, and recovery procedures after message system and
connectivity problems.
Continuous Availability and Resiliency Pattern
• High availability is a component of continuous availability. High availability focuses on reducing the downtime for
unplanned outages, and continuous operations focus on reducing the downtime for planned outages. The sum of
 Different Derived Operational Patterns
(Selections and Reuse)
Multi-Tier High Availability for Critical Data Pattern
• Redundancy is a critical and well understood means of achieving high availability. This includes redundant
components, redundant systems, and redundant data. Hardware components can fail, and software quality varies
from release to release, making other techniques for high availability equally important.
Content Resource Manager Service Availability Pattern
• Contributes to availability by segregating functions and can enable increased redundancy, increased scalability, and
simplified management among components
Federated Metadata Pattern
• Communicates with and retrieve data from remote data sources through wrapper services
Mashup Runtime and Security Pattern
Compliance and Dependency Management for Operational Risk Pattern
• It addresses formal and documented dependency and configuration management procedures, inter-relationships of
information resources, and the impact of a single-configuration change on business applications and infrastructure
services.
Retention Management Pattern
 Different Derived Operational Patterns
(Selections and Reuse)

Encryption and Data Protection Pattern

• Provides greater data security, integrity, retention, auditability, and privacy.
File System Virtualization Pattern
• File virtualization approach is through the use of a Distributed File System Services Clustered Node such as IBM
General Parallel File System (GPFS).
Storage Pool Virtualization Pattern
• It addresses the increasing cost and complexity in data storage management by shifting storage management
intelligence from individual SAN disk subsystem controllers into the network through a virtualization cluster of
nodes.
Automated Capacity and Provisioning Management Pattern
• It has the ability to control lifecycle, starting, stopping, and provisioning of services automatically.