Enterprise architecture and SOA:

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).
The first step in EA is identifying and naming each process, and identifying business
events that mark its start and end. Deeper analysis includes identifying intermediate business
events and human decisions made during the process, participants in the process, exceptional
conditions and how these are resolved. Also documented are non-functional aspects of a process,
such as how often it changes, and its expected time of completion.
The ‘enterprise architecture’ function within enterprise IT has evolved to manage the
complexities of an ever-changing technical environment.
Enterprise Data and Processes:
 Information systems, by definition, need to keep track of the core information vital to the
functioning of an enterprise. Information systems also manage the core business
processes of an enterprise; Enterprise processes can often be classified as ‘vertical’ or
‘horizontal’.
 Vertical processes typically operate within a single organizational function, such as sales
or accounting.
 Horizontal processes, on the other hand, cutacross functional units; ‘order to cash’ is a
horizontal process since it spanssales, production and finance.
Enterprise Components
The term ‘component’ has traditionally been taken to mean to a ‘software sub-system that has
well-defined interfaces which can be used independently of its internal implementation’.
 The coarsest level of enterprise components are business components, defined as collections of
high-level enterprise processes, be they vertical or horizontal. These processes are grouped by
business function; horizontal processes often stand alone.

At the next level of granularity, high-level enterprise processes are broken down into sequences
of smaller processes, and also regrouped so as to be implemented in a set of applications. This
process results in application components: Each application component is a set of smaller
processes such that the information needs of this set is largely restricted to a cohesive set of data,
such as ‘customer data’ or ‘payments data.’

SERVICE-ORIENTED ARCHITECTURE (SOA)

Service-Oriented Architecture (SOA) is an approach for application development. SOA is not a tool
or framework one can purchase but it is a flexible and modular approach for delivering computing
applications.

Software components in SOA paradigm are referred to as services. A service is a self-contained

functional or business activity having some specific consequences. One objective of SOA is to enable
the reusability of these software components.
As the enterprise grows, the complexity of new integrations and number of dependencies increase
exponentially. This gets worse as the pace of change grows, rapid in the current business world and
functional requirements change over time too. SOA is the answer to this challenge. Application
development approach based on SOA paradigm allows dynamic construction and rapid customization.

THE ARCHITECTURE

A model of the service-oriented architecture has been represented in Figure 12.2. With SOA
approach, the applications are built through a collection of services. A service is an independent entity
executing some functionality. The services communicate via message passing.

THE INTERACTION MODEL

Interaction among services in SOA paradigm works in following manners:

1. A service provider registers its services in the service registry managed by the
broker.
 2. The service is registered accordingly in registry as per its category.

3. Service consumer looks up for services in the registry.

4. Service consumer binds itself to the service provider and uses the service.

BENEFITS OF SOA

SOA provides numerous benefits over traditional application-oriented architectural models. The benefits
of service-oriented architecture can be counted from two different viewpoints like architectural and
business.

Architectural Benefits
Flexibility: System functionalities often need to go through changes for betterment. In monolithic
application architecture, it is difficult to incorporate changes to meet new requirements. Changes can be
easily implemented in service-oriented application architecture which provides greater system flexibility.
Reusability: Services are reusable. It is not only in the sense that ‘write once integrate anywhere and
anytime’. Moreover, one cannot throw anything away when different functionality is needed as those
existing functionalities can be reused later.
Simpler integration: System integration is inevitable as multiple different solutions together may work in
a system. Service-oriented approach reduces the complexity of system integration as connectivity, data
exchange and process integration techniques are more simplified here. The adherence to the published
contracts of services also makes it easier for future applications to connect effortlessly with existing
standard-based services.
Maintainability: Service maintenance becomes easier when it can be done in isolation with help of
smaller teams. Thus the maintenance of independent services in SOA becomes less complicated and
incurs less cost.

Business Benefits
Agility: Service-orientated architecture is based on the assumption that system changes over time. Hence,
a well-designed SOA-based development protects a system from the impact of this evolution. The
flexibility of SOA enables a system to respond quickly to new requirements.
Cost reduction: Services once developed can be reused by disparate systems for different kind of
purposes
. Integration of services in a system is also easy. Therefore, the reuse of already existing assets (services)
makes it cheaper as reusability means lower development and testing cost.
Increase in quality: Reuse of a service by multiple consumers make a service well tested and flawless.
Its quality improves and thus SOA provides high performance and delivers good return-on-investment
(ROI).
Quicker release to market: Service-oriented approach takes lesser time for system development or even
for a system up-gradation. It thus makes the launch of a system quicker to market by diminishing the
development time.
Standardization: Services in SOA are generally developed following open standards. This
standardization makes services more vendor-independent and any kind of system can use a service as
long as it uses the proper (standard) service interface.
Application Integration and SOA
The decomposition of business components into application components that are closely tied to
subsets of Information is never exact and applications will often need to access data that is
owned by other applications.
There are a number of mechanisms that applications can use to communicate with each other at
different ‘levels’:
1. Data level integration: direct data transfer using batch programs or on-line exchange
using database triggers
2. API level integration: applications publish API libraries that are used by other
applications to access their data
3. Service-method-level integration: applications publish services using say, web service
protocols, in an organized manner so that many different applications can use a particular
service.
4. User interface level integration: applications publish mashup APIs that are used to
provide a common user interface to functionality from many applications.
5. Workflow level integration: tasks performed in one application lead to work items
being created in others, thereby driving the flow of work in a business process.
 An EAI (enterprise application integration) strategy is usually an integral part of an
enterprise architecture definition. Application integration has come to become
synonymous with ‘service oriented architecture’ (SOA), and many of the features of
traditional EAI strategies have been reborn as ‘SOA strategies.’
 The EAI/SOA process maintains a bridge between the ‘to be’ enterprise architecture
picture (which also evolves) and reality of systems as they are at any given point of time.
SOA Strategies:
(1) Wrap legacy systems with web services and call these from other applications
(2) Develop an enterprise service model with well-defined schemas for data exchange
(3) Develop new application components that publish and use service interfaces
(4) Develop a common user interface using enterprise mashups
(5) Replace legacy systems and application components while retaining the same service
interfaces without impacting users, and at a lower cost.

Enterprise Software:
Enterprise Softwares:
- Enterprise Resource Planning (ERP)
- Supply chain management (SCM)
- Customer relationship management (CRM)

PARTNERS: PEOPLE AND ORGANIZATIONS

Enterprise Custom Applications:

Software Architecture for Enterprise Components:

The application (component) performs the following tasks: It maintains some information in a
data store, supports user interactions with this information through a presentation layer, and in
the process executes some business logic computations.

User interface patterns and basic transactions:

Layered MVC and AJAX Paradigm
Business logic and Rule based computing:
Functions of business logic:
1. Validations (e.g. verifying whether the order is complete)
2. Computations (e.g. computing a total)
3. Transaction Management (e.g. accomplishing all required operations in the scope of a single
database transaction)
4. Data Manipulation (e.g. actually inserting the order and order item records) and Object
Relational Mapping (e.g. ensuring that the order items have the correct order id)
5. Calling other Business Logic Methods (e.g. posting an accounting transaction)
6. Complex Search (e.g. retrieving a set of orders and their related items)
Rule Based Computing:
Rule-based computation is an abstraction based on formal logic.
Rules are especially useful for modeling validation rules, as well as many other computations,
such as evaluating risk or rating insurance policies.

A rule system contains logical statements5 (i.e. rules) that may or may not become true when
evaluated against facts.

For example, a ‘valid’ order may be defined by the following rules:

R1 : ∀ x∀ y∀ z Order(x) ∧ OrderItem(y) ∧ OrderOf(y, x)
∧ ValidOrderItem(y) ∧ CustomerOf(x, z) ∧ Customer(z)
⇒ValidOrder(x)

R2 : ∀ x∀ y∀ z∀ p Order(x) ∧ OrderItem(y)∧ ￢OrderOf(y, x)

∧ CustomerOf(x, z) ∧ Customer(z)
∧ ProductOf(x, p) ∧ Product(p)
⇒ValidOrder(x)
Rule engines are used to evaluate rule systems. There are two varieties of rule engines:
Backward-chaining engines evaluate whether a particular predicate, say ValidOrder(x) is true or
not, evaluating all possible rules that are required to verify this.
Forward-chaining engines, on the other hand, take a set of available facts and determine the
complete set of predicates that evaluate to true, including ValidOrder(x), as well as any other
predicates that may be implied by these facts.
Traditionally, backward-chaining ruleengines have been used in applications, as they are more
attuned to procedural programming paradigms (i.e. a predicate needs to be explicitly checked).
However forward-chaining engines are useful in specific contexts, such as user interfaces or
other event driven systems, since they support ‘reactive’ programming, i.e. any rules that ‘fire’
because of the current state of application data can trigger exception conditions that are handled
in an event-oriented programming style.
Modeling business logic using MapReduce:
In Enterprise applications, Computations, Data Manipulation, Calling other Business Methods
and Complex Search. Are implemented using Map Reduce paradigm.
For example, TCS Instant Apps uses a visual formulation called Logic Map that is based on the
MapReduce cloud programming paradigm, borrowing also from the Map-reduce-merge model
that extends MapReduce for relational processing.
A Logic Map is a graph with create, search, and update nodes, each correspondingto ‘pages’ (as
defined in (14.1)) of some application form.Thesenodes manipulate relational records in the same
manner as the correspondingpages of their associated forms, but without a user interface.
Such nodescan also be viewed as map nodes in the MapReduce parlance; they take key/value
pairs (relational records) as input and produce new pairs, while accessing/manipulating database
tables in the process.
In addition there are ‘compute nodes’ merge and reduce that perform computations on records
obtained after joining (in the case of merge) or aggregating (in the case ofreduce) records
flowing along the edges of a logic map.

For example, the logic map in Figure 14.5 performs a billing function for one or more customer
records.

Workflow and Business Processes:

IMPLEMENTING WORKFLOW IN AN APPLICATION
Enterprise Analytics and Search: