IM Systems Integration and Architecture 1

Systems Integration and
Architecture 1
Compiled by:
Engr. Ranil M. Montaril, MSECE
1
Table of Contents
Table of Contents .................................................................................................................. 2

Module 1: Introduction to Systems Integration and Enterprise Architecture ........................... 5
Overview .......................................................................................................................................5
Lesson Outcomes ...........................................................................................................................5
Lesson 1: Importance of IT in Organizations ....................................................................................5
Lesson 2: Defining Systems Integration ...........................................................................................6
Lesson 3: Defining Enterprise Architecture ......................................................................................7
References ................................................................................................................................... 10
Assessment .................................................................................................................................. 12
Module 2: Overview of Enterprise Architecture Frameworks ................................................ 13
Overview ..................................................................................................................................... 13
Lesson Outcomes ......................................................................................................................... 13
Lesson 1: The Enterprise Architecture Framework ......................................................................... 13
Lesson 2: The Zachman Framework for Enterprise Architecture ..................................................... 15
Lesson 3: The Open TOGAF Framework ......................................................................................... 18
References ................................................................................................................................... 21
Assessment .................................................................................................................................. 22
Module 3: Components of Enterprise Architecture ............................................................... 23
Overview ..................................................................................................................................... 23
Lesson Outcomes ......................................................................................................................... 23
Lesson 1: Components of Enterprise Architecture ......................................................................... 23
References ................................................................................................................................... 26
Assessment .................................................................................................................................. 27
Module 4: Enterprise Information Architecture Concepts...................................................... 28
Overview ..................................................................................................................................... 28
Lesson Outcomes ......................................................................................................................... 28
Lesson 1: EIA Data Domains, Information Governance, and Information Security .......................... 28
Lesson 2: Conceptual and Logical View of Enterprise Information Architecture .............................. 33
Lesson 3: Component Model and Operational Model of Enterprise Information Architecture ......... 38
2
References ................................................................................................................................... 48
Assessment .................................................................................................................................. 50
Module 5: Enterprise Architecture Methods ......................................................................... 51
Overview ..................................................................................................................................... 51
Lesson Outcomes ......................................................................................................................... 51
Lesson1: Evolution of Systems Development Methodology ........................................................... 51
Lesson 2: Strategies for Enterprise Architecture Implementation ................................................... 52
Lesson 3: Enterprise Architecture Incremental Build Context ......................................................... 53
References ................................................................................................................................... 53
Assessment .................................................................................................................................. 54
Module 6: Enterprise Integration Technologies .................................................................... 55
Overview ..................................................................................................................................... 55
Lesson Outcomes ......................................................................................................................... 55
Lesson 1: Integrating Technologies................................................................................................ 55
Lesson 2: Enterprise Application Integration Concepts................................................................... 59
Lesson 3: Enterprise Portal Technologies for Integration................................................................ 61
Lesson 4: Web Services for Real-Time Integration ......................................................................... 64
Lesson 5: Service-Oriented Architecture for Integration................................................................. 65
References ................................................................................................................................... 68
Assessment .................................................................................................................................. 68
Module 7: Enterprise Resource Planning .............................................................................. 69
Overview ..................................................................................................................................... 69
Lesson Outcomes ......................................................................................................................... 69
Lesson1: Definition of Enterprise Resource Planning ..................................................................... 69
Lesson 2: ERP and Systems Integration.......................................................................................... 70
Lesson 3: ERP’s Role in Logical Integration .................................................................................... 70
Lesson 3: ERP’s Role in Physical Integration................................................................................... 71
Lesson 4: ERP implications for Management ................................................................................. 71
Lesson 5: Comparison of E-Commerce and ERP ............................................................................. 71
Lesson 6: ERP- Architecture and Components................................................................................ 72
Lesson 6: ERP Implementations .................................................................................................... 75
3
References ................................................................................................................................... 78
Assessment .................................................................................................................................. 79
Module 8: Other EA Enabling Technologies .......................................................................... 80
Overview ..................................................................................................................................... 80
Lesson Outcomes ......................................................................................................................... 80
Lesson 1: Cloud Computing .......................................................................................................... 80
Enterprise Computing .........................................................................................................................................80
Internet as a Platform .........................................................................................................................................83
Cloud computing .................................................................................................................................................87
Future of enterprise cloud computing ................................................................................................................88
Lesson 2: Business Intelligence, Analytics and Search .................................................................... 89

Data Warehousing ..............................................................................................................................................89
OLTP and OLAP ...................................................................................................................................................90
TEXT AND DATA MINING ....................................................................................................................................92
References ................................................................................................................................... 93
Assessment .................................................................................................................................. 93
APPENDIX A. Course Syllabus........................................................................................................ 94
4
Module 1: Introduction to Systems Integration and Enterprise Architecture
Overview
The Role of IT in an organization is very important especially in enabling business processes. Business
capabilities of a modern organization are often determined largely by the capabilities of IT systems.
Although modern organization are facing misalignment within its different department and its external
parties due to decentralized Information Systems, poor communication within groups, inadequate
planning, incomplete requirements. This challenges creates a critical implications to meet the
organization’s business goal. To achieve this alignment, 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. Facing all these uncertainties and changes, business
processes have to be loosely coupled and flexible enough to be easily reconfigurable and to support the
collaboration of workers at distributed geographical locations.
Enterprise architecture is the process by which organizations standardize and organize IT infrastructure
to align with business goals. These strategies support digital transformation, IT growth and the
modernization of IT as a department.
Lesson Outcomes
o To discuss the role of IT and its importance in an Organization
o To define an Enterprise integration and explain its goals in an enterprise.
o To distinguish Enterprise Integration to System Integration,
o To elaborate the four stages of System Integration.
o To articulate the Enterprise Architecture and explain its goals, and advantages.
o To Enumerate the common Enterprise Architecture Frameworks
Lesson 1: 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.
Through the decades, the Information systems become more powerful, ubiquitous, diverse and
affordable. The computing power and storage capacity of IT systems are exponentially increasing. Today,
Business Applications can be deployed on dedicated servers, can be hosted in the cloud, and can run web
5
browsers and even installed on hand held devices. The relative price of IT systems are getting affordable
making it more accessible.
The purpose of IT is not only limited on installing the appropriate software and hardware in an
organization rather improving the quality of business processes that requires consistent and coordinated
changes in the three broad organizational aspects:
 People
 Trainings and Education to system users.
 Processes
 Introducing new improved business processes enabled by system
 Decision Making procedures 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 Excellence and Cost Leadership

 Product differentiation and leadership
 Customer Intimacy and focus.
Lesson 2: Defining Systems Integration
Each department added its own custom-built applications, built specifically for its own use, without
coordination with other functions or departments. With the passage of time, organizations accumulated
isolated computer silos, each with their specific hardware, software, access procedures, data formats, and
processing tools.
To bring some order into a chaotic situation, enterprise systems integration started as a vehicle and a
methodology to bring disparate systems together through a common front-end and mask the underlying
computer and communication infrastructure. It has evolved into a systematic redesign of the information
architecture, within enterprises and across enterprises, to ensure the flexibility and extensibility of the
Applications by design, in addition to their interoperability. Both aspects coexist in initiatives for systems
integration, even when they are not explicitly stated.
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
6
enterprise behaves as an integrated whole, therefore enhancing its overall productivity, flexibility, and
capacity for management of change (or reactivity)”. The important distinction is that the scope of system
integration may extend outside the boundary of the enterprise to cover suppliers, customers, banks, and
other parties involved in electronic commerce.
Enterprise Application Integration (EAI) was 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.
Four Stages of System Integration

System integration can be achieved at different levels, which are labeled as follows:
o Interconnectivity
o Functional Interoperability
o Semantic Interoperability
o Optimization and Innovation
Drivers for Systems Integration

A combination of several factors have stimulated and facilitated systems integration projects.
These are:
o Advances in computer networks and information processing.
o Globalization.
o Need for organizational agility to cope with competition and rapid development.
o Market positioning through the customization of products and services.
o Regulatory compliance.
It should be noted that the various integration drivers interact with each other and their effects are usually
combined. For example, both technological advances and deregulations have resulted in a worldwide
competitive environment with new patterns of collaboration and partnerships that enterprise information
systems have to contend with.
Issues in Enterprise/System Integration

Current enterprise (or system) integration plans pose significant challenges due to the following issues:
o Nature of the networking technology.

o The difficulties of standardization.
o The security threat to institutions and individuals.
Lesson 3: 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).
7
History
EA began in the 1960s, born from “various architectural manuscripts on Business
Systems Planning (BSP) by Professor Dewey Walker”. John Zachman, one of Walker’s
students, helped formulate those documents into the more structured format of EA.
Both men also worked for IBM during this time, and that’s when Zachman published
the framework in the IBM Systems Journal in 1987.
Figure 1.0 Dewey Walker

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 Figure 2 John Zachman
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 seamless environment.
Goals of enterprise architecture:
EA is guided by the organization’s business requirements — it helps lay out how information, business
and technology flow together. This has become a priority for businesses that are trying to keep up with
new technologies such as the cloud, IoT, machine learning and other emerging trends that will prompt
digital transformation.
“The framework successfully combines people, data and technology to show a comprehensive view of the
inter-relationships within an information technology organization,”
The process is driven by a “comprehensive picture of an entire enterprise from the perspectives of owner,
designer and builder.” Unlike other frameworks, it doesn’t include a formal documentation structure;
instead, it’s intended to offer a more holistic view of the enterprise.
A good EAP strategy considers the latest innovations in business processes, organizational structure,
information systems and technologies. It will also include standard language and best practices for
business processes, including analyzing where processes can be integrated or eliminated throughout the
8
organization. The ultimate goal of any EAP strategy is to improve the efficiency, timeliness and reliability
of business information.
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.
The biggest benefits of EAP include:
o Allowing more open collaboration between IT and business units

o Giving business the ability to prioritize investments
o Making it easier to evaluate existing architecture against long-term goals
o Establishing processes to evaluate and procure technology
o Giving comprehensive view of IT architecture to all business units outside of IT
o 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.
According to CompTIA, these are the four leading Enterprise Architect Planning (EAP) methodologies:
The Open Group Architectural Framework (TOGAF): TOGAF provides principles for designing, planning,
implementing and governing enterprise IT architecture. The TOGAF framework helps businesses create a
standardized approach to EA with a common vocabulary, recommended standards, compliance methods,
suggested tools 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.
9
The Zachman Framework for Enterprise Architecture: The Zachman framework is named after one of the
original founders of enterprise architecture and it’s another popular EA methodology. It’s better
understood as a “taxonomy,” according to CompTIA, and it spans six architectural focal points and six
primary stakeholders to help standardize and define the IT architecture components and outputs.
Federal Enterprise Architecture Framework (FEAF): FEAF was introduced in 1996 as a response to the
Clinger-Cohen act, which introduced mandates for IT effectiveness in federal agencies. It’s designed for
the U.S. government, but it can also be applied to private companies that want to use the framework.
Gartner: 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, CompTIA
recognizes it as a “practical” methodology that focuses on business outcomes with “few explicit steps or
components.”
These are just four of the most commonly referenced and recognized EA methodologies, but others exist.
For example, there’s the European Space Agency Architectural Framework (ESAAF), the Ministry of
Defense Architecture Framework (MODAF) and the SAP Enterprise Architecture Framework. These
frameworks are specifically targeted to individual industries or products, targeting more of a niche market
than the more generalized EA methodologies listed above.
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.
References
DaumBerthold, MertenUdo System Architecture with XML．San Francisco, CA，Morgan Kaufmann
Publishers，2003．
DoanAnhai, HalevyAlon, IvesZachary Principles of Data Integration．Massachusetts，Morgan

Kaufmann Publishers，2012．
Enterprise Information Architecture (EIA)．[Online][Cited: 27 September 2020．]https://cio-

wiki.org/wiki/Enterprise_Information_Architecture_(EIA)．
FinkelsteinClive Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies．USA
，British Library Cataloguing in Publication Data，2006．
FoundationEnterpriseInformation Architecture: A Semantic and OrganizationalTom Reamy ．

[Online][Cited: 27 September 2020．]https://boxesandarrows.com/enterprise-information-
architecture-a-semantic-and-organizational-foundation/．
10
GautamShroff Enterprise Cloud Computing: Technology, Architecture, Applications．New York，
Cambridge University Press，2010．
GodinezMarioet al. The Art of Enterprise Information Architecture: A Systems-Based Approach for
Unclocking Business Insight．New York，IBM Press-Pearson plc，2010．
GormanMichaelM.Enterprise Architectures．
[Online]https://cdn.ttgtmedia.com/searchDataManagement/downloads/Enterprise_Architectures_Chap
ter%2004.pdf．
IEEE 1471-2000 - IEEE Recommended Practice for Architectural Description for Software-Intensive
Systems．[Online]https://standards.ieee.org/standard/1471-2000.html．
MyersonJudithM. Enterprise Sysatem Integration．New York，AUERBACH PUBLICATIONS，2001．
RoshenWaseem SOA- Based Enterprise Integration: A Step by Step Guide to Service-Based Application
Integration．New York，McGraw-Hill，2009．
SageAndrewP., RouseWilliamB Handbook of Systems Engineering and management．s.l.，John Wiley

& Sons，1999．
SherifMostafaHashem Handbook of Enterprise Integration．New York，Auerbach Publications，2010

．
The TOGAF Standard version 9.2．

[Online]https://publications.opengroup.org/c182?_ga=2.228793374.389549404.1598886728-
2043625528.1598886728．
TOGAF Online: Introduction．[Online]http://www.togaf.com/togaf9/chap01.html．
What Is Service-Oriented Architecture?: A Look At the Nuts and Bolts of Service-Oriented Architecture．
[Online][Cited: 27 September 2020．]https://medium.com/@SoftwareDevelopmentCommunity/what-
is-service-oriented-architecture-fa894d11a7ec．
WhiteSarahK.What is enterprise architecture? A framework for transformation．[Online]16 October

2018．https://www.cio.com/article/3313657/what-is-enterprise-architecture-a-framework-for-
transformation.html．
Wikipedia: Enterprise architecture framework．

[Online]https://en.wikipedia.org/wiki/Enterprise_architecture_framework．
11
Assessment
Answer the following questions:
1. What are the Role of IT in an Organization?

2. Explain, how IT systems are becoming more powerful?
3. Why organizations need to invest in IT?
4. Identify and elaborate the issues may encounter during enterprise integration.
12
Module 2: Overview of Enterprise Architecture Frameworks
Overview
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 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.
Lesson Outcomes
o To explain the need of Enterprise Framework for designing and implementing an Enterprise
Information Systems.
o To develop a knowledge on how the Zachman Framework depicts entire artifact of an enterprise
architecture.
o To enumerate the Advantages and the Drawbacks of using Zachman Framework.
o To recognize another known EA framework such as TOGAF.
o To discover its Composition, Use and Benefits.
Lesson 1: 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.
Four Characteristics of Enterprise Architecture Framework

o Skeleton/Structure
 It is an outline when you practice Enterprise Architecture.
o Classification of Schema or Ontology
 Classification of Schema is the way of describing the object, 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 area or enterprise architecture
that shows their properties and the relations between them.
o Thinking Tool
 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.
o 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
13
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.
Figure 3 Conceptual model of architectural description
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.
14
Lesson 2: 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.
It depicts the design artifacts that constitutes the intersection between roles in the design process which
is:
o Owner
o Designer
o Builder
And the abstractions which is:
o What (material) is made of

o How (process) it works
o Where (geometry)
Figure 4 Interest in different diagrams or representations from their views/perspectives
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 systems.
15
Considering the following Abstractions:
Figure 5 Different questions (or abstractions) also need to be considered in the design and construction of buildings, airplanes,
and enterprise systems.
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 normally counted in the five main
rows of the Zachman framework.
16
Figure 6 The complete Zachman framework for enterprise architecture
Advantages of the Zachman framework:

o 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, operating, and transforming the enterprise is enabled.
o It addresses the enterprise as a whole, it is defined independently of tools or methodologies, and
any issues can be mapped against it to understand where they fit.
Drawback of the Zachman framework:
o The large number of cells, which is an obstacle for the practical applicability of the framework.
o The relations between the different cells are not that well specified.
o Does not give a step-by-step process for creating a new architecture.
o Does not give much help in deciding if the future architecture we are creating is the best
architecture possible.
o Does not give an approach to show a need for a future architecture
17
Lesson 3: 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 provides a platform for adding value, and enables users
to build genuinely open systems-based solutions to address their business issues and needs.
18
Figure 7 TOGAF Structure
TOGAF consists of:
o Architecture Capability Framework

 This part discusses the organization, processes, skills, roles, and responsibilities required
to establish and operate an architecture practice within an enterprise.
o Architecture Development Method

 This is the core of the TOGAF framework. It describes the TOGAF Architecture
Development Method (ADM) – a step-by-step approach to developing an Enterprise
Architecture.
o 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.
19
o Enterprise Continuum & Tools:
 This part discusses appropriate taxonomies and tools to categorize and store the outputs
of architecture activity within an enterprise.
Figure 8 ADM Steps of TOGAF
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.
20
References




ter%2004.pdf．

& Sons，1999．

．

2043625528.1598886728．
21


Assessment
Part 1: Read and summarize the ZACHMAN Framework for Enterprise Architecture in your own
words. Map this framework to any enterprise system and provide architecture.
Part2: Answer the following Questions:
1. What is the distinct advantage of Zachman Framework over TOGAF?

2. Explain how can information systems used by organization is related to construction of buildings.
22
Module 3: 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 Resource Life Cycles.
Lesson Outcomes
o To enumerate and explain each components of Enterprise Architecture
o To differentiate the approach of IT on development and support of Enterprise Architecture
Lesson 1: Components of Enterprise Architecture
The Four Primary components of Enterprise Architecture are:
o Enterprise Business Architecture

o Enterprise Information Architecture
o Enterprise Solution Architecture
o Enterprise Technology Architecture
23
Business
Architecture
Development Drives
Information
Architecture Support
Prescribes
Solutions Architecture
Supported by
Technical Architecture
Figure 9 Four Components of EA
Enterprise Business 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?
It is gives a common reference model of citizens, businesses, members of General Assembly, current and
future administrations, and other interested parties that helps define the business of state of government.
Enterprise Information Architecture

EIA provides a framework, model, and method to enhance each agency’s to quickly discover access, and
understand data, while creating information needed to support critical agency business function
decisions.
The EIA framework must have three components that contain information about the enterprise’s data
assets:
o Data Sharing (How do I exchange the data?)
24
 Information Exchange and Query Points – Information generated/required by a Unit of
work and is subsequently passed to another unit of work.
o Data Description (What does the data mean?)
 Structured- Organized description of data to convey semantic understanding usually
through an entity relationship diagram.
 Semi Structured- Data that has characteristics of both Structured and Unstructured such
email.
 Unstructured – data that is more free-form format such as unstructured text.
o Data Context (How do I find the data and access it?)
 Subject Area - Broad Categories of data that supports business processes.
 Information Class - Groupings of lines of business or community of interest.
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:
o Inventory Solutions, applications, and components currently used to support business functions
in an enterprise.
o Analysis of current/baseline solutions, and current technology tools supporting existing
automated solutions.
o Future-state recommendations of automated solutions and related tools.
o ESA governance and implementation requirements.
Enterprise Technical Architecture

ETA is a consistent set of IT standards and models that:
o Reflect and support EBA, EIA, and ESA components.

o Guides the engineering of emerging IS and technology infrastructure.
ETA domains:
o Security
o Enterprise system Management
o Information
o Database
o Applications
o Integration
o Platform
o Networking and Telecommunications.
25
References




ter%2004.pdf．

& Sons，1999．

．

2043625528.1598886728．
26


Assessment
Answer the following:
o Enumerate and Explain each components of Enterprise Architecture

o What’s the effect of an enterprise’s architecture on your projects?
o Is the enterprise’s architecture followed as a controlling guidance?
o What have been the benefits and drawbacks if it is followed as a controlling guidance?
27
Module 4: Enterprise Information Architecture Concepts
Overview
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 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.
Lesson Outcomes
o To examine the different data domains that is being used in the line of business of an enterprise.
o To determine the different areas IT governance that tightly coupled in business strategies and
objectives.
o To identify the different aspects of IT security and Information Privacy services.
o To acquire knowledge on Conceptual and Logical views of Enterprise Information Architecture.
o To design the Component Model of an Enterprise Information Architecture and to assemble the
corresponding Operational Model.
Lesson 1: EIA Data Domains, Information Governance, and Information Security

Data Domains
Data domains classifies information assets used for specific purposes where the purpose identifies usage
patterns with a dedicated set of capabilities.
Certain types of data might be used enterprise-wide and others might be used only locally within a
department or a Line of Business (LOB). The data might be structured (for example, an order) or
unstructured (for example, a scanned contract document). The data might also differ from a retention
perspective indicating how long the data must be stored.
We see the following five data domains:
o Metadata Domain
 Defined as “data about the data.” Metadata is the information that describes the
characteristics of each piece of corporate data asset and other entities.
o Master Data Domain
 Refers to instances of data describing the core business entities, such as customer or
product data.
o Operational Data Domain
28
 Also referred to as transactional data capturing data, which is derived from business
transactions.
o Unstructured Data Domain
 Also known as content, typically managed by an enterprise content management
application.
o Analytical Data Domain
 Usually derived through transformation from operational systems to address specific
requirements of decision support applications.
Figure 10 The five pillars of Enterprise Information
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 Governance
For IT Governance, many standards do exist but one common example is the COBIT standard (Control
Objectives for Information and related Technology), which is owned by the IT Governance Institute. From
the COBIT perspective, IT Governance is considered a framework to govern IT assets over their lifecycle.
Good IT Governance ensures that the IT group supports and extends the company strategies and business
objectives. The decision making process on how information systems are planned and organized, acquired
and implemented, delivered and supported, as well as monitored and evaluated. It should therefore be
just another strategic agenda item that the board addresses.
IT Governance is tightly coupled with the following:
o IT principles
 High-level statements about how IT will be used to create business value and a generic
information-centric set
o IT architecture
 The set of technical choices that guide the enterprise in satisfying business needs.
o IT infrastructure strategies
 Describes the approach to building shared and standard IT services across the enterprise
o Functional business requirements
 Refers to applications that need to be acquired or built
29
o Prioritization of IT investments
 The whole process of IT investments, including where they should be focused and the
procedures for progressing initiatives, their justification, approval, and accountability.
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:
o Compliance and regulatory adherence satisfies auditors and regulators by developing data
management environments leveraging technology and process to ensure adherence to specific
requirements.
o 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)
o 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.
o Improved platforms measure, monitor, and improve business performance by tying operational
metrics to business performance measures and facilitating reporting and management of critical
processes.
o Reduced environmental complexity improves business flexibility and accelerates strategic
initiatives by providing comprehensive and predictable information environments that support
effective business decision making.
30
Figure 11 Information Governance
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:
o Across the globe there has been a growing number of attacks on major enterprises with (internal
inspired) threats still high.
o 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.
o The Cloud Computing delivery model requires new means to federate identities across internal
and external systems to protect data from unauthorized access.
o Regulatory compliance pressures around the world across all industries demand strict
enforcement of data access and Information Privacy.
o Access by partners to internal systems is ever increasing as the new trends to distributed solutions
and cooperation across business boundaries take place.
o 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.
31
The following are:
o 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.
o 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.
o 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 when dealing with data such as test databases and the
requirement to enable structurally integral data sets without exposing live data to the developers or
designers.
As defined by IBM, data masking is the process 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:
o Meet regulatory compliance needs.

o Enhance data security.
o Protect against internal or external attacks as the data has little or no external value.
o Enable the use of production data within exposing private, sensitive or confidential data to any
non-trusted party.
Figure 12 Data Masking Techniques
There are two techniques in Data masking:
o 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
32
production into flat files while masking the data and finally loading the data into multiple
different environments.
o In-Place Data Masking
 Data is first copied from production into multiple environments and then masked in place.
Lesson 2: 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:
o 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
33
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.
o Business Performance Management
BPM is a capability enabling business users to:
 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.
o 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.
o 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.
o Information Governance

o 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.
o 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
34
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.
35
Figure 13 Architecture Overview Diagram for the EIA Reference Architecture
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:
o Deploy enterprise-wide Metadata strategies and techniques.

o Exploit analytics to the finest levels of granularity.
o Exploit Real Time and Predictive Analytics for business optimization.
o Enable KPI-based Business Performance Management (BPM).
36
o De-couple data from applications enabling the creation of trusted information which can be
shared across business processes in a timely manner.
o Strive to deploy an enterprise-wide search capability.
o Compliance with all Information Security requirements.
o Compliance with all relevant regulations and Information Privacy legislation.
o 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.
o Deploy new levels of information lifecycle management creating actionable information.
o Apply Cloud Computing delivery model to Information Services.
o Improve cost efficiency of the IT infrastructure, possibly now also using Green IT techniques.
o Deliver information with appropriate data quality.
o End-to-end inter- and cross-enterprise information integration.
o Develop an EII strategy with optimization of data transport, federation, and placement.
o Virtualize information whenever possible.
o Deliver operational reliability and serviceability to meet business SLA to ensure access to
Structured and Unstructured Data at all times.
o EIA should reduce complexity and redundancy and enable re-use.
o EIA should be based on open standards.
o Enterprise information assets must have a business owner and be part of end-to-end Information
Governance.
o Align IT solution with business.
o Maximize agility and flexibility of IT assets.
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.
37
Figure 14 Logical View of the EIA Reference Architecture
Lesson 3: 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.
A detailed description of each component, the main focus of the Component Model is the Component
Relationship Diagram and the Component Interaction Diagrams.
38
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:
o The dark gray boxes represent the information services components for the metadata, data,
content, master data, and analytical data domain.
o The gray boxes represent information service-related components such as the EII Component, the
Mashup Hub Component, and IT Service & Compliance Management Services Component.
o 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.
Figure 15 The Component Relationship Diagram
39
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):
o ID
 For easy identification
o Name
 Applying intuitive naming convention
o High-level description
 Short paragraph for quick understanding
o Service description
 Focus on service, including service patterns
o Interfaces
 Component interactions and interface standards (such as XML)
Figure 16 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
40
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.
Figure 17 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.
41
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

Logical Operational Model (LOM)
The LOM identifies the required technical services, develops the connections, and refines the technical
specifications. It describes:
o Placement of specified components onto specified nodes

o Specified connections between those nodes necessary to support the interactions between
specified components
o Non-functional characteristics of those nodes and connections, acquired from the placed
specified components and their interactions
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:
o Hardware and software technology and product selection for computers and networks
o Hardware specifications, such as processor speed and disk configuration, or network bandwidth
and latency
o 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

o 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 optionally the number of instances.
o Connections
 It represent physical data paths between nodes and show the shape of the network.
42
o 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.
o Execution deployment units (EDU)
 It represents the installation and execution of components.
o 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:
o The placement and grouping of components into deployment units

o The application of walkthroughs confirming operational aspects.
o The consideration of constraints and quality requirements
o 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.
Figure 18 Generalized Operational Models
43
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.
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:
o External Business Partners Location

o Public Service Providers Location
o Disaster Recovery Site Location
o Branch Systems Location
o Branch Systems Location
Inter-Location Border Types:
o Corporate WAN
 Corporate wide area network
o Branch LAN
 Internal local area network (LAN within a branch)
o Head Office LAN
 Internal local area network (within head office)
o Internet Link
 Internet link and access to the external business partner’s organization
44
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:
o System Support and Management

o File Download (from file producers)
o File Upload (to file consumers)
o Message Receipt (from message producers)
o Message Sending (to message consumers)
o Socket Request (from socket requestors)
o 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:
o Information Services
o Application Platform Layer for Information Services
o Technology Layer for Information Services.
o IT Service & Compliance Management Services.
45
Figure 19 Standard node types and their categorization in layers
Figure 20 Example of a populated Logical Operational Model Relationship Diagram
46
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:
o Discrete solution scope

 Predominately applies to the use of services in a single Line of Business (LOB)
o Integrated solution scope
 Typically signifies the use of services as shared services across the enterprise
o 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)

o 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.
o 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.
o 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.
o 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 high availability and continuous
operations equals continuous availability, and enables “never stop” of a set of
information systems.
o Multi-Tier High Availability for Critical Data Pattern
47
 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.
o Content Resource Manager Service Availability Pattern
 Contributes to availability by segregating functions and can enable increased redundancy,
increased scalability, and simplified management among components
o Federated Metadata Pattern
 Communicates with and retrieve data from remote data sources through wrapper
services
o Mashup Runtime and Security Pattern
o 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.
o Retention Management Pattern
 It is about retaining corporate records for the minimum appropriate retention period to
meet business and regulatory requirements (laws, policies, and regulations on the
business).
o Encryption and Data Protection Pattern
 Provides greater data security, integrity, retention, auditability, and privacy.
o 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).
o 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.
o Automated Capacity and Provisioning Management Pattern
 It has the ability to control lifecycle, starting, stopping, and provisioning of services
automatically.
References



48


ter%2004.pdf．

& Sons，1999．

．

2043625528.1598886728．


49
Assessment
1. How the different data domains can manage successful enterprise though a coherent Information
Governance framework?
2. What is a Component Interaction Diagram? How does it demonstrated the viability of the
component model?
3. What are the introduced operational patterns that enable the architect to improve the reuse of
the implementation design of Information Services?
50
Module 5: Enterprise Architecture Methods
Overview
There are various methods for implementing enterprise architecture. The emphasis of these methods is
to identify priority data, business activities, and business processes, and then deliver these priority areas
in 3-month increments as production systems.
Strategic modelling that identifies the reusable business activities and business processes from data
models. This is a key method that is used to derive project plans manually or automatically from data
models. This method enables high priority business subprojects to be identified for delivery in 3-month
increments.
It is also an important step in enterprise architecture is strategic alignment: so that data as well as
processes, locations, people, events and business plans all support each other.
Lesson Outcomes
o To review the evolution of systems development methodologies.
o To identify the different strategies for enterprise architecture implementations
o To plan EA based on Incremental Build Context
Lesson1: Evolution of Systems Development Methodology

Methodologies that have evolved since the beginning of the Information Age have helped us to examine
current manual processes so we could automate them. From rudimentary methodologies in the 1960s,
by the 1970s these had evolved into the software engineering methods which are also called structured
methods.
Evolutions of Software Engineering

The software engineering methods analyzed current manual processes, documenting them with data flow
diagrams (DFDs) and functional decomposition diagrams (FDDs). The structure of modular programs to
automate these processes was documented using structure charts (SCs). Programs were then written in
various programming languages to execute the automated processes.
With software engineering, each DFD that was defined for a process identified the data that it needed as
data stores. Each different version of the same process often resulted in redundant data store versions
implemented for each automated process, moving us to data maintenance chaos!
Evolution of Information Engineering
In this same period—from the late 1960s through the early 1970s—Edgar Codd, a research fellow at IBM
San Jose Labs, developed the relational model from mathematical set theory. This was the foundation of
the relational database technology that we still use today. The first relational database management
51
systems (RDBMSs) were released by IBM Corporation (IBM DB2 RDBMS) and by Oracle Corporation
(Oracle RDBMS) in the late 1970s and early 1980s.
From the mid-1970s, three approaches emerged, as discussed next, to apply concepts of the relational
model to the methods that were used for database design. The first approach was from the United
Kingdom and Europe, the second approach was from the United States, and the third approach was
business driven and emerged independently in Australia. Each addressed the development of data
modeling methods, using normalization to eliminate redundant data versions.
The business-driven approach evolved into integrated methods for information, using a rigorous
engineering discipline, called information engineering (IE). Originally developed by Clive Finkelstein, IE
was popularized worldwide through-out the 1980s by James Martin. Further books showed the use of
business-driven information engineering. This evolved into what is today called enterprise engineering
(EE).
Evolution of Object-Oriented Methods

In the late 1980s, the concepts of object-oriented (O-O) development and the unified modeling language
(UML) were developed by Grady Booch, James Rumbaugh, and Ivar Jacobson. Object-oriented methods
based on UML were found to be very effective in developing reusable code. They use a number of
diagrams to model various aspects for O-O development: class, state transition, use-case, collaboration,
sequence, and activity diagrams. Booch, Rumbaugh, and Jacobson established Rational Corporation to
develop associated UML modeling tools. They popularized UML and Rational software tools, which were
widely used in the late 1990s. When IBM purchased Rational Corporation in 2003, Rational became a
subsidiary of IBM.
Lesson 2: Strategies for Enterprise Architecture Implementation

Many strategies are available for implementing enterprise architecture, according to John Zachman. We
will discuss three alternative strategies in this section:
o Strategy A: Implementation in top-down, rigorous detail;

 This strategy achieves enterprise-wide data integration with a fully attributed, fully
normalized logical data model. It identifies architecturally normalized business processes
before they are submitted for applications design and development deliverables. The
time and cost savings of this strategy—when compared to traditional systems
development methods—are impressive.
o Strategy B: Selective EA, based on ROI business case;
 Strategy B is appropriate if an ROI business case must first be established before a
decision is made to introduce an enterprise architecture approach. This strategy
evaluates the ability of legacy systems to support required data, processes, organizational
structure, and business plan relationships. It assesses the benefits and trade-offs of
enterprise architecture to address the needs for the future and prioritize the systems that
should be addressed. The business case can then be established for enterprise
52
architecture. The most appropriate enterprise architecture implementation approach can
be selected.
o Strategy C: Deliver progressively in 3-month incremental builds.
 This approach leads to incremental implementation of priority areas that are needed first,
before other areas that can wait until later. This approach enables strategic business plans
for the future to be defined using the strategy analysis methodology of enterprise
engineering. The business plans are used to identify data and information that are
required for the future. This is documented in a strategic model, which is a high-level
enterprise model that achieves enterprise-wide data integration.
Lesson 3: Enterprise Architecture Incremental Build Context

It covers data mapping methods for development of data maps from business planning statements. The
following steps keyed to implementation of Enterprise Architecture.
o Step 1: Strategy analysis identified statements for mission, vision, core values, goals, objectives,
issues, KPIs, and strategies in the strategic plan.
o Step 2: Strategy analysis identified from the organizational structure those managers and business
experts responsible for implementing priority areas of the strategic plan.
o Step 3: With participation by the identified managers and business experts, over 5 days in a
business planning workshop they optionally apply the strategy analysis methodology to define
tactical business planning statements to implement strategic plans.
o Step 4: Data mapping is used to enable business experts and IT experts to work together to
identify data for integration. This begins with a 2-day strategic modeling facilitated session.
Entities that represent required information and data are listed.
o Step 5: The facilitated modeling session continues over 2 days, documenting key entities in a
strategic model on a whiteboard. The strategic data map is a high-level enterprise model.
References
MyersonJudithM. Enterprise System Integration．New York，AUERBACH PUBLICATIONS，2001．
53
Assessment
1. What is the significance of Object Oriented development and Unified modeling language in the
development process?
2. What is the contribution of Zachman Framework in drafting the strategies of Enterprise
Architecture?
3. Explain the meaning of Strategic Modelling and Strategic data map?
54
Module 6: Enterprise Integration Technologies
Overview
This module will cover the technologies and vendor products that can be used to deliver into production
the priority databases, activities, and processes identified in EA Methods.
It also introduces the concepts and technologies used by enterprise portals and discusses their use for
rapid delivery of priority information and content resources in enterprise integration projects.
Web services concepts and technologies are introduced in this module, along with the evolution of Web
services. It describes the technical foundations of Web services that are used for enterprise integration in
this part. It discusses their use in enterprise portals with Web services for remote portals.
The technologies used by SOA and BPM languages will be discussed. Four BPM languages are described:
Business Process Execution Language for Web Services (BPEL); Web Services Choreography Interface
(WSCI); Business Process Modeling Language (BPML); and Business Process Specification Schema (BPSS)
for ebXML. These offer the potential to transform systems development in twenty-first-century
enterprises, with XML-based BPM languages automatically generated as executable code directly from
workflow models or process models.
Lesson Outcomes
o To discuss the different Integrating Technologies used in an Enterprise Architecture.
o To describe the Direct to Point-to-Point, and Middleware approach in Integrations.
o To explain the concept of XML in enterprise application integration.
o To discuss the usage of Enterprise Portal in Enterprise Integration.
o To identify the different Web Service Technologies for Real Time Integration.
o To define Service-Oriented Architecture and its services for Integration.
Lesson 1: Integrating Technologies

The development of technology over the years has led to most systems within an organization existing in
heterogeneous environments. Different applications were developed with varying languages, operate on
different hardware and available numerous platforms. The problems lay in the fact that when
implementing systems, decisions on the technology employed different from department-to-department
and also had some dependence on the latest trends. These systems serve only the departmental needs.
Information and process sharing across an organization is not accommodated for. These systems is what
we known as “stovepipes”
Stovepipe systems held independent data; it was recognized that customer information and the sharing
of this information across departments was extremely valuable to an enterprise. Allowing the disparate
systems to interoperate become increasingly important and necessary. As an organization grew, its desire
to integrate key systems with client and vendors are essential.
55
The idea and implementing application integration is not new. What is new are the approach and ideas
that Enterprise Application Integration (EAI) encompasses and techniques that can be utilized. The Success
of applying EAI requires involvement of the entire Enterprise.
This involves:
o Business Processes
 The key is to combine tasks, procedures, required input and output information and tools
needed in each stage of the process. It is imperative, than an enterprise identifies all
processes that contribute to the exchange of data within the organization. This allows
organizations to streamline operations, reduce costs and improve responsive to customer
demands.
o Application
 Merging of one application data /functionality to another application.
o Data and Standard
 This addresses the need to have a global standard by which data can be shared and
distributed across an enterprise’s network of systems. In order to achieve this, all data
and its location must be specified, recorded and a metadata model built. Without this
format, Business Processes and Application integrations will not be viable.
o Platforms.
 This provides a secure and reliable means for corporation’s heterogeneous systems to
communicate and transfer data from one application to another without running into
problems.
Two Types of Logical integrations Architecture in EA:
o Direct Point-to-Point
o Middleware-based integrations.
Direct Point-to-Point Integrations

Direct Point-to-Point integration is appropriate when dealing with few application. It is usually being
pursued due to its easy and fast implementation. The efficiency of this method deteriorates as you try to
integrate more systems. In this method, has a huge concern on scalability. Though you only have few
systems, consideration must go into the future. The number of integration points is double the number
of systems. This will be problematic because of the tight coupling between the systems. Alterations in one
system could have adverse effects on another. Each Additional thus becomes more difficult to maintain
and integrate
Middleware Integrations
To solve the issue of high amounts of integration points and thereby relieving the coupling problem, the
use of middleware has been introduced where the number of integrations points will be equal to the
number of systems.
56
A middleware is an intermediate layer provides generic interfaces through which the integrated systems
are able to communicate. It perform tasks such as routing and data passing. Each of the interfaces-defines
a business process provided by a certain application. Adding and replacing applications will not affect
another application. Middleware is a technology that allows us to move information between enterprises.
There are two types of middleware models:
o Logical middleware model

 Depicts how information moves throughout the enterprise conceptually
o Physical middleware model
 Depicts both the actual method of information movement and the technology employed
Synchronous and Asynchronous Middleware

Asynchronous middleware moves information between one or many applications in an asynchronous
mode i.e., the middleware software is decoupled from the source or target applications. Applications are
not dependent on other connected applications for processing. Application can always continue
processing, regardless of the state of the other applications.
Synchronous middleware is tightly coupled to applications. The applications are dependent on the
middleware to process one or more functions calls at a remote application. Calling application must halt
processing to wait for the remote application to respond.
Asynchronous is preferred over synchronous application integration solution. Synchronous middleware

faces problems such as network or remote server problems. Therefore, application has to stop processing.
Synchronous middleware eats up bandwidth because several calls must be made across the network in
support of a synchronous function call.
Types of Middleware
o RPC

Oldest type of middleware. Provide ability to invoke a function within one program and
have that function execute within another program on a remote machine. RPC are
synchronous so RPC must stop the execution of the program. They also require more
bandwidth than other types of middleware.
 Advantage of RPC is its simplicity for mechanism and programming. Disadvantage is are
its huge performance cost and inability to scale.
o Message-oriented middleware (MOM)
57
 MOM is queuing software that uses is messages as a mechanism to move information
from point to point. MOM uses the notion of messages to communicate between
applications, Direct coupling with the middleware mechanism and the application is not
required. MOM rely on asynchronous paradigm. This allows application to function
independently such as continue processing after making a middleware service request.
Message is dispatched to a queue message, which ascertains that message is delivered to
its final destination. Messages returning to the calling application are handled when the
calling application finds the time. Managing are easy to manage using MOM as it has
structure (schema) and content (data). MOM can be thought as one-record database that
move between applications through message-passing mechanisms. MOM supports two
communication models; Point-to-point, and Message queuing (MQ).
o Distributed objects
 Small application programs that use standard interfaces and protocols to communicate
with one another. Provide mechanisms for application development, providing enabling
technology for enterprise, or enterprise-wide method sharing. There are two types of
distributed objects in market today; Common Object Request Broker Architecture
(CORBA) and Component Object Model (COM).
o Database-oriented middleware
 Facilitates communication with a database, whether from an application or between
databases. Can be used as mechanism to extract information to extract from either local
or remote databases. Works with two basic database types; the first one is Call-level
interfaces (CLI) - Common APIs that span several types of databases, providing access to
any number of databases through a well-defined common interface such as Open
Database Connectivity (ODBC).The second one is Native database middleware.
o Transactional middleware
 Provides mechanism for coordination information movement and method sharing
between many different resources. – Provides tightly coupled integration that requires
changes with source and target applications. Based on concept of transaction a unit of
work with a beginning and an end and application logic is encapsulated within a
transaction that either completes or is rolled back completely.
There are two types of transaction-oriented middleware:
 TP monitors
 Provide mechanism to facilitate the communication between two or more
applications as well as a location for application logic. Provides scalability by
sharing and processing transactions among other connected TP monitors. Provide
connectors to databases, other applications and queues. Once connected these
resources are integrated into the transaction and leveraged as part of the
58
transaction. TP monitors greatest performance value is in their load-balancing
feature.
 Application servers
 Provide application logic sharing and processing and for connections to back-end
resources such as databases, ERP applications and even traditional mainframe
applications. It also provide user interface mechanisms to deploy applications to
the web platform
o Integration servers
 Facilitates information movement between two or more resources and can account for
differences in application semantics and platforms without any application necessarily
understand anything about other applications it shares information with. It can also join
many applications by using common rules and routing engines and transform the schema
and content of the information as it flows between various applications and databases. It
can broker messages between two or more source or target systems.
Lesson 2: Enterprise Application Integration Concepts

This module explains the concepts of XML and enterprise application integration. EAI applies both to
integration of applications within an enterprise (intra-enterprise) as well as between enterprises (inter-
enterprise). A good understanding of these EAI concepts is fundamental to appreciating the opportunities
presented by some of the latest integration technologies used by enterprise architecture. We will first
examine business-to-business (B2B) integration issues and B2B business drivers. We will look at trading
communities and XML messaging standards.
XML
o Stands for Extensible Markup Language.
o A Markup language that defines set of rules for encoding documents in a format that is both
human-readable and machine-readable.
o It is normally used in website frontends, SW frontends, developing, and backend API
development.
o The most API responses are JSON and XML.
o Extension file is .xml
o Internet Media Type are application-xml or text-xml.
XML Usage
o KEEP – it can keep data separated from your HTML.
o STORE – it can store data inside HTML documents.
59
o FORMAT – it can be used as a format to exchange information.
o STORE IN DATABASE – it can be used to store data in files or in database.
Basic XML Concepts

XML indicates the context of relevant data by surrounding that data with tags that define its meaning. For
example, sales orders from ABC Company appear in XML as shown below:
<Customer>ABC Inc.</Customer>
But the Credit Control and Finance Departments use different terminology. They only recognize ABC by
their relevant terms:
<Client>ABC Inc.</Client> for the Credit Control Department
<Debtor>ABC Inc.</Debtor> for Accounts Receivable in the Finance Department
The start and end tags clearly indicate the terminology that is used in each department. We can see from
these XML data fragments that each department is dealing with the same enterprise: ABC.
Supposed a purchase order (PO) that is exchanged between both companies. This PO is issued by Smith
and Co, a subsidiary of ABC. It is a PO expressed in XML. It will look like this:
Figure 21 Example of PO XML
XML Technologies used in Enterprises.

XML provides the very powerful core to the enterprises to get and synchronize their data across all devices
and keep their record in databases. The XML provides the fast and reliable communication from database
to the web interface or frontend of apps.
XML is also used to model Enterprise architectures using XML enterprise framework.
60
Enterprise Information Integration requires an accurate, precise, and complete understanding of the
disparate data sources, the needs of the information consumers, and how these map to the business
concepts of the enterprise. In practice, such integration takes place in context of any enterprise
information system. Approaches to EII, its architecture as well as its association to enterprise application
integration. We justify why XML technology contributes to finding sufficiently powerful support for EII.
We present some features of XML technology, mainly its database part, and show how it is usable to EII.
Lesson 3: Enterprise Portal Technologies for Integration

An enterprise portal (EP) also called corporate portals or enterprise information portals is a gateway to
the structured data and unstructured data resources of an organization. It shows how these resources are
accessed from an enterprise portal, along with execution of business processes and application systems.
This technology is important for integration, because it provides easy access to resources where access
was often difficult before.
Definition of an Enterprise Portal

EP, generally defined as a single gateway via the network to relevant workflows, application systems, and
databases, tailored to the specific job responsibilities of each individual.
Different Forms of Enterprise Portal

o Employee Portal
 A single gateway that enables all employees to access the processes, systems, workflows
and databases via the network to carry out their relevant job responsibilities, with full
security and firewall protection.
o Customer Portal –
 A single gateway via the network to details about products and services, catalogs, and
order and invoice status for customers, tailored to the unique requirements of each
customer.
o Supplier Portal
 A single gateway to the purchase orders and related status information for the suppliers
of an enterprise.
o Partner/Shareholder Portal
 A single gateway for business partners or shareholders.
Basic Architecture of an Enterprise Portal

An enterprise portal is a Web-enabled, distributed environment with a single, common, managed user
interface to information supporting all categories of end users. It facilitates and supports e-commerce, e-
business, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply
Chain Management (SCM), along with browser-enabled access for customers, suppliers, business
partners, and employees. It supports operations such as virtual integration, knowledge-enabled
processes, and cross-function delivery of applications.
61
A key characteristic of enterprise portals is support of a single sign-on function: enabling qualified users
to sign on once to the portal and be automatically signed on to each application or resource that they are
authorized to access for relevant sites in the enterprise network.
Enterprise Portal Characteristics:
o Provide a single point of content delivery and management.

o Collect and organize information, making it easy to navigate.
o Provide a customizable, personalized, Web-based user interface.
o Include a content management system that automatically scans, filters, and catalogs content from
internal and external sources.
o Provide a capability to easily publish information and subscribe to information tailored to end
users’ specific needs.
o Include a search engine, content scanner, and Web crawlers to maintain, analyze, and locate
information.
o Provide an interactive portal capability, interacting with the underlying corporate applications.
o Provide a role-based portal capability for users to manage and update corporate data.
o Utilize a single sign-on for password and authentication, ideally LDAP-compliant.
o Utilize and attach to the native security of the underlying applications.
o Provide support for and integration of structured and unstructured information.
o Provide integrated access to an enterprise business intelligence system.
o Provide access to query and reporting, spreadsheet, graphs, and OLAP functions.
o Provide integration at the metadata level with ERP, CRM, SCM, e-commerce applications, analytic
applications, BI tools, and ETL tools.
o Support a standards-based infrastructure and environment, with support for HTML, HTTP/SSL,
XML, LDAP, Java, JavaScript, ActiveX, Web services, and so forth.
o Utilize an architecture that supports XML messaging
o Provide event-driven alerts or notification to users on user-defined events.
Figure 22 Typical enterprise portal architecture
62
Integration Using Enterprise Portal
An enterprise portal appears to deliver integration across many data sources presented in the separate
windows. But this is deceptive; each window is typically independent of all other network.
An enterprise portal that provides a view to one of these redundant versions sees only those values for
the relevant version. Hopefully these are up to date. But if they are out of date, that version must be
synchronized with more recently updated versions that exist elsewhere in the enterprise.
A portal presents an appearance of integration. It supports presentation integration. But the underlying
data themselves must first be integrated. Access through a portal to non-integrated, out-of-sync data is
irresponsible and is the ultimate exercise in futility.
Enterprise Portal Product Categories

Portal products are generally categorized based on their predominant focus, but most also offer
capabilities in other categories. This section provides a brief overview of the types of enterprise portal
product
Enterprise Portals comprise three categories:
o Collaborative Portal Products
Collaborative portals generally focus on unstructured knowledge resources, and typically offer
access to Microsoft Exchange and Lotus Notes. Examples of such resources are documents,
reports, e-mail, graphics, images, audio, and video. Collaborative portal products include the
following:
 IBM WebSphere Portal from IBM Corporation;

 Plumtree Corporate Portal from Plumtree software (now BEA);
 Microsoft SharePoint Portal Server from Microsoft Corporation;
 Citrix NFuse Elite Portal from Citrix, Inc.
o Business Intelligence Portal Products
Business intelligence portals generally focus on structured knowledge resources, with access to
data warehouses and information system databases. These structured resources are accessed via
business intelligence (BI), online analytical processing (OLAP), and other tools. Most data
warehouse products are evolving into this BI portal category. Some representative BI portal
products include:
 Axielle from Ascential Software (now IBM);

 CleverPath Portal from Computer Associates;
 Cognos Upfront from Cognos, Inc.;
 Enterprise Information Portal from Hummingbird.
o Integration Portal Products
63
Integration portals focus on easy integration between structured and unstructured knowledge
resources existing in information systems and data warehouse databases, ERP environments,
CRM, SCM, and others—within an enterprise via the corporate intranet, or between enterprises
via the Internet. A popular integration portal product is SAP Enterprise Portal from SAP.
Lesson 4: Web Services for Real-Time Integration

Web Service Technologies:
WS is a service offered by an electronic device to another electronic device, communicating with each
other via WWW.
It is a server running on a computer device, listening for requests at a particular port over a network,
serving web documents (HTML, JSON, XML, and images) and creating web applications services, which
serve in solving specific domain problems over the WWW.
Essential Functions of WS:
o Available over the internet or intranet networks.

o Standardized XML messaging system.
o Independent of a single Operating System or Programming Language.
o Self-describing via standard XML language.
o Discoverable through a simple location method.
Different Types of Web Services

XML (Remote Procedure Call)
The most basic XML protocol to exchange data between varieties of devices on a network. It uses HTTP
to quickly and easily transfer data and communication other information from client to server.
UDDI (Universal Description, Discovery, and Integration)

An XML based standard for detailing, publishing, and discovering web services. It’s basically an internet
registry for businesses around the world. The goal of streamline digital transaction and e-commerce
among companies.
SOAP
An XML based Web service protocol to exchange data and documents over HTTP or SMTP (Simple Mail
Transfer Protocol). It allows independent processes operating in disparate systems to communicate
using XML.
REST
Provides communication and connectivity between devices and the internet API-based tasks. Most
RESTful services use HTTP as supporting protocol.
64
Lesson 5: Service-Oriented Architecture for Integration
Service-Oriented Architecture (SOA) is a style of software design where services are provided to the other
components, through a communication protocol over network. Its principles are independent of vendors
and other technologies. It is basically a collection of services. The communication can involve either simple
data passing or it could involve two or more services coordinating some activity. It is an evolution of
distributed computing based on the request/reply design paradigm for synchronous and asynchronous
applications. For example, a service can be implemented in.NET or J2EE, and the application consuming
the service can be on a different platform or language.
SOA is an architectural approach, in which applications make use of services available in network. In this
architecture, services are provided to form applications, through a communication channel over the
internet.
Security
Data
confidentiality
and integrity
Process
Services
Align IT with
Improved
Information Flow Business
Operations
SOA
Service-
Oriented
Architecture
Platform Practice
Increase Employ Best
Operational Practices
Efficiency
Methodology
Adaptability
Ability to Adapt
quiclkly to different
external
environment
Figure 23 Components of Service-Oriented Architecture
Three Roles within SOA
o Service Provider
o A role that works in conjunction with the service registry, debating the whys and how’s of
the services being offered, such as security, availability, what to charge, and more. This
role also determines the service category and if there need to be any trading agreements.
o It is the maintainer of service and the organization that makes available one or more
services for others to use.
o Service Broker
o This role makes information regarding the service available to those requesting it. The
scope of the broker is determined by whoever implements it.
65
o Service Requester/Consumer
o It locates entries in the broker registry and then binds them to the service provider. They
may or may not be able to access multiple services; that depends on the capability of the
service requester.
Guiding Principle of SOA
o Standardized service contract.

 Specified through one or more service description documents.
o Loose Coupling
 Services are designed as self-contained components, maintain relationships that
minimize dependencies on other services.
o Abstraction
 It is completely defined by service contracts and description documents. They hide their
logic, which is encapsulated within their implementations.
o Reusability
 Designed as components, services can be reused more effectively, thus reducing
development time and the associated costs.
o Autonomy
 Services have control over the logic they encapsulate and from a service consumer point
of view, there is no need to know about their implementation.
o Discoverability
 Services are defined by description documents that constitute supplemental metadata
through which they can effectively discovered. Service discovery provides an effective
means for utilizing 3rd party resources.
o Composability
 Using services as building blocks, sophisticated and complex operations can be
implemented. Service orchestration and choreography provide solid support for
composing services and achieving business goals.
Advantages of SOA
o Service Reusability
 Applications are made from existing services.
 Service can be reuse to make many applications.
o Easy Maintenance
 As services are independent of each other they can be updated and modifies easily
without affecting other services.
o Availability
 SOA facilities are easily available to anyone on request.
o Reliability
 SOA applications are more reliable since it is easy to debug small services rather than huge
code.
Disadvantages of SOA
o High Overhead
66
 A validation of input parameters of services is done whenever services interact this
decreases performance as it increases load and response time.
o High Investment
o Complex Service Management
 When services interacts they exchange messages to tasks. The number of messages may
go to millions. It becomes a cumbersome task to handle a large number of messages.
Introduction to Service-Oriented and Event-Driven Architectures

Service-oriented architecture is the term that has emerged to describe executable components, such as
Web services, that can be invoked by other programs that act as clients or consumers of those services.
As well as the execution of Web services, these services can also be complete modern—or even legacy—
application programs that can be invoked for execution as a “black box.” A developer does not need to
know how the programs work; they need only know the input required, the output provided, and how to
invoke them for execution. Software categories that provide this SOA flexibility are called Business Process
Management (BPM) or business product integration (BPI) products.
Event-driven architecture is an approach for designing and building applications where business events
trigger messages to be sent between independent services that are completely unaware of each other.
An event may be the receipt by the enterprise of a sales order transaction from a customer for processing.
An event may also be a change in a data value that requires a purchase order to be placed with a supplier,
when the available quantity of a product in the warehouse falls below a minimum balance threshold.
The following are the Business Process Management (BPM) languages of SOA:
o Business Process Execution Language (BPEL)

 Business Process Execution Language for Web services combines IBM’s WSFL and
Microsoft’s XLANG. BPEL is designed to support implementation of any complex business
process, as well as being used to describe interfaces of business processes.
o Web Services Choreography Interface (WSCI)
 Web Services Choreography Interface is an alternative specification to BPEL. It is used to
define the flow of messages exchanged by Web services participating in coordinated
activities with other services. WSCI is not a “workflow description language” as such, but
describes the behavior of Web services that interact with a workflow, or a system that
implements a workflow.
o Business Process Modeling Language (BPML)
 Business Process Modeling Language defines a formal model for expressing executable
business processes. It defines simple and complex activities, transactions and
compensation, data management, concurrency, exception handling, and operational
semantics. BPML provides a grammar as an XML schema to enable the persistence and
interchange of definitions across heterogeneous systems and modeling tools.
o ebXML Business Process Specification Schema (BPSS)
 The ebXML Business Process Specification Schema (BPSS 1.0) defines a business process
for physical business interchanges between parties so that collaborations and
transactions can be carried out between commercial business partners. It works in
67
conjunction with the ebXML CPP and CPA. It also defines the automatic generation of
BPSS code from UML diagrams. BPSS 2.0 uses BPMN instead of UML for process models.
o Business Process Modeling Notation (BPMN)
 Business Process Modeling Notation is emerging as a way to specify business process
models and diagrams. This is as an evolving standard for the specification of process logic
for all of the above BPM languages. The Business Process Management Initiative (BPMI)
and the Open Management Group (OMG) have announced they are merging their BPM
activities to advance the use of BPMN as an open standard.
References


Assessment
1. What are the different types of Middlewares?

2. How middleware does addresses the redundant data version problem efficiently and
inexpensively?
3. What is the difference of XML and HTML?
4. What is the advantages of implementing enterprise portal in enterprise integration?
5. Enumerate and explain each Web Service Technologies that can be used for Real Time
integration.
6. Define a successful Service-Oriented Architecture?
68
Module 7: Enterprise Resource Planning
Overview
The Enterprise resource planning (ERP) software market is one of the fastest growing markets in the
software industry. It has seen a rocky start with several project failures and a huge shortage of skilled and
experienced workers. The application such as Enterprise Resource planning aims at integrating enterprise
systems across functional departments. It is an integrated computer-based application software used to
manage internal and external resources.
It interfaces with all aspects of an organization: people, process, technology, systems, structure, skills,
culture, and definitely available technology funds. Executives responsible for such projects must develop
a very clear understanding of the tasks they are about to undertake and ensure that all the relevant
variables are accounted for in the planning process and that time and effort are dedicated to them during
and after the implementation.
Lesson Outcomes
o To discuss the role of Enterprise Planning to Physical and Logical Integrations.
o To assess the implications of ERP to Management.
o To distinguish ERP to E- Commerce.
o To identify the components of ERP and its Architecture.
o To discuss the ERP Implementations and Pros and cons in Business Level.
o To give examples of ERP Vendors.
Lesson1: Definition of Enterprise Resource Planning

Enterprise Resource Planning (ERP) systems are a major kind of information system allowing organizations
to integrate different systems into one organization-wide application with an integrated database
management system.
The goal of ERP is to integrate departments and functions across an organization into a single
infrastructure sharing a common database and serving the needs of each department.
ERP systems replace an assortment of systems that typically existed in organizations. Moreover, ERP
solves critical problem of integrating information from different sources and makes it available in real-
time.
69
Figure 24 Integrated Systems - ERP
Lesson 2: ERP and Systems Integration

ERP systems are integrated, multi-module application software packages designed to serve and support
several business functions across an organization. It is typically commercial software packages that
facilitate collection and integration of information related to various areas of an organization. It enables
the organization to standardize and improve its business processes to implement best practices for its
industry.
ERP systems are the first generation of enterprise systems meant to integrate data and support all the
major functions of ERP systems integrate various functional aspects of the organization as well as systems
within the organization of its partners and suppliers.
The goal of an ERP system is to make the information flow dynamic and immediate, therefore, increasing
its usefulness and value.
Lesson 3: ERP’s Role in Logical Integration

ERP systems require organizations to focus on business process rather than on functions. It comes with
built-in processes for a wide variety of common business functions.
An ERP system implements best practices via specific built-in steps for processing a customer order in
terms of:
70
o Order entry.
o Routing through departments.
o Communication of output to various parties.
Lesson 3: ERP’s Role in Physical Integration

Before installing the ERP system, an organization may have to upgrade or install middleware or get rid of
their legacy system’s hardware and software. Integration is also required at the Data level, Client level,
and at the Application level.
A good ERP implementation improves operational efficiency with better business processes that focuses
on organizational goals rather than on individual departmental goals. Improved efficiency with a paperless
flow and electronic data interchange (EDI) or business-to-business (B2B) commerce environment with
partner
Lesson 4: ERP implications for Management

In the early days of ERP implementation most management did not understand the magnitude of issues
an organization has to consider before, during, and after implementation. ERP systems are very different
from conventional packaged software, such as Microsoft Office and others.
o ERP systems implementation is a complex organizational activity.

 There are no shortcuts when it comes to implementing an enterprise system.
o It is important to evaluate and learn from the successes and failures.
o ERP systems implementation requires strong project management oversight.
Lesson 5: Comparison of E-Commerce and ERP

E- Commerce
o Focuses on linking a business with its external partners and stakeholders
o Disruptive technology
 Totally transformed the way a business operates in terms of buying and selling,
customer service, and relationships with suppliers.
ERP
o Focuses on integrating the internal functional silos of the organization into an enterprise
application.
o Adaptive technology
 Merged the early data processing and integration efforts within an organization.
71
Figure 25 Venn Diagram of E-Commerce and ERP Approach
Lesson 6: ERP- Architecture and Components

ERP Systems Components
ERP consists of the following:
o Hardware
 Servers and peripherals
o Software
 Process Operating systems and database
o Information
 Organizational data from internal and external sources
o Process
 Business processes, procedures, and policies
o People
 End users and IT staff
Figure 26 ERP Systems Components
72
ERP Architecture
The architecture of an ERP system influences the cost, maintenance, and the use of the system. The ERP
architecture helps the implementation team build the ERP system for the organization. If purchased,
ERP architecture is often driven by the vendor (Package-Driven Architecture).
There are two types of architectures.
o Logical Architecture
 Focuses on the supporting needs of the end users.
Figure 27 Logical Architecture or ERP Systems
73
Figure 28 Example of Tiered Logical Architecture of ERP Systems
o Physical Architecture
 Focuses on the efficiency of the system.
Benefits and Limitations of ERP

System Level
Benefits Limitations
Integration of data and applications across Complexity of installing, configuring, and
functional areas (i.e., data can be entered once maintaining the system increases, thus requiring
and used by all applications; thus improving specialized IT staff, hardware, and network
accuracy and quality of the data) facilities
Improvements in maintenance and support as IT Consolidation of IT hardware, software, and
staff is centralized. people resources can be cumbersome and
difficult to attain.
Consistency of the user interface across various Data conversion and transformation from an old
applications means less employee training, better system to a new one can be tedious and complex
productivity, and cross-functional job process.
movements.
Security of data and applications is enhanced due Retraining of IT staff and end users of the new
to better controls and centralization of hardware. system can produce resistance and reduce
productivity.
74
Business Level
Benefits Limitations
Agility of the organization in terms of responding Retraining of all employees with the new system
to changes in environment for growth and can be costly and time consuming.
maintaining
market share
Sharing of information across functional areas Change of business roles and department
helps collaboration between employees boundaries can create upheaval and resistance to
the new system.
Linking and exchanging information in real-time
with supply-chain partners improves efficiency
leading to lower costs.
Better customer service due to quicker
information flow across departments.
Efficiency of business processes are enhanced
due to the re-engineering of business processes.
Lesson 6: ERP Implementations

Before implementing ERP, an organization has to plan and understand the life cycle of these systems. The
key to a successful implementation is to use a proven methodology, take it one step at a time, and begin
with an understanding of the ERP life cycle. ERP system implementations are very risky, and using a well-
defined project plan with a proven methodology will assist in managing those risks. There must be a strong
well-communicated need to make the change from the existing information stems/applications to an ERP
system.
75
Figure 29 ERP Implementation
Software and Vendor Selection

It is best for an organization that does not have experience in developing ERP systems to purchase one on
the market. Before selecting a vendor, the organization must carefully evaluate its current and future
needs in enterprise management. Review the organization’s existing hardware, network, and software
infrastructure, and the resources available for implementation.
Vendor Evaluation
The following are consideration in evaluating potential vendor:
o Business functions or modules supported by their software.

o Features and integration capabilities of the software.
o Financial viability of the vendor as well as length of time they have been in business.
o Licensing and upgrade policies.
o Customer service and help desk support.
o Total cost of ownership.
o IT infrastructure requirements.
o Third-party software integration.
o Legacy systems support and integration.
o Consulting and training services.
o Future goals and plans for the short and long term.
76
Considerations on Operations and Post-Implementation
Going live (“Go-live”) is one of the most critical points in a project’s success. It is vital to focus the efforts
of all project teams to ensure that task and activities are completed before going live.
Five areas of stabilization are important:
o Training for end-users.

o Reactive support (i.e., help desk for troubleshooting).
o Auditing support to make sure data quality is not compromised by new system.
o Data fix to resolve data migration and errors revealed by audits.
o New features and functionalities to support the evolving needs of the organization.
People and Organizations

Below are the members or people of Organizations:
o Project Management
 For an ERP system to be implemented successfully, project management must provide
strong leadership, a clear and understood implementation plan, and close monitoring of
the budget.
o Consultants
 It is often the case for organizations without much ERP implementation experience to use
implementation partners such as consultants.
o Change Management
 Role is essential because it prepares for changes to how business is done. In implementing
new systems, communicating, preparing, and setting expectations is as important as
providing training and support.
o Business Process Re-engineering
 Business processes will need to be changed, adjusted, or adapted to the new system to
use the functionality of an ERP system fully.
o Global, Ethical and Security Management
 Outsourcing overseas, ethical issues, and problems with system security have also
attracted a lot of attention in ERP implementation.
Sample ERP Vendors:

o SAP
SAP is the recognized global leader among ERP vendors with over 12 million users. Its
solutions are for all types of industries and for every major market.
o Oracle/PeopleSoft
 As the second largest ERP vendor, Oracle provides solutions divided by industry
category and promises long-term support for customers of PeopleSoft- (acquired in
2004).
o Microsoft Dynamics
 Formerly Microsoft Business Solutions or Great Plains, Microsoft Dynamics is a
comprehensive business management solution built on the Microsoft platform.
77
o Infor
 The world’s third largest provider of enterprise software. It delivers integrated
enterprise solutions in supply chain, customer relationship and suppliers management.
o Lawson
 Industry-tailored software solutions that include enterprise performance management,
distribution, financials, human resources, procurement, and retail operations.
Figure 30 Sample Vendors
References
An Overview of Enterprise Resource Planning (ERP)．[Online][Cited: 27 September 2020．

]http://www.retawprojects.com/uploads/An-Overview-Enterprise-Resource-Planning__ERP.pdf．
Lawson Website．[Online]www.lawson.com．
MyersonJudithM. Enterprise System Integration．New York，AUERBACH PUBLICATIONS，2001．
Oracle Website．[Online]www.oracle.com．
SAP Website．[Online]www.sap.com．
78
Assessment
1. What is Enterprise Resource Planning?

2. What is the difference of ERP to Supply Chain Management and Customer Relationship
Management Application?
3. Why an organization undertake ERP?
4. What are the advantages of having Outsourcing and Insourcing of ERP? And what are the
disadvantages?
79
Module 8: Other EA Enabling Technologies
Overview
There are different technologies that enables the Enterprise Architecture Integration nowadays and one
of these is Cloud Computing. The role of information in Cloud Computing as a new delivery model and
information delivery in a WWW rounds off key aspects of the EIA. It provides capabilities to further
facilitate both the breadth and depth of capabilities required for a true Enterprise Information
Architecture. The 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.
Another technologies that provides as a motivation to the enterprise's operation is Business Intelligence.
Under Business Intelligence are concepts of Data Warehousing, Data Mining, OLTP and OLAP.
Lesson Outcomes
o To discuss how internet becomes a service for Information Systems.
o To explain the role of Cloud Computing in IT and Business Enterprise.
o To discuss the common cloud models of cloud providers.
o To explore the future of enterprise cloud computing.
o To determine the different approaches that Business Intelligence can offer in an enterprise.
o To discuss the Data Warehousing Process
o To illustrate some text and Data mining approaches in BI.
o To distinguish the OLAP and OLTP Processing tool.
Lesson 1: Cloud Computing

Cloud computing promises to revolutionize IT and business by making computing available as a utility over
the internet. Software architects primarily need to assess the impact of such a transformation. It explains
the evolution of the internet into a cloud computing platform, describes emerging development
paradigms and technologies, and discusses how these will change the way enterprise applications should
be architected for cloud deployment.
Enterprise Computing
Enterprise computing means the use of computers for data processing in large organizations, also referred
to as ‘information systems’ (IS), or even ‘information technology’ (IT) in general. The use of computers for
enterprise data processing began in the 60s with the early mainframe computers. Over the years
enterprise computing paradigms have changed dramatically with the emergence of new technology.
With each of these advances, enterprise systems have dramatically improved in terms of scale and
ubiquity of access. At the same time their complexity, and consequently cost, has increased as well.
Now, cloud computing offers the potential for revolutionizing enterprise computing once more, this time
by transforming computing itself into a utility that can be accessed over the internet.
80
Mainframe Architecture
The history of enterprise computing began in the advent of ‘3rd generation’ computers in the 60s; these
used integrated circuits as opposed to vacuum tubes, beginning with the IBM System/360 ‘mainframe’
computer and its successors, which continue to be used to date, e.g. the IBM z-series range.
Figure 31 Mainframe Architecture
Client-Server Architecture
The microprocessor revolution of the 80s brought PCs to business desktops as well as homes. At the same
time minicomputers such as the VAX family and RISC-based systems running the UNIX operating system
and supporting the C programming language became available. It was now conceivable to move some
data processing tasks away from expensive mainframes to exploit the seemingly powerful and inexpensive
desktop CPUs. As an added benefit corporate data became available on the same desktop computers that
were beginning to be used for word processing and spreadsheet applications using emerging PC-based
office-productivity tools.
81
Figure 32 Client-Server Architecture
3-TIER ARCHITECTURES WITH TP MONITORS
In late 90s, RISC CPUs had exceeded mainframes in raw processing power. However, unlike the
mainframe, client-server architectures had no virtual machine layer or job control systems to control
access to limited resources such as CPU and disk.
Client-server architectures fail to scale for high volume transaction processing because the CPUs were
inferior to mainframes.
Client-server fails 3-tier architecture scales
82
Figure 33 3-tier TP monitor architecture
Internet as a Platform
The internet was born as a communication infrastructure for data sharing soon grew to include academic
institutions across the world. Using a browser, information ‘published’ over the internet could be accessed
anonymously by the public at large, giving rise to the ‘world wide web’. The subsequent history of the
commercialization of the web and the dot-com boom is also well known. The internet also evolved into a
platform for enterprise applications, eventually giving birth to the cloud computing paradigm.
INTERNET TECHNOLOGY AND WEB-ENABLED APPLICATIONS

Internet-based applications rely fundamentally on HTTP, the HyperText Transfer Protocol, and HTML, the
HyperText Markup Language; both are now standards defined by the World Wide Web consortium (W3C).
Browsers, such as Internet Explorer, and servers, such as HTTPD (HyperText Transfer Protocol Daemon)
implement these standards to enable content publishing over the internet. Other technologies such as
XML and SOAP are also important, the essential aspects of these underlying technologies that are critical
to understanding internet-based enterprise applications and cloud computing.
83
Figure 34 Internet technology and web-enabled applications
WEB APPLICATION SERVERS
In a web-enabled application architecture, processing logic, including database access, took place outside
the web server process via scripts or programs invoked by it, using CGI for inter-process communication.
Each such ‘CGI-script’ invocation included the costly overhead of launching the required server program
as a fresh operating-system process.
84
Figure 35 Web application server
The invention and proliferation of the Java language, designed to be portable across machine
architectures with its interpreted yet efficient execution model made possible alternative approaches to
execute application functionality inside the web-server process, leading to the birth of the ‘application
server’ architecture.
Figure 36 Web application server technology stacks
Through the 2000s, the application server architecture has become pervasive across enterprise IT,
virtually replacing all other alternatives for new application development. The only major choice to be
made has been between a Java or Microsoft stack.
85
INTERNET OF SERVICES
Once applications began to be web-enabled, it became natural to open up access to some of their
functionality to the general public. For example, web-based access to back-end applications meant that
end-users could themselves perform tasks such as tracking courier shipments, getting quotations for
services, or viewing their bank balances; soon secure payment mechanisms were also developed that
enabled users to place orders and make payments online.
With web-based access to applications becoming uniformly available to users through a browser
interface, the next step was programmatic access to the same applications over the internet. This was
open to abuse and malicious behavior (denial of service attacks etc.). Web services were developed
initially to address this need.
The W3C defines a ‘web service’ as interoperable machine-to-machine interaction over HTTP. The HTML
format for data exchange over the internet, was used extensively in the mainframe world for generating
reports. While hugely successfully, HTML was less suited for machine-to-machine communications as its
syntax is not ‘well-formed. In 1997 W3C published XML (extensible markup language), using which one
could also write well-formed HTML (XHTML), thereby driving browsers to support XML in addition to
HTML.
This, together with XML as a basis for interoperable message formats, laid the foundation for formal web
service standards. The XML-RPC standard mimics remote procedure calls over HTTP with data being
transferred in XML. Like RPC, XML-RPC limits itself to simple data types, such as integers, strings etc. To
support complex, nested (object oriented) types, the SOAP protocol was developed, whereby the schema
of the messages exchanged as input and output parameters of published ‘services’ was defined using an
XML format called WSDL (web services description language) and communicated over HTTP as SOAP
messages (another XML format). Using SOAP, applications could call the web services published by other
applications over the internet.
86
Figure 37 Internet of services
An alternative to the SOAP protocol, called REST (representational state transfer), which is rapidly
emerging as preferred protocol for remote data access especially in the context of cloud computing.
Cloud computing
Whereas software as a service is about packaged applications made available over the internet, cloud
computing makes a lower level of infrastructure and tools available over the internet in data centers
maintained by a cloud provider. To understand the additional features that account for the surge of
interest in cloud computing, we first need to trace the evolution of cloud computing by the pioneers in
the field. Amazon and Google.
Amazon, the first ‘cloud’ provider, faced a different set of challenges as it grew from an online bookseller
to an online retail hub, but solved them in a highly innovative and reusable manner, leading eventually to
a new cloud computing business. First, the complexity of Amazon’s application suite; to display one page
featuring a book, a number of services from fairly complex applications are needed, such as reviews,
recommender systems, and collaborative filtering. Next, the peaks and troughs of the seasonal retail
business necessitated Amazon to continuously monitor load and automatically provision additional
capacity on demand. Finally, as they became a retailer catering to the ‘long tail’ of small niche products,
they saw the need to support their suppliers with some minimal IT, many of whom had no systematic
computing systems apart from a few personal computers.
For Google, the scale of computing power needed to support large-scale indexing of the web, the immense
volume of searches, and machine-learning-based targeting of advertisements across this volume meant
87
orders of magnitude larger computational needs as compared to even the largest enterprise. Large banks
today often have tens of thousands of servers; Google, on the other hand is estimated as running over a
million servers, as of today. Google developed innovations in programming models for large-scale
distributed processing, such as the Map Reduce model for partitioning a sequence of tasks to be
performed on a very large data set and executing it in parallel across a very large set of machines.
Cloud models
Future of enterprise cloud computing

The ecosystem of technologies related to the enterprise adoption of cloud computing is constantly
evolving. As cloud computing matures, many of the concerns surrounding its use for enterprise
applications are likely to be addressed. In the meantime, there are a few quick-wins that can result in
immediate benefits by leveraging available cloud platforms. In the longer term, cloud computing will itself
evolve in hereto unknown directions, and we speculate on a few of these:
o Commoditization of the data center

o Inter-operating Virtualized Data Centers
o Convergence of private and public clouds
o Generalized ‘cloud’ services
88
Lesson 2: Business Intelligence, Analytics and Search
Another equally important motivation to maintain data about an enterprise’s operations is to unearth
hidden patterns and discover knowledge that can improve business strategy or optimize operational
processes. Such knowledge discovery tasks are supported by analytical applications. Additionally, with the
advent of the web and the ubiquity of internet search, any knowledge discovery or creation exercise today
includes web search as an integral supporting activity. This naturally leads to the question of whether
similar search technologies can be applied to enterprise information retrieval.
Interest in enterprise search has also been fueled by the increasing amounts of text (and other
unstructured) information generated and maintained by large enterprises and the use of search
technologies to index such data. There also interest in exploring whether search techniques apply to
structured data.
An end-user’s view of a business intelligence application is that of a variety of reports that aggregate
operational details of the enterprise summarizing business performance. For example, sales analysis may
require viewing quarterly sales of products from different categories (such as ‘consumer’ versus
‘enterprise’), segregated by region.
Figure 38 Example of Summary of Report arrive using BI
Data Warehousing
Actual operational data maintained by the enterprise is in terms of orders placed by customers, shipments
dispatched, invoices raised and payments made. Further, the number of such records can be very large.
For example, a large global retail chain might generate a few million such records a day. Operational data
needs to be transformed into a form on which a variety of reports can be computed. The process of
extracting and transforming operational data into such a ‘reporting database’ is called data warehousing.
Data Warehousing Process

Data Warehousing is not as simple a process as may appear at first glance; data warehousing usually
involves steps such as:
1. Removing all purely operational data, such as remarks or shipping reference numbers.
2. Time stamping and related restructuring of data so that it represents historically valid snapshots:
For example, the category of a product may change over time; therefore the product category at
89
the time of sale needs to be stored along with a sales record instead of in a separate product
category table, so that even if a product changes category, historically correct information is
maintained.
3. Computing and inserting derived data, such as the location of a sale, which is possibly defined by
the city and country specified in the customer’s address, if available, or by the address of the retail
store where the sale was made.
4. Aggregating measures by the lowest expected granularity required for reporting, such as
aggregating sales figures at a weekly level rather than by date, if it is determined that this is the
finest level to which reporting may be needed.
5. Computing any required aggregates based on the desired semantics. For example, is a ‘sales
record’ an order, a payment, or an invoice? The period in which a sale may be counted may be
different in each case. Moreover, some invoices may be unpaid or some orders rejected. Such
facts would need to be accounted for while creating ‘sales records’ in the data warehouse.
Usually an enterprise data warehouse aggregates many different measures of enterprise performance.
Thus, in addition to sales, other measures such as income, costs, shipment delivery times and average
manufacturing production throughput are also captured along with relevant dimensions. Such a large data
model becomes difficult to navigate and query; therefore purpose specific data is often extracted from
the enterprise data warehouse into a data mart. For example, a sales data mart would include only sales
information with relevant dimensions, leaving out dimensions such as manufacturing location, or product
cost.
OLTP and OLAP

OLTP stands for On-line Transaction Processing. OLTP is transactional system and deals with the operation
in a system with lot of short transactions on-line i.e. INSERT, UPDATE, and DELETE. OLTP focus on very
fast query processing. It is quite efficient to maintain data in multi-accessed environments. The data is
frequently updated.
OLAP stands for On-line Analytical Processing. OLAP is analytical system and deals with historical data with
low volume of transactions. Response time is an effective measure of the OLAP systems. Data is stored in
multi-dimensional schemes and is aggregated. Queries are quite complex here. Its processing speed
depends upon the amount of data involved.
90
Figure 39 High Level Differences of OLTP and OLAP
Key Differences between OLTP and OLAP
o OLTP stands for On-line Transaction Processing while OLAP stands for On-line Analytical
Processing.
o OLTP provides data to data warehouse while OLAP analyze this data.
o OLTP deals with operational data while OLAP deals with historical data.
o In OLTP queries are simple while in OLAP queries are relatively complex.
o Processing speed of OLTP is very fast while in OLAP processing speed depends upon the amount
of data.
o OLTP requires less space for data as compare to OLAP.
o Database design of OLAP is highly normalized with many tables while in OLAP the database design
is de-normalized with few tables.
o In OLTP database transactions are short while in OLAP database transaction are long.
o IN OLTP volume transactions are high while in OLAP volume transaction are low.
o In OLAP transaction recovery is necessary while in OLTP transaction recovery is not necessary.
o OLTP focuses on updating data while OLAP focuses on reporting and retrieval of data
OLAP on a star schema

Business intelligence tasks aggregate measures of business performance along a set of dimensions. At a
data mart level, the star schema is a popular data model for capturing multidimensional information,
especially where dimensions are hierarchical. The name ‘star’ comes from its structure: A central fact table
surrounded by associated dimension tables. The dimension tables capture the hierarchical structure of
each dimension, such as time period in days, weeks and months, or product category in terms of a
hierarchy of categories (such as board games, toys, entertainment, and consumers).
91
Figure 40 Star schema
TEXT AND DATA MINING

A similar analysis could also evaluate customers, or employees. On the other hand, detecting fraud,
finding patterns in product purchases or identifying trends and opinions, are more difficult, and are
perhaps impossible to achieve solely through OLAP. Further, when the number of dimensions on which
data needs to be analyzed becomes large, slicing and dicing becomes difficult to comprehend and results
in a trial-and-error process of iteratively choosing dimensions to see if they yield insight.
Instead, the data mining approach mathematically models the analysis task. This results in a few broad
categories of problems that can be solved (using a variety of computational techniques), rather than
relying on human analysis alone:
o Classifying data by manually assigning labels (e.g. ‘valuable’) to a known subset of data, and using
this to construct a classifier, i.e. a mathematical model, which can then be used to automatically
assign the labels for remaining data, or for new records as they arrive.
o Clustering data into groups that are more ‘similar’ to each other than to other clusters, for
example to determine which documents discuss the same set of topics, or which customers
exhibit similar buying patterns.
o Identifying anomalies, which are records very dissimilar from the vast majority of data, such as in
fraud detection, or crime and intelligence investigations.
o Analyzing patterns in subsets of data that have particularly strong connections to each other,
especially in conjunction with other techniques, such as anomaly detection or clustering: For
example, automatically characterizing anomalous behavior in terms of ‘explanations’ that yield
deeper insight, or describing the actual behavior patterns of customers belonging to the same
cluster.
o Making predictions by choosing hypotheses that might explain data, by constructing probabilistic
models, such as in tracking a moving target, modeling price movements or fault diagnosis.
92
References
DadiaRajeenOLTP vs. OLAP．[Online][Cited: 27 September 2020．

]https://www.youtube.com/watch?v=Zd4VK3gHYs0&feature=youtu.be．

GHarold OLTP vs. OLAP．[Online][Cited: 19 September 2020．]https://diffzi.com/oltp-vs-olap/．
Assessment
1. How can Cloud computing be an impact to the new delivery models on operational service
qualities?
2. Who pioneered the design of cloud models in cloud computing fields? What are their major
differences?
3. Define Internet as a Service.
4. What do we mean about Commoditization of the data centers?
5. What is Data Warehousing?
93
APPENDIX A. Course Syllabus
POLYTECHNIC UNIVERSITY OF THE PHILIPPINES

College of Computer and Information Sciences
Department of Information Technology
COURSE TITLE Systems Integration and Architecture

COURSE CODE COMP 30033
CREDIT UNITS 3 UNITS / 3 HOURS
COURSE PREREQUISITE
COURSE DESCRIPTION This subject should develop skill in enterprise architecture planning and enterprise application integration. By creating an enterprise architecture
plan, the student should be able to define and describe the data, the applications, and the technology needed to support the organization.
Application integration should cover creating strategic business solutions using technology integrating it with the, business functionalities and
processes.
Institutional Learning Outcomes Program Outcomes Course Outcomes

1. Creative and Critical Thinking Apply knowledge of computing, science, and An
Graduates use their imaginative as well as rational mathematics appropriate to the discipline. Combine lessons from previous subjects to come up with
thinking abilities to life situations in order to push an integrated solution at the enterprise level
boundaries, realize possibilities, and deepen their Analyze complex problems, and identify and define the
interdisciplinary and general understanding of the world. computing requirements appropriate to its solution.
Identify and analyze user needs and take them into

account in the selection, creation, evaluation and
administration of computer-based systems.
2. Effective Communication Communicate effectively with the computing community Document data gathered in every step of the process.
Graduates are proficient in the four macro skills in and with society-at- large about complex computing Create reports on progress updates.
communication (reading, writing, listening, and speaking) activities through logical writing, presentations, and Create project presentations on the application
and are able to use these skills in solving problems. clear instructions.
Making decisions and articulating thoughts when
engaging with people in various circumstances.
3. Strong Service Orientation Function effectively as a member or leader of a Perform tasks, depending on the role assignment
Graduates exemplify the potentialities of an efficient, development team recognizing the different roles within Contribute expertise to other members of the team.
well-rounded and responsible professional deeply a team to accomplish a common goal. Solve problems, whether technical and or non-technical
committed to service excellence. issues that may arise.
94
4. Community Engagement Analyze the local and global impact of computing Design and develop solutions which are relevant to the
Graduates take an active role in the promotion and information technology on individuals, organizations, changing needs of the stakeholders
fulfillment of various advocacies (educational, social and and society.
environmental) for the advancement of community
welfare. Integrate IT-based solutions into the user environment
effectively.
5. Adeptness in the Responsible Use of Technology Apply knowledge through the use of current techniques, Design and develop solutions that will cater to the needs
Graduates demonstrate optimized use of digital learning skills, tools and practices necessary for the IT profession of the organization
abilities, including technical and numerical skills.
Understand best practices and standards and their
applications.
Design, implement, and evaluate computer-based

systems, processes, components, or programs to meet
desired needs and requirements under various
constraints.
Assist in the creation of an effective IT project plan.
6. Passion to Lifelong Learning Recognize the need for and engage in planning, self- Plan knowledge sharing with the team for lessons
Graduates are enabled to perform and function in the learning, and improving performance as a foundation for which will be applied in the design.
society by taking responsibility in their quest to know continuing professional development.
more about the world through lifelong learning.
7. High Level of Leadership and Organizational Skills Function effectively as a member or leader of a Perform the role of a leader and organize the team so
Graduates are developed to become the best professionals development team recognizing the different roles within that each member will be able to maximize his full
in their respective disciplines by manifesting the a team to accomplish a common goal. potential
appropriate skills and leaderships qualities.
8. Sense of Personal and Professional Ethics Understand professional, ethical, legal, security and Design solutions which will be useful or beneficial to the
Graduates show desirable attitudes and behavior either in social issues and responsibilities in the utilization of well-being of the stakeholders
their personal and professional circumstances. information technology.
9. Sense of National and Global Responsiveness Analyze the local and global impact of computing Design solutions which will be useful or beneficial to the
Graduates’ deep sense of national compliments the need information technology on individuals, organizations, broader segment of the community
to live in a global village where one’s culture and other and society.
people culture are respected.
95
Course Plan
Week Topic Learning Outcomes Methodology Resources Assessment

Week 1 Introduction to the Course a. Demonstrate an understanding of Orientation University Student Quick recitation using online
Introductions (Faculty and what the subject is all about, what Self- Handbook application to get students’
Students) will be in scope for the semester, and Introduction College Manual understanding of what has been
Discussion of Course Syllabus what students are expected to learn (On-line) Course Syllabus discussed
including Grading System and b. Explain the importance of this subject Online application
General rules and how it can synthesize with other
Classroom Management subjects learned before
c. Communicate with fellow students
and teacher and begin to establish
rapport
d. Identify and explain the course
assessment and validation criteria ,
including grading system to
understand how to pass the subject
e. Explain what are the do’s and don’ts
while the class is on-going
Week 2 Introduction to Systems a. Discuss the role of IT and its Online Class Instructional Online quiz
Integration and Enterprise importance in an Organization Discussion Manual
Architecture b. Define an Enterprise integration and Reading Online application
a. Importance of IT in explain its goals in an enterprise. Assignment Slide Presentation
Organizations c. Distinguish Enterprise Integration to
b. Defining Systems System Integration,
Integration d. Elaborate the four stages of System
c. Defining Enterprise Integration.
Architecture e. Articulate the Enterprise Architecture
and explain its goals, and advantages.
f. Enumerate the common Enterprise
Architecture Frameworks
Week 3-4 Overview of Enterprise a. Explain the need of Enterprise Online Class Instructional Online quiz
Architecture Frameworks Framework for designing and Discussion Manual
a. The Enterprise Architecture implementing an Enterprise Reading Online application
Framework Information Systems. Assignment Slide Presentation
b. The Zachman Framework b. Develop a knowledge on how the
for Enterprise Architecture Zachman Framework depicts entire
c. The Open TOGAF artifact of an enterprise architecture.
Framework c. Enumerate the Advantages and the
Drawbacks of using Zachman
Framework.
d. Recognize another known EA
framework such as TOGAF.
96
e. Discover TOGAF Composition, Use
and Benefits.
Week 5 Components of Enterprise a. Enumerate and explain each Online Class Instructional Online quiz
Architecture components of Enterprise Architecture Discussion Manual
a. Enterprise Architecture and b. Differentiate the approach of IT on Reading Online application
its Components development and support of Assignment Slide Presentation
Enterprise Architecture
Week 6-7 Enterprise Information a. Examine the different data domains Online Class Instructional Online quiz
Architecture Concepts that is being used in the line of Discussion Manual
a. EIA Data Domains, business of an enterprise. Reading Online application
Information Governance, b. Determine the different areas IT Assignment Slide Presentation
and Information Security governance that tightly coupled in
b. Conceptual and Logical business strategies and objectives.
View of Enterprise c. Identify the different aspects of IT
Information Architecture security and Information Privacy
c. Component Model and services.
Operational Model of d. Acquire knowledge on Conceptual and
Enterprise Information Logical views of Enterprise
Architecture Information Architecture.
e. Design the Component Model of an
Enterprise Information Architecture
and to assemble the corresponding
Operational Model.
Week 8 Enterprise Architecture Methods a. Review the evolution of systems Online Class Instructional Online quiz
a. Evolution of Systems development methodologies. Discussion Manual
Development Methodology b. Identify the different strategies for Reading Online application
b. Strategies for Enterprise enterprise architecture Assignment Slide Presentation
Architecture implementations
Implementation c. Plan EA based on Incremental Build
c. Enterprise Architecture Context
Incremental Build Context
Week 9 MIDTERM Online Midterm Examination
Week 10-11 Enterprise Integration a. Discuss the different Integrating Online Class Instructional Online quiz
Technologies Technologies used in an Enterprise Discussion Manual
a. Integrating Technologies Architecture. Reading Online application
b. Enterprise Application b. Describe the Direct to Point-to-Point, Assignment Slide Presentation
Integration Concepts and Middleware approach in
c. Enterprise Portal Integrations.
Technologies for c. Explain the concept of XML in
Integration enterprise application integration.
97
d. Web Services for Real-Time d. Discuss the usage of Enterprise Portal
Integration in Enterprise Integration.
e. Service-Oriented e. Identify the different Web Service
Architecture for Integration Technologies for Real Time
Integration.
f. Define Service-Oriented Architecture
and its services for Integration.
Week 12 Enterprise Resource Planning a. Discuss the role of Enterprise Online Class Instructional Online quiz
a. Definition of Enterprise Planning to Physical and Logical Discussion Manual
Resource Planning Integrations. Reading Online application
b. ERP and Systems b. Assess the implications of ERP to Assignment Slide Presentation
Integration Management.
c. ERP’s Role in Logical c. Distinguish ERP to E- Commerce.
Integration d. Identify the components of ERP and
d. ERP’s Role in Physical its Architecture.
Integration e. Discuss the ERP Implementations and
e. ERP implications for Pros and cons in Business Level.
Management f. Give examples of ERP Vendors
f. Comparison of E-
Commerce and ERP
g. ERP- Architecture and
Components
h. ERP Implementations
Week 13-14 Other EA Enabling Technologies a. Explain the role of Cloud Computing Online Class Instructional Online quiz
Cloud Computing in IT and Business Enterprise. Discussion Manual
Business Intelligence, Analytics b. Discuss the common cloud models of Reading Online application
and Search cloud providers. Assignment Slide Presentation
c. Explore the future of enterprise cloud
computing.
d. Determine the different approaches
that Business Intelligence can offer in
an enterprise.
e. Discuss the Data Warehousing Process
f. Illustrate some text and Data mining
approaches in BI.
g. Distinguish the OLAP and OLTP
Processing tool.
Week 15-17 Project Demonstrate the ability to integrate Project
Discussions/Presentations heterogeneous systems into a cohesive Online Submission of
application. Documentation/
Online Presentation
18 Final Examination Online Final Examination
98
Suggested Readings and References
REFERENCES
1. The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight , 2010, by Mario Godinez, Eberhard Hechler, Klaus
Koenig, Steve Lockwood, Martin Oberhofer, Michael Schroeck
2. Enterprise Systems Integration by Judith Myerson
3. Enterprise Integration , An Architecture for Enterprise Application and Systems Integration, 2002 by Fred A. Cummins
4. Business Intelligence Guidebook, from Data Integration to Analytics, by Rick Sherman
5. Principles of Data Integration by AnHai Doan, Alon Halevy, Zachary Ives
6. System Architecture with XML, 2003, Daum Berthold, Merten Udo
7. Enterprise Cloud Computing: Technology, Architecture, Applications, 2010, by Gautam, Shroff
8. SOA- Based Enterprise Integration: A Step by Step Guide to Service-Based Application Integration, 2009, by Roshen, Waseem
9. Handbook of Systems Engineering and management, 1999, by Sage, Andrew P., Rouse, William B
10. Handbook of Enterprise Integration, 2010, by Sherif, Mostafa Hashem
Note: Extended readings may be assigned by the professor.
Project Rubrics
CRITERIA EXCELLENT GOOD SATISFACTORY POOR FAILED
96-100 86-95 76-85 60-75 Below 60
Content (50%) Analysis and Analysis and Analysis and Analysis and
integration of the integration subject integration subject integration subject
Did not submit
subject matter is clear matter is clear and matter is under matter is
and convincing effective developed unsophisticated
Organization (30%) Paper shows
Paper shows good Paper lacks clear
exceptionally clear Paper is disorganized
organization, purpose organization, purpose
organization, purpose and confusing
and focus and focus
and focus
Grammar (10%) Some grammatical Appropriate
mistakes but grammatical
Free of most Frequent grammatical
generally shows knowledge not
grammatical errors errors
successful grammar displayed for current
usage language level
Timeliness (10%) Assignment turned in -
Assignment turned in Assignment turned in
earlier than the
on time late
deadline
Course Grading System
99
COURSE ASSESSMENT& EVALUATION CRITERIA (GRADING & REQUIREMENTS)
Assignments / Quizzes / Exercises
Major Requirements
 Midterm and Final Exam
 Faculty in charge will decide what Project to be provided.
GRADING SYSTEM:
FIRST GRADING = Class Standing (70%): Quizzes, Recitation, Assignment, Exercises, Project; Midterm Examination (30%)
SECOND GRADING = Class Standing (70%): Quizzes, Recitation, Assignment, Exercises, Project; Final Examination (30%)
FINAL GRADE = (FIRST GRADING + SECOND GRADING) / 2
Online Class Policy

Aside from what is prescribed in the student handbook, the following are the professor’s additional house rules:
1. The course is expected to have a minimum of four (4) quizzes.
2. Assignments and research projects/report works will be given throughout the semester. Such requirements shall be due as announced in class. Late submission shall
be penalized with grade deductions (5% per day) or shall no longer be accepted, depending on the subject facilitator’s discretion. Assignments and exercises are
designed to assist you in understanding the materials presented in class, and to prepare you for the exams.
3. Students are required to attend online classes regularly as scheduled, including possible make-up classes. The student will be held liable for all topics covered and
assignments made during his/her absence. The university guidelines on attendance and tardiness will be implemented.
4. Any evidence of copying or cheating during any examinations may result in a failing grade from the examination for all parties involved. Note that other university
guidelines shall be used in dealing with this matter.
5. Students are advised to keep graded work until the semester has ended.
6. Contents of the syllabus are subject to modification with notification.
7. Student are required to interact with the learning management system (LMS).
8. During the online class student are expected to be actively participating in the course.
9. Withdrawal and dropping from the subject should be done in accordance with existing university policies and guidelines regarding the matter.
Consultation Time: Online Consultation under pre-determined time.
** Course Syllabus taken from the University of the Sunshine Coast, Queensland, Australia (ICT 321 Architecture and Systems Integration)
100
Prepared by: Reviewed by:
Engr. Ranil M. Montaril, MSECE Assoc. Prof. Melvin D. Roxas , MSGITS

Faculty Member from the Main Campus Department/Academic Program Head
Recommending Approval:
Prof. Gisela May A. Albano, PhD.

Dean
Approved by:
Prof. Emanuel de Guzman, PhD

Vice President for Academic Affairs
101
102

IM Systems Integration and Architecture 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IM Systems Integration and Architecture 1

Uploaded by

Copyright:

Available Formats

Systems Integration and

Engr. Ranil M. Montaril, MSECE

Table of Contents .................................................................................................................. 2

Lesson 2: Business Intelligence, Analytics and Search .................................................................... 89

Lesson 1: Importance of IT in Organizations

 Operational Excellence and Cost Leadership

Lesson 2: Defining Systems Integration

Four Stages of System Integration

Drivers for Systems Integration

Issues in Enterprise/System Integration

o Nature of the networking technology.

Lesson 3: Defining Enterprise Architecture

Figure 1.0 Dewey Walker

Goals of enterprise architecture:

Benefits of enterprise architecture:

The biggest benefits of EAP include:

o Allowing more open collaboration between IT and business units

Enterprise architecture methodologies

Enterprise architect role

DoanAnhai, HalevyAlon, IvesZachary Principles of Data Integration．Massachusetts，Morgan

Enterprise Information Architecture (EIA)．[Online][Cited: 27 September 2020．]https://cio-

FoundationEnterpriseInformation Architecture: A Semantic and OrganizationalTom Reamy ．

MyersonJudithM. Enterprise Sysatem Integration．New York，AUERBACH PUBLICATIONS，2001．

SageAndrewP., RouseWilliamB Handbook of Systems Engineering and management．s.l.，John Wiley

SherifMostafaHashem Handbook of Enterprise Integration．New York，Auerbach Publications，2010

The TOGAF Standard version 9.2．

TOGAF Online: Introduction．[Online]http://www.togaf.com/togaf9/chap01.html．

WhiteSarahK.What is enterprise architecture? A framework for transformation．[Online]16 October

Wikipedia: Enterprise architecture framework．

1. What are the Role of IT in an Organization?

Lesson 1: The Enterprise Architecture Framework

Four Characteristics of Enterprise Architecture Framework

Figure 3 Conceptual model of architectural description

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

And the abstractions which is:

o What (material) is made of

Figure 4 Interest in different diagrams or representations from their views/perspectives

Advantages of the Zachman framework:

Drawback of the Zachman framework:

TOGAF consists of:

o Architecture Capability Framework

o Architecture Development Method

o Architecture Content Framework

Figure 8 ADM Steps of TOGAF

DoanAnhai, HalevyAlon, IvesZachary Principles of Data Integration．Massachusetts，Morgan

Enterprise Information Architecture (EIA)．[Online][Cited: 27 September 2020．]https://cio-

FoundationEnterpriseInformation Architecture: A Semantic and OrganizationalTom Reamy ．

GautamShroff Enterprise Cloud Computing: Technology, Architecture, Applications．New York，

MyersonJudithM. Enterprise Sysatem Integration．New York，AUERBACH PUBLICATIONS，2001．

SageAndrewP., RouseWilliamB Handbook of Systems Engineering and management．s.l.，John Wiley

SherifMostafaHashem Handbook of Enterprise Integration．New York，Auerbach Publications，2010

The TOGAF Standard version 9.2．

TOGAF Online: Introduction．[Online]http://www.togaf.com/togaf9/chap01.html．

WhiteSarahK.What is enterprise architecture? A framework for transformation．[Online]16 October

Wikipedia: Enterprise architecture framework．

1. What is the distinct advantage of Zachman Framework over TOGAF?

Lesson 1: Components of Enterprise Architecture

The Four Primary components of Enterprise Architecture are:

o Enterprise Business Architecture

Figure 9 Four Components of EA

Enterprise Business Architecture

Enterprise Information Architecture

o Data Sharing (How do I exchange the data?)

Enterprise Solution Architecture