Money, it's a crime Share it fairly But don't take a slice of my pie

I think I was lucky, in that I began my post-College career working closely with Accounting. The common joke is that Accounting is the most important part of an organization because they're responsible for the paychecks, but the accounting machine at even small organizations is dramatically more complex than that. Funds are transferred between General Ledger accounts, some of which represent cash-on-hand, others expenses or potential income, all of which carry various meanings that are very important to the financial health of the organization.

But outside of accounting, no one even knows about these accounts. Nor would they. To almost everyone in an organization, Accounting is a black box. Money goes in from customers, and comes back out again to employees and vendors. And sometimes Accounting seems as an impediment to the rest of the organization, as they may need to prevent a project from going forward (in conjunction with management, obviously) due to concerns about the money.

The point is, every single activity within an organization impacts one of these accounts, even though most people don't understand, or generally need to, how that happens.

Usually, this isn't a problem, but right now Washington State University is beginning the Fit-Gap analysis for replacement of the Student Information System across all of our campuses. However, while we are all glad to be replacing our aging student system, we are doing nothing at this time, with our aging financial system, which I think is simply backward. There is a reason that the Kuali Project has released three major revisions of the Financial System (beginning with the General Ledger), but still don't have the first release of the Student System (which should happen soon).

All over the PeopleSoft interface as "GL Interface" Links, or other such information that controls how the Academic Structure information we're working on now drives those all important General Ledger accounts. However, we haven't really discussed that interface much, as it's beyond the scope of our current discussion, which is fine. The problem is, the number of people who assume that things can be set up differently than we have in the past, without even considering how those sorts of decisions would bubble down to the Financial System.

For instance, we aggregate out our schedule data to the Campus level, in addition to the Year and Term level, so that students and administrative staff can limit how much information they see when viewing the schedule. This is metadata that will still be present in the new system, absolutely, but there was some brief discussion about creating Term records unique to each campus. Problem is, that there is linked information at the term level (from Academic Calendar data to Accounting Data) that is shared among all campuses. Plus, GL lines can be impacted by other selections like Campus and Organization that a given Course or Section is linked to, overriding options further up the Chain.

This is a recurring theme in most information systems, but definitely in Accounting systems. Define all data at the highest level possible, and do it once. Let it be overridden later if necessary, but common defaults should be defined once, at the highest level, to work their way down to the lower information. This can lead to challenges with those defaults changing late in the game, but that's a communication and business policy discussion, not so much a technical discussion.

Most programmers end up working on Information Systems that are all very similar in their data integrity (and even structure) requirements. My introduction to many of these concepts came from working with Accounting systems, but any large system should be based on similar principles. My education on this topic was very much 'in the field', by analyzing existing systems. I learned far more about designing data schemas and other such systems after I graduated with my B.S. in Computer Science, than I think I even had the opportunity to when in school. Given that most software developers will end up working on or with an large information system, I suspect that programs seeking to offer a more general (or even vocational) software engineering program, should talk about these systems more directly. Whether it be the design of an Accounting system like MAS90, larger ERPs like Kuali, or even project management systems like Launchpad, there are similar data problems to be solved across all these problem spaces.