Do It Framework
Do It FrameworkThe DOIT (Document Oriented Information Technology) framework is a strategy for information processing that could ease the development, increase the capabilities, and improve the value of commercial information systems. DOIT is described as an information system (not application) framework, since it presents a unified interface that combines information from diverse functional areas and eliminates conventional application boundaries.
I describe it as a strategy -- it is not something that exists or is being built. Some of the ideas showed up in a Mac HyperCard application developed for a client some ten years ago, but I've never had the resources or skill to carry it beyond that demonstration project.
(The DoItFramework is not to be confused with FirstUnionNationalBank's Distributed Object Integration Team (DoIt) who got the Wiki name first, and would probably consider any implied association a huge embarrassment.)
The following is a very gross level overview. -- JimRussell
Introduction
This overview suggests an alternate approach to providing information services, in the context of typical enterprise record-oriented business systems. I call it "document-oriented information technology", or DOIT for short. The following gives an overview of the underlying metaphor as seen by users, but does not discuss the implementation strategy nor architecture. It should suggest (but does not describe specifically) how the proposed technology would greatly improve the availability, accuracy, and usability of enterprise data. A goal is to eliminate application boundaries (and applications as we know them). A key benefit is an ultimate reduction of information system development effort, and an increase in development effort reuse. The reuse advantages are due to two important characteristics:
DOIT is an enterprise information system framework that simulates a manual approach to maintaining, organizing, and analyzing business data. The underlying metaphor is that of one or more worktables upon which business forms are arranged and organized. The contents of the worktables are selected to support various business tasks. Each worktable organizes all information that might be required in support of its related tasks.
Each worktable is populated with forms that typically correspond a some real-world collection of "things" (entities, or objects) of interest to the enterprise. Examples of the "thing" collections that are suitable for worktable presentation are facilities, personnel, assets, equipment, companies, customers, etc.
The forms range from simple index cards to source documents (purchase requisitions and orders, invoices received), output documents (checks, receipts, W2 forms) and related data records. Each form has a home (the department or organization with the responsibility and authority to maintain the data) but unlimited copies are available to populate any variety of worktables in any location.
Forms on the worktable are arranged in rows and columns forming a grid. Each row of forms (from the top to the bottom end of the work surface) relates to an individual item of the collection. Typically, the leftmost form in the row defines the thing that is the topic of all the forms in the row. The forms in the remaining columns may also correspond to the topic item, or may represent some items from other collections which are related to the topic item.
For example, a personnel worktable might present forms arranged such that each row of forms relates to an individual employee. The leftmost form in a personnel worktable might be an employee's business card to identify the specific individual that is the topic of remaining forms in the row.
The other forms provided in each employee's topic row are defined to support a particular business task. Staffing and organizational review tasks might be supported by a worktable with columns defining department (a department summary index card), supervisor and staff (populated with the supervisor's business card and a stack of business cards for the staff.) Other columns might contain, for each employee, their original employment application, skills inventory, annual review forms, promotion notices, etc.
A personal worktable to support payroll activities might include stacks of pay checks, time cards, salary action request forms, previous and current W2's and W4's. An asset worktable might present, for each asset topic (rows identified with an asset tag and description card) the original requisition, PO, invoice, AP check, maintenance schedule forms, warranty definition, service contracts, etc.
In addition to the relationships implied by the placement of forms in a topic row, relationships can be expressed by attaching (paper clip or staple) supporting forms to a parent form. For example, pay stub forms may have one or more corresponding time cards attached; a purchase order form may be supported by an attached salesman's business card, the supplier's address rolodex card, the related invoices and payments. The attachments can nest to any level; an attached document can have it's own attached supporting documents, and so on.
Imagine, as a user, that you could chose from worktables to support any task. You would have complete access, for any topic item, to all (authorized) related and supporting information. You have all relevant and current enterprise data at your fingertips, and you have control over the content and presentation.
You request changes to the topic content (show all rows, remove if..., add if..., sort by...) to refine the order and content of items to present. You glance up or down to inspect neighboring items to detect data patterns or anomalies. You glance right and left to see related documents. You thumb through a stack of forms to see all the subordinate items related to each topic item. You flip to attached documents to inspect supporting documents and detail information.
You can rearrange, add, or remove form columns or attachments to suit your particular needs. You can name and save the selection and presentation criteria for your future use. You can ask for summary spreadsheets to condense the worktable data (one row per topic row), or to provide an index or summary of a stack of forms in a particular worktable cell.
The developers no longer build ad-hoc, stove-pipe applications. You and the developers specify information requirements by defining new topic items and forms. You then define how to infer the relationship of the new items to existing items. Where useful, you add the new form, as a column or attachment, to both new and existing work table definitions. Plus, when defining a new worktable presentation, you may include any existing associated items and forms previously prepared in support of other business functions.
Some forms and form fields serve only to display data relating the one or more topic items. Others serve as surrogates for one topic item, and as those forms are created, updated, moved, or deleted, an associated topic item (behind the scenes) receives the same treatment. Some forms can capture and preserve a snapshot of their field contents, for example to preserve a form revision history when a new active or proposed revision of the form is created. (This can implement draft and approval cycles, as a means of updating the topic item values once proposed changes are reviewed and approved.)
Support for versioning is one example of generic services available to all forms. Other services might allow forms to have an attached change log to record users and timestamps of revisions. Forms may include procedural definitions to raise and react to events and manipulate related forms. Forms can collect freeform notes and comments. Of course, the selection, presentation, data entry, and maintenance capabilities are all also non-problem domain specific, and are reused by all forms created for all business functions.
Importantly, while unlimited copies of a form may appear in multiple topic item rows and columns, on many worktables, and presented to many individual users, all copies are updated immediately and simultaneously to ensure that only up-to-date data is displayed.
My own biased list of typical IS application problems, and DOIT solutions realized by providing a framework that eliminates the concept of applications is in DoItSolutions. -- JimRussell
Comments, critiques, suggestions, and feedback are solicited and appreciated.
It sounds interesting, but I think your SystemMetaphor may be a little out of date. These days even technically illiterate people are relatively cognizant of somewhat less paper-oriented structures.
I do like the SeparationOfConcerns between domain neutral and domain specific aspects, however I doubt that it's all that unique: most of the major database vendors would claim that their products meet that definition. -- LarryPrice
"...SystemMetaphor may be a little out of date." OK, even a lot out of date (although what ever happened to the paperless office?). But the form concept provides a generic information system element for which abilities and services can be defined and implemented independently of, and useful for all "application" requirements.
Further, compare a "form" to a typical GUI frame or screen. The GUI is a prisoner of its enclosing application; the form is available to any problem context. Creating (New) or deleting a form can represent the creation or deletion of the underlying business object, the GUI typically doesn't represent the object, it is only a control panel, between the user and the system, which might have item selection and add/delete buttons to indirectly invoke an add/delete capability. The GUI can't be copied and attached to an email, or even (too often) printed. A GUI only provides an interface with a workstation operator; forms, in addition to the interface function, can be made to emulate the paper analog - versions preserved and retained for revision history, copied, printed, distributed, etc.
And the bad news is that (too often) the services offered by the GUI are implemented as part of the development effort for the application being built.
"...most of the major database vendors would claim that their products meet that definition."
Right, databases are a great example of problem-domain-neutral technologies. Before their availability (excluding some earlier predecessors, like Total, IMS, CODASYL) the application development tasks had to include designing and implementing access methods, retrieval strategies, indexes, links, etc. Today, application developers can assume the availability of those capabilities, while DM/DBA technical specialists can concentrate on their core technology without becoming experts in the problem domain.
The DoItFramework is an attempt to emulate the encapsulation of databases as generic tools, and provide many more of the non-problem-specific application requirements via interfaces to an existing foundation.
See LittleDatabase for an example of the above pattern ConsideredHarmful. "File" might be a better example of a problem-domain-neutral technology. I would even go so far as to consider whether a detailed enquiry might show that files, and filesystems, were a SilverBullet under Brooks' definition (in NoSilverBullet). I sense an insight there that has gone over my head. "Files" have been around since we stopped collecting our records in decks and keeping them in trays. Or is it the directory structure concept that you would consider a SilverBullet?
(Good implementation suggestions and discussion moved to DoItImplementation, where more suggestions and discussion are welcome.)
Is it necessary to have tables (2-D, possibly sparse arrays) of forms? What happens when a row of a workspace itself becomes a form in a larger workspace--particularly when the information about the smaller workspace is lost, e.g. because it is accessed via a mediating server of some sort that discards the source information?
I think of the documents on the worktable as n-D; 3-D when "stacks" of related documents are considered; 4-nD when attachments to attachments are considered. But from a presentation point of view, the birds-eye view of documents on a worktable is not required, but offers a powerful mechanism to visualize and navigate object relationships and associations. (Or if the mention of sparse arrays implies an implementation approach, no internal array of contents is required.) Could you say more about the hierarchy of workspaces (worktables?) you mention -- I don't understand, which probably means I have missed some important modes of use!
EditText of this page
(last edited February 26, 2006)
or FindPage with title or text search