InfoLibrarian™ · Engineering record
How the classic platform actually worked.
The design decisions behind the enterprise metadata software—and why most of them are industry standard now. This is the engineering record, not a support portal. Classic product end of support.
Heritage covers what was released and when. Customer Success covers what it delivered. This page covers the part that is hardest to reconstruct and easiest to lose: how it was built, and why a platform designed in 2005 was solving problems the market would not name for another decade.
The System at a Glance
Four bands: the systems it read, the machinery that read them, the repository that made sense of it, and the surfaces people worked through. Everything below the fold is a closer look at one of these.
The repository is the anchor deliberately: every other band is replaceable, and the model in the middle is what the rest of the platform existed to serve.
Shipped Early, Standard Later
The clearest way to judge an architecture is to check what the industry decided to do afterward. Nearly every foundational choice in the platform is now a default expectation of a modern data catalog or semantic layer.
The Core Idea: a Model of Models
Every competing product of the era shipped a fixed schema — a vendor's opinion of what a table, a report, a policy or a business term is — and asked the customer to bend their world into it. InfoLibrarian inverted that. It shipped a meta-metamodel: a model describing what a model is. Each organization defined its own.
- Object types arranged into hierarchies, with instances organized into taxonomies — an organization modelled its concepts, not a vendor's
- Custom properties on any object type, each bound to a specific editor: free text, masked text, valid-value list, category picker, date, boolean and more
- Controlled vocabularies for the governance layer — stewards, publication status, data-quality metrics, lineage categories
- Domains and domain maps scoping a model to a business area
- Integration rule sets attached to object types and evaluated by the rules engine as metadata was harvested
The hard part, and the good part. A user-defined model is easy to store and very difficult to use — the software cannot know at compile time what a customer's objects look like. InfoLibrarian solved it by emitting properties at runtime: a steward's model definition materialized as live typed properties that the property grids and the rules engine bound to directly. Define an object type in the morning, and by the afternoon stewards had working editors for it, contributors had generated forms, the rules engine could evaluate against it, and adapters could map into it. No release cycle, no schema migration, no vendor ticket.
That single decision is why the platform could serve a media company modelling brands, franchises and media assets and a bank modelling loan systems and regulatory reports — from the same codebase, with no forking.
Harvesting: Automatic by Default
The founding premise was that enterprise documentation is always stale because it is written by hand. So the platform read the systems directly. Adapters connected, walked the source's own catalog, and wrote structured metadata into the repository — scheduled, unattended, and repeatable.
Depth mattered more than logo count. The Oracle adapter alone issued around thirty distinct catalog queries, harvesting tables, columns, views, materialized views, indexes, constraints, triggers, sequences, synonyms, PL/SQL package source and object dependencies — down to details like excluding recycle-bin objects and reading instance sizing. Object dependencies became lineage. Stored procedure source became searchable. This is the level of detail that separates a catalog that lists assets from one that can answer questions about them.
- Generic by design — an OLE DB/ODBC adapter reached any compliant driver, the XML adapter handled XMI and CWM interchange from modelling tools, and the web-service adapter handled any WSDL endpoint. Breadth came from generality rather than from writing a connector per vendor.
- Change detection built in — every harvested object carried a checksum and a snapshot date, so successive scans produced genuine deltas: what was new, what changed, what disappeared. Governance workflows and notifications fired from that signal.
- An SDK, not a closed set — the platform shipped an adapter template and a universal test harness so customers and partners could build and validate their own scanners against the same interfaces the product used. A 2008 .NET extension library opened the framework, portals and custom scanners to any .NET language.
- One scan engine, driven four ways — the engine that ran every adapter was exposed as a command-line utility, so it could run under any third-party scheduler, be driven interactively from the Administrator, or execute unattended as a Windows service. Scanners were registered rather than compiled in, and distributed scanning roles spread the work across machines for large estates.
- Every scan was an auditable object — scan jobs, job history, per-scan logs and purgeable scan history were first-class administrative surfaces, with configurable rescans and manual re-runs. Each completed pass wrote a historical snapshot to the repository, which is what made change detection and point-in-time comparison possible at all.
- Built for unattended operation — command-line scanner, indexer and maintenance tools, because metadata that refreshes only when someone remembers is metadata nobody trusts.
Reached anything compliant — breadth without a connector per vendor
Native where it was faster
Build your own
Five generic adapters covered an unbounded surface, nine native ones covered what deserved a fast path, and the template plus test harness covered everything else. Breadth came from generality, not from a connector per vendor.
The Pipeline, End to End
One engine ran every adapter, and every run took the same path. Triggered from a command line, a scheduler, the Studio or a service, the work was identical — which is why the same pipeline served overnight batch, ad-hoc re-scans and event-driven refresh without three separate code paths.
Lineage and Impact as Graph Traversal
Because relationships were modelled as typed, first-class objects rather than as a bolted-on lineage feature, source and target mappings were simply property types over one uniform structure. That produced a genuine capability difference:
- Lineage in both directions — resolve the full source chain feeding an object, or the full target chain depending on it, from any starting point
- Impact analysis as a query, not a report — ask what breaks if a column changes, and traverse the answer
- Business and technical lineage in one graph — a glossary term and the physical column implementing it were the same kind of thing, linked the same way, so business users could trace meaning down to storage
- Cross-references and mappings between systems modelled explicitly, which is what made migration and integration programs tractable
Search was built to match: keyword, catalog-scoped, and full SQL-predicate modes against the live repository, plus search across point-in-time snapshots. The companion Search Appliance extended the same idea to unstructured content, indexing up to ten million items across files, databases and websites.
Three Surfaces, One Repository
any ANSI-SQL database
model views, snapshots, change history
desktop → server → appliance → Azure image
Semantics in Practice: Business Language Down to Physical Data
The metamodel's real payoff was the semantic layer built on top of it. The recurring enterprise problem was not a
missing catalog — it was that the business and the warehouse spoke different languages. A steward said
"member enrollment"; the warehouse had a column called MBR_ENRL_DT in one of four hundred
Oracle tables. Nobody could reliably get from one to the other.
The platform modelled that gap explicitly, as a connected chain rather than a spreadsheet:
Each hop was a first-class, typed object in the graph — not a comment in a data dictionary. The platform distinguished between an Exact Map (a confirmed one-to-one binding), a Physical Exact Map (term straight through to an Oracle physical column), a Logical Map (term to logical model), and a Matching Map (a candidate relationship proposed by rule rather than asserted by a human).
That last distinction is what made the work tractable at enterprise scale. Auto-mapping rules proposed candidates
by comparing terms against object names, descriptions and comments — catching the synonyms, abbreviations and
local dialects that make warehouse columns unreadable — and scoped comparisons by parent context so
CUSTOMER.STATUS and CLAIM.STATUS were never confused. Stewards then promoted candidates
to confirmed maps. The platform tracked Auto Mapping Metrics as a first-class object type, so a program could
report how much of its glossary was actually bound to physical reality, and where the gaps were.
Stewards did this work visually. The Studio's modeler let them lay out object types, properties and relationships as a connected graph and draw mappings by drag and drop, while the Portal rendered lineage and cross-reference chains as navigable graph visualizations. Modelling the enterprise's semantics looked like modelling a graph — fifteen years before that became the fashionable way to describe it.
Where it was proven
A&E Television Networks — a full media taxonomy modelled as an eleven-level hierarchy, and the case where the architecture was pushed hardest. Metadata from 20 legacy digital asset management systems was canonicalized into one vocabulary, then syndicated to Netflix in real time. The metamodel was the data contract. What the steward defined in the model was what the partner was guaranteed to receive — so the transform ran from A&E’s own model into FIMS for transport, and the contract could be validated against the model rather than argued about in email. Governed semantics as a runtime interface between two companies, not a document describing one.
Blue Cross Blue Shield — vendor data extracts modelled as governed objects carrying Data Domain, Region, Vendor and status properties, bound to their physical sources and joined to operational run metrics, so business owners could see both what an extract meant and whether it had actually run. The modelling tool stayed where the modellers already worked: business subject areas resolved to terms in ERwin, and the ERwin models were harvested straight into the business metamodel.
UnitedHealth Group — healthcare subject areas mapped through business glossaries into the physical entities of large on-premises Oracle warehouses and operational platforms.
BMO Harris — enterprise banking terminology reconciled across business glossaries and logical models down to warehouse implementation, in support of governance and audit obligations.
Fuji Film e-Systems — the same traversal applied to infrastructure rather than business language: deployed web code, UDL files, custom scripts and registry settings scanned alongside the databases and stored procedures they touched, so a change anywhere in the chain could be traced to everything downstream of it. The Search Appliance ran the other half of the job: spiders and crawlers indexing the web farm, the EMC Symmetrix SAN and the databases into a single latent semantic index, so the estate was searchable by concept rather than by filename. Thirty thousand files across a hundred servers, indexed in two days and refreshed nightly — big-data problems, solved before the term existed.
The result in each case was the same capability, and it is the one people still ask for: a business user could start from a word they actually use, and traverse to the exact columns that implement it — or start from a column scheduled to change, and see every business term, report and subject area affected. Impact analysis expressed in business language rather than schema names.
Proof at Scale
The architecture was validated where it is hardest to fake: inside large, messy, regulated enterprises. A&E Television Networks, Sabre Holdings, Blue Cross Blue Shield, UnitedHealth Group, Standard & Poor's, Fidelity Investments, BMO Financial Group (including BMO Harris), Citigroup, Fujifilm, the University of Arizona, the New Zealand Ministry of Education, Western Power and Biometrics.gov all ran it.
"We were able to get about 80% of what we needed done very quickly; in fact the scanning was completely automatic. InfoLibrarian™ is a powerful product. We are very impressed!"
— Enterprise Architecture Sponsor, Standard & Poor's
"Within days of implementing the InfoLibrarian solution, we began reaping the benefits. As a development company with systems and resources encompassing many platforms and disciplines, we needed a solution that would allow us to see our inter-related components and how they impact each other."
— Ryan Mills, Project Manager, Knowledge Management Initiatives, Fuji Film e-Systems
"It's like automatic documentation."
— Georgia McCabe, Senior Vice President and General Manager, Fuji Film e-Systems
The New Zealand Ministry of Education selected the platform after an eighteen-month evaluation against competing vendors, citing the breadth of scanners and the openness of the model as the deciding factors — the two properties this architecture was built to deliver. Full case notes →
Why the Design Still Holds Up
Strip away the deployment technology and the ideas are the ones the industry converged on: model the enterprise's own semantics rather than a vendor's; treat relationships as data; harvest automatically and detect change; make the model programmable and the connectors open; and give business and technical users different views of one shared graph. Those were contrarian positions in 2005. They are table stakes now.
The platform's later constraint was never the model — it was that the model was implemented for a pre-cloud world. The reasoning behind retiring it, and what carried forward into the modernization work, is set out in Escaping the Legacy Trap and the Knowledge Platform Framework.
Engineering record. The classic InfoLibrarian product line reached end of support. Where licences were negotiated as worldwide perpetual they do not expire — end of support is not end of licence. This record is maintained as part of Brian Brewer's portfolio. See Heritage, Knowledge Platform Framework and Customer Success.
