Enterprise Systems

Week 5
Enterprise Architecture (EA)
1. Architecture

• An EA provides a high-level design of the entire enterprise that will

guide all other enterprise projects.
• An architecture represents significant, broad design decisions for the
enterprise, from which all other design decisions should be
consistent.
• The Software Engineering Institute (SEI) defines architecture as:
“The architecture of a software-intensive system is the structure or
structures of the system, which comprise software elements, the
externally visible properties of those elements, and the
relationships among them”.
1. Architecture
EAs major goals:
1. For the EA, its units, policies, processes, strategies, and
technological infrastructure (e.g., IT systems) to successfully
support all stakeholders in achieving short and long-term business
goals and objectives of the enterprise.
2. For the EA to foster an alignment of the technological systems
developed by and used by an enterprise with its business goals and
strategic direction
3. For the EA to help an enterprise to learn, grow, innovate, and
respond to market demands and changing basic conditions
4. For the EA foster and maintain the learning capabilities of
enterprises so that they may be sustainable
1.1 Architectural Element

• An architectural element is a fundamental piece from which a system

can be considered to be constructed.
• An architectural element possesses several key attributes:
• A clearly defined set of responsibilities
• A clearly defined boundary
• A set of clearly defined interfaces, which define the services that the element
provides to the other architectural elements
1.2 Systems Structures

System structures are of two kinds:

1. The static structures of a software system define its internal design-
time elements and their arrangement.
• Internal design-time software elements might be modules, object-oriented
classes or packages.
• Internal data elements include classes, relational database entities/tables,
and data files.
• Internal hardware elements include computers or their constituent parts such
as disk or central processing unit and networking elements such as cables.
2. The dynamic structures of a software system define its runtime
elements and their interactions.
• They show how the system actually works, what happens at runtime, and
what the system does in response to external (or internal) stimulus.
1.2 System Structures

External properties manifest in two forms:

1. The externally visible behavior of a software system defines the
functional interactions between the system and its environment.
• The externally visible behavior of a system (i.e., what it does) is determined
by the combined functional behavior of its internal elements.
2. A quality property is an externally visible, nonfunctional property of
a system such as performance, security, or scalability.
• The quality properties of a system such as performance, scalability, and
resilience (how it does it) arise from the quality properties of its internal
elements.
1.2.1 Quality Attributes
1. Implementation attributes (not observable at runtime); include:
a. Interoperability: Universal accessibility and the ability to exchange data
among internal components and with the outside world.
b. Maintainability and extensibility: The ability to modify the system and
conveniently extend it.
c. Testability: The degree to which the system facilitates the establishment of
test cases.
d. Portability: The system’s level of independence on software and hardware
platforms. Systems developed using high-level programming languages
usually have good portability (e.g. Java)
e. Scalability: A system’s ability to adapt to an increase in user requests.
Scalability disfavors bottlenecks in system design.
f. Flexibility: The ease of system modification to cater to different environments or
problems for which the system was not originally designed.
1.2.1 Quality Attributes
2. Runtime attributes (observable at runtime); include:
a. Availability: A system’s capability to be available 24/7.
b. Security: A system’s ability to cope with malicious attacks from outside or
inside the system.
c. Performance: Increasing a system’s efficiency with regard to response time,
throughput, and resource utilization, which are attributes that are usually in
conflict with each other.
d. Usability: The level of human satisfaction derived from using the system.
e. Reliability: The failure frequency, the accuracy of output results, the
meantime-to-failure, the ability to recover from failure, and the failure
predictability
f. Maintainability (extensibility, adaptability, serviceability, testability,
compatibility, and configurability); the ease of software system change.
1.2.1 Quality Attributes

3. Business attributes, include:

a. Time to market: The time it takes from requirements analysis to the
date a product is released.
b. Cost: The expense of building, maintaining, and operating the
system.
c. Lifetime: The period of time that the product is “alive” before
retirement.
1.2.2 Attribute Tradeoffs
1. Tradeoff between space and time: For example, to increase the time
efficiency of a hash table means a decrease in its space efficiency.

2. Tradeoff between reliability and performance: For instance, Java

programs are well protected against buffer overflow due to security
measures such as boundary checks on arrays. Such reliability features
come at the cost of time efficiency, as compared with the simpler and
faster C language that provides the “dangerous,” yet efficient, pointers.

3. Tradeoff between scalability and performance: For example, one typical

approach to increase the scalability of a service is to replicate servers. To
ensure consistency of all servers, performance of the whole service is
compromised.
1.3 Candidate Architecture
• A candidate architecture for a system is a particular arrangement of
static and dynamic structures that have the potential to exhibit the
system’s required externally visible behaviors and quality properties.
• An architecture style (also known as an “architecture pattern”)
abstracts the common properties of a family of similar designs.
• An architecture style contains a set of rules, constraints, and patterns
of how to structure a system into a set of elements and connectors.
• An architecture style is a viewpoint abstraction for a software
structure that is domain-independent.
• A system can adopt heterogeneous architectures—that is, more than
one architecture style can coexist in the same design.
1.3.1 Architecture Style

Key components of an architecture style:

• Elements that perform functions required by a system
• Connectors that enable communication, coordination, and cooperation among
elements
• Constraints that define how elements can be integrated to form the system
• Attributes that describe the advantages and disadvantages of the chosen
structure
For example:
• In the data-centric style, the data store plays a central role and is accessed
frequently by other elements that modify data.
• In the dataflow style, input data are transformed by a series of computational
or manipulative elements.
1.3.1 Architecture Style

Multitier architecture is commonly used for distributed systems. It

usually consists of three element types, as follows:
1. The client element is responsible for graphical user interface presentation,
accepting user requests, and rendering results.
2. The middleware element gets the requests from the client element,
processes the requests based on the business logic, and sends a data
request to the backend tier.
3. The data store server element manages data querying and updating.
All three types of elements are connected via a network (e.g., the
Internet).
1.4 Stakeholder

• A stakeholder in a architecture is a person, group, or entity with an

interest in or concerns about the realization of the architecture.
• A concern about an architecture is a requirement, an objective, an
intention, or an aspiration a stakeholder has for that architecture.
• A good architecture is one that successfully meets the objectives,
goals, and needs of its stakeholders.
• Stakeholders (explicitly or implicitly) drive the whole shape and
direction of the architecture, which is developed solely for their
benefit and to serve their needs.
• Stakeholders ultimately make or direct the fundamental decisions
about scope, functionality, operational characteristics, and structure
of the eventual product or system.
2. Viewpoints and Views
• A view is a representation of structural aspects of an architecture that
illustrates how the architecture addresses concerns held by stakeholders.
• An architectural view is a way to portray those aspects of the architecture
that are relevant to the concerns with reference to this view.
• A viewpoint is a collection of patterns, templates, and conventions for
constructing one type of view.
• A viewpoint defines the stakeholders whose concerns are reflected in the
viewpoint and the guidelines, principles, and template models for
constructing its views.
• Viewpoints make available a library of templates and patterns that can be
used to guide the creation of an architectural view that can be inserted into
an architectural description.
2.1 Viewpoint Catalog
• Information, describes the way that the architecture stores, manipulates,
manages, and distributes information.
• Functional, describes the system’s functional elements, their
responsibilities, interfaces, and primary interactions.
• Concurrency, describes the concurrency structure of the system and maps
functional elements to concurrency units to clearly identify the parts of the
system that can execute concurrently and how this performance is
coordinated and controlled.
• Development, describes the architecture that supports the software
development process.
• Deployment, describes the environment into which the system will be
deployed, including capturing the dependencies the system has on its
runtime environment.
• Operations, describes how the system will be operated, administered, and
supported when it is running in its production environment.
2.2 Viewpoint Benefits

• Management of complexity
• Communication with stakeholder groups
• Separation of concerns
• Improved developer focus considers the idea that the architectural
description is the foundation of the system design
3. Perspectives
• An architectural perspective is a collection of activities, tactics, and
guidelines that are used to ensure that a system exhibits a particular
set of related quality properties that require consideration across a
number of the system’s architectural views.

• Most important perspectives for large information systems include:

• Performance and Scalability
• Availability and Resilience
• Security
• Evolution
3. Perspectives Advantages
1. A perspective is a useful store of knowledge, helping one to quickly
review their architectural models for a particular quality property
without having to absorb a large quantity of highly detailed
material.

2. A perspective acts as an effective guide when one is working in an

area that is new to them/when they are unfamiliar with its typical
concerns, problems, and solutions.

3. A perspective is a useful memory aid when one is working in an

area that they are more familiar with, to make sure that they don’t
forget anything important.
3. Benefits of Applying Perspectives to a View

• Provides common conventions, measurements, or even a notation or

language that can be used to describe the system’s qualities.
• Defines concerns that guide architectural decision-making to help
ensure that the resulting architecture will exhibit the quality
properties considered by the perspective.
• Describes how one can validate the architecture to demonstrate that
it meets its requirements across each of the views.
• May offer recognized solutions to common problems, thus helping to
share knowledge between architects.
• Helps working in a systematic way to ensure that the relevant
concerns are addressed by the system.
3. Perspectives Catalog
3. Perspectives Catalog – Cont.

Perspectives are defined with details like:

• Applicability: explains which of your views are most likely to be
affected by applying the perspective.
• Concerns: defines the quality properties that the perspective
addresses.
• Activities: identifies the important quality properties, analyzing the
views against these properties, and making architectural design
decisions that modify and improve the views.
• Architectural tactics: an established and proven approach one can
use to help achieve a particular quality property.
• Problems and pitfalls: explains the most common things that can go
wrong and gives guidance on how to recognize and avoid them.
3. Perspectives Catalog – Cont.
3.1 The Change Perspective
• Desired quality: The ability of the system to be flexible in the face of the
inevitable change experienced after deployment.
• Applicability: More important for longer-lived and widely used systems.
• Concerns: Magnitude of change, dimensions of change, likelihood of
change, timescale for change, and when to pay for change.
• Activities: Characterize the change needs, assess the current ease of
change, and consider the change tradeoffs.
• Architectural tactics: Contain change, create flexible interfaces, apply
change-oriented architectural styles, and build variation points into the
software.
• Problems and pitfalls: Prioritization of the wrong dimensions, changes that
never happen, and impacts of change on critical quality properties.
3.1 Applicability of the Change Perspective

a. Functional view may be informed by the Change perspective by enabling

the functional structure to reflect the required change.
b. Information view may be informed by the Change perspective by
mandating a flexible information model.
c. Concurrency view may be informed by the Change perspective by
dictating a particular element packaging or some constraints on the
concurrency structure
d. Development view may be informed by the Change perspective by
determining the impact on the development environment.
e. Deployment view may be informed by the Change perspective by
defining impact on the Deployment view because system change usually
affects structures described in other views.
f. Operational view may be informed by the Change perspective to the
extent that it impacts on the operational view.
3.1 Tactics for enhancement

• Contain change
• Create flexible interfaces
• Build variation points into the system
• Use standard extension points
• Implement reliable changes
• Apply change-oriented architectural styles
3.2 Availability Perspectives
• Desired quality: the ability of the system to be fully or partly operational as and
when required and to effectively handle failures that could affect system
availability.
• Applicability: any system that has complex or extended availability requirements,
complex recovery processes, or a high visibility profile
• Concerns: classes of service, planned downtime, unplanned downtime, time to
repair, and disaster recovery
• Activities: capture the availability requirements, produce the availability
schedule, estimate platform availability, estimate functional availability, and
assess against the requirements.
• Architectural tactics: select fault-tolerant hardware, use hardware-clustering and
load-balancing, log transactions, and apply software availability solutions.
• Problems and pitfalls: a single point of failure, ineffective error detection,
overlooked global availability requirements, and incompatible technologies.
3.2 Applicability of the Availability Perspective

• The Functional view may be informed by the Availability perspective by

enabling the business’s ability to operate effectively.
• The Information view may be informed by the Availability perspective by
considering the set of processes and systems for backup and recovery.
• The Concurrency view may be informed by the Availability perspective by
incorporating features such as hardware replication and failover in the
system.
• The Development view may be informed by the Availability perspective by
imposing design constraints on the software modules
• The Deployment view may be informed by the Availability perspective by
mandating a fault-tolerant production environment.
• The Operational view may be informed by the Availability perspective to
allow the identification and recovery of problems in the production
environment.
3.2 Tactics for Enhancement

• Select fault-tolerant hardware

• Use hardware clustering and load balancing
• Log transactions
• Implement fault-tolerant software
• Implement software availability solution
• Implement backup and disaster recovery solutions
 3.3 Scalability Perspective
• Desired quality: the ability of the system to predictably execute
within its mandated performance profile.
• Applicability: systems with complex performance requirements; and
systems where future expansion is likely to be significant
• Concerns: response time, throughput, scalability, predictability,
hardware resource requirements, and peak load behavior.
• Activities: capture the performance requirements, create the
performance models, and analyze the performance models.
• Architectural tactics: optimize repeated processing, reduce
contention via replication, and prioritize processing.
• Problems and pitfalls: imprecise performance and scalability goals,
unrealistic models, and use of simple measures for complex cases.
 3.3 Applicability of the Scalability Perspective

• The Functional view may be informed by the Scalability perspective

by revealing the need for changes and compromises to one’s ideal
functional structure to achieve the system’s performance
requirements.
• The Information view may be informed by the Scalability perspective
by providing useful input to performance models, identifying shared
resources and the transactional requirements of each.
• The Concurrency view may be informed by the Scalability perspective
to change the concurrency design by identifying problems such as
excessive contention on key resources.
3.3 Applicability of the Scalability Perspective
• The Development view may be informed by the Scalability
perspective through a set of guidelines related to performance and
scalability that should be followed during software development.
• The Deployment view may be informed by the Scalability perspective
through crucial inputs to the process of considering performance and
scalability.
• The Operational view may be informed by the Scalability perspective
by highlighting the need for performance monitoring and
management capabilities.
3.3 Tactics for Enhancement

• Optimize repeated processing

• Reduce contention through replication
• Prioritize processing
• Minimize use of shared resources
• Minimize partition and parallelize
• Make design compromises
4. Enterprise Architecture Frameworks
• Helps stakeholders to make decisions about enterprise design and
operation.
• Provides users with some confidence that the use of the reference
architecture will be successful in the current project.
• Facilitates communication of the enterprise design.
• Applicable to a wide range of enterprise systems and scenarios.
• Establishes a common means to organize, interpret, and analyze
architectural descriptions
• Identifies architectural concerns, generic stakeholders, viewpoints, and
abstraction levels.
• Encourages reuse.
• Provides a unified, unambiguous definition of terminology.
4.1 The Zachman Framework

Six types of views

1. Planner’s View - executive summary for the project.
2. Owner’s View - a high-level view of the system from the owner’s point of
view.
3. Designer’s View - more technically detailed view of the system.
4. Builder’s View - emphasis will be on implementation issues and
constraints.
5. Subcontractor’s View - detailed designs that are given to the development
team.
6. Actual System View - the actual systems that are being developed.
4.2 The Open Group Architecture Framework

• TOGAF provides an approach for designing, planning, implementing,

and governing an enterprise IT architecture.
• TOGAF is a set of phases and associated processes in the form of an
architecture development method (ADM) that will enable an EA to be
created for an organization.
• Instead of views, TOGAF focuses largely on management and
planning, rather than the actual development of the architecture and
its views.
4.2 TOGAF ADM

The ADM is an iterative process

covering all phases of EA development
that is adaptable to the specific needs
of any enterprise.
4.3 Federal Enterprise Architecture Framework

• FEAF is primarily intended for EA development ongoing in federal

agencies for the purpose of standardizing the development and use of
architectures within and between these federal agencies.
• FEAF provides both, a structure (the Consolidated Reference Model)
and a methodology (the Collaborative Planning Methodology).
• The Consolidated Reference Model consists of six reference models
and provides standardized categorization for strategic, business, and
technology model.
• The Collaborative Planning Methodology is a full planning and
implementation life cycle for federal EAs consisting of two main
phases: (1) organize and plan and (2) implement and measure.
4.4 Department of Defense Architecture Framework

• DODAF is a view-oriented architecture framework that provides an

organized meta-model-based visualization infrastructure for
addressing specific stakeholders concerns.
• The framework consists of eight main viewpoints that define specifies
rules for constructing a view on the system under development.
• All DODAF views must follow a Unified Modeling Language-based
meta-model.
• DODAF contains only a high-level, six-step phase model for dealing
with the development process of an EA.
4.5 Ministry of Defense Architecture Framework

• Each viewpoint of MODAF offers a different perspective on the system

of a systems project to support different stakeholder concerns and
interests.
• MODAF consists of seven different viewpoints:
1. All Views viewpoint – define the generic, high-level information
that applies to all of the other viewpoints.
2. Strategic View viewpoint –defines views that support the analysis
and optimization of military capability.
3. Operational View viewpoint –contains views that describe the
operational elements required to meet the capabilities defined in
the strategic views.
4.5 Ministry of Defense Architecture Framework – Cont.

4. System View viewpoint –contains views that relate directly to the

solution that is being offered to meet the required capabilities that
have been identified in the strategic views and expanded upon in the
operational views.
5. Technical Standards View viewpoint – contains two views that allow
all of the relevant standards to be defined.
6. Acquisition View viewpoint –used to identify programs and projects
that are relevant to the framework and that will be executed to
deliver the capabilities that have been identified in the strategy
views.