Why Do We Need Business Knowledge Engineering?

Introduction (v1.0)

It is widely understood that the world economy is changing business practices in large enterprises more rapidly than ever before, with no end in sight.

At no time in history has there been such pressure for agility at all levels and aspects of business enterprise planning and operations. Many new tools, architectures, and styles of business and IT architecture have been developed to cope with this pressure to change. Not only to help enterprises to be more efficient and profitable, but also to avoid the liabilities and losses which result from operational disasters, such as personal identity and credit information being lost or stolen due to unrecognized system design flaws. Most of the new ideas and methods for managing pressures for agile change without risking the introduction of unintended consequences have come in response to the rapid rate of technological change over the past 50 years, especially in IT, but other pressures for agile change have come from the realization that enterprise business objectives are better served with more effective quality and security policy systems such as ISO and Six Sigma, systems that enhance overall customer satisfaction and transactional comfort.

This white paper examines an aspect of Service Science known as the Service Oriented Architecture (SOA) and its relationship to both IT and business knowledge. SOA is an example of one of the most popular of the new business/IT architectural styles to gain popularity in recent years. One of the questions this paper raises is whether SOA alone is sufficient to meet the business modeling and agility challenges facing business enterprises in the global and Internet economy. (See reference 1 for detailed definition of SOA and reference 3 for Service Science)

If SOA is not sufficient, what else is necessary? And why should business enterprise managers care?

 

Why do we need Business/IT Architecture and Engineering?

No one asks such questions about buildings or cities or the Space Shuttle or computer systems. People have learned over the past half century what happens without good architecture, engineering, and management practices. For example, both of the Space Shuttle orbiters that were lost crashed because of failures in all three of these areas. Those responsible failed to perform their roles in the manner required to properly interface all aspects of the NASA enterprise to conduct safe missions. In both cases the crashes were directly caused by failures in architecture, engineering, and judgment of the managers involved in key decisions.

Given such a dramatic example of its importance, why is the need for architecture and engineering questioned as necessary to fully integrate all the knowledge needed to successfully run large business enterprises? Perhaps the need is questioned merely because business people are not used to thinking about business in scientific and engineering terms, only buildings and technology. But whatever the reason, that thinking has been changing in recent years.

One part of the reason for the change in thinking by business people is the transparency and speed with which information moves today over the Internet. Another part of the reason for this change has to do with the history of technology. Over the past 50 years, many lessons have been learned the hard way through business failures and other disasters, many because business knowledge, quality management, and IT were not properly integrated. For example, it is well known to many in the IT industry that in the 1960s and 1970s there were many millions of dollars wasted on huge mainframe computer systems that either did not work at all or only worked in a marginal way because their designers had completely ignored aspects of the business that were crucial for their success, crucial for such large computer systems to operate effectively and profitably. In many cases, these problems were discovered only after the systems had been installed, and most of the failures were traced back to poor design practices, and in some cases, no design at all. To solve these problems, some people in the computer industry decided to imitate the practices in the building industry for a design new model. By that time, the building industry had already put in place standardized design and engineering practices to remedy their own problems with professional practices, such as famous bridge collapses or building design failures. Like building architects and engineers, software programmers began to design, model, and engineer their software products, instead of simply “hacking” them. This change plus the introduction of quality management in many companies led business managers to become more design and model oriented as well, in the ways they think and operate. Today, IBM actually calls their software designers “architects.” The result of these changesd over the years has been much improved IT departments, software applications that are much better integrated with business operations, and many more satisfied computer customers and users.

Over the past 50 years we have gone from old fashioned command line oriented Fortran and COBOL systems to computer systems with graphical user interfaces, to systems with object oriented programming, to systems with service oriented architectures that operate by messaging and even use Web-based service delivery packs for specific lines of business. Given all that has been learned along the way, what improvements still are needed to better build complex business software and to ensure that the software improves business operation, efficiency, quality, customer satisfaction, and profitability?

The advent of software design, modeling, and engineering started with simple flow charts and other similar tools, and eventually reached the level of sophisticated cognitive modeling that included processes performed by people (as processors), and included the process controls, instead of merely the simplistic the process box inputs and outputs found in flow charts. Soon, other aspects of enterprise business processes that software depends on (but are not computerized) were also captured, considered, and sometimes improved as part of the software design process by systems analysts. Eventually, the entire internal, “back end” aspects of business enterprises were analyzed as part of the architecture of IT systems by software architects and engineers to make sure they could work smoothly together as part of a process of systems integration. Many methods and tools invented to enhance these processes such as object oriented system design and programming, object reuse, object messaging, Computer Aided Software Engineering (CASE) tools that could automatically generate code from design models, and so on started spilling over into other areas of the enterprise. This happened because the concepts these tools depended on proved useful for business people to think about how to improve other issues and problems besides those of IT. Business models soon started to appear that enabled the redesign of large parts of the enterprise (including the manual parts), and these in turn required changes to IT systems. Unfortunately in the current design process, only a small portion of the overall business knowledge collected by analysts is used in the software design.

Before the Internet, business processes tended to changed slowly. That made it possible for IT architects and software engineers to modify IT systems slowly on an as needed basis. With the advent of the Internet and the global economy, however, the need for IT system modification came much faster. Those companies who responded quickly in a more agile way without inadvertently introducing design flaws into their systems were able to grow profitable business faster and with lower costs than companies who could not. Soon, it became apparent that an overall system was needed in order to make orderly changes and ensure system integration. In addition, as computer-aided modeling tools found more and more applications in big companies, many large business enterprises began to restructure as a result of the fact that computer-aided modeling tools made visible glaring problems and inefficiencies that previously there was no easy way to identify. About the same time, it was recognize that if a business enterprise was thought of using a modified form of the “object,” “messaging,” and other concepts that had been very successful in graphical user interfaces and in object oriented programming, business enterprises might be improved themselves, by using similar concepts. So some people started thinking about their enterprise operations in terms of “services” that exchanged standardized “objects” and “messages” as inputs, outputs, processors, and controls. All of these factors together led to the observation that a single, consistent architecture was needed for both the enterprise internals and IT systems, in order to keep them synchronized. Eventually, this architecture became known as SOA, or Service Oriented Architecture.

A brief description and review of SOA can be found in references 1 and 2. This has not been included, as the details of SOA are outside the scope of this paper. The description includes the specific architectural principles for SOA, and how these make it possible for large business enterprises to scale more easily using SOA. In addition, there is and explanation of the importance of the registry of all services and a knowledge engineered data base repository that SOA requires to function, how it adds value to the system. Finally, there is information about how adding Business line service Packs and Service Delivery Platforms (SDPs) for specific business lines make great products to sell to customers, as well as helping service software designers make better-faster-cheaper software artifacts. IBM decided to implement SOA in the form of its WebSphere Fabric and business line service packs, and other vendors have their own implementations.

Much has been written about SOA and advanced SOA, its benefits and deficiencies, but the real question is this: Is the SOA alone sufficient for enterprise success as a business architecture system?

 

Is the SOA Business Architecture Sufficient for Enterprise Success?

The short answer is no. The reason SOA is not sufficient is that SOA is only useful for planning and implementing the “What to Do?” part of the business. With the addition of Service Oriented Modeling Applications (SOMAs), Service Oriented Business Applications (SOBAs), pre-built Business line service Packs, and Service Deliver Platforms (SDPs), SOA can be expanded to address the “How to do it?” parts of the enterprise business for IT planning and implementation. But SOA has little to say about the identification part of business analysis, the evaluation part, and the planning part. These are the “What is?” and “What should be?” aspects of systems analysis for the business enterprise, especially the implicit human goals and business knowledge of the people who run the business enterprises. So we can conclude that SOA is not an integrated architecture system that covers the entire enterprise. SOA is an excellent architecture for planning and actualizing agile, best practice implementations for services, but not for identifying existing business structure and process, for evaluating existing policy and processes, and for setting new enterprise business objectives and processes for the future. These areas are more abstract than the level that SOA is designed to address, areas that are currently left to human “processors” with the organized knowledge they have in their minds of the business they run. It is these human processors that set goals, do evaluation, and do the other processing necessary for making policy, and so on. (See reference 2)

Typically, as mentioned above, software designers only use about 10-20% of the knowledge necessary to understand the operation of a business to build the software applications used to automate business functions. System design artifacts are abstractions of the objects, processes, processors, and controls of the business, abstractions that are made by systems analysts, some of which are then used by the programmers to write the computer code for IT systems. Object oriented programming and SOA have added a little bit more information to these design documents than was formerly there, but not very much more, compared to the vast amount contained in ordinary language descriptions and firsthand observations of enterprise operations that systems analysts have in their heads. The computer code must take goals and knowledge of human business people into account, so the people can interface with it and with the various business functions can be automated, but most of the human goals and conceptual knowledge do not become explicit parts of the IT architecture and computer code itself. So once the analysis is done and the computer code is written, most of the human knowledge the systems analysts had to learn to architect the software application design is lost as the analysts move on to other projects. This knowledge has to be relearned by the next group of analysts and programmers who replace or rewrite the computer code at some point in the future.

What if it was possible to save and reuse the abstractions and firsthand observations of the systems analysts? What if it was possible to save and reuse the human goals, evaluations, and other conceptual knowledge that gets discarded by systems analysts in the design process in use today?

In order to answer these questions, we need to find out what these observations and abstractions are, what the goals and evaluations are, what the conceptual knowledge is, and grasp how it could be captured in a way that so that it could be easily and productively reused. We also need to answer the following questions: What else is necessary to identify, evaluate, and plan for a completely integrated, consistent model of the entire business enterprise? How can the implicit goals and conceptual knowledge about the business enterprise now stored in the heads of people be represented, stored, and accessed for reuse in a reuse library? After all, there is no known way to do a download from people's brains, at least not yet? So what alternative is there? How can capturing these abstractions and building this kind of reuse model and associated metadata be automated or at least semi-automated? The answer to all of these questions can be provided by the emerging science of Business Knowledge Engineering (BKE)™ . (See reference 11)

 

Why do we need Business Knowledge Engineering?

Consider four major advances in computer technology in the past 25 years: The graphical user interface, object oriented programming, the client server model that made the Internet possible, and service oriented architecture. What do these advances all have in common? They all enable the people who build and use computer operating systems and applications to think in terms of analogs to real world objects and processes. These advances have made it possible for more and more people who are not trained in command-line level computer concepts and skills to use computers or more easily provide input to the IT people who are trained to build software. The advances also give IT professionals a valuable second perspective on the systems they build, as well as new graphical tools and methods for their trade.

By creating analog simulations to the way people naturally think and interact with the real world in computer operating systems and applications, these advances in computer technology have provided enormous benefits to software designers and users, as well as billions in profits for businesses. However, since programmers only need very specific, abstract IT related information to write code, the application design documentation programmers use leaves out most of the detail discovered by systems analysts as they learn about, abstract, evaluate, and document the business systems that the code must work with and support. If it is possible to identify and save more of the human goals, observations, conceptual business knowledge, and evaluation information that systems analysts don't use in their specifications to programmers, we can extend similar benefits to new areas of the enterprise. We can do so by reusing this information to simulate new aspects of the enterprise. These other areas are still mostly dominated only by manual human knowledge and processing, but BKE can supply the means to, at minimum, simulate and semi-automate some of this information flow, processing, and control. We can provide new graphical tools and simulation data structures to enable much of this vast knowledge resource to be reused.

To leverage all this implicit business knowledge is precisely what BKE is designed to do. BKE marries the domains of IT with human goal-directed action, evaluation, and conceptual knowledge in the context of the business enterprise to produce new benefits to the business enterprise, not the least of which is faster and more complete SOA software application designs.

Businesses are complex causal systems initiated and driven mainly by human volition, observation, abstraction, logical induction/deduction, evaluation abilities, and hard work. Businesses are hybrid systems that mix human and IT processors in many ways in order to automate as many of the causal chains in the enterprise system as possible to save human labor. When they operate successfully, businesses do so by enacting the right causes and effects at the right times and places, either by people directly, or indirectly through IT systems, to produce satisfied customers and profits. Implicit in such business operations are the observations, goals, and abstract business knowledge of the people who own and operate the businesses, and of the customers they do business with. These observations, goals, and their associated abstract conceptual knowledge are stored perceptually and conceptually in the minds of the business and customer people who play all the business roles. In fact, those who play all the roles in the business from customers to sales and support representatives to secretaries to middle managers or C-level corporate officers are called Subject Matter Experts (SMEs) by systems analysts. Each business role is an area of expertise, which directly or indirectly provides services to the other areas. These SMEs are the people analysts must go to in order to “pick their brains” to learn what they need to architect the SOA system designs they create for the programmers to turn into code. The question for BKE, therefore, is: How can we better capture human observations, goals, evaluations, actions, and abstract business knowledge for future reuse?

In state of the art SOA systems, architects design software applications for customers based on what SMEs show and tell the architects they need to have to improve their performance. The SMEs also provide detailed descriptions and explanations about their business goals and knowledge in ordinary human languages. Systems analysts, architects, software engineers, and programmers then process their own observations of what is going on in the business and decode this abstract knowledge to build the software applications to the specifications derived from the SMEs. As a direct result of this complex process, the software applications contain the correct artifacts and services (processes) necessary to enact the causes and the effects the business operators and their customers need.

As users use the applications, they request changes when the applications do not meet their goals. Many times this happens because the goals of the users or their customers get lost in the design process. This can happen if an analyst leaves out too much information when they abstract it for the design. Or sometimes information was not their in the first place because the customers never thought their goals through themselves, and so never gave the information to the analysts. Or because the analyst modeled the inputs, processes, and outputs, but left out the identity of the processor or the controls that limit process activity. In other cases, after some time has passed, changes are necessary because the goals of users or customers are changed by market forces acting on their business. If a lot of time has passed, the same analysts may no longer be available to the programmers, and all the business knowledge they had in their minds, but did not include in their system models and designs that were provided to the programmers, is lost. New systems analysts must start from scratch to recapture all the human observations, goals, evaluations, actions, and abstract business knowledge that has now been lost. This is an enormous waste of costly resources.

As mentioned earlier, the SOA analogy and terminology to ordinary human infrastructure building architecture and construction, and the analogy of thinking about computational processes as services is just the latest in a series of design and modeling techniques that have been developed over the years, such as the graphical user interface, client/server systems, and object oriented programming environments that have made thinking about computer software applications more like thinking about real world operations. Why is this trend occurring? It is occurring because thinking in terms of everyday objects and actions, causes and effects is common to all of us and what we all have the most experience with. Thinking in such terms is common to everyone because we all share the same world and our minds all follow similar patterns of conscious processing. We all perceive and identify the same world of objects, think in terms of those objects that act and interact in certain ways with certain cause and effects, and we have done so since we first opened our eyes and learned to use our senses and our minds.

In IT, the trend to object-orientation started with flow charts and expanded in many directions over the years to 4 Dimensional Cognitive Modeling (see reference 4), graphical interfaces, CASE tools, and now to SOA. But one thing that has largely been left out of the architecture and design processes along the way is the explicit representation of the human observations, goals, and abstract conceptual knowledge of the SMEs who actually perform the jobs being modeled. There are many reasons for this, not the least of which is that human observations, goals, and abstract knowledge have not been very well understood. This is especially true of the nature and operation of human conscious processes. Epistemology (theory of knowledge) is not a very popular subject these days. Psychology also has many conflicting theories about what consciousness is and how it works. But that is changing. Though not known by very many people, much study has been done over the past 40 years in one small corner of academia about the nature of human consciousness, and these academics have produced some new ideas. Their ideas include radical new approaches to sense perception (observation of the world), goal-directed action, how conceptual knowledge can be methodically abstracted, and how logical induction can be used to generate premises (sentences), so the resulting abstract knowledge can be represented using computer systems, and simulated using new software techniques. When applied to IT, we call this new study domain “computational epistemology.”

Most people would think of this as Artificial Intelligence (AI). In fact, many people lump Artificial Intelligence and Artificial Life (AL) into one subject. But actually, these two separate subjects cover hundreds of different topics from biology to robotics to computational linguistics. In fact in the past 20 years or so, AI has seen some loss of popularity for not living up to the expectations of many (After all, where is Hal? Or a Star Trek-like computer or a robot such as “Mr. Data,” for example?). But Artificial Life has been more successful in recent years than AI and produced some very popular movie characters, computer based ecology experiments, and life-like robotic simulations of pets and people, such as those produced by Patti Maes, Rodney Brooks, and the world famous Asimo robot of the Honda Motor corporation, the humanoid robot that can run up and down stairs. (See reference 7)

The fact becoming apparent to more and more people is that computer systems are more than calculators or systems for running large business enterprise software applications. Computer systems are in fact simulators, and there are plenty of examples to prove that assertion. Even an ordinary computer spreadsheet is a simulation of a pencil and paper spreadsheet accountants used for years and processed first with mental arithmetic, and later with hand calculators. Computer spreadsheet programs are merely very fast and accurate simulations of that manual process of using paper spreadsheets. What is missing from many such computer-based simulators, however, is human-like observations, goals, and abstract conceptual knowledge as seen from the simulator's own perspective . And that is why most computer software applications are merely passive processors. To make simulation applications that are pro-active like people are, the processes that enable them to simulate their own “observations,” “goals,” and “abstract conceptual knowledge” must be included as part of computer system architecture. That is the first step to being able to collect the human observations, goals, evaluations, actions, and abstract business knowledge discussed above, so it can be stored in reuse libraries.

It would take and entire book to even begin to explain in detail how to use computer technology to simulate human consciousness and conceptual knowledge in this way. However, by providing a few clarifications to some fundamental principles that most people already grasp in a general way, it is possible to trace an outline of how it is possible to do so using current day computer technology. The principles that need clarification to understand how to do this are as follows: The nature of goal-directed action, causation explained by the “object-identity” model (rather than the action-reaction “billiard ball” model most people use), life as caused by a more complex form of object-identity causality (rather than simple mechanistic causality), the methodical formation of the concepts which hold knowledge by means of a mathematical method (as opposed to intuition or arbitrary fiat), and the use of logical induction as a non-statistical means to encode simple sentences (premises). (See reference 8)

The study of goal-directed action or behavior is known as teleology, another not so popular science these days. Goal-directed action is different from mechanistic action and behavior. While the details of teleology are outside the scope of this paper, it is important for the reader to be clear about the differences. All action and behavior is causal, but mechanistic actions work by a simpler form of causation. The commonly accepted action-reaction model of two billiard balls colliding is an over simplification that does not explain the essence of how causality works. Causality is more than one event of a given type always observed to follow another. That context is set too narrowly.

If one sets the context somewhat more broadly, it is possible to see that all causation is determined by the identities of the acting objects. For example, if you take an egg and a soap bubble and drop them both from say a meter above the floor in your living room here on earth, the egg will fall and make a mess, while the soap bubble merely floats away. This is not an accident, nor could anyone's choice, nor could any other result occur, given the same objects and scale, conditions, and context. Each object has an action capacity in relation to the other and the earth. Its action capacity is determined entirely by the identity of the object, and that identity absolutely determines how it can interact with the identities of the other objects. The mechanistic, human scale laws of physics and mathematics measure, describe, and explain the exact causal relationships of how these objects will interact, and this is the only way they can interact. In addition, all object actions that operate by mechanistic causality are externally driven. (See reference 5, chapter 5)

The actions of life-forms on the other hand, are internally driven, yet the identity of life-forms also determines their action capacity. However, because the identity of life-forms is more complex, and because the actions of life-forms are internally driven and goal-directed, their actions are also causally more complex than passive, externally driven non-living objects. Though the internal, life supporting processes of goal-directed causality depend on and are made possible by simple mechanistic causality as well, a life-form as a system is more complicated than its individual non-living parts and processes. Those parts and processes are mechanistic. The goal-directed action by life-forms is an emergent property.

The internal, goal-directed causality of life processes is indirectly caused by the simpler mechanistic causes and effects of physics and chemistry. And though life-forms depend on outside energy like non-living processes, life processes are organized differently and in a separate context or supporting layer from mechanistic processes (as opposed to the unconditional existence of non-living, mechanistic causal processes). Living processes are more complex and causally different due to their conditional , self-regulated relationship with reality. The processes of all life-forms are self-generated, self-sustaining and self-regulating, so as to maintain certain conditions (those conditions their life depends on). For example, consider an earthworm and ice cube, both on sloping boards and under a heat lamp. Given the identities of the objects in this example, both the ice cube and the earthworm will move away from the heat, but for very different reasons . The ice cube moves by simple mechanistic, identity-action causality as the ice melts and the water reduces the friction between the ice and the board, thereby causing the cube to slide down the board by gravity, an outside force. The earthworm, on the other hand, causes its own movement internally, but by a much more complex form of identity-action causality. The self-contained sensor system inside the earthworm is genetically pre-set to values within the range of conditions that enable the earthworm to survive. These values, pre-set by evolution, are the implicit goals (life conditions) that the overall goal of survival of the life of earthworm depends on. (All earthworms that had different settings no longer exist because they died.) Since the heat lamp creates a temperature outside the conditions the earthworm's survival requires, the identity of the earthworm's internal regulation system causes it to move away from the heat. By so doing, the earthworm literally causes its own future survival.

As you can see, both of these actions are caused by identity-action causality, but compared to the ice cube, the causal steps of the earthworm are much more complex. In the general life causation diagram below, for example, the goals for the earthworm are movements away from heat to lower the temperature it is sensing on its skin. This internal, self-regulating processes cause the earthworm to move, and in each case, the movement away from the heat lamp directly causes the earthworm's survival and continued existence. This example demonstrates quite specifically how the causal complexity of life-forms differs from the simpler causality of mechanism. The ice cube has no goals or internal self-regulating processes. It simply melts according to the mechanistic laws of physics and chemistry.

(See reference 6, page 115, the earthworm example and causal action series is text only, the graphic created by author)

In order to be internally driven, a life-form needs to be self-powered, self-contained and have its own value system to enable its self-regulation. That is, for the self-contained processes to be conditional, they must really be dependent on certain conditions being maintained by the life-form itself and from its own unique perspective, not by the action of an outside entity (even though it may process and use outside energy). The life-form must therefore work to attain its values that keep it in existence, and avoid disvalues that threaten to cause the life-form to cease to exist. Values are the source of goals implicit in all life-forms, including humans. The actions of life-forms depend on their identity, and their identity is such that these actions truly are self-caused.

Only an entity with values can have goals. The very concept of goals depends on the concept of values, which is logically more primary. That is why a computer system can only simulate life-like behavior, not actually be alive, not actually have goals. Computer systems have no values of their one (only value to humans), they exist under conditions directly determined by humans, they run by simple mechanistic causality, and they depend on humans to keep them running. Computer systems can only be programmed to simulate the conditional behavior of life-forms, not to be alive. Actually trying to simulate life using computer systems, however, is a fairly recent idea that is becoming more common, and most of the simulations are designed only for human benefit, not that of the simulated life-form itself. Life simulation systems that also provide value for simulated life-forms can enable them to have more autonomy.

To summarize, values are the conditions required for a life-form to maintain its existence, to stay in existence, to survive. Without them, their processes stop and action ceases (they die), then they rot and disintegrate, they cease to exist in their original causally complex form, but instead revert back to causally simpler, mechanistic forms of their components. A simulation of a life-from using our patented goal-oriented life simulation technology architecture is a Digital Life-Form™ (DLF™ – see reference 8). Properly designed DLFs possess simulated consciousness, simulated values, and are a means of including goals into computer applications. DLFs can use these functions to identify objects by properties and measurements, and when sufficient objects have been identified, DLFs can then methodically form concepts by means of a mathematical method of abstraction that works by measurement comparison within a specific context.

To simulate human goals in software application architecture and design systems, a DLF is required in order to represent values and goals in the application design system. The DLF is a patented new kind of software agent that adds the system properties that make it possible to simulate goals and proactive behavior. To simulate human knowledge and skills other kinds of objects are needed as explained below, but the key idea to grasp is that it is the addition of these new kinds of objects that make it possible to simulate and engineer software agents to proactively carry out human goals (as their own goals), to store and use business knowledge in new ways. DLFs can also store and use IT knowledge and use it in computer application architecture design systems to enhance their capabilities. Obviously, more is needed to build a practical system, including the help of human architects, designers, and subject matter experts to make this kind of system work properly, but the items in the list above are the basics necessary to get past the current state of the art.

Let's be clear: BKE implemented with goal-directed agents that simulate consciousness such as DLFs is not about building a complete AI or AL robot system in an attempt to fully automate the production of software applications or products with a “Star Trek like” computer or “Mr. Data like” robot. BKE is about adding a few more kinds of agents and objects and processes to a SOA system to make it possible (within strict limits) to semi-automate some aspects of the software development process and to reuse more of the human abstract conceptual business knowledge than is possible with current practices.

If a DLF is included in the architecture, by virtue of its identity, its simulated value system and more complex causality that drives it, the DLF agent can identify objects, form concepts and construct ontologies, and then identify causal and other relationships between objects and concepts (but only within the set of permissions humans provide to set its action limits, and the ways human expert tutors set to interact with). That means a DLF is a self-motivating, self-regulating agent within a software design environment that can assist the human software engineers and designers---like the pro-active auto-pilot and collision avoidance systems that are in use to assist airline pilots to fly commercial airliners, for example. In the case of semi-automating software development, by making the goals and knowledge of both the customer and the IT people building the software applications a proactive part of the development environment, it is possible to free architects and software engineers to work on the most difficult problems, because the human goals and knowledge built into the overall product architecture and design system enable the DLFs to handle the easier, more routine problems.

Great idea you say, but how can you build such a system? The answer is by bootstrapping it, just like your computer does every time you start it up, and the entire computer industry has done from the very beginning. The main difference in this case is that the overall approach is very different from the way bootstrapping is done in state of the art systems because additional software layers have been added to incorporate the processes for goal-directed action, simulated consciousness (the identification process), methodical concept formation, and inductive premise generation.

The truth is, much of the hard work to enable this new bootstrapping process is already done. Nearly everything in modern computer software applications is already in the form of objects, processes, agents, and messages. Every object, process, agent and message in modern systems has an identity consisting of certain properties and measurements. In fact, it is the very identity of these objects and properties in every computer system which determines and enables the action capacity of that system, which determines and enables what it can do. If you alter the identity of the objects and/or processes, agents, or messages in a software application, then you alter its action capacity as just explained. That is what programmers do manually when they modify computer programs. A DLF system has a limited capacity to do this for itself and to itself.

 Bootstrapping works precisely because identity determines action capacity . A bootstrapping system acts on itself, it changes its own identity in a carefully scripted manner, and it thereby changes its own action capacity. A properly designed DLF can do the same thing (within the limits of its design and permissions, of course). By designing a DLF that has the simulated values and goals of both the customer and the IT people who architect, design, and build software applications, only a limited number of actions are possible, initially. But in order to do so, a DLF system must first identify and compare the measurements of the objects in its world and methodically conceptualize them. And this happens in a very different way than it does in the state of the art.

State of the art systems begin with a story invented by humans using ordinary language and their abstract conceptual knowledge that describes the system, what its goals and actions are, the concepts all of this depends on, the objects the system contains and their relationships, and so on. All of this information is abstracted by people, the details are omitted and the essence modeled, and then finally, what remains is converted into computer code. Such a process assumes from the outset that computers are mechanistic and passive and that only people can perform the identification and programming processes. This is true, of course, because state of the art computer systems are in fact organized in the manner just described. A DLF system operates in a different way to bootstrap itself.

Unlike an ordinary computer system, a DLF is pro-active, rather than passive. The DLF system bootstraps itself using its own built-in goals and actions (within specified limits), but DLFs do not wait for humans to act, like life-forms, DLFs are always acting, identifying the results, evaluating them against their goals and values, and acting again. The pre-set value system of a DLF has identification as a key value, so within the range of its permissions, a DLF agent identifies every object in its system of operation. It does so by “looking at or observing” the object files (reading them) and starting its own inventory and index.

At some pre-set point, the system begins to conceptualize or categorize the objects it is “aware” of, objects that are in the system inventory. Concepts are analogous to (though not the same as) “classes” in object oriented programming environments, but they are not formed the same way and not used for computer programming. Concepts are for the identification of their world by DLFs. Conceptualization as performed by DLFs is specific, patented kind of identification method that is a contextual and mathematical process that can be applied to any type of object, not just programming objects. Abstractions can also be formed from pre-existing concepts, in other words, from earlier formed concepts. The details of the process are outside the scope of this paper, but are fully explained in reference 8, mid way through chapter 5. Human help is required in this identification process. Humans provide the words used to name the concepts as DLFs are not designed to invent concept names, so a human tutor is required during the bootstrapping process to teach DLFs words and help them avoid errors (of contradiction and context).

Once a DLF has formed a significant number of concepts of objects, it treats these earlier formed concepts as new objects, and forms higher level concepts to build contextual ontologies of concepts at increasing levels of abstraction, until an ultimate genera is reached, such as the concept “object”. A DLF can also form concepts of actions and relationships. The conceptual ontologies are unbroken, hierarchical chains of concepts that connect the highest abstract concepts (the ultimate generae) with the actual software objects used to form them and define the structure of every context in the system. Human help is also required at this stage in the form of tutoring to provide the DLF with more human words to name the concepts it forms, as well as help identifying some of the relationships. (See reference 8, chapter 5)

Having reached this point in the bootstrapping process of identifying its world, a DLF can identify objects, process, and relationships with single words using the concepts in its conceptual system. For example, if a human tutor indicates a system object, the DLF can respond with the word that names not just that specific object, but every object of that type past, present, or future. This is possible because the contextual definitions the DLF has calculated are a part of the identities of the objects, and hence from the perspective of a DLF, any object of a given type has its conceptual definition as an integral part of it very identity. The context boundaries used when the concepts are formed ensure this will be the case for every member of the context. The definitions are all recalculated every time a context expands by the additions of new objects. (See reference 8 chapter 5)

The reverse of conceptual identification is possible at this point in the bootstrapping process as well. A DLF can simulate the understanding of single words by performing a reduction. That is, the DLF can trace the conceptual chain from a word, to its conceptual definition of an object concept to find an instance to show a human user as an example of that type object. (See reference 8 chapter 5) This is why it is important there are no broken conceptual chains in the system, ever.

As the number of concepts and words a DLF has connected with conceptual chains increases, a DLF is able to identify objects, processes, causal and other relationships with multiple words. This is made possible by the fact that as the number of ontologies a DLF has increases, any given instance of objects is likely to trigger more and more concepts. For example, an instance of an “insurance policy” would be identified as such by a DLF because the definition of the “insurance policy concept” is contained in its identity, and that would trigger the policy instance as a unit or instance of that concept. But many other concepts of action process and relationships would be triggered as well. These other concepts would provide the DLF with additional words for any identification attempt. Help from a human tutor would be required to teach the DLF to properly order the words, but for short, simple sentences of only 4-5 words, this is not a difficult problem. The DLF has formed concepts of words. The ordering of the words is simply learned as a new kind of relationship that is stored like any other, by the measurement ranges of the objects involved. (For more details, see reference 8, chapter 5)

The final step in the bootstrapping process is for DLFs to identify causation as a relationship to produce premises or simple sentences about causes. This is the real process of logical induction, and it is not statistical as most people have been led to believe. The logical induction process works by the same basic conceptual processes as object identification just described in the previous paragraphs, but the details are outside the scope of this paper. (See reference 10, which is an 8 CD lecture course.)

Eventually, as DLF agents acquire more knowledge and processing experience, they will require less help from their tutors to carry on simple design conversations with customers, architects, software engineers, and programmers. Through these conversations, business knowledge can be identified, conceptualized, and saved in a library for future reuse.

 

How Does Business Knowledge Engineering Work with DLFs?

BKE is analogous to SOA in many ways because it uses some similar attributes, especially abstraction, encapsulation, compose-ability, orchestration, and so on, but these terms as used in BKE have more specialized definitions. BKE actually works largely in parallel with SOA to store and apply the human goals and abstract conceptual business knowledge that are implicit in a SOA system, and which usually resides only in the minds of SOA systems analysts.

For example, an enterprise business vision, strategy, goals, and objectives in a business plan are high level abstractions in human language of the concrete actions that are performed by people and IT systems to carry them out in action. Just as with SOA, abstraction and encapsulation hides detail in human language sentences about business knowledge as well. For humans, abstraction is a method of forming concepts and ontologies for the purpose of hiding detail in a way that allows the detail to be exposed at will to specific audiences in predictable ways, just as SOA artifacts do so for IT systems. This is necessary because human consciousness as powerful as it may be is still a limited process, and only a few objects or concepts can be the focus of attention at any given time. DLFs use this same context oriented strategy to reduce processing units to manageable levels.

Special abstraction data types and ontologies are computational mechanisms that enable this capability in IT systems. People use concepts with human language premises and graphics to do something similar to build enterprise business models and business plans. BKE integrates and manages both SOA and human business planning and modeling into one complete, consistent system for the enterprise using many of the same ideas. Concepts, ontologies, and premises encapsulate the detail they subsume so it can be implied without actually specifying it in every context. The sentence: “In 2009, XYZ Insurance will increase profitable sales by 300%.” contains and implies all the specifics about how the enterprise, including the SOA artifacts necessary to accomplish that objective. It also subsumes or encapsulates all the objects, processes, and relationships that make it a valid premise and a true statement. All of that is what those 10 words in that order mean .

Once created, human language, logical deduction, and reduction can be used methodically to decompose ontologies and the concepts they contain to validate their logic to make sure all the necessary specifics are in fact contained in the enterprise systems, and integrated in a consistent way.

Human language and logical induction are analogues to the computational simulation methods of composing, linking, and orchestrating abstract data types (words and other premises) to identify causal and other types of relationships that exist between their contents, as determined by data object attribute measurement identification of the objects they contain (their hidden detail).

The specifics of how human conscious mental processes work to accomplish this are beyond the scope of this paper, but like with SOA, they are contained in the human mental analogs to SOMAs, SOBAs, SDPs, and so on. The specifics can be identified quite easily with 4 dimensional cognitive modeling and other similar techniques. (See reference 4) Then, they can be used directly, or eventually converted to computational simulation artifacts to enable their semi-automation.

The point to grasp here is that by adding a couple more levels of abstraction above that of SOA to the enterprise business logic that include simulated human goals and conceptual business knowledge for reuse, the architecture for the enterprise can be developed that integrates it all into one complete, self-consistent system. As pointed out in reference 2: “Enterprise Business Architecture should always represent the highest and most dominant architecture. Every service should be created with the intent to bring value to the business and the customer in some way, and such, must be traceable back to the business architecture.”

It is the job of BKE to ensure that this is always the case.

Conclusion

Based on the foregoing, it is evident that SOA alone is not sufficient to keep business enterprises competitive and successful in the modern global economy.

What is needed in addition is BKE as additional layers of abstraction in business enterprise models, abstraction layers that marry IT with human goals, pro-active agents, business conceptual knowledge, evaluation, and processing to ensure the entire business enterprise system is one integrated, consistent whole that is dedicated to achieving the business objectives that the enterprise has chosen to pursue.

Additionally, this paper outlines a BKE architecture to prove that this objective possible using the little known, but currently available patented DLF technology architecture from Blue Oak Mountain Technologies, Inc.

References

1. Wikipedia.org , http://en.wikipedia.org/wiki/Service-oriented_architecture
2. Wikipedia.org , section on SOA and Business Architecture (mid page)
3. Service Science, (also known as Service Research) is the science of the service industry and how to improve our knowledge of its workings. See http://thesrii.org/initiative.asp for more information.
4. MetaVision (aka: 4 Dimesional Cognitive Modeling) - patent # 5,233,513 , http://patft.uspto.gov/netacgi/nphParser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearchadv.htm&r=7&f=G&l=50&d=PTXT&S1=metavision&OS=metavision&RS=metavision William Doyle August 1993
5. Objectivism: The Philosophy of Ayn Rand - Dr. Leonard Peikoff, Dutton, 1991, ISBN# 0-525-93380-8
6. The Biological Basis of Teleological Concepts - Dr. Harry Binswanger, Ayn Rand Institute Press, 1990, ISBN# 0-9625336-0-2
7. a) Artificial Life meets Entertainment: Lifelike Autonomous Agents , Pattie Maes, 1995, MIT Media Lab, Rm. E15-305, 20 Ames Street, Cambridge, MA 02139, pattie@media.mit.edu Artificial Intelligence (Third Edition), b) Patrick Henry Winston, 1999, http://www.ascent.com/books , c) Redefining Robots, Smithsonian Magazine, February 2000 issue, d) Asimo http://asimo.honda.com/asimotv/
8. How to Simulate Consciousness Using a Computer System - Gregory J. Czora, Copyright 2001, published only on the Internet, a patented Digital Life-Form technology, http://www.blueoakmountaintech.com/DLF_Book.html/Cover.html
9. Introduction to Objectivist Epistemology - Ayn Rand, Meridian , Expanded Second Edition, 1990, ISBN# 0-453-00724-4
10. Induction in Philosophy and Physics - Dr. Leonard Peikoff, 2003, Second Renaissance, Inc.
11. Business Knowledge Engineering and its acronym BKE are trademarks of Blue Oak Mountain Technologies, Inc.

For information about licensing this new technology, just mailto:greg@blueoakmountaintech.com and we will contact you to discuss how you can become a licensee.

< Back to FAQ page

< Back to FAQ for Licensees, Investors, & Strategic Partners page

< Back to DLF Simulation Technology page

© Copyright 2008 - 2010, Blue Oak Mountain Technologies, Inc. All Rights Reserved

* STAR TREK and related marks are trademarks of Paramount Pictures Corporation.