Systems Dynamics

Study of Integration in

IT

Information Technology offers a continuous choice of

options to be harnessed and used to support business. IT

applications have specific domain focus to solve business

problems. Since business is always dynamic the

technologies offered to support business are always

being improved to promote flexibility agility and user

friendliness. Integration domain helps in streamlined

integration of various enterprise applications, data,

business process etc. Applications, technology and

software belonging to this domain are perhaps the most

dynamic of all other IT domains. The paper gives a high

level view of technology lifecycle of various integration

lifestyles. Understanding the various forces acting when

a technology is being offered will help an IT worker,

whether he is an architect ( for choice of integration

style) or a project manager ( for investment decisions in

specific technology) or an IT consultant ( for decisions on

learning specific technology)

2 | P a g e

1 Introduction All applications in the organization are developed in a heterogeneous environment.

There is a constant need to share information between various applications across the IT

landscape. Hence integration between these applications are important. Software tools

developed are trying to facilitate development efforts in integration and as such there is a

constant product innovation in the market. When new products are launched the reaction

from the firms are of varied degree and it can be anything from the following: early

adoption, late adoption, sheer rejection. Since there are multiple stakeholders in this

market the point of views put forward often have conflict of interest.

The focus of this paper would be to develop a framework to understand the lifecycle of

the Integration style with special focus to SOA. The model tries to find the drivers for

emergence of an integration style with various data related to SOA1 , lifespan of SOA and

time required for emergence of new area such as Integration-As-a-Service2.

2 Objective

• Build a systems dynamics model for development of integration style

• Identify Drivers for development of Integration Technology

• Predict technology lifecycle of the current Integration Style

• Predict Adoption of Alternate Integration Style

• Use the framework to decide on new technologies available

3 The Model

3.1 Problem Articulation Integration Domain has been in constant flux with the single theme of integration

of business data, process or application. New requirements within business are always

driving new application/software development. Applications business logic is acted on

the data and information which often comes from other applications. For example a CRM

solution being built may need data from an already existing ERP application. This would

need an information flow from ERP application to CRM application and hence there is a

need for integration.

3.1.1.1 Integration Spaghetti Integration, done without any foresight often leads to a situation which has been

referred to as Spaghetti Integration3 in many journals and articles. IT skilled workers

have always been offered myriads of technology options for integration. With such a

wide range of options and no focused strategic use of integration inappropriate use of

technology is quite common. At any point of time an Integration architect has the

following options:

3 | P a g e

i. To develop a quick fix solution with existing tools

ii. To develop a strategic solution with existing tools.

iii. To invest in new integration tools for better handling the integration

requirements.

3.1.1.2 Architect’s Dilemma IT applications are normally considered part of operation and in many firms IT is

not considered strategic but a backroom operational process to optimize costs. Even if IT

application developed has strategic business significance Integration is one domain where

strategic planning is virtually nonexistent. Thus an architect and project manager in many

case continue doing integration using old tools and old methods.

Integration is always in flux and technology offering from this space is quite

dynamic. So there is a tendency to look at new options as some kind of hype. This is not

uncommon there is often a hype associated with many technical innovations4 . But if an

architect always thinks of new Integration Style as hype there is a good chance that firm

may get delayed in adopting new integration technology which could have added

significant business value. At this stage the architect or the firm may completely miss the

improved technology wave or if there is no proper way to manage new technologies he

may bring in outsiders as consultants and depend on them. In both cases (missing the

wave and bringing in outsiders) has the chance of IT division within the firm losing out

on learning. When outsiders (consultants or contractors) are brought in it requires

substantial time to understand the organization culture and business. Thus it may take

some time before realizing business when outside experts are invited.

There is an option to continue as it is or invest in new technology. While investing

in new technology a farsighted IT manager or an architect focused on Integration should

also have an idea how long the integration framework or supported by a specific

commercial product proposed by the new technology would last. This is important as

with every investment there is always a question on ROI. Thus an IT Integration

manager will always remain in the dilemma which perhaps can be termed as Architect’s

Dilemma as he will always have the choice to pick form variety of design and technology

options.

Each and every domain has its own in inherent dynamic behavior and it affects the

IT applications in a similar fashion. For example marketing domain is much more

dynamic than domain of human resources. Hence there are chances that applications

supporting marketing will come up quickly compared to applications. For example we

have CRM applications, SalesForceDot Com where as HR nothing much is heard beyond

outsourcing of payment processes and generations of pay stub.

Nevertheless whatever happens in rest of the domains integration is one domain

which always remains under pressure to deliver and support business process. Since rest

of the business process is changing there is always an need to connect this various pieces

of business. Thus an architect in the domain of Integration will have more than fair share

of Architect’s Dilemma.

4 | P a g e

3.2 Reference Mode of Behavior

3.2.1.1 Integration Style Integration in the paper would mean technical options to share information across

various applications. There are various kinds of integration patterns. Integration style is a

combination on Architecture style implemented using a specific group of products. Thus

an SOA architectural style of integration can be implemented over SOAP/HTTP

framework provided by any tool. Technology Lifecycle often follows growth pattern

similar to product lifecycle i.e. S shaped Curve. If specific integration technologies are

considered from past in most cases the curve seems to follow the S shaped curve.

Integration has various technology options for example RPC, Com D-Com, CORBA (in

the past) along with many architecture patterns like Hub and Spoke, SOA etc. Also on the

horizon there is a virtualization and Integration as a Service. For each architectural style

there will be associated products (commercial or open source) in the market. A firm

trying to leverage on a integration style will have to buy or get a off the shelf software

which will provide frameworks, features to implement the Integration solution. Thus an

integration style will be combination of architecture style and associated product

offerings. Within a firm thus there is a tight coupling between architecture styles a

product supports.

3.2.1.2 Reference Mode If we have to think of a reference mode of integration style we have to study the

reference mode of its constituent variables namely Architectural pattern ( e.g. SOA),

Product/software( e.g. Mule) and technology ( e.g. Soap,HTTP). The reference mode of

each of these variables will be somewhat be similar to a Technology Lifecycle. Thus

product lifecycle and technology lifecycle has similar reference mode of behavior except

for the fact that a architectural life often outlives a product. For example SOA is an

architectural style and there are many products (Example WebSphere, BizTalk, Mule etc)

in the market which provides framework for SOA. Hence it cam be said the Product

lifecycle is smaller than architecture lifecycle.

Figure 1 Architecture Style Vs Product Lifecycle

5 | P a g e

The blue curve is the architectural style and the green and orange curves are hypothetical

product lifecycle curve. The reference mode behavior is not drawn to scale.

Thus the Integration Style will also have a reference mode of behavior as follows:

3.3 Formulating Dynamic Hypothesis

Much has been stated already in the paper to indicate that the technical world of

integration is quite dynamic. At the time of writing this paper there are quite a few

integration styles looming large in the horizon. Some of them are:

• SOA –SOAP-HTTP-WS*

• SOA-Rest over HTTP

• SOA-Others5

• SOA-BPM

• Integration as a Service.

It can be found out that SOA is an architectural style which can be implemented in

various ways and some of them have just been mentioned. There are different products in

the market and many of them provide SOA framework with partial to many of the

features or styles listed above. The focus of the paper is to have a high level view of

integration styles and predict which part of the lifecycle each style belong to. It also aims

to develop a framework for forecasting lifecycle of integration style. The following

hypotheses are being made:

i. SOA-SOAP-HTTP Integration style is currently at its peak

ii. Firms have to adopt a portfolio approach on integration style

Time

Activity

6 | P a g e

3.4 Causal Loop Diagram

3.5 Variables

The Variables in the Model can be grouped in three categories: Variable for

current Integration Style, Variables for Alternate Integration Style and Generic

Variables Applicable to both style.

3.5.1 Group A( Generic Variables)

ISFocus

ISAdoptionRate ISDesertionRate

ISAdoptionSense AltISAdoptionSense

ISTechLimitation

AltISTechLimitationISAdoptionEase

AltIsAdoptionEase

AltISMaturityISMaturity

TechnologyInnovation

IntegrationMarket

IndustryCooperation

AltISFocus

AltIsIndustryCooperation

ISMaturity Technology

Innovation

Integration

Market

7 | P a g e

I. Integration Market: Integration market opportunity. In an article Gartner indicates

around 30% of the 872454 Mn dollar IT services belongs to development and

integration 6. This huge market opportunity is one of the key driver for various IT

firms (software vendor, IT services providers) to continuously invest and

innovate.

II. Technology Innovation: This is a variable to indicate the rate of innovation. High

value of Technolgy Innovation indicates high product maturity and hence

Integration Style maturity

Technology Innovation = Integration market × k1

k1 is the coefficient to convert integration market opportunities to technology

innovation. This is a proxy parameter to indicate level of activities in terms of

R&D effort, new product developed ( e.g ESB)7, new architectural style proposed

(e.g REST-HTTP)

3.5.2 Group B (Variables Applicable for Current Integration Style)

III. ISMaturityAge: This is a proxy variable indicating maturity of the Current

Integration Style. This measured by a number which is proportional to number of

years the Integration style has been prevalent in the industry.

IV. ISMaturity( Integration Style Maturity): Technology innovation influences the

growth of the IS Style maturity

ISStyleMaturity = Technology Innovation × ISMaturityAge × k2

ISMaturity

TechLimitation

AdoptionEase Adoption Sense

ISFocus

Industry

Cooperation

+

+

8 | P a g e

k2 is the coefficient to convert the Technology Innovation to appropriate

ISMaturity.

V. ISAvailableProducts: This is a dimensionless variable. For every integration style

available with there are usually a set of products available in the market. The

value for this has been arrived by weighted avg of the products. A higher weight

signifies feature rich product

ISAvailableProducts= [(∑ Product i × Weightage i ) ÷ n] where i= 1,2,..n

VI. Adoption Ease: This is a dimensionless variable. Products which provide options

to quickly develop and implement solutions will score high on Adoption Ease

scale. Features such as matured IDE or various configuration options or other

“cool features” often create ease of adoption. Products need to be at certain level

of maturity and complexity to provide various cool features to help in

development. For example IDEs like Eclipse has various options to declare define

variables and avoid errors. Commercial Middleware’s such as webSphere IBM or

SAP PI are much more complex and development and coding activities have been

reduced to only configuration. The adoption ease value for this software products

are quite high

Adoption Ease = ISMaturity × ISAvailable Products

VII. ISTechnicalLimitations: This is a dimensionless variable on a relative scale.

These are limitations for a certain integration style which arise because standards

are not clear or perhaps the developer needs to take care of many low level details

while implementing the solution. 8

TechLimitation = ISMaturity × (1÷ ISMaturity) × k5

k5 being the coefficient to convert ISmaturity to TechLimitation

VIII. Adoption Sense: This is a dimensionless variable. Adoption makes sense when it

satisfies three important criteria

a. Ease of Adoption (i.e. how developer friendly the product is) sense

indicates whether it makes sense to adopt the integration style.How

Reusable components and interfaces can be built using the Integration

style

b. Technical Limitation: Lesser the technical limitation the better sense it

makes for adoption

9 | P a g e

c. Industry Cooperation: More the industry cooperation in terms of uniform

standards support by multiple vendors more it makes sense for the firms to

adopt a certain integration style.

There is no precise mathematical way to model the complex behavior to arrive at

these values. For simulation purpose the following equation has been considered

Adoption Sense= Adoption Ease × Market Cooperation – Technical limitation

IX. ISShareofIndutryCooperation: This is a dimensionless variable.

ISShareofIndutryCooperation is a fraction of the Total industry cooperation.

Total Industry Cooperation is a combination of many factors. Cooperation

initiatives are done actively and passively in many ways by the stakeholders in the

entire eco system. It starts from marketing and sales launched by product

companies to thought leadership by industry speakers, articles and blogs written

by independent consultants. This is a cooperation which works in a self sustained

manner. The fact that consultants and industry speakers will adopt a new

technology is not only driven by the notion that a new concept may help solve

integration issues and facilitate business but also because it will help them to be

establish credibility through thought leadership . Thus once the concept is adopted

by critical mass of people these thought leaders are suitably rewarded in economic

sense. 9

Industry cooperation also refers to cooperation between big firms on agreeing and

promoting common standards

X. Staff Maturity: This is a dimensionless variable. The success and failure of any

technology depends ultimately on the staff involved in implementing it. No matter

how promising a technology may seem to be its success ultimately depends on the

employees. Appreciation for new technology, ability to understand the merits of

different technologies, and application of different technologies for solving

different problems are some of the key traits of matured staff.

XI. IS Adoption Rate (Integration Style Adoption Rate): This is a variable to indicate

the integration style adoption rate within firms. This is a dimensionless variable

IS Adoption Rate=Adoption Sense × Staff Maturity × k3

k3 is the coefficient to convert staff maturity to appropriate ISAdoption rate

XII. ISFocus (Integration Style Lifecycle): Firms at any point of time will be focused

on specific integration style. For example throughout during 2005-2007

Integration vendors offered EAI tools like webMethods , TIBCO offered and

promoted hub and spoke style of integration using message brokers. This was not

only represented by the increasingly huge number of projects that author

10 | P a g e

experienced as a consultant but also by the large number of articles published in

the magazines and articles. Thus, at the time of writing this article a significant

number of firms are focused on SOA style of integration. With time the focus will

gradually shift to different integration style. Thus for simulation purpose:

∫ d(ISFocus ) = ∫ ISAdoptionRate . dt - ∫ ISDesertionRate .dt

11 | P a g e

3.5.3 Group C (Variables Applicable for Alternate Integration Style)

XIII. ISDesertionRate ( Integration Style Desertion Rate). This is a variable to signify

the Desertion rate from current Integration style. A higher desertion rate style

with respect to the Adoption rate will signify the shift in trend to the new

Alternative Integration style. When desertion rate is high than adoption rate there

will be steady decrease in value of the ISFocus. ISDesertion rate is influenced by

alternative Integration Style Adoption Sense and Staff maturity. The equation

governing the nature of this variable occurs in the similar fashion as that of the

ISAdoption rate but works against the current integration style. Hence

ISDesertionRate = AltAdoptionSense × Staffmaturity

XIV. AltISAdoptionSense. This variable is similar to AdoptionSense but it signifies

how much sense it makes to adopt the new/alternate Integration Style.

AltISAdoption Sense = (AltISAdoptionEase × AltISShareIndustryCooperation )–

AltISTechLimitation

XV. AltISAdoptionEase: This variable is again similar in nature to ISadoption ease

except for that it works for new/alternate Integration Technology Style

AltISAdoptionEase=AltISMaturity × ALtISAvailableProducts

AltIS

Maturity

AltIS

TechLimitation

AltIS

AdoptionEase

AltIS

Adoption Sense

Alt

ISFocus

Industry

Cooperation

+

+

12 | P a g e

XVI. AltTechLimitation. Variable similar to ISLimitation

[AltISTechLimitation= 1÷ AltISmaturity]

XVII. AltISMaturity: Similar to ISMaturity except that technical limitation in one

product will influence growth of alternative Integration Style. This is quite

common in the industry as one Technology paves way for another technology as

it hits its limitations. Hence the equation is slightly different from ISMaturity.

AltISMaturity = AltISMaturityAge × TechnologyInnovation × k7 × k6

k6 is the coefficient which converts IS tech limitation to AltIS maturity

k7 is a variable similar to k3 and its values are similar to k3 except for that it

contributes to the AltMaturity after sometime

XVIII. AltISMaturityAge: Similar to ISMaturity Age

13 | P a g e

3.6 Loops Analysis

3.6.1 Reinforcing Loops of Integration Style

Maturity

There are two reinforcing loops in this model one

for Current Integration Style and Another for

alternate Integration style. With the increase in

Integration Style maturity there much more tools

and products in the market which ultimately

increase the adoption rate. With the increase if

adoption rates the focus on the specific integration

style increases. As focus on the specific integration

style increases product companies and industry

work as a whole to improve the IS Maturity and this cycle keeps on repeating till it

reaches a saturated level of ISFocus.

Similarly the same cycle exists for Alternate Integration style. However both the

cycle don’t work at the same time. There would be a switch form one cycle to another

cycle with the passage of time. This switch form one cycle to another cycle takes effect

when one integration style hits saturation level or there is attractive alternate technology

options.

3.6.2 Reinforcing Loops of Industry Cooperation There are reinforcing loops : one for the existing Integration Style and another for

the Alternate Integration Style.

Once the Integration Focus increases it influences the Industry which helps the

promotion of the integration style. Integration Service Providers , Software Vendors,

Independent Consultant, Industry Though Leaders , IT Consultants all ride in the wave of

the new technology style. This is a very self sustained reinforcing model. All IT

ISAdoptionRate

ISAdoptionSense

ISTechLimitationISMaturity

ISFocus

AltISAdoptionRate

AltISAdoptionSense

AltISAdoptionEaseAltIsMaturity

AltISFocus

K6

Switch

IS AltIS

ISFocus

ISAdoptionRate

ISAdoptionSenseISAdoptionEase

ISMaturity

14 | P a g e

stakeholders participate in promoting the integration style which influences the IT firms

to adopt the Integration style. Architects in the firm when looking for information on the

integration style consult the independent consultants or white papers , all of them has the

same information which promotes the integration style. This facilitates adoption within

the firm and thus the cycle keeps on going.

A similar reinforcing loop exist for Alternate integration style

3.7 Running the Model

In this model Vensim 5.9 is being used for simulating the model and investigating

various key impact factors. It has been simulated for 20 years starting from year

2000.

3.7.1 Parameter Values

The model has been run with two different scenarios one the current SOA-HTTP-

SOAP style and another Integration As a Service. There are similar set of variables for

each technology scenario. The values for each of these variables are different.

3.7.1.1 Independent Variables There are some independent variables like ISAvailableProducts, ISMaturityAge,

AltISProductsAvailable, AltISMaturityAge, k1, k1 k3, k4, k7. The values for theses

variables and their justification is in the following tables

Variable Equation Values Explanation ISAvailableProducts (∑ Product i × Weightage i

) ÷ n

where i= 1,2,..n

3.06 All technology stack like

Fusion(Oracle),

webSphere(IBM), PI ( SAP),

BizTalk ( Microsoft and host

of other open source ESB

products were considered.

AltISAvailableProducts (∑ Product i × Weightage i

) ÷ n

where i= 1,2,..n

1.2 To calculate the value of the

AltISProducts products

supporting Integration-as-a

service, products from

CastIron10

and few other

firms were considered.

ISShareofIndutryCooperation NA 0.42 ( at pd =1) Industry Cooperation to

promote certain integration

style. Proxy parameter

considered has been search

results in using google search

engine11

. With time the value

changes. Values are

calculated based on this :

(0.42+RAMP(0.2, 1 , 14 ))

AltISShareIndustryCooperation NA 0.29 Similar to

ISShareofIndustryCoperation.

Values are calculated based

15 | P a g e

Variable Equation Values Explanation on this :

(0.42+RAMP(0.2, 1 , 14 )).

ISMaturityAge

Staff Maturity Constant 5 This is a proxy number being

modeled to reflect the staff

maturity

k1 NA 0.17 Market to Innovation

Coefficient. The value of this

variable is taken from the

R&D budget percentage of

TIBCO,12

a popular

Integration product.

k2 NA i = 1,2,…12 Maturity to Innovation

coefficient for existing

Integration style. k7. Initial

Value of this is 2 and for each

unit of time it increases by 1

till it reaches a saturation

point 12 at year 12.

k7 NA i=0.7 (for pd 1-

8,

0.8, 0.9, 1, 1.2,

1.3, =1.4(for pd

15-18)

Maturity to Innovation

coefficient for Alternate

Integration Style.

The values of k7 would be

quite low compared to k2 as

its initial years Alternate

Integration style

k3 NA 1 AdoptionSense To

AdoptionRate Coefficient

k4 NA 1 AltAdoptionSense To

ISDesertionRate

k5 NA 30 Maturity to TechLimitation

Coefficient

k6 10/ISTechLimitation NA Coefficient for

converting Technical

limitation of one integration

style to promote Maturity of

alternative technical style

3.7.1.2 Dependent variables There are the dependent variables which are derived from the independent variables

through various mathematical formulas. The dependent variables along with their

supporting Vensim equations has already been explained in Section 3.5

16 | P a g e

3.7.2 Simulation Run

ISFocus is an indication of activities around certain Integration Style. As proposed in the

beginning of the paper [see Reference Mode of Behavior] that any Integration Style will

follow a curve similar to Product Lifecycle which has been validated through the curve.

ISFocus is a Level variable and its behaviors is controlled by two variables one working

as inflow and other as outflow:

ISFocus

60,000

30,000

0

-30,000

-60,000

0 2 4 6 8 10 12 14 16 18 20

Time (year)

Dm

nl

ISFocus : Current

ISAdoptionRate

20,000

15,000

10,000

5,000

0

0 2 4 6 8 10 12 14 16 18 20

Time (year)

1/y

ear

ISAdoptionRate : Current

ISDesertionRate

40,000

30,000

20,000

10,000

0

0 2 4 6 8 10 12 14 16 18 20

Time (year)

1/y

ear

ISDesertionRate : Current

17 | P a g e

3.7.3 Implications

Some of the variables play more important role as they directly change the behavior

of the system. Out of all the variable the independent variable are key to the

changing the input pattern of the model. The significant variables are mentioned

below:

i. Industry Share of Cooperation: This variable directly controls the

adoption sense for any integration style. The value of this variable

doesn’t change quickly with time. Industry cooperation is a variable

which is influenced by many stakeholders. There are some important

stakeholders who can change the direction of the technology (see note

9).

ii. k6 Switch (Coefficient for converting Technical Limitation of one

integration style to promote alternative Integration Style) :

The trigger to shift form current integration style to another integration

style is the technical limitation of one Integration style. It should be

understood that limitations in one technology paves way for other

technologies. Two integration style has been evaluated in this paper : In

house SOA-HTTP-SOAP style and Integration-As-As Service. Both are

completely different models hence a complete switch from one form to

another form is not expected. Integration As a Service promotes

virtualization of integration efforts. This will mostly happen because of

limitations of in house SOA-HTTP-SOAP style. In spite of much

promise and awareness on this style it still is not as flexible and agile as

business would like an integration development want it to be like. With

virtualization of Integration efforts all non core integration efforts, B2B

integration efforts would clearly get outsourced to this new integration

style.

iii. Lifecycle of Integration Lifecycle:

The model was simulated for 20 years with two Integration style in

focus. Although the lifecycle of Integration may seem to last for 15

years the peak lifecycle for any Integration style is only 5-7 years. This

is also in agreement with the experience by Integration consultants in

the IT firms.

18 | P a g e

3.7.4 Limitations of the Model

a. Industry Cooperation:

Industry Cooperation is a function of many variables

Total Industry cooperation = ISShareofIndutryCooperation +

AltISShareIndustryCooperation + Other Industry efforts.

Increase in share of industry cooperation in alternate Integration style will be

marked by decreased of Industry cooperation of current integration style. This

dynamic behavior of the two variables have not been captured in the model

b. Influence on ISMaturity:

An increased focus on Integration Style ( i.e increase in value of ISFocus)

influences maturity of the Integration style till it reaches a stage where the

limitations cannot be removed anymore and new Integration Style needs to be

adopted. The feedback connection between ISFocus and IS maturity as not been

captured in the simulated model.

c. Multiple Integration Styles:

Although the model has been simulated with two integration style but at any

given point there may be multiple Integration Style option available. Different

kinds of limitation may lead to different kinds of integration. For example

limitation of SOA supporting products frameworks may be heavy investment

which can promote Integration-As-a Service Style of Integration where as

limitation SOAP messages may promote HTTP-REST architectural style. Thus the

Integration Style SOA-SOAP-HTTP is promoting two alternate style of Integration.

This dynamic behavior of various integration styles has not been captured in the

model

3.8 Conclusion In last 35 years Integration efforts has seen wide range of options from RPC,

Webservices to much as sophisticated BPM modeling tools. The technical options for

Integration domain will continue to evolve.

While an Integration lifecycle starting with initial conception may be around 15

years, Integration Style peak lifespan of any integration style is only 5-7 years. Since

change is inevitable firms should be careful to evaluate whether an integration style

available will support the strategic direction of business and hence IT. Firms should also

carefully scan their own integration technology landscape to identify and retire legacy

technology and integration options which pose risk for IT operations. A certain

Integration Style involves investment and commitment for the IT department. But

investment commitment doesn’t guarantee that newer and better Integration styles won’t

evolve. Firms shying away from newer and better technical options may lose opportunity

19 | P a g e

to learn as well as option to leverage IT for significant business productivity. Thus at any

given point of time firms should manage various Integration styles as a portfolio of

options.

20 | P a g e

1 SOA= Service Oriented Architecture

2 Integration as a service: Integration-as-a-service is the ability to deliver a complete integration stack from

the cloud, including interfacing with applications, semantic mediation, flow control, and integration design.

In essence, integration-as-a-service includes most of the features and functions found within traditional EAI

(enterprise application integration) technology but delivered as a service.

Source: Linthicum,David S."Defining Clouds For Enterprise" in Cloud Computing and SOA Convergence

in Your Enterprise: A Step-by-Step Guide

3 Spaghetti Integration: is a process of integration of the systems where each system is interconnected to

each of the remaining subsystems. When observed from the perspective of the subsystem which is being

integrated, the connections are reminiscent of a star, but when the overall diagram of the system is

presented, the connections look like spaghetti, hence the name of this method. The cost varies due to the

interfaces which subsystems are exporting. In a case where the subsystems are exporting heterogeneous or

proprietary interfaces, the integration cost can substantially rise. Time and costs needed to integrate the

systems increase exponentially when adding additional subsystems. From the feature perspective, this

method often seems preferable, due to the extreme flexibility of the reuse of functionality. Source:

http://en.wikipedia.org/wiki/System_integration#Methods_of_integration

4 Gartner Publishes Hype Cycle for emerging technologies every year. For the curious mind here is a the

link to 2009 Hype Cycle 2009. http://www.gartner.com/it/page.jsp?id=1124212

5 SOA can be implemented over many technologies. Others in general refer to other options available.

6 http://www.gartner.com/it/page.jsp?id=728811

7ESB : http://en.wikipedia.org/wiki/Enterprise_service_bus

8 An example of product limitation could be features absent to implement a single-sign-on. For simulation

purpose it has been considered that TechLimitation is inversely proportional to ISMaturity which implies

that more the IS style is matured technical limitation would be less till it reaches a saturation level.

9 It’s a common knowledge that in industry there are various kinds of forces starting from

competing vendors developing products in same platform like Java, to vendors who develops products in

different platforms like .Net and Java. It won’t be a wrong statement to make if we state that firms will

adopt or promote a certain technology or integration style only if it suits their business. For example during

the times of CORBA there were two different competing technologies like CORBA (promoted by OMG)

and Com-DCOM(promoted by Microsoft ) was competing against each other . In the end although the

technology was promising it was dropped.

Another common example is HTTP. Most of the Internet traffic is based on this protocol and its

simple to adopt. Thus there is a virtual cycle around the use of HTTP. This is important as SOA-SOAP-

HTTP-WS* integration style will have major industry cooperation since products will definitely support

HTTP and XML. For example an architectural style (like SOA etc) , Protocol ( like TCP, HTTP etc)

message formats (SOAP which is based on XML) etc. Industry co-operation depends on to what extent

each of these components is supported by the industry vendors. At the time of writing this article there

seems to be wide consensus for this integration style (SOA-HTTP-SOAP-WS*) except for a group which is

favoring adoption of SOA-HTTP-REST integration style

10

www.CastIron.com

21 | P a g e

11

Industry cooperation can often be in terms of blogs, articles, etc. Ideally each of these events are

reflected by creation of webpage. As such a search engine like GOOGLE can easily find in on web. Hence

a proxy parameter has been considered to find out the industry cooperation. Its being assumed that a

Integration style will promote more responses if industry cooperation is high. Google search on following

terms reveals the following :

Term SOA= 37,500,000 results

CORBA= 3,650,000 results.

Thus various terms like Enterprise Application Integration, SOA, CORBA, Integration As a Service,

SOAP-HTTP, SOA –REST were considered. So to calculate the values for an Integration Style following

formula was considered:

[(Search results For SOA Specific terms)÷(Total Search Results For all key terms Related to Integration)]

Values were calculated using the following tables:

Term Results

CORBA 3,650,000

SOA 37,500,000

Enterprise Application Integration 6,460,000

Cloud Computing 28,000,000

Integration-as-a-Service 32,100,000

SOAP HTTP 13,500,000

SOA REST 4,230,000

Cloud integration 7,230,000

Total 121,210,000

Thus for the term ISShareofIndutryCooperation=( SOA Search results+ SOAP HTTP Serach

Results)/ Total Search Results 12

www.tibco.com