IT4350 - INFORMATION SYSTEMS Dr.

Nguyen Huu Duc

ARCHITECTURE AND APPLICATIONS Information Systems
Department
L E C T U R E 1 - IN T ROD U CT ION TO IN F OR MAT ION S Y S T E MS SoICT, HUST
MICROSOFT TEAMS
Teams Code: qufudxy
Email: [email protected]
KEY TERMS

We begin with definition of some basic concepts

 Information Technology
 Business Process
 Information Systems
 Organization
 Integration
 Enterprise Systems (ES)
 IS/ES architecture
INFORMATION TECHNOLOGY

Computers (maybe…): hardware and software

Resources: computer hardware, software, networks,
databases
BUSINESS PROCESS
A specific ordering of work activities across time and place, with
a beginning, an end, and clearly identified inputs and outputs.
Davenport, 1993
A way of work is organized, coordinated, and focused to
produce a valuable product or service

Concrete workflows of material, information, and knowledge -

sets of activities

Sequence, purpose, interaction

BUSINESS PROCESS EXAMPLES
• Manufacturing and production: Assembling product, checking
quality, producing bills of materials

• Sales and marketing: Identifying customers, creating customer

awareness, selling

• Finance and accounting: Paying creditors, creating financial

statements, managing cash accounts

• Human Resources: Hiring employees, evaluating performance,

enrolling employees in benefits plans
 BUSINESS PROCESS EXAMPLES
Cross-Functional Business Processes

Transcend boundary between sales, marketing,

manufacturing, and research and development

Group employees from different functional

specialties to a complete piece of work

Example: Order Fulfillment Process

BUSINESS PROCESS EXAMPLES
The Order Fulfillment Process
 INFORMATION SYSTEM

An information system is a unique configuration of

IT resources and organizational processes whereby
the IT resources (and the information they provide) are
applied to support specific organizational processes.
Processes

INFORMATION
SYSTEMS

IT resources
ORGANIZATION

People
Process
Structure
 coordination and control mechanisms

Organization and environment

 stakeholders, competitors, other influences
ORGANIZATION & ENVIRONMENT
investors

regulators partners

suppliers customers

INPUTS OUTPUTS
INFORMATION SYSTEMS IN ORGANIZATIONS
investors

regulators partners

suppliers customers

INPUTS OUTPUTS

information
systems

IT resources
KEY SYSTEM APPLICATIONS IN THE ORGANIZATION

Types of Information Systems

MAJOR TYPES OF SYSTEMS IN ORGANIZATIONS

• Executive Support Systems (ESS)

• Decision Support Systems (DSS)
• Management Information Systems (MIS)
• Office Systems
• Transaction Processing Systems (TPS)
MAJOR TYPES OF SYSTEMS IN ORGANIZATIONS
INTERRELATIONSHIPS AMONG SYSTEMS
Traditional View of the Systems

Within the business: there are functions, each having

its uses of information systems

Outside the organization’s boundaries: There are

customers and vendors

Functions tend to work in isolation

Traditional View of the Systems
INTEGRATION

Making whole or complete

Overcoming isolation of information systems
Enterprise resource planning (ERP) systems
Enterprise systems
 Technical and organizational solution
ENTERPRISE SYSTEMS
 ENTERPRISE SYSTEMS

Enterprise systems (ES) are large-scale application

software packages that support business processes,
information flows, reporting, and data analytics in
complex organizations.
ES are generally packaged enterprise application
software (PEAS) systems they can also be bespoke,
custom developed systems created to support a specific
organization's needs
ENTERPRISE SYSTEMS

Examples are:
 Supply chain management systems
 Customer relationship management systems
 ERP
 EXAMPLE : ENTERPRISE RESOURCE PLANNING
(ERP) SYSTEMS
• Enterprise Resource Planning Systems are the first
generation of enterprise systems meant to integrate data
and support all the major functions of organizations.

• 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.
INTEGRATED SYSTEMS - ERP
ENTERPRISE RESOURCE PLANNING (ERP)
SYSTEMS (CONT’D)

• Another goal of ERP is to integrate departments and functions

across an organization into a single infrastructure that serves
the needs of each department.

• ERP systems replace an assortment of systems that typically

existed in organizations. (Accounting, HR, Materials Planning,
Transaction Processing, etc.).

• ERP solves the critical problem of integrating information from

different sources and makes it available in real-time.
EVOLUTION OF ERP
Timeline System Platform
1960s Inventory Management Mainframe legacy systems using third
& Control generation software-(Cobol, Fortran)

1970s Materials Requirements Mainframe legacy systems using third

Planning (MRP) generation software-(Cobol, Fortran)

1980s Materials Requirements Mainframe legacy systems using fourth

Planning (MRP-II) generation database software and
manufacturing applications.
1990s Enterprise Resource Mainframe client-server systems using fourth
Planning generation database software and package
software.
2000s Extended ERP or ERP- Client-server systems using Web platform,
II open source with integration to fifth generation
applications like SCM, CRM, SFA.
 BUSINESS PROCESSES AND ERP
• A crucial role of ERP in business is to better position the
organization to change its business processes.

• ERP software have hundreds of business processes built into the

logic of the system which may or may not agree with current
processes of an organization.

• When implementing an ERP system, organizations have two

choices:
– Change business processes to match the software functionality.
– Modify the ERP software to match the business processes.
ERP SYSTEMS COMPONENTS
An ERP system consists of:

Hardware Servers and peripherals

Software Operating systems and database

Information Organizational data from internal and

external sources

Process Business processes, procedures, and

policies

People End users and IT staff

ERP COMPONENTS
ERP COMPONENTS INTEGRATION
 ERP ARCHITECTURE
The architecture of an ERP system influences the cost,
maintenance, and the use of the system.
A flexible architecture is best – it allows for scalability as needs
change and grow.
A system’s architecture is a blueprint of the actual ERP system and
helps the implementation team build the ERP system.
If purchased, ERP architecture is often driven by the vendor, but
other IT architectures are driven by organizational strategy and
business processes.
EXAMPLE OF ARCHITECTURE OF ERP AT
LARGE UNIVERSITY
LOGICAL ARCHITECTURE OF AN ERP SYSTEM
TIERED ARCHITECTURE EXAMPLE OF ERP SYSTEM

35
 CHARACTERISTICS OF ENTERPRISE SYSTEMS

They are some of the most complex systems in use today

They are typically:
 N-tier systems made up of clients, an application layer, and a
data layer
 Many are now employing a service-oriented architecture
 SaaS, PaaS, SOA, Web services
WHY ENTERPRISE SYSTEMS
IT departments in every organization continue to be
challenged on too many fronts:
 Cost pressures
 Data growth
 Security and privacy breaches
In this environment, transforming the management of critical
information and processes is vital to generating new business
value, delivering new client services and capturing new
markets.
To deliver this transformation, forward-thinking businesses
rely on ENTERPRISE SYSTEMS
BENEFITS OF ENTERPRISE SYSTEMS

Firm structure and organization: One organization

Management: Firm-wide knowledge-based management

processes

Technology: Unified platform

Business: More efficient operations and customer-driven

business processes
CHALLENGES OF ENTERPRISE SYSTEMS
Difficult to build: Require fundamental changes in the way the
business operates

Technology: Require complex pieces of software and large

investments of time, money, and expertise

Centralized organizational coordination and decision making:

Not the best way for the firms to operate
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

WHAT IS ENTERPRISE ARCHITECTURE?

▪ Enterprise architecture (EA) can be defined as a collection of
special documents (artifacts) describing various aspects of an
organization from an integrated business and IT perspective
intended to bridge the communication gap between business and IT
stakeholders, facilitate information systems planning and thereby
improve business and IT alignment

▪ Enterprise architecture typically describes business, applications,

data, infrastructure and sometimes other domains relevant from the
perspective of business and IT, e.g. integration or security
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #40
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

THE ESSENCE OF ENTERPRISE ARCHITECTURE

▪ Enterprise architecture provides effective instruments facilitating

communication, collaboration and mutual understanding between
different groups of actors

▪ Using EA documents for supporting discussions helps alleviate

communication problems resulting from disparate knowledge,
interests and goals of various involved actors

▪ Essentially, enterprise architecture can be considered as a

communication medium between diverse business and IT
stakeholders in organizations
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #41
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

EA DOCUMENTS AND ORGANIZATIONAL ACTORS

▪ To business executives EA documents explain the implications of

planning decisions for the business strategy
▪ To IT executives EA documents explain the implications of
planning decisions for the IT strategy
▪ To business unit managers EA documents explain the impact of
planning decisions on their business processes
▪ To IT project teams EA documents explain the implications of
planning decisions for specific IT projects
▪ To third parties EA documents explain the implications of
planning decisions for the structure of specific contracts

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #42
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

EA AS AN INSTRUMENT FOR COMMUNICATION

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #43
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

SPECIFICS OF ENTERPRISE ARCHITECTURE

▪ Enterprise architecture has not much in common with
building architecture
▪ Organizations as dynamic socio-technical systems
cannot be designed or engineered and then built
▪ Organizations are extremely complex, organic and living
entities that gradually evolve over time
▪ Enterprise architecture is a pragmatic set of descriptions
useful for managing the evolution of organizations
▪ The term “enterprise architecture” is purely metaphorical
and is only an umbrella term for multiple diverse
documents used for information systems planning
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #44
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

DOMAINS OF ENTERPRISE ARCHITECTURE

▪ The informational contents of enterprise architecture
typically encompass the following common EA domains:
• Business domain – covers customers, capabilities, processes,
roles, etc.
• Applications domain – covers programs, systems, custom
software, vendor products, etc.
• Data domain – covers data entities, structures, sources, etc.
• Integration domain – covers interfaces, connections, interaction
protocols, integration platforms, etc.
• Infrastructure domain – covers hardware, servers, operating
systems, networks, etc.
• Security domain – covers firewalls, authentication mechanisms,
identity and access management systems, encryption, etc.
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #45
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

EA DOMAINS AS A STACK
▪ The set of common EA domains can be represented as a
multilayered stack of domains, where lower layers
underpin higher layers:
• Applications automate business processes
• Data is used by applications
• Integration mechanisms link all applications and data together
• Infrastructure hosts all applications, databases and integration
platforms
• Security mechanisms permeate all other EA domains
▪ The business domain is non-technical in nature, while all
other EA domains are technical domains directly
related to respective technologies
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #46
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

ENABLING AND SUPPORTING EA DOMAINS

▪ All EA domains can be also separated into business-
enabling domains and business-supporting domains

▪ Business-enabling EA domains occupy the top layers

of the stack and represent functional domains
▪ These domains are relevant to business stakeholders
and define the core business functionality of IT systems

▪ Business-supporting EA domains occupy the bottom

layers of the stack and represent non-functional domains
▪ These domains are irrelevant to business stakeholders
and unrelated to business functionality of IT systems
SK #47
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

THE STACK OF EA DOMAINS

Generally, enterprise architecture can describe any

domains considered as important from the perspective of
the relationship between business and IT

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #48
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

ENTERPRISE ARCHITECTURE ARTIFACTS

▪ Separate documents constituting enterprise architecture
are typically called as EA artifacts
▪ EA artifacts provide descriptions of an organization from
different perspectives important for the various actors
involved in strategic decision-making and
implementation of IT systems
▪ An EA practice implies using specific sets of EA artifacts
for improving communication between different actors
▪ EA artifacts can be very diverse and differ in their
informational contents, general meanings and lifecycles

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #49
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

INFORMATIONAL CONTENTS OF EA ARTIFACTS

▪ From the perspective of their informational contents,
various EA artifacts can have different:
• Representation formats - textual, graphical and tabular formats
or a mix of these formats
• Levels of detail - range in their granularity from very high-level
abstractions to low-level details
• Organizational scopes - range from entire organizations and
lines of business to separate change initiatives and IT projects
• EA domains - business, applications, data, integration,
infrastructure and security domains as well as their combinations
• Temporal states - current state (now), short-term future state (<1
year), mid-term future state (2-3 years), long-term future state (3-
5 years), stateless and their combinations
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #50
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

TWO MEANINGS OF EA ARTIFACTS

▪ From the perspective of their general meaning in an EA
practice all EA artifacts can be separated into decisions
EA artifacts and facts EA artifacts
▪ Decisions EA artifacts represent made planning
decisions, i.e. achieved and formalized agreements
between various stakeholders regarding the desired
future course of action
▪ Facts EA artifacts represent documented objective
facts, i.e. reflections of the actual current situation in an
organization as it is

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #51
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

DECISIONS EA ARTIFACTS
▪ Decisions EA artifacts may represent these decisions:
• How an organization needs to work from the IT perspective
• Where an organization should invest its IT dollars
• How a particular IT solution should be implemented

▪ They always have certain implications for the future

▪ These EA artifacts are always developed or updated
collaboratively by all relevant stakeholders
▪ After decisions EA artifacts are created and approved, all
stakeholders should act according to these decisions
▪ All EA artifacts describing the future, and all stateless EA
artifacts, can be considered as decisions EA artifacts

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #52
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

FACTS EA ARTIFACTS
▪ Facts EA artifacts may document these facts:
• What technologies the organizational IT landscape uses
• What IT assets an organization possesses, runs and maintains
• How the existing IT systems and databases are interconnected
▪ They have no implications for the future
▪ These EA artifacts may be developed or updated solely
by specific actors
▪ After facts EA artifacts are created, they can be used by
any actors as reference materials for planning purposes
▪ All EA artifacts describing only the current state can be
considered as facts EA artifacts
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #53
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

TWO LIFECYCLES OF EA ARTIFACTS

▪ From the perspective of their lifecycles in an EA practice

all EA artifacts can be separated into permanent EA
artifacts and temporary EA artifacts
▪ Permanent EA artifacts are long-lived EA artifacts often
existing for many years
▪ Temporary EA artifacts are short-lived EA artifacts
often existing for several months or even weeks

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #54
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

PERMANENT EA ARTIFACTS
▪ Permanent EA artifacts live and evolve together with an
organization
▪ They are created once and then updated when
necessary according to the ongoing changes in an
organization and its business environment
▪ After being developed these EA artifacts are constantly
used, continuously maintained and occasionally
discarded when become irrelevant
▪ Most EA artifacts covering wider scopes beyond specific
IT initiatives or projects tend to be permanent EA
artifacts
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #55
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

TEMPORARY EA ARTIFACTS

▪ Temporary EA artifacts are transitory, single-purposed

and disposable
▪ They are created at specific moments for particular
purposes, used as intended and then immediately
discarded or archived
▪ Due to their short lifespan, the very need to update or
maintain temporary EA artifacts is usually absent
▪ All EA artifacts covering narrow scopes (e.g. separate IT
initiatives or projects) tend to be temporary

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #56
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

EXAMPLES OF EA ARTIFACTS

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #57
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

THE ROLE OF ARCHITECTS IN AN EA PRACTICE

▪ The key actors of an EA practice are architects

▪ Architects act as chief IT planners in organizations
▪ Ideal architects are effective communicators, team
players, innovators and systems thinkers knowledgeable
in both business and IT
▪ Architects are “T-shaped” professionals in connecting
business and IT, i.e. specialists in finding optimal IT
strategies and solutions satisfying business strategies
and needs

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #58
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

GENERAL RESPONSIBILITIES OF ARCHITECTS

▪ Communicating with various business and IT
stakeholders and understanding their concerns
▪ Facilitating the dialog and conversation between different
stakeholders
▪ Finding, proposing and discussing optimal planning
decisions satisfying the concerns of stakeholders
▪ Developing and updating EA artifacts for supporting
discussions and documenting the achieved agreements
▪ Establishing and maintaining a repository of EA artifacts
▪ Establishing, running and optimizing EA-related
processes
SK #59
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

ARCHITECTS AS DEVELOPERS OF EA ARTIFACTS

▪ Architects are the key developers of all EA artifacts

▪ Architects are responsible for involving relevant
stakeholders, collecting necessary data and completing
all other activities required to develop EA artifacts
▪ However, the typical process of developing and updating
EA artifacts differs significantly for decisions EA artifacts
and facts EA artifacts
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

DEVELOPING DECISIONS EA ARTIFACTS

▪ The development and update of decisions EA artifacts is a
complex, creative and tricky process
▪ Decisions EA artifacts are always developed collaboratively by
architects and their stakeholders
▪ Essentially, the collaborative development of decisions EA
artifacts is the actual process of IT planning
▪ Even though architects usually act as facilitators or drivers of
their development, fundamentally decisions EA artifacts are
products of a collective teamwork
▪ Decisions EA artifacts are normally created in a proactive
manner
BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO
SK BUSINESS AND IT ALIGNMENT #61
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

DEVELOPING FACTS EA ARTIFACTS

▪ The development and update of facts EA artifacts is a

more simple, routine and straightforward process
▪ Unlike decisions EA artifacts, facts EA artifacts may be
developed by individual architects alone or with only a
minimal involvement of other actors
▪ Facts EA artifacts are often created in a reactive manner
on an as-necessary basis

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #62
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

PROCESSES FOR DEVELOPING EA ARTIFACTS

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #63
 The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])

EA ARTIFACTS, ARCHITECTS AND OTHER ACTORS

BASED ON THE BOOK THE PRACTICE OF ENTERPRISE ARCHITECTURE: A MODERN APPROACH TO

SK BUSINESS AND IT ALIGNMENT #64
REFERENCES

•Motiwalla and Thompson, Enterprise Systems for

Management, Second edition, Prentice hall
Publications, 2012

•http://www-03.ibm.com/systems/enterprise-
systems/index.html