LEARNING MODULE

FOR
IT 323 SYSTEM INTEGRATION AND ARCHITECTURE I

_____________________________________________________

WEEK 8

COURSE OUTLINE

COURSE CODE : IT 323

Overview:
 The course focuses on how a proposed system will be integrated with other existing or planned systems. It
addresses the System Integration problem using architectures as the basis and then addresses the evaluation of the
architectures in terms of the capabilities they provide.

Objectives:

 Discuss IT Architecture Concepts

Instruction to the Learner

Teaching this course will be in lecture form. A number of case studies will also be used to illustrate
some concepts as mentioned in the indicative content. The System of Systems Integration Problem Human,
Organizational, Societal Cultural, Economic, and Technological aspects. The theory and practice of business
process integration, legacy integration, new systems integration, business-to-business integration, integration of
commercial-off-the-shelf (COTS) products, interface control and management, testing, integrated program
management, integrated Business Continuity Planning (BCP). Specific focus will be given to issues of interface
integration and interoperability of systems.

Getting Started

Systems Architectures

Architecture

 The word “architecture” is derived from the Greek word “architecton”, which means master mason or
master builder. Webster’s Dictionary defines architecture as: the art or science of designing or building
structures
 The structure (in terms of components, connections, and constraints) of a product, process, or element –
The Art of Systems Architecting
 An Architecture is the highest-level concept of a system in its environment – IEEE
 The architecture of a system defines its high-level structure, exposing its gross organization as a collection of
interacting components.
 Components needed to model a software architecture include:
Components, Connectors, Systems, Properties and Styles.
IT Architecture Concepts

• Components

– The computational elements and data stores of the system

– May have multiple interfaces, called ports

– Ports define a point of interaction between a component and its environment

• Connectors

– Model interactions among components

– Runtime perspective: connectors mediate the communication and coordination activities between
 components

– Connectors may have interfaces that define the roles played by the participants in the interaction

• Systems

– Graphs of components and connectors

– Tend to be hierarchical – components and connectors may represent subsystems that have their own
internal architectures

– Bindings map the interfaces of one level of a system to another

– Properties

– Represent the non-structural information about the parts of an architecture description

– Example: a connector can be a function call, or a network interaction

– Properties can be attached to any architectural element

• Style

– An architectural style represents a family of related systems

– Defines the design vocabulary (and constraints) for the components, connectors, ports, roles,
bindings and properties.

System Architect

• The architect is a member of the team that is responsible for designing and building a system

• The architect’s contribution comes in the very early stages of the systems engineering process

– When the operational concept is defined

– The basic structure of the system is conceptualized

• A system architect, not only knows about the individual components, but also understands the
interrelationships among the components

Systems Architecting

Systems architecting has been defined as the process of creating complex, unprecedented systems

• Building systems in today’s world is tenuous at best

– Requirements of the marketplace are ill-defined

– Rapidly evolving technology provides new services at a global level instantly

– Uncertainty is increasing about the way the system will be used, the components that will be
incorporated and the interconnections that will be made

Note: Generating a system architecture as part of the system engineering process can be seen as a deliberate
approach to deal with the uncertainty that characterizes these complex, unprecedented systems

Traditional Approach to System Architecting

 Many methodologies have been developed to support a traditional system development model

o Define the requirements

o Consider several options

o Emerge with a well-defined design through a process of elimination

 Effective when the requirements are well defined and remain essentially constant during the system
development period

o Cannot handle change well

 If the implementation of the system is long – on the order of years – the requirements
change because of changing needs and new technology offers different alternatives and
opportunities

The Traditional Approach

Evolutionary Approach

• New approach that is emerging with roots in software systems engineering

• Deals with uncertainty in requirements and in technology, especially for systems with a long development
time and expected long life cycle

– Evolutionary development

– Build-a-little, Test-a-little

• Requirements are allowed to be more abstract and therefore subject to interpretation

• Alternative solutions are explored and pursued further as new technology options become available

• Intermediate designs are saved

• Some intermediate designs are implemented as prototypes but not operationally implemented while others
are implemented in traditional ways

 Advantages of Object-Oriented approach:

o Allows flexibility in the design as it evolves over time

 Disadvantages of Object-Oriented approach:

o Requires some early elimination of technology alternatives in the absence of reliable

Evolutionary Approach
Select, Build, and Field

• At any time in the development process, when there is a need to build a system, the available solution that
best meets the current requirements is selected and implemented using any systems engineering approach

The Challenge of Coping with Change

• If the implementation is long, then the situation shown next prevails, with the unfortunate consequences
that very little, if any, from the work on Option A is used for Option B

How to Define an Architecture

• Defining an architecture, especially of an information system, requires the following items to be described:

– Processes exist that need to take place in order that the system accomplish its intended functions

– The individual processes transform either data or materials that “flow” between them

– The processes or activities or operations follow rules that establish the conditions under which they
occur

– The components that will implement the design (hardware, software, personnel, and facilities must
be described)

 Functional Architecture
• A set of activities or functions that are arranged in a specific order and when activated,
achieves a set of requirements
 • Divide and allocate the functional requirements into different sub-functions and modes of
operation

 Physical Architecture
• A representation of the physical resources

• Expressed as nodes that constitute the system and their connectivity

• Expressed in the form of links

 Technical Architecture
– A minimal set of rules governing the arrangement, interaction, and interdependence of the parts or
elements that must ensure that a conformant system satisfies a specified set of requirements

– Provides the framework upon which engineering specifications can be derived, guiding the
implementation of the system

– Analogous to the building code that provides guidance for new buildings to be able to connect to the
existing infrastructure by characterizing the attributes of that infrastructure