Modular Design Theory

[Thales750]

Databases with well developed core functions are useful for many businesses. However, addressing the differences is imperative, and costly. So for these problems we can either create custom systems, or use modules. Not "code modules" actual components that are more customer specific and integrate with the core program.

The question for discussion is when is it better to open a new database, and when is it preferable to replace the forms and queries in the core database?

Thank you.

 

[vba_php]

Not "code modules" actual components that are more customer specific and integrate with the core program.

The question for discussion is when is it better to open a new database, and when is it preferable to replace the forms and queries in the core database?

don't think i'm following this. care to expand on it in detail?

 

[GinaWhipp]

Hmm, well I would think some (if not most) developers have something like...

Access-Diva Model Database

Access-Diva provides custom databases using Microsoft Access utilizing SQL Server when called for.

www.access-diva.com

Having one cuts on the cost as you only to incorporate the differences. (And in my case this would also include Code Modules.) All that said, my Model Database has grown as every time you take a *new* industry you find and yet another *core* table that you never knew you needed.

When it's time to create a new database I simply copy the Model Database and move on from there. I have even done this for rewrites. It's quicker then trying to fix everything in the existing file.

 

[The_Doc_Man]

Thales750,

The question you asked is actually the core of at least one fairly well-known business - PeopleSoft. They have a data layout and optional modules for business management including payroll, benefits, taxes, insurance... the problem comes about when you wanted to do something that wasn't part of their "standard" offering. Then you have to pay through the nose to fix things that conform to YOUR business model.

In answer to your direct question, you must do a lot of research on just how closely this "commercial off-the-shelf" (COTS) project matches what you actually do, and how much of your business model are you willing to change to begin using the COTS product. The closer the match, the more likely it is that you can make it work. But when there is a big divergence between your model and the model used by the COTS product, that way lies pain, monetary disaster, and (if it is a big enough "fail" - a touch of ignominy.

This business-model/COTS-model mismatch once led to a billion-dollar screw-up. You can look up DIMHRS as the case study. I watched it happen.

In brief, the U.S. Congress tried to achieve a savings by converting all services to use a single personnel management system, Defense Integrated Military Human Resource System, which would have been powered by PeopleSoft. The problem was that the major military branches each had their own systems and were not willing to change the way their internal business models worked. (Yes, the military thought of themselves as having a business model.) That discord on business models meant that they couldn't reach common ground and the project fell apart over the squabbling of how to manage military personnel.

It started with PeopleSoft coming in to look over each major branch's HR system. The PeopleSoft "modules" were oriented to the commercial HR world, but the military world has radically different ways of doing personnel business. (Not the least of which is that if you try to quit during wartime, it is called "desertion" and they shoot you.) But even in peacetime, there were RADICAL differences between military and civilian HR.

For the Navy Reserve, PeopleSoft identified over 3500 such differences. EVERY MAJOR MODULE of PeopleSoft had to be modified. But worse, every module had to be modified DIFFERENTLY for all of the services. (We didn't have the Space Force yet, so only five services, and the Coast Guard used something similar to the Navy's system - though not identical.) Eventually, the evaluation was made that the Navy would only be able to use 19% of the code extant in the PeopleSoft modules. The next competitor was an ORACLE package because ORACLE hadn't yet bought out PeopleSoft. They were an 18% match. The contract was awarded to PeopleSoft on a 1% difference in usable code.

The problems that abounded included such things as the database engines getting swamped because PeopleSoft did EVERYTHING by Triggers - so the database servers went "compute bound" trying to resolve the stack of triggers that applied to each record. The best hardware we could get could only manage a 36-hour run-time on the daily processing cycle, and there were no shortcuts available such as skipping a step, because with the military, you do things in the right order or they don't get done. (It's a military oversight sort of thing.) Eventually it became clear that DIMHRS was not viable and Congress pulled the plug.

Here are some articles on the subject:

Examining DIMHRS Primary Risks

Shrinking Department of Defense budgets have resulted in a greater focus on IT project expenses. The Defense Integrated Military Human Resource System (DIM...

ischool.uw.edu

Military Update: DIMHRS program dumped as ‘a disaster’

www.stripes.com

Military payroll project in New Orleans gets the ax

One year after the Pentagon canceled an $850 million payroll system that never became operational, the last of the contractors who worked at the project's New Orleans home base are

www.nola.com

 

[Thales750]

Doc, thanks for that story. Gina, of course it would include code modules, and everything else needed to be a plug and play.
vba_php, Maybe less detail is needed.

The question is: When you are assembling a new system from components, how would you decide when to use a second database front end, instead of adding the object to the core database?

 

[CJ_London]

My own view is that most 'off the shelf' systems will meet 80% of the requirements, the rest is customisation. With your own modules, since they are usually initially created for a specific client it will meet 100% for that client and 80% for new clients. It is not just about data storage, but also layout and terminology/naming convention (e.g. postcode/zipcode)

If you can break your module/table(s) to a small enough 'component' then that component will probably be useable across all applications with some built in configuration functionality - e.g. an address table/form/report. So show/hide labels, show labels to left/top/right, make first line bold, include a gap between name and address, make postcode right justified, etc.

I frequently get involved with providing solutions between enterprise scale systems where they have different standard schema - sticking to the address theme, one has 4 lines for the address, another has 6 or 2. One has an address table that can be linked to customer or supplier, another has separate tables for each whilst a third might include a primary address in the customer table.

An accounting system has different address requirements to a marketing or contact management system. Another might have the addresses in another system that is designated as 'data master'.

So you could incorporate all these variations into one module, just to handle addresses - but is it worth it?

Having said that I do have a few modules which are 'off the shelf' and customisable, but the range of customisation is relatively limited - e.g. a search function you can associate with any form, a multivalue continuous form which mimics a multivalue control, another which is a continuous form but has some of the functionality of a datasheet (user can hide, resize and move columns) etc. None of them really care about the underlying data, just about presentation and functionality.

When you are assembling a new system from components, how would you decide when to use a second database front end, instead of adding the object to the core database?

Think you need to be clearer what you mean - are you suggesting adding a financial system to a CRM system - both front end and back end?

 

[GinaWhipp]

Doc, thanks for that story. Gina, of course it would include code modules, and everything else needed to be a plug and play.
vba_php, Maybe less detail is needed.

The question is: When you are assembling a new system from components, how would you decide when to use a second database front end, instead of adding the object to the core database?

Hmm, only once have I ever created a second Frontend and I still regret it... as in will never do that again. Separate Frontends become a nuisance to update and generally not worth the trouble in my opinion. Are you thinking of a specific scenario (because I'd be interested in which case you would think this would be needed) or just asking?

 

[Thales750]

Hmm, only once have I ever created a second Frontend and I still regret it... as in will never do that again. Separate Frontends become a nuisance to update and generally not worth the trouble in my opinion. Are you thinking of a specific scenario (because I'd be interested in which case you would think this would be needed) or just asking?

Not really planning it. But as Pat said I can see a situation where the user may not overlap.

This is what got me going on this. Now that the chemical plant software is converted to SQL, with only a few minor changes to be made, other opportunities for it are becoming available. Mainly, small custom manufacturing. But their marketing, and order taking are completely different.

The other system I have for managing complex processes and projects has been evolving for the last 4 years. But once again, the sales order format is completely limited to the type of projects it was designed for. I've ported all Clear Lake's data over to that backed and it is much better for managing projects then the old one. But, and its a big one, I still use the old system (linked to the new BE) because the invoicing is completely different. That got me to thinking.

 

[Thales750]

CL,
Same server, different frontends.

When is it the right thing to do?

 

[GinaWhipp]

Okay, but Pat's scenario has a separate file no one interacts with. So, not seeing that as multiple Frontends.

I would not *mix* the two. I would take what I could from the one and create another one for the one where Order, Marketing, etc. are in play. (If I am understanding what you are saying.) Yes, there will be overlap but the two are radically different and I would not want to mic\combine them into one Backend.

 

[The_Doc_Man]

An IT-savvy economist named Barry K Boehm (think that's the right name) wrote several treatises on project management from the economist's point of view, sometime in the late 1960s/early 1970s. Pat, your manager's question actually makes sense in light of what BKB found.

If you have a project that can be divided up into 9 pieces, depending on how closely related they are, and based on "milestone" issues, it MIGHT be possible to get faster results with fewer people. It all depends on how "cleanly" the parts can be divided and how many meetings you can avoid in order to coordinate interfaces and testing - because such meetings are work killers. The cleaner the split for the parts, the more likely that you can do the maximum division. But it is not a black/white case - it involves shades of gray.

The "more cleanly divisible" case usually means that you can gain some economy by dividing up tasks once the overall specification is complete and the task specifications are completing pending their interactions with reality. So in my case 35 years ago when I had a major multi-person development project, we had 6 major tasks and could divide the labor, but the parts were unequal in size. I had to let other groups use my team members at times because of milestone dependencies that left them idle for relatively short periods. From an efficiency viewpoint, true divisibility usually means some people have down time because (from queueing theory) the "equal-sized tasks, equal-ability processor" case is easy to solve but doesn't occur often in nature.