Description of Pragma

A pragma is not Greek to me, but a very specific type of pattern. Similarly, what I mean by pattern in this context is much more specific than usual. But we will begin with this: A pragma is a pattern.

To fully explore the concept of patterns that I am using, you begin with "The Timeless Way of Building" by architect Christopher Alexander. Then, you note that Alexander's work was enthusiastically embraced by the Object Oriented Development world, a realm inhabited by software engineers and their ilk. So now there are a wealth of web sites and books devoted to the development of patterns for use in software development.

Needless to say, that is all very deep thought. It is fundamental to the meaning of pragma, but there is already so much explanation of patterns and their use in software engineering that I will refer to, and not add to it in this post.

A key sentence from The Timeless Way of Building is this: "A pattern only works, fully, when it deals with all the forces that are actually present in the situation." This sentence was running through my mind in the days that I was working on the Pragma class library.

Typically middleware is developed with a view to the fine-grained details of a business operation and its information structures. By its nature, an end-user database application is idiosyncratic of the particular business. So there is no universal solution for managing business operations.

For a software system to be useful, it must contain a model of the operations it applies to, and so the developer needs a specific conceptual framework to program within. Not just the ideas, but the coded and implemented software objects.

I have always recreated this framework specific to a particular client, but under time constraints, only in the most basic way. Specific operational details within any organization always have to be analyzed individually in context, something that is difficult to do in a general way.

But there are of course many reliable patterns in the specifics that get repeated from company to company. Double-entry bookkeeping comes to mind. There is no one-size-fits-all chart of accounts, but there is a chart of accounts that both models a given business and also meets the requirements of accounting.

For business purposes, the most fundamental information level is the cost object. The cost object is subsidiary to the time object. Time is money, but you can't buy time. For other endeavors, some other basic unit can be associated with time, such as a number of people or objects. That depends on the endeavor. But a business pragma is built on the foundation of costs over time.

The time factor is connected, in business, with operational activities. It is in the activities that resources are used, and it is the resources that drive costs. In an effectively run business, the goal is to minimize activities that are not productive. This means that the important activities are associated with customers by way of the products or services they purchase from us.

And finally we have the relationship over time between customers and our company itself. Now we have traversed a pragma tree: from the measure of costs and the time it takes to perform operations, we create a chain of resources and their costs, operational activities, customers, and ourselves. The hierarchy looks like this:

Company
-Customers
--Jobs
---Operations
----Activities
-----Resources

Typically what I find in a customer's information technology situation is a reliable source of internal Company data, Customer data, and Job information in a database that everyone can access parts of. And all of the information about costs and which resources are on hand is contained in the accounting system, which is behind that locked door in the room with the password-protected screensaver. Not to be critical of these controls, just saying: that's where the needed information is. Control of sensitive information is among the biggest challenges -- it is necessary to share the information, as well as protect it.

As for operations, what I am asked to do has something to do with this area. The production manager has a system of some kind in place, at least a mashup of spreadsheets. But there is a felt need to manage operational costs more effectively, and a desire to avoid redundant data-entry into the separate systems. Operations knows who needs to be billed, and for what -- but they do not do invoicing. How does Accounts Receivable clerk get the information from Ops? Probably in a spreadsheet. Unfortunately often though, on a hard copy.

In a large corporate data center, redundant data entry is not a problem so much as the order of the day. The clerks themselves are the middleware -- wet middleware that ties together the disparate systems in use throughout the company. That is what clerks are hired to do. The fact that clerks routinely go crazy with the insanity of much of what they are required to in this regard is moot. They aren't hired to be happy either. In that case, I am hired to write software that does things too complicated or specialized for a human employee to be tasked with.

It is somewhat different in a small company -- the clerks are often the owners, and they don't enjoy wasting time nor money on redundancy. Or there is a large amount of data that is generated by their operations, which does not fit easily into a standard spreadsheet or simple database system. In that case, we are designing a database application specifically to track that, and only that, store of information.

Another scenario is the bottleneck. There is some desk somewhere with overflowing boxes of documents and many megabytes of raw data in their computer system, with no hope of manually digging out of the hole in timely fashion. Radical measures are deployed in the form of a software development project, and a team of temporary clerks are called in to enter the bottleneck data while a programmer writes code to parse the raw data into a database.

None of these scenarios lend themselves to the development of comprehensive pattern frameworks. Despite seeing so many different operations with abundant similarities, there are also many differences and idiosyncrasies in every situation. So this approach that I am calling Pragma is the result of those years of experience, the extrapolation of the basic necessary information needed to run a business and track its information.

The first Pragma component is an operations management module that organizes production activities for cost analysis (contribution margin and break-even) along a timeline. I had never seen any software do this sort of thing very well. Probably because those solutions so far outside my price range I wouldn't even recognize the neighborhood. Deep calls to deep when it comes to pockets and software budgets.

Coolest thing of all is the availability of the Quickbooks API. This exposes a popular accounting package to my own applications, and the accounting system contains most of the operational data -- just not organized in the perspective of a production employee. In software development terms, Pragma is a business-objects layer framework which performs middleware integration of customer databases, operations databases, and accounting systems.