Legacy Application Integration

tukwilagleefulInternet and Web Development

Oct 31, 2013 (3 years and 7 months ago)

78 views























Legacy Application Integration

Subject Overview




This white paper has been prepared for Management, Marketing, Sales, Services and Development
members who wish to gain a high
-
level understanding of Application Integration. Some marke
t drivers,
and the evolution of the application integration infrastructure, are discussed. Also, some core
competencies are loosely positioned.





John G. Deitz

Consultant



Draft:

January 20, 1999





Table of Contents


Preface
................................
................................
................................
..............................

1

Introduction

................................
................................
................................
...................

1

Core Competencies

................................
................................
................................
......

2

Application Integration
................................
................................
..............................

2

Applications in a Distributed Infrastructure

................................
.....................

3

Evolution B
eyond Client
-
Server

................................
................................
.............

4

Application Servers

................................
................................
................................
.....

5

Application State
................................
................................
................................
................................
..........................

6

Connection Pooling
................................
................................
................................
................................
.....................

6

Load Balancing and Fail
-
Over

................................
................................
................................
................................
.

6

Multi
-
Threading
................................
................................
................................
................................
...........................

6

Interoperability

................................
................................
................................
................................
............................

7

Application Server Monitor/Application Manager
................................
................................
................................

7

Middleware
................................
................................
................................
.....................

7

Transaction Management

................................
................................
.........................

8

Security Administration, Access Control and Authentication

....................

8

Conclusion

................................
................................
................................
......................

9

White Paper

Application Servers & Integrati
on

Page
1



Preface

Several technology vendors and system integrators plan to provide solutions that aid and facil
itate “legacy
application integration”. This paper dispels some of the mystery around application integration, introduces
some of the key concepts, and discusses why they are important.

I think it is essential to view application integration in the cont
ext of a vendor’s core competencies, and
more fundamentally, in the context of creating
business solutions

that may be distributed or interact over
the web. In this paper, I wish to make the following points:



The world of application integration has strik
ing similarities to the maintenance and enhancement
themes that certain vendors (i.e. Y2K service providers) know well,



These vendors’ core competencies are relevant and applicable to application integration, and



Business solutions (especially electronic
commerce, customer relationship and supply chain) will
increasingly require application integration capabilities for scalability.



In the context of making these points, an overview of application integration is presented.



Introduction


“Legacy applicat
ion integration”
is a label attached to

the activities and projects that connect legacy
application functionality and databases to each other, to new distributed application middleware, and to
new web
-
based interfaces.

The subjects of
application integrati
on

and
legacy application integration

are difficult to separate.
Although
legacy
application integration is a specialized subset of the general integration market, legacy
integration projects are rarely immune to the issues and challenges of deploying dis
tributed systems. A
solution to a business problem may touch legacy applications, as well as newer applications; at the
conceptual level, the business problem may not care at all where the constituent business solutions reside.


The term “application int
egration” is a new buzzword. Yet it is essential to understand that
application
integration is just a logical extension of application development and maintenance
. In the application
integration world, application development/maintenance is simply much b
roader in scope: it includes more
processing platforms (Windows NT, UNIX and AS400, in additional to MVS), application servers, ERP
packages, middleware and gateways, languages and design architectures. And it typically involves the
web. These are all a
spects of applications that are distributed in nature: instead of an application running
solely on a single MVS machine, parts of it run on MVS, other parts on a web server, and perhaps other
parts on various application servers.


From an engineering per
spective, application integration is
not

an entirely new endeavor. It is very similar
to the practices of maintenance and enhancement. Application integration still requires that:



Solutions are designed;



Application parts are analyzed, modified/changed,
tested, and re
-
deployed;



Projects are managed;



Business and IT people communicate effectively; and



Solutions solve the intended business problem in the most elegant manner.


Recognized in these terms, it is easy to see that the process of application int
egration maps nicely to the
core competencies of several Y2K service vendors. I’ll outline some of these competencies in the next
section.


White Paper

Application Servers & Integrati
on

Page
2

The challenge [generally speaking] is to expand the core competencies of a subject vendor to handle the
additional
platforms, technology and management issues found in the application integration environment.
The resulting solutions must provide unique value that differentiates a given vendor’s offerings from those
of other vendors. The overriding objective is to sol
ve serious IT problems that impede customer’s progress
in developing, deploying and managing application solutions …

even distributed ones
.



Core Competencies

Specific core competencies lend themselves to the application integration problem space. Just a

few of
these are:



Analytical engines to:



Deeply analyze the “internals” of individual legacy application parts



Help identify which application parts are germane, inconsequential, or missing in a scope



Analyze the interface points between legacy applicatio
n parts



Capture deep relationships, such as synonyms or data flows



Technology to perform impact analysis,



Technology to automate/assist program change, along with some change management,



Technology to re
-
engineer multi
-
function programs into more discret
e functions,



Technology to debug programs after changes have been made, and track program test status and
coverage,



Practices and methodologies relevant to object
-
oriented, component
-
based development techniques
essential for application integration, and
the ability to activate those practices,



Powerful repository technology for sharing information about:



IT application parts and interfaces, and some of their value as assets,



Models and designs,



Software tool, middleware, and transaction processing deploy
ed in the environment,



Domains, networks, and operating systems deployed in the environment,



Terms, standards, conventions, policies and authorities,



People, organizations and ownership/accountability,



Goals, initiatives and projects.


Core competencies an
d strengths must be fully understood and appreciated when exploring any new market
opportunity. It is often beneficial to view a vendor’s offerings in terms of the functionality they provide (as
shown here) in order to see the breadth of capability provid
ed. This perspective provides a basis for
envisioning how the vendor’s current offerings can be leveraged and extended to fulfill roles relating to
application integration.



Application Integration

Application integration will eventually become synonymou
s with solution development


something IT
organizations do every day in the course of maintaining their application systems. IT developers:



Begin with a business problem to be solved



Envision one or more solutions



Determine the existing systems involved,

and determine the scope of changes to be made to those
systems, to serve the solution



Determine what other technology, infrastructure or process is required to implement the solution.
Identify the resources necessary to support the solution

White Paper

Application Servers & Integrati
on

Page
3



Apply the be
st practices of architecture and design to optimize the solution design



Prototype, or otherwise validate the design assumptions



Review the solution costs (budget) and gain approvals



Prepare a development plan, acquisition plan or procurement plan for the p
roject. Allocate resources,
and execute the plans



Test the individual components of the solution, and the aggregate solution



Prepare a deployment (rollout) plan and execute it



Verify that the deployed solution meets its objective in meeting the business p
roblem, and/or measure
it against the design objectives.

These steps are the essence of solution development, and of non
-
trivial application maintenance;

they are
also the cornerstones of application integration
. In
MVS
-
only

IT environments, application
integration
between MVS applications has been going on for years.


Applications in a Distributed Infrastructure

So why is “application integration” a new buzzword that is shaking the industry? And why is it a key
initiative for all of today’s Fortune 1000

companies?


The answer lies in a simple fact: the necessity to develop distributed and web
-
based applications is quickly
becoming a
fate compleat

for many companies. But designing solutions that operate in a distributed or
web
-
based environment is new t
o most traditional, mainframe
-
based IT organizations. The learning curve
can be steep, because of the myriad of new technologies, architectures and platforms that come into play.
This lack of experience explains why it is so difficult for IT organization
s to determine how, or even
if
,
legacy applications can be leveraged.


Yet, these same IT organizations will not be given much time to ramp up. Competitive pressures simply
won’t allow IT organizations to approach new and advanced solution areas leisurely
. As an example,
observe the bite that upstart book company
Amazon

took out of the business of established rival

Barnes &
Noble
; consider the very limited time that
Barnes & Noble

had to respond with a similar solution in order
to protect its market shar
e. Internet
-
based commerce continues to evolve at an alarming rate; and with it,
savvy business managers have the means to crush competitors.


Lets look at a brief comparison of the traditional MVS integration environment versus the web
-
based,
distribut
ed one. The following figure illustrates some of the differences in facilities, and complexity,
between the two scenarios.


Table 1: Integration Considerations: MVS
-
only vs. Distributed Environments


Traditional MVS Integration Environment

Web/Distributed

Integration Environment


Hardware:


MVS
-
based mainframe


Hardware:


MVS
-
based mainframe


Windows NT


UNIX and variants


AS/400

Server and Network Architecture:


SNA, APPN, some TCP/IP

Server and Network Architecture:



SNA, APPN, TCP/IP


Application/Web Servers
(IBM, BEA, Sun, other)


CGI, HTTP or IIOP


DCOM, CORBA, Java RMI; COM, ASP


Appl.Server Issues: load balancing, failover, etc.

White Paper

Application Servers & Integrati
on

Page
4

TP Monitors:


CICS, IMS/DC or IDMS


TP Monitors:


CI
CS, IMS/DC or IDMS


BEA Tuxedo and M3; Encina


Component Broker (IBM)


MTS (Microsoft)

Source Code Managers:


Panvalet, Librarian, Endeavor


Source Code Managers:


Panvalet, Librarian, Endeavor (MVS)


SourceSafe, PVCS, sever
al others

Middleware:


Low level APPC or EHLLAPI

Middleware:


MQSeries (IBM); NEON Integrator


MSMQ (Microsoft)


Active Server (Active Software)


Enterprise Data Access (Information Builders)


Message Oriented Middleware (va
rious)


And more …

Databases:


IMS/DB, DB2, IDMS, VSAM, BDAM

Databases:


IMS/DB, DB2, IDMS, VSAM, BDAM


SQL Server, Oracle, Sybase


Jasmine, O
2

, Versant, others (Object DBs)


Native file systems on NT and UNIX

Languages:



COBOL, ASM, PL/I; several 4GLs

Languages:


COBOL, ASM, PL/I; several 4GLs


C, C++; Java; Visual Basic; other


Perl, HTML/SHTML/XML, Tcl


ActiveX; IDL (for DCOM and CORBA)


Many 4GLs and private languages

Security:


R
ACF, ACF2, TopSecret; other

Security:


RACF, ACF2, TopSecret; other


Access Control Lists (ACLs)


Lightweight Directory Protocol (LDAP) stores


Cookies, certificates, and public keys


Internet firewalls

Applications:


Prima
rily home
-
grown

Applications:


Home
-
grown


Enterprise Resource Planning (ERP) packages


Business process automators (Vitria, Extricity,


and Crossworlds)



This table illustrates the myriad of new technologies, architectures an
d platforms come into play in the
distributed application environment. Application integration is challenged with creating seamless solutions
from existing applications, middleware, ERP packages and newly developed components. This can be a
daunting task
, and one that requires specific skills and extensive knowledge about the application
deployment environment.



Evolution Beyond Client
-
Server

The distributed application infrastructures have evolved to serve a purpose. To understand the issues, you
can l
ook back at the history of client
-
server, and then identify how current business drivers have changed
the requirements:


Early Client
-
Server

In the early years of client server, companies concentrated on putting value
-
added front ends
(clients) on their se
rver applications. These applications served users inside the company, and
White Paper

Application Servers & Integrati
on

Page
5

volume was typically low. Although poor performance was not well accepted, it was tolerated if
the client
-
side application provided additional value (such as sexier information pr
esentation).
Client
-
server infrastructure was fairly arcane and cumbersome, including methods like EHLAPPI,
APPC and proprietary remote procedure calls (RPCs). Applications were rarely designed with the
potential for distributed access, or even applicat
ion
-
to
-
application communication, in mind.
Client
-
side applications pushed the performance limits of desktop computers, and became just as
cumbersome to administrate as their server
-
side counterparts.


Web
-
based Client
-
Server

The client server market matu
red, and new protocols like TCP/IP were introduced to provide a
standard “communication sockets” solution. The world
-
wide web began to gain acceptance, and
with it a renewed appreciation for low
-
cost, thin client “browser” access to server applications
ru
nning on larger, more capable machines. This architecture was attractive for replacing the
earlier client
-
server solutions, which still served a fairly small audience and handled insignificant
amounts of traffic; the concept of the “intranet” was born.

C
ompanies scrambled to find simple ways to provide web
-
based access to server applications.
Various “screen scraping” solutions flooded the marketplace. But users soon realized that as the
volume of interactions increased, these simple solutions could no
t handle the load. Each web
-
based client allocated its own resource connections to databases and other important resources,
squandering network throughput and connection pools. Still, as long as the volume was low, these
solutions could be tolerated.


I
nternet, Supply Chain & Business
-
to
-
Business

The rampant adoption of the Internet for electronic commerce and business
-
to
-
business
collaboration has changed the rules of client
-
server dramatically. Retail Sales and Customer
Relationship solutions drive hu
ndreds of thousands of Internet interactions. E
-
commerce
applications require significant security and authentication. And supply chain (supplier
-
to
-
consumer) business system integration is driving the need to share access to legacy information
systems b
etween companies.

This radical jump in the
volume

of client
-
server interactions has driven a whole new set of
requirements for applications: load balancing and fail
-
over to ensure 24x7 operation; new
security and authentication methodologies including ce
rtificates, public keys, LDAP, and ACLs
(access control lists); abilities to integrate anything with anything
-

including legacy applications,
databases, middleware, ORBs, gateways, ERP packages, EDI and more. The traditional client
-
server environment s
imply cannot scale to meet these needs.

In short, the business drivers outstripped the capabilities of traditional client
-
server architectures, and a new
architecture, called the
application server
, was born.



Application Servers

An application server is

an application control mechanism that operates on a “mid
-
tier” platform. The mid
-
tier platform is located between the traditional “client” and traditional “server” platforms. The purpose of
the application server is to provide new levels of scalability,

reliability, security and performance to
applications that must service significant interaction loads. Electronic commerce, customer relationship,
and business
-
to
-
business collaboration (supply chain) applications fall into this category.

The idea of an

application server actually evolved from the web server. A web server runs on an
independent hardware platform and handles the HTTP message traffic to and from web clients. When the
demand for high volumes of Internet interactions began to occur, the we
b server seemed like a good place
to provide application scalability. Some web server vendors began expanding their servers to provide load
-
balancing features, while other new vendors began designing scalable application server solutions from the
ground u
p. It can be hard to tell these solutions apart, but the latter typically has richer features.

White Paper

Application Servers & Integrati
on

Page
6

Most application servers come with an integrated development environment (IDE) for C++ and/or Java.
The IDE is used to develop applications that “integrate” th
e traditional
client

and
server

portions of
applications, and create HTML or Java user interfaces to be run from web browsers. These mid
-
tier
applications provide seamless integration with web servers, take advantage of distributed middleware and
TP monit
or facilities, introduce additional security and authentication points, and link to traditional legacy
applications and data stores running on the traditional server (MVS/UNIX) platforms. Primarily, these
mid
-
tier applications are hosted on the applicatio
n server platform.

The purpose of the application server tier is to provide a new level of scalability and reliability, and to
provide the “application state” for Internet applications (which are inherently stateless). Applications
running on an applicat
ion server can take advantage of several features now common to nearly every
application server implementation. These include:


Application State

In an application, the context necessary to complete an interaction (request/response), or a
sequence of inte
ractions, is called the application
state.

Application servers provide application
isolation and state storage features to the applications they host. Some servers even implement
state management as a standalone process that can be scaled and load balan
ced like any other
managed application.


Connection Pooling

Most applications utilize connections to databases and other resources. These connections cost
relatively little when the application and the resource reside on the same platform. But when this
is
not

the case, the connection between the application and the [database] resource takes up
network bandwidth over a gateway. Poorly designed web applications can open hundreds, even
thousands, of connections to the same resource, creating bandwidth bott
lenecks and wasting the
precious performance cycles of database and resource managers.

Connection pooling is a feature that allows a single gateway connection to be shared by multiple
application instances, or even separate applications, thus saving precio
us, in
-
demand resources.


Load Balancing and Fail
-
Over

Load balancing

is a
scalability

feature provided by most application servers.

Applications developed to run on an application server can be designed to enable multiple
instances of the application to

run concurrently, servicing different users. These applications are
monitored by the application server; if an application instance cannot keep up with its request
load and becomes a bottleneck, then the application server dynamically spawns another ins
tance of
the application. Theoretically, this scalability is limited only by the number of physical servers in
the server group that hosts the application.

Fail
-
over

is an
availability

feature. This technique requires either a multi
-
instance application
server, or the ability to start an application server instance on another platform. If the application
server should fail, the request processing is restarted automatically on a different application
server. Fail
-
over is a critical feature for applicatio
ns that require 24x7 uninterrupted availability.
Note that it is
highly dependent

on effective management of application state, because that state
must be supplied to the new server instance.


Multi
-
Threading

Another aspect of performance and scalability
is
multi
-
threading
. Threading is the ability to
perform multiple asynchronous processes concurrently, while honoring serial access to shared
application resources. Creating good threaded applications is inherently difficult; until recently,
most applicat
ion servers were not multi
-
threaded. The introduction of Java has greatly simplified
the development of threaded applications, so application servers implemented in 100% Java can
provide excellent throughput benefits.

White Paper

Application Servers & Integrati
on

Page
7


Interoperability

An application ser
ver must provide the means to integrate with a wide variety of existing
applications, packages, components and middleware. Most application servers provide a
specialized software architecture called a “connector”, “bridge”, “adapter” or “integration modul
e”
for this purpose; term “integration module” is used in this discussion.

API
-
based

integration modules

use an application
-
specific API. For example, most integration
with ERP packages is through a package specific API; in the case of SAP R/3, this API

is called a
BAPI (for Business API).

Middleware

integration modules

connect to middleware facilities such as CICS, Tuxedo,
MQSeries, COM services, CORBA services, ODBC, SMTP (for e
-
mail), security services and
web servers, and distributed transaction mana
gers.

Component

integration modules

connect to Java applets and servlets, JavaBeans, Enterprise Java
Beans, CORBA objects, ActiveX (COM) components, and so on. Because component models are
based on standards, the application server IDE can provide
dynamic

introspection

of these
components to identify the
interfaces

registered for the components.

Custom

integration modules

provide one
-
of
-
a
-
kind connections to custom applications. Access
to legacy applications is usually through a custom integration module,

unless the legacy
application is first “wrapped” with a component model interface, such as CORBA.


Application Server Monitor/Application Manager

The application server environment is inherently complex to manage. Several servers are often
clustered toget
her to provide fail
-
over capabilities; yet each server may have different availability
to gateways, directories or other resources


thus affecting interchangeability.

Mature application server implementations come with a management facility used to moni
tor
server loads and balance, add/delete and configure server domains, and push management events
out to application management tools such as Tivoli TME, CA’s Uni
-
Center, BMC’s Patrol or HP’s
OpenView.


In short, application servers provide the reliability
, availability, scalability, security and interoperability
features required by a new breed of business application that must handle an indeterminate, but potentially
high volume, number of interactions. They also provide an excellent environment (IDE and

deployment
facilities) for developing integration solutions that utilize distributed architectures. Over time, expect many
features of today’s application servers to be incorporated into operating systems like Windows NT, UNIX
and Open MVS.




Middlewar
e

Various kinds of middleware were mentioned above, but what is middleware all about? Specifically, why
is the notion of middleware important to modern applications?

Middleware provides a generic infrastructure that allows applications deployed on differ
ent platforms,
and developed using vastly different technologies and languages, to freely cooperate together in a
unified solution.

To understand the important role of middleware, consider how difficult it was to develop client/server
solutions [of any com
plexity] over the past ten years. Nearly every solution was a customized RPC
(remote procedure call) implementation, or depended on weak protocols like EHLAAPI. Interactions
between client and server were typically synchronous. Clients and servers were
impossibly coupled, their
logic cluttered with code to respond to contingencies occurring at the other end of the connection. Most
implementations were a mess. Sound and effective solutions required a considerable amount of
forethought, engineering and c
ross
-
platform expertise.

White Paper

Application Servers & Integrati
on

Page
8

Standardized middleware implementations changed all that. Modern middleware takes responsibility for
the inter
-
platform communications, and handles low
-
level communication errors. It provides a consistent
API and semantics for in
ter
-
application communications that can be invoked from nearly any platform and
development language base. Designers of distributed applications no longer need to be a
jack
-
of
-
all
-
trades

on all potential platforms.

Advanced middleware enables a great deal

of asynchronicity between cooperating applications. New
event
-
based and message
-
based architectures allow applications to
subscribe

to “events” that they are
interested in, or to
publish

events that other applications can respond to. These events are ha
ndled by a
message
-
broker. The message
-
broker manages message queues; it also ensures that events and messages
get delivered, and that they get delivered only once, even in the event of system failure.

Middleware also handles the scalability issues assoc
iated with communication volume, and handles the
common set of low
-
level failure and recovery scenarios.

Coupled with the new component model standards (like CORBA, COM and EJB), middleware represents a
tour de force

in architecture supporting modern, inte
r
-
application cooperation. Yet the middleware
industry and solutions are still evolving: some vendors are adding workflow features, and you can expect
deeper operability between middleware and distributed transaction managers in the near future.



Transac
tion Management

Applications running on the application server tier, and integrating resources from multiple platforms,
present very interesting problems for transaction management.

Assume such an application is designed to interact with a MVS
-
based CICS
transaction for part of its task;
in addition, it reads and writes to a DB2 database through ODBC, and also posts messages to other
applications through an MQSeries message queue. Interactions with each of these resources are necessary
during a
single
u
nit of work

in the application. What happens if one or more parts of the unit of work
cannot be committed? Naturally a rollback should occur for the pending unit of work.

This scenario illustrates the need for an all
-
encompassing transaction monitor, some
times called a
distributed transaction processor
, or DTP. Such a monitor is necessary to coordinate the
commit

or
rollback

of a “composite transaction” that may span multiple physical platforms, and may interact with
other transaction processors (such as

CICS, IMS, Tuxedo or Microsoft’s MTS).

Distributed transaction managers are beginning to reach viability. Most early solutions take advantage of
the object
-
oriented
container

and
component

concepts to establish and enforce transaction scopes. Some
adapt
ive frameworks even allow a component to exhibit different transaction behaviors depending on the
container it is deployed in. Expect to see significant evolution in this very interesting, but complex, area.
In particular, expect Enterprise Java Beans pr
ovide a simpler and cleaner composite transaction capability.



Security Administration, Access Control and Authentication

Applications developed for the application server tier have a wide range of security issues to consider.
They may provide access to

a company’s core business systems. They may utilize significant network
bandwidth. They may allow access to databases containing sensitive information. These applications may
provide all these services to any party that is authorized to pass through (o
r can hack through) the corporate
firewall.

As companies begin providing richer web
-
based customer relationship services, or embark on e
-
commerce
initiatives, or develop business
-
to
-
business “supply chain” integration, providing security is a paramount
is
sue. Some of the concerns include: securing access to corporate information and resources, ensuring that
customer information is kept private, and managing the integrity of electronic commerce transactions based
on credit cards.


White Paper

Application Servers & Integrati
on

Page
9

An
ACL

(or access contro
l list) is used to manage the list of services available on a server
../13/82.htm
,
along with the list of the hosts permitted to use each service. ACLs introduce administrators and users to
the principals of granular access cont
rol on file system objects. Sophisticated ACLs can control all
connections between the trusted and untrusted sides of the Internet firewall; in particular, they can allow or
deny connections based on the source or destination of the request, and the clas
s of service


for example,
FTP, Telnet, HTTP (web) or SMTP (mail).


Once a user has been granted access past the firewall to a particular domain,

authentication

is the process
of ensuring that the user has authority to use a service. There are many kind
s of authentication ranging
from simple USERID/password schemes, to highly sophisticated digital certificates and public key
infrastructures (PKI) used to conduct electronic commerce. Some say PKI will replace firewalls someday.


These security measures g
o far beyond the ACF2, RACF or TOPSECRET utilities used to control access to
MVS
-
based resources. The stakes (and risks) are considerably higher, and the scope of users to manage is
[potentially] the entire Internet user audience.



Conclusion

In conclusi
on, let’s return to the fundamentals of providing solutions to business problems. It is clear that
application integration


like maintenance or new development


is just a means to solve a problem. It
simply adds a few more platforms, technologies, and
perhaps the Internet, into the equation.

I purposely did not explore the specific methods and architectures involved in the integration of legacy
applications


although I hinted at them in
Table 1
. These subjects are too extensive to explore here.

Certa
in existing technologies are well positioned to provide value to the application integration process


especially the integration of MVS
-
based legacy applications or databases. Analytical engines must provide
an important information base for “introspectio
n” into legacy application parts. At a minimum, this
information base can be leveraged for:



Identifying and classifying application assets for re
-
use



Understanding the current role, state and quality of an application asset



Determining application asset
suitability to a proposed solution



Performing detailed re
-
engineering of legacy application parts, and



Performing unit testing of legacy application parts.


Naturally, many of these functions must be performed from the non
-
MVS platforms where application
integration activities take place; in particular, they will need to be accessible from the application server’s
IDE, or some other centralized project coordination facility.

Knowledge and process management products can play an immediate role in applicatio
n integration
projects. They can provide centralized, but remotely accessible, knowledge about the technologies and
architectures available in the environment; likewise, they can point to previous successful implementations
of patterns. Knowledge
-
based p
rocess management can supply the rigor needed for fledgling engineering
projects, and enhance thoroughness, quality and repeatability. These solutions provide the basis for
applying a continuous maturity model (CMM) to IT organizations.

An equipped Servic
es organization can offer a spectrum of application integration solutions ranging from
planning/installing application servers, to deploying sophisticated message
-
broker architectures. They can
also offer solutions to build global business information arc
hitectures. Most large companies have formed
architectural committees charged with defining the standard technology architectures for distributed
applications; these committees will seek consultation and assistance in selecting and implementing new
infra
structures. Well selected and crafted Services can answer this call.

Again, it remains essential to consider core competencies, which may offer much to application integration.

White Paper

Application Servers & Integrati
on

Page
10















We can analyze and outline the strategies and success factors t
hat a vendor can consider in developing
solutions for this new market. Such analysis will also suggest how existing product lines and technology
can be refocused to provide value to this strategic direction.