Resolving Application Fragmentation Without Soa

SOA is too big and too expensive regardless of whatin terms of solution is needed. The more rigid the
all the vendors tell you. Is it wise to trust the peopleuser interface, the processes, data and content
who created the original mess with fixing it? Isn't itaccess is the less it will support corporate agility.
likely that the typical large corporation will end upCode a single line in Java for any of the five
with a larger mess than before?integration levels and there goes your so-wished-for
Every IT expert must be aware that developing aagility!
software product is an expensive proposition. Thus itIt is PARAMOUNT that for all levels of integration -
is understandable that any software vendor will havedata, content, backend apps, business process and
to try and expand the lifetime of a product by sellinguser interface - full lifecycle change management is
it under a new name. The same is obviously true foravailable. All levels of consolidation/integration need
an inhouse application.integrated SECURITY as otherwise one cannot open
So how can we utilize those applications and dataup between levels. This is one of the huge issues still
without too much cost and effort? Using a cleverhindering consolidation today! What is needed is FULL
mix of integration, consolidation and federation doesconsolidation and not just interaction that is smugly
the trick without the need for a fully blown SOAshown on a dashboard. Any change needed on any
project.level has to be propagated automatically to ALL
Business service consolidation integration andlevels.
federation is a difficult task, and given the data andA business service approach as suggested here
applications explosion in most organizations, it will notrequires a powerful data federation technique, which
get easier if you wait. Large organizations typicallyin turn requires a metadata repository to provide the
have large amounts of legacy data and numerousflexibility to define and use multiple data sources. A
hard-coded processes because they typically buy thebusiness service can then query any data source or
so-believed best-of-breed products that create thebusiness application at any time. Because of the
integration problem. SMB or small to mediummetadata information, synchronized writes are
businesses have less legacy data and thus focus onpossible when needed, but must be used carefully.
integration from a business intelligence perspective.Data federation can be slower in accessing than data
Five integration towers are to be considered:consolidation or propagation but requires the least
metadata, content, applications, business process, andchanges to current systems and provides the highest
user interface. Do not forget SECURITY on all levels.flexibility and the most accurate and real-time data
There are many offerings for each tower but it isaccess that offsets the possible additional runtime
important to consolidate on all levels of enterprise ITissue.
and not just on one of them. Only then a coherentBy means of the metadata the business service has
view of the business can be given to the user as wellaccess to semantic and model information and can
as the customer. I call this approach a Businessmerge data from different sources into a coherent
Service Approach or BSA. The key problem is that inimage for the business user or customer without the
the sense of consolidation ERP, ECM, CRM, and BPMhuge overhead of consolidation or propagation. Model
products are legacy systems and have to beinformation can provide data access paths that the
considered as expendable.user can freely explore given the right authorization.
Integrating on any level lower than the user interfaceData federation is also the best approach for existing
and customer service will come back to haunt the ITcontent from archives or newly created content
organization once again. Yes, I know that IBM andfrom the federated data that is transmitted back to
others talk about integrating on a business processthe source application. A simple process oriented
level, but that it still not enough and a huge problemchanged-data mechanism can ensure that data
if it involves any Java coding at all. Yes, SOA as achanges are written back to the data source with full
concept is good, but it is nowhere near enough.conflict resolution. Time-stamps and versioning that
Calling some other approach with business processare common in content management are here used
SOA is just adding to the confusion.for data records.
Several vendors now support business process andA solution than can perform data consolidation,
application integration with a single product set, justpropagation and federation from a SINGLE metadata
business intelligence vendors fail to understand thatdefinition is the best choice. A solution also has to
business data only make sense to anyone from aperform data replication to remote locations and
business process perspective.easily link to the data sources by means such as
A business service approach has to provide users -ODBC, JDBC, SQL or messaging services such as
and/or customers via the web - with a personalizedJMS, MQ-series, SOAP or others. Enforcing the use of
interface to customer focused business servicesSOA Webservices at this point will drive integration
using data, content, business processes, and backendcost and time sky-high.
applications. At this point the user interface also hasAs you can see, much of that is not part of the
to support collaboration via email and other means.typical SOA project, but these are the problems that
Setting up a portal without taking integration to thathave to be and can be solved without SOA
level will only highlight the lack of integration andoverhead. These were the consideration that went
reduce the possible benefits and thus the return ofinto the development of the ISIS Papyrus Process
investment. It is at this point where the most agilityand Content Platform.