Integration - Data Tier
Copyright 2006 Robert J. Glushko
Creating an information model is a significant investment in capturing context-specific (or application-specific) requirements in a technology-neutral and robust way
The abstraction in a good model makes it simpler and easier to work with than the specific technologies of implementation
A Model-Based Application explicitly uses a model as a specification for generating code or configuring an application
I can't imagine why you'd design and implement an application without making the information and process models "first class citizens" but...
Why did they call it "spaghetti" code?
There is little separation of information models and the code that handles them in most scripting languages
Many programs "flatten" and "deconstruct" a hierarchical document model into a set of "attribute-value" pairs
The iterative, heuristic, and non-deterministic techniques by which most people design user interfaces don't emphasize the information and process models
Easier to understand the software architecture
Generated code is of higher quality than hand-crafted code
Easier to maintain (regeneration when model changes)
A software platform solves some class of generic problems so that application developers can focus on the context-specific parts
Operating systems, programming languages and their runtime libraries, databases, software frameworks, and web browsers are platforms...
But ideally, the context-specific parts of the application that are based on the model(s) remain distinct and inspectable apart from the generic functionality provided by the platform
In this case, the platform interprets the model to determine how the software behaves -- the model configures or customizes the platform
MRP was the big business buzzword in the 1980s
MRP systems plan production, procurement, and distribution for an enterprise and you can view them as embodying a generic model of a manufacturing enterprise that is configured for a specific firm
For each of the products a company manufactures there is a "recipe" or "parts list" or "bill of materials" that lists the parts or components that go into it (and how many of each).
BILL OF MATERIALS X SALES FORCAST = PARTS WE NEED INVENTORY ON HAND = PARTS WE ALREADY HAVE PARTS WE NEED - PARTS WE ALREADY HAVE = PARTS "SHOPPING LIST"
"Shopping lists" for each production cycle were typically sent to suppliers using EDI
ERP was the big business buzzword in the early 1990s
ERP is a natural evolution of MRP that connects it to other key functions of an enterprise -- it is the information "backbone" or "nervous system" of a big firm
ERP interconnects internal systems for manufacturing control, production planning, inventory, and procurement (scope of MRP) with accounting, finance, and personnel
You can view ERP as extending the generic model of a manufacturing enterprise in MRP to handle a wider set of processes and information components (especially the HR ones that involve hiring and staffing)
But implementing ERP is hard and many ERP implementations fail (completely or partly)
Some implementation difficulty is architectural; prior to integration data models are likely to differ between applications and will need to be harmonized or mapped ("Customer" is different for sales and accounting)
Other problems have organizational causes
Some problems are caused by vendors and consultants
When you consider how to integrate two applications, you can think in terms of software architectural tiers as the integration points -- if there are N software tiers, you have potentially N x N possible integration approaches
But in practice, you'll never see most of the possible N x N combinations because some of them work a lot better than others and have thus become patterns that are repeatedly reused
The "old" way to integrate two applications within an enterprise (or the same application between two companies) was to write a custom program that fit only between the two of them
This method has traditionally been called A2A (Application to Application) integration
The technical approach is usually file transfer or remote procedure call mechanisms; in the latter, the calling or receiving program basically stops and waits for the called application to return the desired information
When everything works, A2A integration enables a tightly-coupled and real-time connection between applications
But the low-level granularity of APIs means this isn't model-based
In contrast to traditional A2A integration, where neither application interface is visible outside the company, B2B integration is concerned with automating the exchange of information between enterprises
Loose coupling is a fundamental design principle for the Web, and today almost all B2B integration software uses Internet and Web standards with XML documents as the message format and provides "bridges" to and from legacy formats
Much B2B integration software has moved to a "hub" or "bus" architecture to replace point-to-point A2A integration with a more scalable approach
It is the sender's responsibility to transform the message (the envelope and its contents) into the model needed by the receiver
Modern connector software may include predefined data translation solutions (adaptors) for common ERP systems, enterprise databases and enterprise messaging software
The receiving application accepts whatever message the sender wants to produce and does the transformation. This is the "be liberal in what you accept" strategy.
This strategy captures existing "transaction flows" by making it easy for legacy systems to join the marketplace or network (for example, by letting EDI-capable suppliers send EDI messages that the market operator transforms into the required XML ones
The transformation can be carried out by a third-party service provider - a transformation intermediary.
This is often the most efficient architecture if there is a "hub" or "interoperability" message format (such as xCBL or UBL) because it minimizes the number of transformations that will be required
XML's growing importance in the last few years is both a cause and effect of significant changes in architectural thinking for the Web and applications
Because XML is platform and programming-language neutral, it naturally fits in contexts involving cross-application or cross-platform information exchange
But XML has steadily moved from the "edges" of applications toward their core
The idea of "document" has significantly expanded while becoming more unified around XML
Business information in databases and other enterprise applications can now be externalized as XML documents, giving a common view to content aggregation, management and distribution
Database platforms already provided good support for applications using traditional field-oriented structures, but XML substantially enhances the ability of applications to handle semi-structured or mixed content information model
The XML documents (whether transactional or more narrative in type) used by the application are composed in "building block" fashion from reusable semantic components
This component architecture facilitates the reuse of information between documents and the integration of the applications that produce and consume them
XML's value as both a source and target format means that it is often produced by converting non-XML information; and XML documents are often transformed to meet the requirements of other contexts, programs, or devices.
The idea of "document type" has inspired a programming paradigm is emerging in which XML schemas, programming language classes, database schemas, and UML models can be treated as equivalent
XML schemas are increasingly being used to generate or configure application code, especially for user interfaces
User interface design started as a distinct activity in the 1980s, and has been dominated by iterative and heuristic techniques ever since
In the 1990s the goal of model-based UIs emerged with the hope that automatic generation of window and menu layouts from information already present in the application data model can relieve the application designer of unnecessary work while providing an opportunity to automatically apply style rules to the interface design
Some people starting calling this the search for the Big Red Button, and in many cases it involved user interface modeling languages (expressed in XML) from which UI code would be generated
An alternative to the search for the BRB is the goal of partial automation for user interface generation:
Tools that generate prototype from specifications
Tools that synthesize use cases into sequence diagrams
Tools that merge sequence diagrams to hide states that have no UI implications
Tools that generate UI skeletons or scaffolds while enforcing layout constraints
Tools that generate a family of UIs via "graceful degradation"
UI Design Patterns
Team members: Tim Dennis, David Hong, Mano Marks, Kelly Snow
Welcome Kelly Snow
