In the 1980s, an idea circulated among system designers called 'perfect technology.'^[1]  The basic message, rather obvious today, is that 'functional' requirements should be considered independently of hardware constraints.  A BRCommunity member expressed this idea as follows.

Assume the execution mechanism is perfect:  It's infinitely fast, has unlimited memory, it never breaks, consumes no energy, dissipates no heat, takes up no space, has transparent interfaces (a-la the 1960's Star Trek Vulcan Mind Meld), is free, and so on.  Then, ask yourself the question, "If I had this perfect technology, would I still need to levy this as a requirement on the system?"  Any requirement that becomes irrelevant in light of perfect technology is a non-functional requirement.  If it has to do with speed, cost, reliability, presentation to the outside world, etc, then it's non-functional.  What's left over after all the technology stuff has been filtered out is the functional stuff -- the business policies that need to be enforced and the business processes that need to be performed.

The real world, of course, offers no such thing as perfect technology.  But things are relative -- today's 'execution mechanisms' almost seem perfect compared to technology a mere two decades ago.  In hardware, we have certainly come a long way!

System architecture, unfortunately, is another matter.  Today we still struggle to understand the precise differences between models of the business, models of the system (platform-independent designs), and models at the platform level (platform-dependent designs).  Time to take a giant next step.  In this article, I examine the difference between the later two of these kinds of model using the next-generation notion of the perfect platform.

A Closer Look at Models of Requirements

First, however, let's review the kinds of models mentioned above based on the Zachman Framework.  Zachman's view is that the form of deliverables should be based on the perspective of the audience they address.  Following his Framework, this actually leads to four kinds of models, as follows:

• Business model
• System model
• Class-of-platform model
• Specific-platform model

Zachman indicates that a system model differs from the models above and below it in the list above as follows:

1. A business model focuses directly on the real-world things of the business.  A system model, in contrast, focuses on surrogates for these real-world things.  The purpose of the system model is to design the elements of knowledge/record-keeping^[2] needed to support the real-world things described in the business model.

2. A class-of-platform model is one suitable for -- or more accurately biased toward -- the class(es) of platform chosen for implementation.  A system model is in no way influenced by such choices.  Therefore a system model might be described as logical as opposed to 'physical.'  Note that 'logical' does not imply simple -- indeed, systems models can be pursued to 'excruciating' [but useful] level of detail^[3].

To illustrate what 'influenced by platform choices' might mean, consider just the aspect of data management.  Classes of platform for data management can range as widely as relational database to pencil-and-paper.  It is not hard to see that the transition from a system model to a model suitable for (i.e., biased toward) particular class(es) of platform could involve huge differences.  What is harder to see is exactly how being free of all platform^[4] influences shapes (and simplifies!) the system model.

The notion of the perfect platform addresses this question.  This notion brings into sharp relief the issues that need not be of concern for the system model.  (Obviously, the business model therefore need not concern itself with these issues either.)  Such a perfect platform would exhibit the characteristics described below.  These characteristics can be nicely organized around the six interrogatives, which of course are represented by the columns in the Zachman Framework.

Six Principles of the Perfect Platform

What -- Data:  The Principle of Perfect Platform Recording

You can assume data can always be recorded, no matter what its kind, type, or size.

Implication:  There is no need to worry about data type support (or related specifications) in the system model.  This is inherent to the meaning of logical in 'logical data model.'

Note:  It is tempting to append the following to this Principle:  " … and the platform will never forget the data (unless so instructed)."  However, this idea actually derives from the business model, where the interrogative 'what' is modeled using a fact model (a.k.a., structured business vocabulary or semantic model).  An important assumption in that context is the notion of perfect memory, which might be stated as follows:  You can assume if you can name it, you can design a system to remember it.

How -- Process:  The Principle of Perfect Platform Execution

You can assume if you can formulize the process, the platform will never fail in executing it.

Implication:  There is no need to worry about platform failures in executing processes specified in the system model.  This is inherent to the meaning of logical in any kind of logical process design.

Note:  Even though you can assume that executions of processes will never fail for platform reasons that does not mean an execution will produce the correct output.  Only correct specification of the process in the system model can guarantee that!

Where -- Network:  The Principle of Perfect Platform Deployment

You can assume if you need it somewhere, the platform can get it there.

Implication:  Platforms and communication links can be deployed anywhere without complications (for the system model), so there is no need to worry about deployment issues (or related specifications) in the system model.  This is inherent to the meaning of logical in any kind of logical network design.

Note:  It is tempting to assert that "platforms have infinite capacity, and any amount of data can be made available anywhere instantaneously."  The implication would be that there is no need to worry about platform/line overload or delay.  However, that would probably violate 'the laws of physics.'^[5]  In any event, it runs counter to the logical design focus of the 'where' interrogative for the system model.

Who -- People:  The Principle of Perfect Platform Users

You can assume if you connect someone, the platform will not permit him or her to misuse it.

Implication:  There is no need in the system model to worry about people misusing, abusing, or subverting the system (a.k.a. hacking) using platform features.  This is inherent to the meaning of logical in any kind of logical human interface design.  Note carefully that this Principle does not say, "You can assume people will never try to access or use data or other aspects of the system without authorization."  Security is definitely a system model issue.

Note:  It is tempting to assert that "people never go off-duty; can always do work requests immediately; have no limit on how many work requests they can do simultaneously (multi-tasking), etc."  The implication would be that there is no need to worry about worker overload or delay (e.g., work queues).  However, these things would definitely violate 'the laws of physics' (insofar as they relate to real flesh-and-blood human beings).

When -- Time:  The Principle of Perfect Platform Timing

You can assume if users need it at the same time, the platform can supply it.

Implication:  You can assume that platform events can happen simultaneously.  There is no need to worry about preventing or prioritizing simultaneous platform events, deadlocks, etc. in the system model.  This is inherent to the meaning of logical in any kind of logical dynamics design.

Note:  It is tempting to assert that the system model need not consider simultaneous system events (or the prevention thereof).  But this is not the case.  For example, requiring unique time-stamps on business transactions may be necessary to support sets of rules establishing priority.

Why -- Rules:  The Principle of Perfect Platform Guidance

You can assume if you need rules evaluated, the platform can accomplish it.

Implication:  Rule(set)s can always be evaluated, no matter what kind or source of data (or state information) they require.  There is no need to worry about data access (or related specifications) in the system model.  This is inherent to the meaning of logical in any kind of logical rule(set) design.

Note:  Just because rule(set)s can always be evaluated does not mean they will not result in unresolved conflicts.  Conflict resolution in the logical sense is definitely a system model issue -- and often probably a business model issue.

A Business Policy Example

The IRS has a regulation (governing rule) that corporate records of financial transactions must be retained for a minimum of seven years.  (I am over-simplifying here -- there are probably a host of exceptions and policies for different scenarios.  However, let's keep the example simple.)  Consider the treatment of this regulation for the different kinds of models.

Business Model.  Violating the IRS regulation would entail significant -- perhaps unacceptable -- risk to the enterprise.  Therefore, I would expect to see this IRS regulation explicitly addressed in its business strategy (what BRS calls a Policy Charter), within which it would be represented by one or more core business rules.

System Model.  Assume the Principle of Perfect Memory.  No special treatment is required for the IRS regulation in the system model because you can assume it will never 'forget' the transactions.  The seven-year horizon entails no special requirement for the system model!

Platform Model.  Keeping every one of the company's financial transactions on-line for seven years could prove expensive for a real-life platform.  So the requirement might be rendered in the platform model as follows:  Keep transaction history on-line for 30 days, then archive it to CD-ROM for the rest of the seven years.  Since users seldom access the data after the first month, the trade-off in longer access time is deemed worthwhile.

Incidentally, I think the requirement as rendered in the platform model could actually be expressed as platform rules.

Rule:  Data about a financial transaction must be kept on-line for 30 days from the date of completion.

Rule:  Data about a financial transaction must be archived to CD-ROM 30 days from the date of completion.

Rule:  Data about a financial transaction must be kept on a CD-ROM archive until seven years from the date of completion.

Note that these rules arise only in the context of the platform model -- not for business or system reasons directly.  So they are not business rules as expressed above!  I will have more to say about this kind of rule in a future column.

References

[1]  A reader reports that the concept appeared in McMenamin & Palmer's book, Essential Systems Analysis, Yourdon Press (1984), chapters 1 thru 4.  

[2]  For this discussion, we are interested in the Framework only as applied to information systems ('white-collar' capabilities as Zachman calls them) -- not the 'blue-collar' facilities of the business.  

[3]  This is how Zachman puts it.  Actually, any of the four kinds of model can be pursued to 'excruciating' level of detail.  

[4]  For convenience, from this point on I will drop the 'class of' from class of platform and say simply platform.  The distinction is not important for this discussion.  

[5]  Again as Zachman would put it.  

# # #