“Give me whereon to stand and
I will move the earth,” said the Greek mathematician Archimedes. Fair enough.
Leave it to another
mathematician, Elementus Maximus, to augment that claim. “Give me a long enough
lever and a place to put the fulcrum and I’ll move the earth.”
Once the perfect tools were
levers. Now they’re database management systems. In the advocacy of levers,
however, the devil is still in the details. The trick is to extract the
confusing details and leave the essential understanding.
When talking to prospective
newspaper customers, we hear several recurring refrains. “Do you use QuarkXPress
or Adobe InDesign for pagination?” “What database do you use?”
If you have a vision for how
systems should be built, then neither of these questions should likely top your
list. Let me tell you how I think about it.
Newspapers require highly
functional systems to efficiently run their businesses. Some of the tools they
need are very specific to them. An integrated newspaper system for all but the
smallest of newspapers is a highly complex collection of software.
Building newspaper software
involves solving some very large and complex problems. As development
progresses, you hope that the software will not grow so dauntingly complex as to
preclude providing a functional, installable and maintainable solution.
That said, the question is
this: What tools will help you build, maintain and install newspaper software?
Problem solving
This is an engineering issue
that has to do with problem solving. Problems are either small and can be solved
in a single step, or large and require a solution composed of numerous steps.
Envision a number of steps and that each step might be small and solved
immediately.
Either way, here’s the
question when building newspaper applications, or any software for that matter:
How do you break big problems down into smaller problems that you can solve?
Understanding this is easier
than you might think. You know your computer has programs and data. The programs
examine and modify the data; for example, Microsoft Word can be used to change
the data in a Word document.
Now, documents are a type of
data, and data is something used to describe nouns. The data is stored in memory
(RAM, disks, tapes, etc.). You want the memory to be big. Then there’s the
processor. It is the processor’s job to change the data based on programs. The
processor should be fast. Programs are made up of instructions, which are verbs
- everything from add and subtract to sort and save.
In a world where there are
verbs and nouns (or operators and operands), factoring big problems into small
ones requires choosing between refining a verb or a noun at each step of the
problem-solving process.
Noun-centric view
Database management systems
essentially facilitate a view of the world based on nouns. If someone tells you,
“I have the perfect database management system for newspapers,” they’re saying
they think they can build complex systems such as those newspapers use based on
a noun-centric view of the world.
But remember, the devil is in
the details. Clearly, some pieces of a newspaper system can be built effectively
around a database view of information processing technology. And, of course, if
such a tool exists that manipulates the types of data newspapers deal with
(everything from text to pictures, etc.), then this view is likely to yield
useful solutions. For example, managing newsprint inventory is easily done in a
database context. Paginating classifieds quickly and optimally is not.
A problem arises, however,
when a vendor claims for an enterprise advertising system or enterprise newsroom
system that, “everything can be stored in the database.” Such a solution would
entail significant complexity because it’s unlikely that the whole could be
understood from a conglomeration of all the parts.
Any system with more than 100
different types of database entities is considered large. (In database
terminology, a database entity is something like the set of customers, or ads or
insertion orders.) Our advertising front-end system with its billing and sales
management tools has nearly 275 entities - a very large number. Our Layout-8000
ad dummying software has well over 150. So, by now you can understand that
simply having the right database and putting in all the data isn’t appropriate
if you want to build, install and maintain newspaper systems.
Factored by verbs
The challenge of building
newspaper systems can also be factored by verbs. In this view one thinks of
“taking ads” as opposed to “ad records.” If you build an enterprise newspaper
system around verbs, you would say your system has a service-oriented
architecture. Some of the services a newspaper software package might have
include wire capture, ad entry, billing, accounts receivable, ad dummying and
classified pagination, among other components.
If I wanted to have a system
built around a service-oriented architecture, what database would I choose? The
answer is simple. Service-oriented architectures are about verbs;
database-oriented architectures are about nouns. Both are clearly appropriate in
some cases and clearly inappropriate in others - and neither is appropriate for
all cases.
Service-oriented
architectures
Service-oriented architectures
have a number of desirable attributes. Since the pieces are functionally
oriented, new releases of different services can come out independently. Since
the subsystems are distributed and based on exchanging and replicating data
rather than storing it in a single place, system upgrades are greatly
simplified. And, of course, it’s much easier in a system built on services to
attach components from a number of different vendors.
With a service-oriented
approach, you get to build an integrated system from “best of breed” technology.
There are numerous technical
advantages to a service-oriented architecture as well. Transactions can take
place across application servers based on numerous data services. Data can be
replicated where required according to the underlying distribution model. Again,
buying multiple applications from different vendors is made much easier. The
constraints of a single database often prove to be a vendor’s Achilles’ heel.
Linked together
One of the characteristics of
well-engineered service-oriented applications is that the components are tied
together via messaging. Today the messaging technology of choice is based on
XML. Messaging, not a database, is the key to building service-oriented systems
- especially those that use the Web.
For those who anticipated that
I would identify Oracle, MySQL, MS-SQL, PostgreSQL, or some other
database-oriented tool as the perfect technology for building newspaper systems,
I apologize.
Is there a perfect database?
The perfect database is the one which, when mentioned along with other magic
words by a vendor’s salesperson, provides a unique and compelling selling
message. If you can’t sell what the application does, sell its database.
Richard
Cichelli is president of Software Consulting Services, a 30-year-old newspaper
systems vendor. He can be reached at 610.746.7700.
