Swivel-Chair "Application Integration"
Copyright 2006 Robert J. Glushko
Composite applications
The vision vs. reality
Document engineering for composite applications
XFY and Jeteye demos
Create a single interactive user experience by combining multiple business functions or information sources
Reuse the application logic from these existing applications / sources
Do not change the constituent services/sources, which can still function independently in their original contexts
Business strategy perspective - can provide improved and new services to customers by combining customer information, order management, product information, etc.
Business operation perspective - Reduce errors and time for information to flow from one "stovepipe" system or process to another by replacing manual methods of information sharing like re-typing or phone with automated interchange
Technology perspective - reuse of legacy applications extends their useful lives and can be technically easier than reimplementing their functionality in a new application
Business strategy perspective - can focus on core competencies by using services provided by other firms in "plug and play" business models
Business operation perspective - can improve collaboration and information exchange with suppliers and other partners
Technology perspective - composite application platform can exploit "on demand" services and reuse the models and techniques needed to integrate (and interoperate) applications and services
Business Architecture -- Looking at business models and processes in more granular terms so that business functions are visible and reusable
Service Architecture -- Platform-neutral and standard specifications for service interfaces
Document Engineering -- Methods for analyzing and modeling service interfaces and the documents that they produce and consume
Business model and business process patterns and reference models can serve as templates to be instantiated by component services
Example: marketplace is a very abstract composite application pattern
Example: drop shipment pattern is more concrete, consists of 4 core services
Are the component services incorporated as generic or specific ones?
Do we require transparent substitutability?
A "market maker" or "market operator"
Participating businesses
The services these businesses provide to each other
The messages and documents that are exchanged to request and perform the services
Procurement
Order management
Content management
Transaction tracking / support
Payment processing
Sourcing
Shipping
Trade facilitation
Auctions
Supply chain optimization
Credit rating
Escrow
A very common business pattern on the Web
4 roles of retailer (the catalog), distributor (the warehouse), the credit authority (bank), the delivery service
The retailer doesn't own the goods, only takes orders
What are the dependencies among the component services?
Are these dependencies logical/intrinsic or contextual/selective?
Service dependencies determine choreography of transactions and collaborations
Identifying "correlational" or "glue" components needed to interconnect or synchronize services
Harmonizing the semantics of these components
But these components might have different names in different services
Input forms in user interfaces == document assembly models
Business processes are increasingly global and involve widely dispersed parts of an enterprise or multiple enterprises
An "agile," "adaptive," "on demand" [insert other buzzwords here] enterprise needs to be able to quickly and cost-effectively change how it does business and who it does business with (suppliers, business partners, customers)
So ideally, the component services that come together in composite applications can be dynamically discovered and combined from different firms
Do I know what service I'm looking for?
Do I know where to look? Can I find the service I'm looking for?
Is the service compatible from a business perspective?
Is the service technically compatible? (technical interface compatibility)
Can I transform the service inputs or outputs to achieve compatibility?
Does the service meet my quality and performance requirements?
Integration means that one application can extract or obtain information from another one
It doesn't mean that the information will work "as is" in the target application
Transformation of the incoming information is often required before it can make sense to the receiving application
Most services aren't listed in public registries
Service descriptions are often limited to technical interfaces (WSDL), lacking information needed to assess business model and business process compatibility
Emerging platforms for composite applications are limited in the kinds of document interfaces they can handle (e.g., optimized for services operating on relational databases)
Some platform support for reusing integration semantics, but not sufficiently grounded in ontologies or reference models to enable automated mapping and transformation
Electronic Patient Record = Active Document
Unified Patient Information Application = Composite Application
How are they similar?
How do they differ?
Brief review of activities since last report
Any new modeling artifacts
Most helpful / least helpful document engineering concept or technique
Big ideas or lessons learned about your domain
Future plans for the project
10-15 minutes for team projects; 5-10 minutes for solo projects
Written / final artifacts turned in by Friday 5/10