Software for the finest computer – The Mind

Posts Tagged ‘Systems’


Posted by Tim Bryce on April 18, 2016


– a return to basics in system design.

To use this segment in a Radio broadcast or Podcast, send TIM a request.

PREFACE: A few months ago I made a promise to some of my techie friends I would describe the concept of “Information Driven Design” as used in our “PRIDE” Methodology for system design. This concept originated in the original version of our product in 1971 and was successfully used by our customers to build enterprise-wide systems. The reason I bring this up is that it appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design…

Information Driven Design begins with a simple concept:


Information is the intelligence gained from the processing and/or analysis of data. This means information is a product based on two variables, data and processing. We do not store information, we produce it based on these variables. Whereas data represents “what” is to be processed, processing (or systems) represents “how” it is to be processed, using formulas, algorithms or calculations. An invalid calculation is just as misleading as invalid data; both will produce erroneous information. From this perspective, both data and processing must be carefully designed and controlled as resources for producing information, and as resources, they can be shared and reused to produce information for other uses. In this way they should be identified and controlled like any other resource, hence the need for “Information Resource Management,” a concept very much akin to “Materials Resource Planning” as found in manufacturing.

Since the intent of an information system is to produce information, the more we understand about information requirements, the better we can accommodate its implementation. This is why we refer to this concept as “Information Driven Design,” a system design derived from the inherent properties of information.


Information requirements should be defined in such a way as to explain the Business Functions they serve, their Business Purpose, the Actions and/or Business Decisions they support, and the benefits derived from the use of the information. In this way, it a textual justification for the information. Now let’s take it further…

There are three types of information:

Policy Information – To implement executive decisions.

Control Information – To monitor policy and manage operations.

Operational Information – To implement the routine day-to-day activities of the business.

Information is a dynamic and perishable commodity. It only has value at the time it is required. Whereas the definition of data is constant, information requirements can change for a variety of reasons, such as politics, government, competition, economics, people, etc. Ultimately, corporate survival depends on providing users with accurate and timely information.


In order to properly specify information requirements, it is not sufficient to merely determine what data is required to support it; it is also necessary to define the timing of the information (to support the actions and/or decisions). This timing will ultimately dictate how data will be collected, stored, and retrieved to produce information.

Failure to recognize timing as an important element of design will result in the data base being out of synchronization with the system. For example, consider a situation where data is collected on a routine weekly basis (just once a week). Daily analysis of the data will be inappropriate since the data will remain constant until the next weekly update. To resolve the conflict, data collection should be changed to at least a daily basis.

All information systems operate in time frames, such as instantaneous, daily, weekly, monthly, quarterly, annually, etc. If this is true, why not make use of this timing consideration during system design as opposed to discovering it afterwards while trying to correct the data base design?

There are three aspects to timing: frequency, offset and response time.

FREQUENCY defines “how often” the information is required, e.g., upon request, hourly, four times daily, once a week, twice monthly, quarterly, semi-annually, etc.

OFFSET defines when processing should begin, such as the beginning of the week, end of the month, etc. However, if the frequency is ‘upon request,’ then there is no scheduled offset; this is because the information can be requested at any point in time.

RESPONSE TIME defines how fast the information must be delivered to the user. For example, five seconds, two hours, one day, etc. This should not be confused with computer ‘response time’ or ‘throughput’ which is concerned with machine speed. Rather, response time is concerned with the maximum amount of time that will transpire between the request and delivery of the information, so the user can make the necessary decisions and/or take action. This implies that if the response time is exceeded, it is no longer information, only historical data.

Timing ultimately defines data availability and accessibility issues. Availability specifies, “Is the data there when I need it?” (a function of Input/Data Collection). And Accessibility specifies, “Can I get to the data when I need it?” (a function of Output/Information Retrieval). Understand this, you cannot access data (retrieve information) if it has not been made available (collected) in a timely manner.


Data comes in two forms, Primary and Generated. Primary data is what is collected and inputted into the system. Generated data represents calculations derived from primary values. To illustrate, suppose we need the generated data element, “Net Pay,” as used in payroll. It would be necessary to define all of the other data dependencies, e.g.;


Other data elements used in the formula may also be generated, such as:


What this means is that in order to arrive at the correct value for “Net Pay,” we must be able to reach all of the primary values, such as “Hours Worked” and “Pay Rate,” in a timely manner. If we cannot do this, “Net Pay” will be incorrect.

Defining these data dependencies has typically defaulted to the programmer who redefines the relationships with each application and buries it in the program source code, making maintenance and change considerably difficult. Consequently, It is not unusual to find “Net Pay” defined differently in multiple applications throughout a company.

The timing nuances of the Information Requirements ultimately dictate the various sub-systems of the system (the business processes). Some will be used to exclusively input data (aka “maintenance”), some to produce information (aka “queries”), and some for both maintenance and query purposes.

The basic operations that can be performed on data include “create,” “update” and “reference” (“delete” is the opposite of “create”). In programming terminology, a “create” represents a “write,” an “update” represents a “read/write,” and a “reference” represents a “read” only.

The timing and data specifications resulting from the information requirements will ultimately dictate the type of sub-systems to be created. For example, if information is needed upon request and within a matter of seconds, this will probably result in an “interactive” type of process. However, if the information is required upon request but within a few hours, this will probably result in “batch” type processing (it may even be processable manually). These specifications are the basic building blocks for all systems and software design.

Producing an information system design that correctly satisfies requirements is a vital part of Information Driven Design. If the information requirements are correct, the resulting system design will be correct. However, if the information requirements are wrong or incomplete, the resulting system design will be incorrect. With this approach, the emphasis is on business analysis as opposed to technical detail.

This approach to system design ultimately recognizes, “No amount of elegant programming or technology will solve a problem if it is not defined or understood correctly.”

Keep the Faith!

MB – “Est superbia”

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at

For Tim’s columns, see:

Like the article? TELL A FRIEND.

Copyright © 2016 by Tim Bryce. All rights reserved.

NEXT UP:  UNDERSTANDING TRUMP’S ANTAGONISTS – The louder they get, the stronger the candidate gets.

LAST TIME:  JURY DUTY: A NECESSARY EVIL  – Why we hate to be called for duty.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; KIT-AM (1280) in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific); and WWBA-AM (News Talk Florida 820). Or tune-in to Tim’s channel on YouTube.


Posted in Systems, Technology | Tagged: , , , , , | Leave a Comment »


Posted by Tim Bryce on April 11, 2016


– Do we have enough Systems Analysts or too many programmers?

To use this segment in a Radio broadcast or Podcast, send TIM a request.

Whenever I’m asked to discuss the subject of Information Systems in the corporate world, I am inevitably asked, “Where does the programmer fit in?” I think this is an odd question as I see programming as only a small part of the overall puzzle. People are startled when I mention this, particularly programmers, who tend to see themselves as the center of the systems universe. I counter by asking, “What exactly does a programmer do?” After much discussion, we end up with the same answer, “a programmer takes human understandable specifications and converts it to a machine executable program, either by writing and compiling source code or through some interpreter capable of generating the program.” This, in turn, leads to an interesting discussion as to what is meant by “requirements” (it seems everyone has their own spin on this). More importantly, it leads to a discussion as to what exactly a system is.

I like to follow this by posing the question, “How many programs make up a system? One? Two? Three? Is a suite of programs a system?” Again, after much discussion we conclude there is no finite number of programs in a system, it is as many as satisfies the system’s needs (and again we’re back to “requirements”).

I finally ask if a system can be implemented without computer assistance (without programs). The programmers typically balk at this one, but grudgingly admit an information system can be implemented manually or through the use of other equipment. Actually, information systems have been used for hundreds of years, well before the advent of the computer. As one of our more famous Bryce’s Laws points out, “The first on-line, real-time, interactive, data base system was double-entry bookkeeping which was developed by the merchants of Venice in 1200 A.D.” In other words, computer programming is but one way to implement an information system, but certainly not the only way. This premise implies information systems are much larger in scope than programming, and that systems have two dimensions, a logical side and a physical side. The logical side defines the various business processes comprising the system (aka, “sub-systems”). These processes can be implemented through manual processing, use of other equipment, with computer assistance, or combinations of all three. The physical processing changes more dynamically than the logical simply because technology changes.

To pull this all together requires a type of person more knowledgeable about the business than about computers. Historically, this type of function has been referred to as a “Systems Analyst” or more recently a “Business Analyst.” Regardless, the analyst is a precursor to the programmer. In the absence of an analyst, programmers must try to understand the overall system architecture, a talent they are not necessarily well versed in.

The day a company starts its business is the day when its systems are born. Even a company in name only requires systems support in order to report to the government on their activity (or inactivity). As businesses begin, a “natural” system is devised whereby work is distributed among employees, hopefully in a cohesive manner. Without orchestration though, there is a tendency for the natural system to develop inconsistencies and redundant work effort, particularly if the business blossoms. Data duplication is unavoidable thereby causing inconsistencies in information. If the information is “dirty” inferior business actions and decisions will ensue thereby causing an adverse affect on the company’s bottom-line.

The point is, no amount of elegant programming can solve a system problem without someone who understands the overall system architecture, someone who understands how the business works. Attacking systems development without such orchestration, such as one program at a time, will not produce the desired results. That would be like trying to build a bridge without a set of blueprints; it would probably be disjointed and one end would likely not connect with the other in the middle. I for one would not want to travel across such a bridge. Yet, this is precisely what is happening throughout corporate America today. If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats. If you consider how counterproductive it would be to try and build a bridge without a set of blueprints, you get a good idea how counterproductive a lot of systems development organizations are. A lot of time and money is lost simply trying to deduce what is to be built in a concerted manner.

It is the Analyst’s job to understand the business, not the programmer’s.
It is the Analyst’s job to develop and maintain the system architecture, not the programmer’s.
It is the Analyst’s job to develop the specifications for programming, not the programmer’s.
It is the Analyst’s job to develop the data specifications for the Data Base Administrator, not the programmer’s.
And it is the Analyst’s job to test and install systems, not the programmer’s (although they should be performing unit and string tests of their software prior to system tests).

Programmers should be consulted to review the feasibility of a system design, but make no mistake, it is up to the Analyst to develop such plans. And if the Analyst performs his job properly, he will greatly simplify the life of the programmer, thereby making that person more productive. Regrettably, corporate management has little appreciation for the Analyst’s duties and responsibilities. Consequently, the Analyst is pressured to short stroke his work effort and turn it over to programming prematurely, thereby causing the programmers to act on poorly defined specifications which inevitably results in project delays and increased development costs.

So, is the tail wagging the dog in your company or the other way around? Do you have a sufficient number of Analysts to properly design systems before turning the specifications over to programming? Consider this, if done properly true programming should take no more than 15% of your development time and costs. If you are expending more than this, I suspect you do not have enough Analysts.

Remember this, anytime you have a systems development project involving multiple business processes, multiple people, and multiple programs, you damn well better design a system architecture first.

Originally published: Febraury 9, 2011

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at

For Tim’s columns, see:

Like the article? TELL A FRIEND.

Copyright © 2016 by Tim Bryce. All rights reserved.

NEXT UP:  WHAT MAKES US HAPPY? – Is it how we act or how we perceive life?

LAST TIME:  MY LAST PUFF  – Quitting is not easy.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; KIT-AM (1280) in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific); and WWBA-AM (News Talk Florida 820). Or tune-in to Tim’s channel on YouTube.

Posted in Systems, Technology | Tagged: , , , , , | Leave a Comment »


Posted by Tim Bryce on October 9, 2012

New “Bryce’s Laws” Mini-Posters for Project Management and Information Systems have been introduced. The popular “Bryce’s Laws” include axioms for a variety of management and technical subjects, not to mention life in general. This particular collection includes ideas pertaining to Project Management (“Manage from the bottom up; not just from the top down; this creates personal commitment and accountability”) and Information Systems (“An information system is a product that can be engineered and manufactured like any other product.”) The Mini-Posters are thought provoking and good conversation starters.

Click on image to download

Click on image to download.

Click on image to download

Click on image to download.



Posters courtesy of M& JB Investment Company, Palm Harbor, Florida.

Posted in Business, Management, Project Management, Systems, Technology | Tagged: , , , , | 1 Comment »

%d bloggers like this: