Resolving Application Fragmentation Without Soa

SOA is too big and too expensive regardless ofagility in terms of solution is needed. The more
what all the vendors tell you. Is it wise to trustrigid the user interface, the processes, data and
the people who created the original mess withcontent access is the less it will support corporate
fixing it? Isn’t it likely that the typical largeagility. Code a single line in Java for any of the
corporation will end up with a larger mess thanfive integration levels and there goes your
before?so-wished-for agility!
Every IT expert must be aware that developingIt is PARAMOUNT that for all levels of integration
a software product is an expensive proposition.– data, content, backend apps, business
Thus it is understandable that any softwareprocess and user interface – full lifecycle
vendor will have to try and expand the lifetime ofchange management is available. All levels of
a product by selling it under a new name. Theconsolidation/integration need integrated
same is obviously true for an inhouse application.SECURITY as otherwise one cannot open up
So how can we utilize those applications and databetween levels. This is one of the huge issues still
without too much cost and effort? Using a cleverhindering consolidation today! What is needed is
mix of integration, consolidation and federationFULL consolidation and not just interaction that is
does the trick without the need for a fully blownsmugly shown on a dashboard. Any change
SOA project.needed on any level has to be propagated
Business service consolidation integration andautomatically to ALL levels.
federation is a difficult task, and given the dataA business service approach as suggested here
and applications explosion in most organizations, itrequires a powerful data federation technique,
will not get easier if you wait. Large organizationswhich in turn requires a metadata repository to
typically have large amounts of legacy data andprovide the flexibility to define and use multiple
numerous hard-coded processes because theydata sources. A business service can then query
typically buy the so-believed best-of-breedany data source or business application at any
products that create the integration problem. SMBtime. Because of the metadata information,
or small to medium businesses have less legacysynchronized writes are possible when needed,
data and thus focus on integration from abut must be used carefully. Data federation can
business intelligence perspective.be slower in accessing than data consolidation or
Five integration towers are to be considered:propagation but requires the least changes to
metadata, content, applications, business process,current systems and provides the highest
and user interface. Do not forget SECURITY on allflexibility and the most accurate and real-time
levels. There are many offerings for each towerdata access that offsets the possible additional
but it is important to consolidate on all levels ofruntime issue.
enterprise IT and not just on one of them. OnlyBy means of the metadata the business service
then a coherent view of the business can behas access to semantic and model information
given to the user as well as the customer. I calland can merge data from different sources into a
this approach a Business Service Approach orcoherent image for the business user or
BSA. The key problem is that in the sense ofcustomer without the huge overhead of
consolidation ERP, ECM, CRM, and BPM productsconsolidation or propagation. Model information can
are legacy systems and have to be considered asprovide data access paths that the user can
expendable.freely explore given the right authorization.
Integrating on any level lower than the userData federation is also the best approach for
interface and customer service will come back toexisting content from archives or newly created
haunt the IT organization once again. Yes, I knowcontent from the federated data that is
that IBM and others talk about integrating on atransmitted back to the source application. A
business process level, but that it still not enoughsimple process oriented changed-data mechanism
and a huge problem if it involves any Java codingcan ensure that data changes are written back to
at all. Yes, SOA as a concept is good, but it isthe data source with full conflict resolution.
nowhere near enough. Calling some otherTime-stamps and versioning that are common in
approach with business process SOA is justcontent management are here used for data
adding to the confusion.records.
Several vendors now support business processA solution than can perform data consolidation,
and application integration with a single productpropagation and federation from a SINGLE
set, just business intelligence vendors fail tometadata definition is the best choice. A solution
understand that business data only make sensealso has to perform data replication to remote
to anyone from a business process perspective.locations and easily link to the data sources by
A business service approach has to provide usersmeans such as ODBC, JDBC, SQL or messaging
- and/or customers via the web - with aservices such as JMS, MQ-series, SOAP or others.
personalized interface to customer focusedEnforcing the use of SOA Webservices at this
business services using data, content, businesspoint will drive integration cost and time sky-high.
processes, and backend applications. At this pointAs you can see, much of that is not part of the
the user interface also has to supporttypical SOA project, but these are the problems
collaboration via email and other means. Setting upthat have to be and can be solved without SOA
a portal without taking integration to that level willoverhead. These were the consideration that
only highlight the lack of integration and reducewent into the development of the ISIS Papyrus
the possible benefits and thus the return ofProcess and Content Platform.
investment. It is at this point where the most