Legacy and Green Field

This is a reprint of an article (August 2003 COE Newsletter) that concerned the then-state-of-the-art (v4 – LeFo) and the new environment (v5 - GFiv). The article used three major categories to discuss the subject, namely CAD-off-the-shelf (CoT), expertise related to using CoT (ExP), and intelligent use of CoT by KBE (CyB). For definitions, see bottom of the articles.

The intent of the article was to look forward given where we were with the occasional look back as needed. The use of LeFo and GFiv, in terms of legacy and green field, respectively, was not meant to refer to CATIA strictly; rather, the article discussed the KBE industry as a whole as it pondered next steps. CoT included the sum total of CAD/CAM/CAE/etc. capability plus the human side as it existed. Related to KBE were two components: ExP represents expertise as encapsulated in a human domain expert. CyB was the computational collection that could demonstrate expertise bordering on intelligent behavior.

The article in the below reprint has only a few minor modifications, such as links to supporting material that is accessible via the World Wide Web.

Background
As one looks at the computer in a modern day setting many things come to mind, such as ubiquity and intelligence. At any point in time, the playing field is immense supporting many diverse activities. Restricting the view to the portion only related to CoT still leaves a very large picture.

Application of CoT occurs in a myriad ways daily; but, changes can also be pending, as research and development continue to push horizons. Any static basis for viewing CoT will be conditioned by the technology and the time. Though we do not have foresight that is 20-20, we can think about the important factors and look at the possibilities (this is not unlike how we handle the undecidables - covered later in the article).

Two concepts of interest here are Green Field and Legacy.

• Green Field (GF) denotes the new horizons where current methods have little or no influence. In our context, this can be thought of as the GFiv framework and as venturing forward without any Legacy. GF deals with the promise offered by an entirely new approach. In actuality, there are not many times when the new is completely devoid of any traces of the past; though, these traces can fade over time. Even if this is not apparent at the application (domain) level, it is true at the core of systems where proven techniques carry across generations. So, given that a GF would have a Legacy, perhaps a proper basis for the GF in the present will allow its Legacy to continue far longer than we expect.
• Legacy (LY), as used by this article, denotes the current state that might have portions from several generations or that might just be predominately LeFo in nature. LY can take on pejorative connotations, as it deals with what we know. Familiarity allows insight into quirks and failings (LY, unlike the GF, does not have a greener grass syndrome). In a sense, LY might just apply to the current basis, which ought to be something that grows in capability and in trustworthiness through time. As mentioned before, in the computer industry change occurs so rapidly that it is not rare to have several generations of capability co-existing within a domain. In terms of an analogy, chemical forms can be thought of as LY to the GF of biological life (LY is the basis for GF capability).

Some LY systems will face the question of using LeFo or GFiv, at some point. One thing to discuss will be how this type of transition, which may not be minor, will happen. A pure GF seems to be mostly a hypothetical notion; more likely would be a mixture of GF and LY. There can be many relationships, such as the hierarchical structure or a recursive relation. That is, the GF and LY dynamic ought to be ongoing as we progress in capability; from time to time, there may be major changes (paradigm shifts).

This article will look at these two in terms of representation (structure), methods (operations), and quality (measurement). Again the view is from outside of CoT, looking at the matter from the side of the user. Since we can think of the computer as the continually improving enabler, the article is looking at how an ExP process might apply the newer ways. A major factor for the new approach might be the benefit of faster processing; any benefit would have a cost in terms of dollars and in effort on the part of the ExP to adapt the process.

Since this article covers a fairly large subject, it mostly looks at the general issues. Here and there will be brief reference to a topic that will be a separate article. One assumption is that the GFiv context will open up computer modeling particulars to the user community (through the Automation API); the open field is vast with many unknowns. The experience of KBE shows the power of the approach (allowing user expression of knowledge) and suggests both the potential boon and bane.

Representation
Representation deals with structure and can differ between GF and LY. Structure variations abound; for the most part, LY applications have settled on what is efficient from their view, but that does not mean that the LY representation is not without pending changes. It is not always clear if change, whether in the GF or LY sense, will be for the better or worse (undecidability) before the fact. The process dealing with the structural improvement would need to manage this risk.

One GF approach would look for generalities (patterns) and model those. Such work needs to be tempered with the 'anti-patterns' that can override generalities, when necessary. A common theme has been the friction between the general and specific views. The dynamics of these issues will play out over time and will be more aptly handled if we have both GF and LY frameworks from which to work.

A prominent way to handle modeling is the class that offers a way to describe structure and to put a name on some one thing. The class description would include attributes that stand for properties. The class also can be either of a general or a specific nature. In a sense, the class is only a definition, participates in relationships and roles, and gets gathered into collections. Classes have methods that can be thought of as action descriptions (next section). The way classes and their combinations (we can call these 'type') are used is through the object. Objects are created via a make operation (instantiation) on a type. Even simple objects are not small creatures, as we will be below using a point as the example.

Given that classes can be mixed, the GF approach allows collections that make sense in the ExP world. For instance, in the LY framework, a 'hole' was a collection of geometry such as cylinders and fillets. The solid modeler might have taken care of the bookkeeping, yet operations on the hole had to be accomplished at a fairly detailed level. The GF variant would be a 'hole' that is a type with a large collection of properties. It would have a name (handle) and allow operations at a higher level. One could change the type of the hole or move the hole with one operation.

Given the power of this type of representation, we can think about higher-order operations, such as morphing. This is an approach to parametric design in the GF framework that assumes that topological invariance, if known and managed, will allow adjustable geometry. That is, a change to one parameter of a hole can result in several effects, such as location change, size modification, and so forth.

There is no doubt that having 'types' as a basis is very powerful. In the GFiv era, the CoT has a large set of these pre-defined types with mechanisms available for interfacing with these either interactively or via the API. As well, there are means for making extensions to the currently defined set. At issue is how much effort will be put into mapping GF and LY views. Even though there is a cost to this mapping, one could make the argument that this type of bridging is imperative.

One way to look at the differences of GF and LY would be to consider a simple point. A point can be more complicated in the GF era than it was in prior times; now, several classes in GFiv may describe a point (such as geometry, shape, role). From a LY view, a point was expressed by coordinate values (xyz); this was simple enough, basically. Then, given the LY context, more characteristics might have been needed. It was left up to the application. There are many good examples, but consider Reverse Engineering (where we might want to know additional information about the point's origin) or presentation to the user (where a point might have color and shape).

From the newer (GF) view, a point can be several types. The Euclidian point would have xyz; a planar point would only have xy; points can also be of dimension greater than 3, such as a point used for multivariate optimization. For any point, shape and representation properties of the point would be inherited via a class structure. This means that there will be a larger footprint in the modern scheme for the simple point than there was before.

The upside, though, is the richness of the representation. That is, general properties can now become commonly defined. One benefit would be more ease in moving data between applications and sites. In the LY era, since additions were related to the applications, there were many ways to store the information; there generally was no agreement about the definitions.

In the newer era, the definitions are more common, with some agreement about use (an area needing attention). Adding in new features is a type of specialization. In theory, the base types can be held constant and additions made that are independent. One benefit of the new way would be the improvement that the commonality will allow for better data modeling (object-oriented database with class structure inherent in the schema).

Another concept for the object is the role. For instance, a point can have several roles, such as being a vertex or being a center point. The properties would vary according to the use. Of concern will be how the structure might change for different roles. One approach to this would be to have mutable structures (this is the representation analogue of morphing, see above). Such adaptability would allow structure to change by viewpoint and is a highly complicated technique that we need to learn to manage. Through means such as adjustable structures and improved methods, the computer will be able to adapt to the ExP world in both the GF and LY senses.

Methods
Methods have a GF and LY flavor similar to representation. In fact, from certain views it is hard to separate these two due to their interrelationship. To discuss some of the issues, consider that methods can be put into two major categories, irrespective of whether they are GF or LY.

• Process - Those methods dealing with things as they work (definition not limited by computational support) in the ExP world that have priority from several perspectives.
• Enabler - Those methods dealing with support for a process. These methods can be either CoT or CyB but are not limited to computation.

We have much more experience with the process; therefore it can be better founded than the enabler, in many cases. Our processes have accounted for much progress, including the enablers themselves as they result from attempts at automating processes, to a large degree. Processes are always under scrutiny and being improved. Enablers undergo the same dynamic; witness the attention in the software industry in trying to mature their products via better processes.

One characteristic of the current state is that the GF enablers can demonstrate a lot of power and proficiency such that they can play more major roles in processes. Where enablers are prominently superior to the processes (and this is a quasi-empirical question), the human world will adapt in order obtain the benefits. But, as we will see with quality, the use of enablers can be a two-edged sword; until an enabler is proven, the process would take precedence depending upon the risk.

There is a difference in how we handle process versus enabler. Knowledge related to methods (both a process and its enablers) may be internal or external to the company. The existence of off-loading shows how external methods may deal with processes or enablers. In terms of the external processes, documentation and observables allow management and quality measurement. External enablers mostly will be handled through behavioral means, due to the black-box nature of delivery.

As it happens, internal enablers can be managed the same way. Even when there are analogues between the process and enabler viewpoints, several factors contribute toward making access to computational aspects elements less than desirable. The framework of information hiding is one aspect. Success in this approach will be related to how well the representation and methods actually reflect the ExP domains. This will require a major focus for both GF and LY as we progress through time.

Again, for enablers, it is not necessarily an external/internal dynamic that is the problem. Internal code, even if accessible, may not be understandable. This is a property that results from several modern quandaries: disparate disciplines, complication (breadth), difficulty (depth), undecidability, and more. Methods must deal with computational truth handling, which would lead to quasi-empirical processes and more advanced logic being coupled with numeric processing.

Another aspect that will be important to methods is the level of completion. In some ways, a series of methods might be a balance of process and enablers; we already see this with the interplay between the ExP and CoT. Such interaction requires proper handling of partial steps and results, almost like a volleying of control. We have seen various attempts at this; a smart warm start is a simple example. With growing interplay of representation and methods though, it will become more intricate. One can only marvel at the potential of an enlightened interplay between ExP and CoT. At issue will the assumption that order is not of importance; we learned this through dealing with commutative spaces. There are situations where the commutative assumption breaks down; we already know this through dealing with matrices in numeric processing. We will see it more as the need for advanced approaches (such as non-monotonic logic) comes to fore.

In representation, mention was made about adjustable structure, with morphing given as an analog. There will be many types of mutable entities as the CoT and CyB capability grows through time. In the new mix of GF and LY, we will see many new quality concerns as we scrutinize the growing complexity of processes and enablers.

Quality
Quality will be of special interest as it handles the transitions from LY to GF. As was mentioned earlier, this is a continuing dynamic, though some may face a major threshold with the growing presence of the GFiv environment. One problem that quality faces is that it is difficult to determine what is inherently true; this is one major aspect of undecidability in computation that will be addressed further below. One thing that we have learned through experience is the statistical nature of applying measures. That type of expertise will continue to be of use but will grow in complexity. We will need to consider several aspects, such as the measurement act itself and how we're interpreting the results.

In natural phenomenon, we can look for strong relationships that hold up under time and observation. With the computational metaphor on the other hand, we cannot assume that we've established such a strong counterpart for our relationship with the computer (we need to develop disciplines such as software physics). We also need to adopt better means for handling the dynamics of software.

At decision points related to dynamic phenomenon, we can use a model that allows three major parts to be ascribed to an event. A very common idea is to accept two of these: the before and the after states. Normally, mapping strategies don't consider more than these two, as the common practice is to only think of input and output (by definition, a function has an in and an out). We see this notion applied everywhere, especially with the growing use of the computational metaphor.

However, there is a third state that we can consider, namely the in-between state. In certain types of thinking, this lost item can be very important. One example would be differential equations that will play a heavy role in CoT affairs. The main issue with the third state is whether it matters how things are accomplished. That issue can, in many cases, be reduced to being of no concern; undecidability brings it back to fore.

We can call these three by the following definition.

Q - This is the input side of the equation. It deals with the state prior to an event and has to do with what might be called pre-conditions. These conditions, if related to normal operations, can be reduced through causal analysis to a small set of factors. That reduction activity is the focus a whole lot of intellectual work.

R - This is the output side. It deals with the state after an event and what are the new values, so to speak. The description can become quite complicated given higher-order objects with many property changes. The advanced design context is full of examples.

F - This is the third item; it deals with between state issues. That is, unless the change and the time step are modeled almost infinitely small, there are many things that occur in-between Q and R. In a sense, a lot of our modeling work looks at trying to remove this piece of the puzzle.

So, to take one example, many functional relations in linear systems are essentially mappings from the Q to the R sides, where both sides contain well-behaved entities. There are too many examples to mention, as they are everywhere. Several factors can lend to the situation where we need to worry about this common method. This will be the topic of a future article.

Above, morphing as a parametric method assuming invariant topology was offered as an example of adaptation. Topological choices sometimes can be thought of as binary, where we worry about whether something is in or out. Other choice types also take this complementary stance. Advanced logical situations, though, need to be multivalent, which one might argue is allowing the F (or excluded middle, in a sense) to get a little attention.

As one would expect, greater complexity can lead to more concern about undecidability. Being that a decision is undecidable does not mean that we cannot make a reasonable determination. There have been many operational variants proposed and applied to handle this type of situation. The main thing to remember is that no theory supports a priori the potential of any of these methods over the others. Many people are struggling with the issue. Those involved in the situations work out their best approach through management of practices.

As Stephen Wolfram explains in his book "A New Kind of Science", we can use chemistry to look at undecidability. Wolfram writes, "For even though the basic physical laws relevant to chemical compounds have been known since the early 1900s, it remains extremely difficult to predict the actual properties of a given compound." He goes on talking about the combinatorics of trying new compounds, which is a very expensive proposition in time and cost. In evaluating how to make new compounds, it is "undecidable whether a given set of possible transformations can ever be combined to yield a particular compound." That is, we have to do the actual experiments; we cannot rely solely on our predictions obtained via advanced computation (however, we can hope that there is a substantial base of knowledge that is stable and capable of supporting predictive methods - this is one challenge for KBE).

Now, to put it in the context of the article, we see a growing interest in the industry to apply continuous improvements from the increasing advent of Lean thinking. In the past, there was an adage that "if something was not broken, don't fix it" which really was a folklore intuition from experience that relates to other adages such as the "can of worms" or the historic notions about Pandora's Box. In the more modern context of Lean and with growing confidence in our understanding of physical phenomenon, the adage is "if something is not broken, fit it" as this relays the truth that nothing is optimal. Due to not being perfect, things are always subject to some improvement.

The success of efforts at improvement in process in the Lean context relies on our knowledge of nature, of our capabilities, and our process. That is, the long successful practices of science and engineering have produced good methods that can be repeated between situations. When the computer is introduced, we have a serious change in dynamic. Of course, it depends upon the type of computational methods, but for some approaches the presence of undecidability will be problematic. We need an additional caveat dealing with a 'fix' to something that is computational: the fix activity must focus on completion and evaluation of the completion to the extent necessary, despite the projections. Even if the fix turns out to be more difficult than realized, the 'box opened by the fix activity' nevertheless needs to be re-closed once it has been opened. A reasonable fallback position to GF problems is the LY. Perhaps, we can use the current situation to understand the issues related to GF and LY better.

Conclusion
This article looks at the current state as it applies to using older or newer systems in the sense of the Legacy versus the Green Field. This type of discussion is prevalent now, such as in the context of deciding between LeFo and GFiv and involves the introduction of KBE to the ExP and CoT framework. This point-in-time discussion really applies to a longer-term strategy that concerns continual improvements to the balance between process and enabler. The computational aspects require special attention, some of which will involve a cooperative evolution by all the players, where the computer provides increasing intelligence to the equation.

For further discussion of the content of this article, please contact the author.

John M. Switlik (john.m.switlik@ieee.org, 1-316-204-0758) has interests that cover a broad spectrum: computational support for applied science, mathematics, and management; lifecycle and veracity control for system, application, and domain engineering; integration, use, and quality of computational knowledge; truth engineering.

Definitions
LeFo - The former/current computational era that excelled despite serious constraints on resources.
GFiv - The current/future computational era with open issues about resources.
KBE - Knowledge Based Engineering
CoT - CAD/CAM/CAE/etc. plus "Top Gun" talents. This element does not subsume CyB.
ExP - Expertise as encapsulated in a domain expert.
CyB- Hardware, software, control, and KBE demonstrating expertise.
Green Field - The open book situation having few constraints.
Legacy - The situation that needs to consider constraints from current states.
Q, R, F - the qualification, ramification, and frame concepts defined for non-monotonic reasoning