Application Development and Integration: Solutions Converge to the Benefit of Both

Mike Gilpin
May 8, 2002

Giga Position For years Giga has highlighted the convergence of technologies for application development and integration within the context of evolving standards-based application platforms !"t the relationship between development and integration technologies act"ally goes back decades to the very beginning of software development for the first b"siness comp"ters #ltho"gh the appreciation of application integration as a distinct architect"ral discipline is relatively recent compared to that timescale, one can best appreciate the evolving relationship between development and integration technologies and approaches by considering it in the context of this f"ll history, s"ch that application platform convergence takes on added significance $merging standards-based application platforms from IBM, Microsoft, BEA Systems, racle, Sun and others are increasingly positioned to offer a wide range of technologies for both application development and integration, across the f"ll spectr"m of architect"res that evolved over the decades %he ability to satisfy s"ch a wide range of development and integration re&"irements in one context presents a "ni&"e opport"nity to merge the best &"alities of development approaches with sol"tions for application integration, improving the &"ality, repeatability and manageability of application integration %he ready availability of rich application integration facilities to application developers also adds val"e to the development context, likely increasing the proportion of applications, components or services that are b"ilt from the start to fit into an integration architect"re, rather than adding integration later as an aftertho"ght Given the potential benefits arising from scenarios enabled by this convergence, enterprises sho"ld redo"ble efforts to correlate strategies for application development and integration, in the context of both the broader application platform, and between more distinct sol"tions for development and integration #s these sol"tions converge aro"nd the same emerging ind"stry standards s"ch as 'eb (ervices, the opport"nity to obtain the benefits of tighter correlation of application development and integration will contin"e to increase dramatically in the next two years

Proof!"otes From the beginning of application software development there has also been application integration )n earlier times conventional integration was generally performed by developers and fell into two categories*

+ (pecific provisions for integration ,interfaces- b"ilt in when the application was constr"cted 2 )nterfaces and other integration activities ,s"ch as moving data- that take place after the application is constr"cted, often as part of a later pro.ect

%he evol"tion of application integration sol"tions in recent years changed these dynamics in important ways*

#pplication integration evolved into a separate discipline distinct from application development, with commercial off-the-shelf applications often the foc"s of integration more than c"stom applications, altho"gh c"stom application developers still do conventional integration %his distinct integration discipline in t"rn has evolved specific architect"re and tooling approaches that are "ni&"ely well s"ited to rapid integration, especially where application adapters provide a convenient form of adaptation of application interfaces into a standard integration infrastr"ct"re

/et some integration sol"tion architect"res have not kept pace with innovation in the application development domain, add "nd"e management complexity or s"ffer from other flaws

)n response to this and many other technical and ind"stry iss"es and trends ,see )dea!yte, )% %rends 2002, Midyear 0pdate* (oftware )nfrastr"ct"re for #pplication )ntegration and 1eployment, Mike Gilpin-, application infrastr"ct"re has been converging for the last few years toward a different sit"ation, in which there will be s"bstantially two kinds of application integration sol"tions ,which may in some cases "se the same technology "nderneath, b"t be packaged differently beca"se of the intended a"dience-*

+ Development and Integration: application integration sol"tions packaged as part of a comprehensive application platform sol"tion from a ma.or application platform vendor, targeting organi2ations doing a combination of development and integration aro"nd the same or related application domains 2 Integration Only* application integration sol"tions packaged as an independent sol"tion for internal and3or b"siness-to-b"siness ,!2!- integration, targeting organi2ations doing primarily application integration and little or no application development

)nd"stry events contin"e to conform to this model, incl"ding the ac&"isition of "e# Era of "et#or$s by Sy%ase, of Cross&orlds by )!M, of E'tricity by Peregrine, of "etfish by Iona and other likely f"t"re ac&"isitions #ltho"gh a limited n"mber of

independent integration sol"tions will remain, even these are finding it necessary to broaden their sol"tions to s"rvive, and where this has not happened, consolidation m"st inevitably res"lt, as in the ac&"isition of (alarian by (IBC , or Active Soft#are by #e%Methods 4latform sol"tions m"st be provided by larger entities that have the critical mass to s"rvive economic downt"rns and to offer more complete sol"tions that deliver more demonstrable b"siness val"e %he existence of two emerging classes of application integration sol"tions is distinct from the trend toward market and vendor consolidation, altho"gh the trends are related )ndependent integration sol"tions may be offered by ma.or platform vendors, or independent integration vendors, with the latter more foc"sed on serving the a"dience that does little application development F"rthermore, independent sol"tions may be complementary to ma.or application platforms, and sold as add-ons, or may be entirely separate and have no direct relationship to ma.or application platforms, or some middle gro"nd between these two strategies %he analysis below is foc"sed primarily on the first type of sol"tion ,1evelopment and )ntegration- )n considering the benefits of correlating strategy for the development and integration aspects of these sol"tions, it is "sef"l to factor the disc"ssion across the fo"r levels of the typical application architect"re of today, as depicted below, comprised of data asset, b"siness logic, interaction and process integration layers

%echnologies at any of the fo"r layers, or more than one "sed together, can be the right sol"tion for a partic"lar development or integration re&"irement (ome proprietary independent integration sol"tions overly constrain the architect"ral levels at which integration can be done, or they are m"ch better at some levels than others #s integration sol"tions evolve to embrace the same standards that have revol"tioni2ed the application platform, there is an opport"nity to become e&"ally capable at all levels, thro"gh access to a broader "nderlying platform of standards-based technologies across all fo"r layers

#nother key iss"e with dedicated integration sol"tions to date is that they have not, in general, had the benefit of the same richness of total capabilities s"rro"nding the development life cycle for management, deployment and maintenance, nor have the best process or life-cycle management practices that have been refined over decades of application development been e&"ally available for integration #ltho"gh some progress has been made in enriching integration sol"tions and approaches in this regard, they have not made eno"gh progress to tr"ly compete with the more comprehensive application platforms and their development tools #s these platforms merge, common architect"res and practices can be applied to both development and integration 5ne of the reasons we need integration sol"tions today is that, in the past, developers have not paid s"fficient attention to the integration needs of the f"t"re, nor have the tools and environments they "se e&"ipped them to do so easily #nother desirable side effect of the application platform6s evol"tion to incorporate both development and integration capabilities in one environment is that developers will now find it easier, even essential, to develop applications, components and services designed with integration in mind 'hen development and integration are approached holistically by an organi2ation, both development3integration and integration-only scenarios benefit from increased infrastr"ct"re and skills synergy, contrib"ting to a more coherent overall architect"re that will also deliver markedly greater flexibility in the f"t"re #nd the cost savings of b"ying one coordinated infrastr"ct"re sol"tion can be dramatic, often as m"ch as 70 percent

#t the data level, options for data access or integration incl"de*

0sing a shared database with a single data model ens"res data integrity across m"ltiple applications, b"t is hard to achieve "nless all the applications are b"ilt together ,or over time- to that same model %oday this approach is most likely to appear ,and be practical- in s"ites of packaged applications from one vendor !"t as application vendors broaden their portfolios thro"gh a combination of development and ac&"isition, this model often deteriorates to resemble a typical enterprise environment with a wider variety of databases and data models in place

'hen m"ltiple application databases exist, it is often necessary to "se replication or synchroni2ation to maintain consistent data across the enterprise ,and if their data models differ, then well-defined bidirectional transformations are re&"ired- #ltho"gh this option does not re&"ire all applications to agree on one model, it can res"lt in data inconsistencies if s"fficient care is not observed

# more holistic approach that encompasses development and integration for data access, movement and replication3synchroni2ation, has the potential to simplify information systems and red"ce cost For example*

%he metadata that governs the behavior of new applications and integration infrastr"ct"re can be managed as one logical entity ,even if m"ltiple physical metadata stores still exist "nderneath-, making it less likely that inconsistencies in data formats or access statements will inadvertently red"ce data integrity or c"rrency )nvestments in data-oriented middleware sol"tions can be leveraged across both contexts, potentially accelerating payback and increasing the val"e of these investments 1eveloper skills in designing, accessing and managing data reso"rces can be more easily leveraged across a wider range of problems when the tools, technologies and techni&"es "sed are the same or at least more similar across the development and integration contexts $cosystems that grow aro"nd vendors8 technology stacks are more likely to reach critical mass as these stacks converge aro"nd a smaller n"mber of more common technology standards

#dditional options for data access or integration incl"de*

0sing an extract, transform and load ,$%9- prod"ct to create a derived database, which may be a data wareho"se or mart, or an operational data store :ere the key iss"e can be timeliness of the data, as well as the cost of processing large vol"mes of extracted data when only part of the data may ever be "sed !"t for many re&"irements for derived forms of data, this is still the best sol"tion, especially where timing constraints are not an iss"e )t is not "n"s"al even in real-time interactive applications for

some of the data to be on a relatively infre&"ent "pdate cycle ,tax rates, postal codes, etc -, s"ch that maintaining a physically derived view is the most practical sol"tion

0sing a virt"al data-view middleware layer to make it appear that m"ltiple "nderlying database reso"rces are a single logical database :ere the challenge is performance; it is very hard to make this approach perform well, especially when the "nderlying data reso"rces are heterogeneo"s ,limiting the options for distrib"ted &"ery optimi2ation- !"t in some sit"ations the ability of this approach to provide near-real-time access to c"rrent data, and to avoid the potential for inconsistency that comes from d"plication, may be worthwhile if the performance can be made acceptable 5ne example of s"ch an application is the integration of data from emergency services for a <++ ,or <<<- emergency call center, where real-time access to the "nderlying data is essential 'hen the relevant data assets are most easily accessible thro"gh the 1!M(, then a virt"al view can create the appearance of integrated services where none exist, more easily than the alternatives

#ltho"gh either techni&"e is more likely to be considered an integration option, there are many examples in the history of their "se in a development context as well to help solve thorny development problems #ltho"gh one m"st strike a balance between data d"plication and the potential loss of data integrity, sometimes the only practical way to implement a new application f"nction is to place the re&"ired data closer to the point in time and space where it is needed, where &"ality of service iss"es make it impractical to access the data at its so"rce (o even tho"gh some integration architects might advocate a more excl"sive reliance on message passing between systems of record, each of which manages its own "ni&"e and "nd"plicated data, there are many real-world sit"ations that can make s"ch an approach impractical in a bandwidth-constrained and3or highly distrib"ted environment %herefore, data movement or virt"ali2ation will contin"e to form part of the architect"ral landscape for some time to come For g"idance on the strategy behind s"ch decisions, see )dea!yte, 1ata #sset (trategy )s =ritical to G"ide =omplex )ntegration (cenarios, >andy :effner

%here are a variety of mechanisms available for b"siness logic access or integration, which may be "sed directly or indirectly thro"gh an integration server or service-broker that s"pports these mechanisms ,see 4lanning #ss"mption, (ervice !rokers* #n )mportant 5ption for )mplementing (ervice-5riented #rchitect"res, Mike Gilpin- %he key difference here is that integration happens between applications rather than their databases, helping to ens"re that a common set of b"siness r"les is always "sed when

"pdating data thro"gh the ?system of record? for each database %hese techni&"es are also those that come into play when implementing shared services within a m"lti-channel service-oriented architect"re ,for one example of s"ch an architect"re, see 4lanning #ss"mption, Financial #pplication #rchitect"res - $"ropean %rends, @ost :oppermann and Martha !ennett'hether these mechanisms are "sed to integrate components or services when b"ilding a new application, or to integrate existing applications after the fact, the concept of integration as a separate discipline is really ."st another type of factoring, and as with any factoring design decision and its architect"ral implications, it is overly simplistic to s"ggest that ?factored is always better ? :owever, experience s"ggests there are many more sit"ations that ."stify factoring integration o"t of application components than are recogni2ed at the time those components or services are being constr"cted !ased on that wisdom, many organi2ations are now enco"raging the development of more ?integrateable? components and services as applications are constr"cted, and that the architect"re of the applications sho"ld be designed to enhance the ease with which they can be integrated, as scenarios "nanticipated today may arise in the f"t"re %his is especially important as the delivery of new application capabilities today is more often than not the res"lt of not only new development, b"t also integration and assembly of existing c"stom and packaged applications, into a complete sol"tion ?Aew? development pro.ects today are often b"ilding on the fo"ndations of previo"sly b"ilt and bo"ght applications, making integration an even more critical foc"s, as a contin""m with development, not as a distinct and separate discipline

1evelopment or integration thro"gh the interaction layer has two aspects*

+ )nteractions with h"mans, which often involve content aggregation or application access thro"gh portals 2 )nteractions with other applications s"ch as thro"gh a !2! server or 'eb (ervice interface

#s these interactions are considered not as distinct stovepipe applications, b"t as elements of a more cohesive whole, one can see the wisdom of treating the "nderlying application services as a shared layer, which provides consistent answers regardless of which interaction mechanism asks the &"estion ,or as a shared service invoked by other applications or services- %hat is not to s"ggest that all applications will be b"ilt in this manner #ltho"gh this is clearly preferable for today8s ?systematic? applications, there will contin"e to be ?opport"nistic? or ?tactical? applications b"ilt in isolated contexts in which it may not be practical to treat them as a part of this contin""m :owever, as with the general iss"e of development vs integration, the appearance of a tactical nat"re is often misleading, and many tactical sol"tions have s"rvived well beyond their planned lifetime (o again experience s"ggests that the criteria "sed to allow applications to be treated as tactical stovepipes sho"ld be as stringent as organi2ational dynamics allow )n the interaction context, the benefits of a "nified approach to development and integration incl"de*

%he incremental cost to add a new interaction channel as an extension to an existing m"lti-channel service-oriented implementation is often dramatically lower ,by a factor of two or three- than if the new interaction re&"irement has to be satisfied by a stovepipe application, which then wo"ld also introd"ce added complexity in d"plicate data and the need to keep the system state synchroni2ed (ynchroni2ation fre&"encies that were acceptable prior to 'eb-based c"stomer self-service are also no longer acceptable now that c"stomers or other "sers can see in real-time ."st how messed "p one8s internal systems really are @"st as on the other layers, the line between development and integration activities is also bl"rring, with new development pro.ects b"ilding things into a portal that also aggregates existing content and applications )n these scenarios, the convergence of integration capabilities is an essential enabler

#ltho"gh b"siness processes have been implemented inside application code in most past applications, there has been a trend in recent years, even among packaged applications, to factor the details of these processes o"t of the "nderlying transactional applications into a separate layer 'hen this is done, if the layer is associated with special tools that

make it faster to create and change these processes than if they were implemented in a conventional way, it can have a positive impact on the rate at which this aspect of application behavior can be implemented and changed in response to changing b"siness re&"irements 'hen s"ch process-related re&"irements are likely to change often and change significantly, then this added flexibility can be most "sef"l 'hen not, then it may still be better to implement processes in applications, for simplicity in development and maintenance, and to save the cost of a process integration sol"tion %he architect"re of these separate process layers may differ )n some cases, a process model is transformed into metadata that is exec"ted by a r"ntime engine )n others, the model is transformed by a generator into code, which is then made part of the application code base, b"t factored into a separate software layer that can still be more easily changed than if the code were hand written 'ith either approach the architect"ral iss"es are the same, altho"gh the characteristics of the two approaches are &"ite different in their operational nat"re and in the approach "sed to make changes to the process !"t even when a r"ntime engine is employed, it remains important to treat the deployment of new metadata to the r"ntime as an important deployment event that needs to be managed and controlled like the deployment of an application Aot all process integration sol"tions offer s"fficient richness in their deployment management and versioning capabilities to enable this level of control, so in some cases it may be necessary to s"pplement those b"ilt-in capabilities with additional tools or proced"res #s o"r concept of an application grad"ally evolves away from rigidly composed exec"tables at specific network nodes toward more loosely and dynamically composed sets of interactions and services that are more context aware and personali2ed, the importance of a separate layer for b"siness process integration is likely to be elevated still f"rther #nd within the context of s"ch an environment, the vario"s elements that participate in the integrated scenarios will each be bo"ght or b"ilt as appropriate, which will contrib"te still f"rther to the bl"rring of the distinction between development and integration =onvergence of #pplication )ntegration (ol"tions %here are many classes of integration sol"tions available today, incl"ding those for internal integration of front office or back office or both, external ,!2!- integration, or both, as well as integration sol"tions offered by application vendors as a complement to their application s"ites #s disc"ssed above, the market is converging aro"nd more comprehensive sol"tions able to do all these things ,altho"gh perhaps not e&"ally well#ll increasingly hold in common some capability for b"siness process integration, altho"gh the vendors that have led in providing this capability still tend to be the best at s"pporting it #s integration sol"tions based on broad application platforms evolve they will offer integration capabilities across all these domains, b"t implemented on the same "nderlying technologies as development and deployment platforms For those doing both development and integration within a single platform, it sho"ld be m"ch easier to develop ?integrateable? applications, and easier to integrate these with other c"stom or packaged applications %his does not eliminate the need for an integration server, beca"se ."st as a process server factors volatile b"siness process implementation o"t of applications, an integration server factors knowledge of connections and ro"ting and transformations with other applications o"t of an application %his is still ."st as "sef"l when new applications and components "se consistent open standards as it was when applications "sed disparate proprietary comm"nication standards #nd given the fact that older applications that weren6t retrofitted to the new standards will likely live for years or even decades,

the standards translation f"nction of the integration server will also contin"e to be "sef"l for the foreseeable f"t"re @"st as with proprietary integration approaches, for simple cases a separate integration infrastr"ct"re may not be ."stified !"t the good news for those with the more complex sit"ations that do ."stify integration sol"tions is that the trend to more open integration standards will also tend to lower prices and implementation costs for these sol"tions )ndeed, the drive to lower costs is one of the market forces speeding the transition to more open standards-based approaches to integration, altho"gh there are other trends lowering costs ,see )dea!yte, #pplication )ntegration Bendors %"rning to )nd"stry %emplates to >ed"ce 4ro.ect =ost, Cen Bollmer#pplication platform standards have evolved for years, and in each case the standards co"ld be "sed for both development and integration /et there were obstacles to this practice becoming widespread*

4roprietary message-oriented-middleware sol"tions were desirable in their s"pport for m"ltiple lang"ages and platforms, b"t were not as well s"ited to synchrono"s re&"est3reply integration, tended to be complex to "se and manage and were ill s"ited to comm"nication thro"gh firewalls =5>!# ))54 is an effective standard for binary comm"nication across m"ltiple lang"ages and platforms, b"t was not widely adopted for vario"s reasons, incl"ding its complexity and the lack of s"pport from key vendors s"ch as Microsoft )t is also ill s"ited to comm"nication thro"gh firewalls @ava standards, s"ch as @M(, @=# and >M)3))54, are widespread within the @ava comm"nity and widely s"pported by the leading application platforms !"t their immat"rity, and @ava centricity, means their appeal is confined to that domain and that @=# adoption will not take off "ntil after the next ma.or version has been widely implemented, perhaps as late as late 2002 (everal application vendors contacted by Giga indicate commitment to these standards for integration, b"t often with vag"e timing for act"al delivery, or a ?we8ll get to it after 'eb (ervices ? Microsoft8s =5M3=5MD standards ,also not well s"ited to "se thro"gh firewalls- and Bi)(al$standards for adapters are dominant within the Microsoft domain, altho"gh !i2%alk8s is relatively early in its adoption cycle !i2%alk is evolving to increase its complementary val"e-add to 'eb (ervices, and as those improvements are delivered later this year, its adoption sho"ld accelerate 'eb (ervices are immat"re, b"t are destined to be a better integration sol"tion than previo"s standards Aot only are they lang"age and platform ne"tral, they also s"pport both synchrono"s re&"est3reply and asynchrono"s message-based styles of interaction and work well thro"gh firewalls !"t they lack implemented standards for sec"rity and transactions, which will impede broader "se except on sec"re networks or services, except where they are "sed for internal integration

9ooking at one specific ?1evelopment and )ntegration? scenario in greater depth, consider this example from the @ava domain*

#n existing application A offers an adapter3connector that conforms to @=# that enables the connection to r"n in the same context as a new application B that is being constr"cted "sing @2$$ %he applications comm"nicate by means of a message &"e"e provided by @M(, which is b"ndled with the application server environment )n b"ilding the new @2$$ application B, ass"ming an $@! 2 0 implementation is available ,as in the newer prod"cts-, the developer can "se a Message 1riven !ean to constr"ct an event handler for the incoming messages from application A A might be an e-commerce front-end, whereas B might be the transaction handler that f"lfills re&"ests made by c"stomers in application A

%his scenario is one of those considered by the a"thors of the @=# and $@! 2 0 specifications, so it ill"strates the degree to which standards like @2$$ are evolving to enable development and integration to be considered together as one integrated discipline, rather than distinct separate activities Aote that the two can still be carried on by different teams, b"t the skills developed in each domain are more transferable, and the res"lting application scenario and its r"ntime infrastr"ct"re are likely to be less complex and costly to implement and manage when this level of consistency of standards and architect"re exists between the development and integration domains %his scenario does not r"le o"t "se of an integration server, which might come from the same vendor as the application server, or a different one %he &"estion of whether ro"ting and transformation of messages and other application-to-application comm"nications, management of b"siness processes and frameworks for the operation of adapters and connectors will be needed is really separate from the &"estion of what standards are "sed to implement those capabilities )t8s ."st that "sing the same standards makes them easier to "se together, and this will be tr"e for 'eb (ervices, too )mpact of 1evelopment and )ntegration 4latform =onvergence %hese are f"rther benefits that can accr"e when consistent standards-based technologies are "sed for both development and integration*

'hereas integration tools are historically separate from integrated application development environments, converging integration tools into the same environments will make it m"ch easier for those doing both development and integration to cond"ct those activities within a single coherently managed life cycle, prod"cing a more coherently managed set of deliverables %his is happening rapidly across the tools from most of the ma.or platform vendors, incl"ding )!M, Microsoft, !$# (ystems, 5racle, ("n, (ybase and )ona %he technologies and marketing programs designed to enco"rage this for Microsoft8s Bis"al (t"dio A$%, $clipse 5rg and Aet!eans are also indicative of the desire on the part of vendors of tools for both development and integration to red"ce their costs by eliminating d"plication of tooling infrastr"ct"re, while at the same time broadening the si2e of the developer and integrator markets to which they have access $ven where integration tools still need to be delivered in a form that enables their "se by a primarily integration-foc"sed a"dience ,an integration ?perspective? to "se $clipse terminology-, it is still beneficial to both the vendor and the c"stomer for this convergence of tools environments to occ"r %he vendor still gets thecost red"ction and the c"stomer will find it easier to integrate and manage the work prod"cts from developers in one area and integrators in another, if they are working in a consistent tooling environment with a common infrastr"ct"re for life-cycle and deliverable management )mplementation and s"pport of consistent standards for development and integration environments across an organi2ation will also tend to lower the cost of this s"pport, compared to maintaining m"ltiple distinct and potentially competing stacks of infrastr"ct"re %he realities of corporate politics will limit the degree to which s"ch rationali2ation can act"ally occ"r, b"t the convergence in the sol"tions domain means that the opport"nity for f"rther rationali2ation is at least theoretically available to those who can make it happen )ntegration patterns? can now emerge to leverage development best practices, as well as the tooling for defining and prom"lgating s"ch patterns that are now being made available in the development context #nd as these patterns evolve, one sho"ld also expect to see patterns aimed at those doing a combination of development and integration, taking into acco"nt the availability of integration capabilities in the application platform and tools

(imilarly, there are a n"mber of advantages to application )(Bs from the trend toward "sing the same standards for development or integration, altho"gh in the case of )(Bs it8s important to recogni2e they likely won8t rewrite their packages ."st beca"se there8s a

new standard available :owever, the advantage of standards for integration connectors and adapters will enco"rage their development, which will "ltimately benefit these )(Bs8 c"stomers as well, once those connectors3adapters have had a chance to mat"re %he advantages incl"de*

#pplication vendors are less likely to s"pport any individ"al proprietary integration technology stack, beca"se any one acco"nts for only a relatively small percentage of their market #s integration stacks embrace standards-based integration technologies, and especially standards that eliminate the need for application vendors to create integration-vendor-specific adapters, the application vendors will grad"ally see a m"ch more compelling b"siness case for b"ilding these standards-based adapters or connectors !"ilding s"ch an adapter or connector will give access to a m"ch larger proportion of the vendor8s market in the f"t"re as these standards become increasingly prevalent Giga has indeed observed application vendor behavior conforming to this trend ,see )dea!yte, $merging (tandards-!ased #pplication )ntegration %echnologies Gaining Moment"m, Mike Gilpin5ne trend Giga has seen since the time when the above-mentioned )dea!yte was written is for application vendor s"pport for 'eb (ervices to obtain a higher level of acceptance than for the @ava =onnector #rchitect"re Given that all the @ava platform vendors have embraced 'eb (ervices anyway, it8s not hard to see why, beca"se a vendor can gain access to both the Microsoft and @2$$ worlds with one connection 5f co"rse, 'eb (ervices and @ava =onnectors are not really directly comparable, b"t nonetheless there is an apparent affect on vendors8 attention span, with 'eb (ervices getting a higher priority, even for those vendors that plan to do both !i2%alk adapter s"pport is also growing significantly, with a similar affect within the Microsoft platform domain %he same market dynamics are acting here to motivate application vendors, for access to a larger market, especially in categories where the Microsoft platform is more dominant :owever, it is important to recogni2e that standards-based connectors are still relatively immat"re and "nproven and don8t solve all problems that one may enco"nter %he existing libraries of proprietary adapters3connectors have far more experience represented in their implementations and in general are m"ch richer in their level of application s"pport #lso, the standard-based connectors are generally available, if at all, for only the newest versions of vendors8 applications, so for the many companies still r"nning older versions of those applications, it will be necessary to either "se a proprietary connector or wait "ntil after the newer version of the application has been rolled o"t to start "sing the new standards-based connectors

1evelopment and )ntegration 1esign G"idelines =omponents and services intended to enable integration with other applications, as well as within the application for which they were originally constr"cted, m"st of co"rse take integration-related re&"irements into acco"nt when they are being designed %his can be challenging when f"t"re re&"irements for integration are not entirely known, so some degree of over-engineering may be necessary to b"ild in the flexibility to handle those possible f"t"re re&"irements %his is more likely to occ"r when the components3services are being b"ilt as part of a strategic3systematic application, designed top down with integration in mind 5ne may also find re"sable components3services after the fact emerging from pro.ects that didn8t conscio"sly choose to design them for integration %his can be more challenging and re&"ire additional work to be done to get those components3services into a proper state for integration %his is a type of re"se, except that it is more general than ."st component re"se, and may entail code re"se or other forms where an explicit interface to the component or service does not already exist $specially for services, b"t even possibly for components, their ?integrateable? nat"re is highly dependent on having a good interface that is well doc"mented For ?fo"nd? components3services it may be necessary to retrofit s"ch a ?designed? interface, and will also be necessary to designate

a responsible party for maintenance3s"pport, to place these re"sable assets in a managed life cycle with release management Aote that the decision as to whether to factor integration behavior into a separate layer is distinct from the choice as to whether to implement a bo"ght or b"ilt sol"tion for that p"rpose )n some performance-critical or highly c"stom environments, the benefits of integration discipline can be provided thro"gh an implementation of shared integration services implemented on the application platform %he trend to b"ilding applications in this way will move the concept of an application away from being a specific exec"table on a specific node to being looser collections of services that are orchestrated together more dynamically to s"pport a more flexible b"siness process, altho"gh this transition will take many years to be f"lly reali2ed in most organi2ations

Alternative *ie# %he next most likely scenario after the one depicted above is that convergence will still occ"r ,that is a given-, b"t that the differences in implementations of the standardsbased technologies like 'eb (ervices by different platform vendors will differ to s"ch a degree that interoperability will not be achieved, bl"nting some of the positive impact %his wo"ld act as a brake to the implementation of integrated scenarios across different organi2ations that rely on different software platforms and decrease the synergy that wo"ld otherwise res"lt from integration vendors embracing these same ind"stry standards )t wo"ld also dramatically red"ce the si2e of the market available to application vendors from b"ilding interfaces or adapters to enable their applications to connect into this standards-based integration fabric, necessitating the choice of one or two ma.or platform partners with which to ens"re interoperability #ltho"gh this might drive a larger percentage of platform b"siness to one or two ma.or players, it wo"ld red"ce the si2e of the overall pie so m"ch that the end res"lt wo"ld probably be less b"siness even for the winning ?gorillas? than if tr"e interoperability is achieved #nd c"stomers wo"ld be the biggest losers from s"ch a scenario, since there wo"ld be far fewer options, dramatically less available connectivity and higher costs beca"se of less efficient markets

+indings #s a res"lt of the convergence of vario"s kinds of application development and integration technologies aro"nd the application platform, the markets for application integration sol"tions will evolve to be comprised primarily of two main types of sol"tions* those that primarily aim to provide a combined sol"tion for development and integration on a standards-based application platform and those that primarily aim to provide an application integration sol"tion for those doing mostly application integration and little development 1istinct from this trend there will also be contin"ed vendor consolidation, and within each category of integration sol"tion there will tend to be only larger vendors that offer broader sol"tions that have greater b"siness val"e than ."st providing middleware connectivity, or else smaller specialist vendors that orbit within the val"e-add ecosystem of ma.or infrastr"ct"re or application vendors #pplication integration technologies from all fo"r layers of application architect"re, namely data, b"siness logic, interactions and b"siness process, are potentially applicable to vario"s aspects of application integration %he availability of widely "sed standardsbased technologies from all fo"r layers for application integration will serve to reinforce

the trend of enabling both development and integration to be s"pported from the same platform sol"tion (ignificant benefits will res"lt for those wishing to do both development and integration "sing one comprehensive sol"tion, incl"ding rationali2ation of critical metadata, broader skills leverage, access to larger ecosystems of related prod"cts, easier addition of integration capabilities to applications as they are being b"ilt, lower incremental costs from adding new interaction channels when those are implemented within a coherent m"lti-channel platform architect"re, and easier s"pport for development of the looser more flexible ?applications? that are really ."st dynamic compositions of interactions and services to serve a b"siness p"rpose in a specific context F"rther simplification and cost red"ction will occ"r for both vendors and c"stomers as a res"lt of the convergence of tools for development and integration into frameworks from several ma.or vendors that will accommodate a variety of tools for different p"rposes in one environment %he emerging capability of s"ch development environments to foc"s the "se of s"ch tools according to m"ltiple ?perspectives? will be partic"larly "sef"l in helping this to come abo"t #pplication vendors will experience increasingly powerf"l incentives to embrace these same emerging standards for application integration, s"ch as 'eb (ervices, and indeed are already showing signs that they see these incentives and are responding to them =omponents and services can become more re"sable as a res"lt of being implemented in a context that enables richer combined development and integration scenarios %hey will emerge from both top-down ,intentional- and bottom-"p ,fo"nd- so"rces, b"t in either case will still need to be made part of a release-managed set of re"sable assets if they are to deliver the f"ll benefits of re"se over a long period #ltho"gh many organi2ations contin"e to express fr"stration that re"se is an el"sive goal ,and indeed may have given "p on achieving it-, it is nonetheless the case that merging development and integration capabilities into a common platform and tools will increase the likelihood that re"se can occ"r, witho"t removing any of the other obstacles to its reali2ation, s"ch as organi2ational dynamics

,ecommendations For organi2ations looking to do a combination of application development and integration*

=orrelate and converge the relevant development and integration standards s"ch as those disc"ssed above, wherever feasible %he responsibility for this control sho"ld reside with centrali2ed and3or distrib"ted architect"ral review teams in connection with their charter to manage down to an acceptable n"mber of standards, balancing the need for diversity with the cost of a more diverse infrastr"ct"re =onsider application development standards when selecting application integration sol"tions %his is not necessarily a ?drop dead? re&"irement, b"t to the extent that the benefits above are desired, it sho"ld be given priority =onsider application integration standards when selecting application development sol"tions )nc"mbent standards for message-oriented middleware and other integration technologies are probably already taken into acco"nt in this way, b"t now this consideration sho"ld be extended to any prevailing standards anywhere in the integration stack, incl"ding adapters3connectors, ro"ting and transformation approaches, and b"siness process integration 9earn from the lessons of past application development experiences and implement development best practices for integration where possible %reat integration deliverables as worthy of life-cycle and release management, in a coordinated fashion with the same management disciplines for development deliverables

9ook for and prom"lgate common design and architect"re patterns that "nify development and integration, where appropriate )n partic"lar, foc"s on the intersection points most likely to occ"r in the most common development-and-integration scenarios in yo"r organi2ation, s"ch as in portals, channel integration, back-office transactional application access and so on, as appropriate to yo"r specific context 4lan on the basis that the platform convergence scenarios described above will play o"t mostly d"ring the next two years, based on the expected time frame d"ring which 'eb (ervices and other relevant standards become mainstream and are s"fficiently complete technically to deliver the expected benefits across the whole stack