Enterprise System Integration.com

Flawless Integrated System Quality Assurance REQUIRES Zero-Defect Enterprise Architecture to be “designed in” from the earliest conceptualization of Enterprise Application Integration.

Zero-Defect Integrated systems can NOT be created as an afterthought by merging buggy haystack systems and cramming them together on a communications network (which exponentially multiplies the bugs in one badly-designed large application by the countless bugs in another).

The standardized, ruggedized, fail-safe protocols and interfaces between integrated, consolidated and optimized collaborative enterprise system components are clearly documented in the coordinating Enterprise Model. They are rigidly monitored and enforced by the Publish-and-Subscribe middleware. This makes it very easy to document, and automatically draw attention to component-part fault isolation, which is an essential first-step in integrated enterprise system quality assurance.

Another fundamental requirement of zero-defect software is that every software process must be comprehensively testable with automated systems that leave no room for human clerical error.

Most Enterprise Model Software Objects have message-oriented process-invocation interfaces. Suppose the message has one parameter, whose value is either ON or OFF. The internal code might have one IF statement to implement this binary functionality. The comprehensive automated test procedure would have to have (at least) two test cases: one to test ON and one to test the OFF behavior. If the invocation sequence has two ON / OFF parameters, the code would have (at lest) two IF statements, and require FOUR test cases for comprehensive zero-defect validation.

Suppose the code in one Object process module is a Microsoft-style haystack of ten IF statements. It would require 210 (two raised to the tenth power = 1024) test cases to ensure zero-defect validation. Many Microsoft system software components have over a hundred IF statements, making them impossible to test comprehensively in a lifetime.

Thus, Microsoft-style haystack hackers ALWAYS deliver untested buggy paths through their sloppy code. They do test it PARTIALLY, but never comprehensively. They rely on consumers to help with foolish Beta Tests of their untested code. After the code (like Microsoft Windows Vista) is delivered in production, they always get voluminous problem reports (which generally are ignored very a very-long time). Subtle, infrequently-reported, difficult-to-reproduce often go unsolved in the lifetime of buggy Microsoft software products. AND THEN the next release introduced far more bugs than the last one, compounding software implementation errors on top of overall conceptual design errors.

In Enterprise System Integration Zero-Defect Software Development Methodology, software defects are essentially never exposed to end users. There are no problem reports, and no large department required to accept problem reports, diagnose, or correct bugs (which at NOT allowed to exist).

Simple software automation tools are used to ensure that all software modules conform to zero-defect specifications. One tool counts the number of alternative paths in each module, and sends a report to each developer’s supervisor. More-than-a-few IF statements (etc.) are simply not tolerated. This accelerates the learning process for new (poorly-trained) software developers, and ensures that the SOURCE of software defects (poor coding technique) is reduced at the earliest possible point.

Message-oriented invocation interfaces are simplified, to greatly reduce the required number of  test cases. For example, instead of having an input parameter that is either ON or OFF, two different program modules are designed with NO input parameters (and no internal IF statements): one module is provided for ON, and a different module for OFF. Thus, fewer test cases are required for each software module, greatly lowering zero-defect development and testing complexity and cost.

In contrast, software development costs increase exponential with the number of test cases that are required for comprehensive quality assurance. Thus, rigid automated enforcement of zero-defect development methodology cost MUCH LESS than Bill Gates’ “features-instead-of-quality” haystack hacking.

When zero-defect code is being tested, software execution monitors count the number of times that each line of code is invoked, and a report is sent to the developer’s supervisor. If even one line is never invoked during automated testing, the test cases are clearly incomplete, and the module can NOT be certified as ready for zero-defect deployment. Once again, the automation of error-free methodology draws immediate attention to potential software fault-isolation locations.

When all software Object process modules are comprehensively tested and certified “Zero Defect” then the only remaining possibilities for software defects (not including hardware failures) are in the Enterprise System Integration protocols and interfaces themselves.

BEFORE Object-Oriented processes are written and tested, the invocation trigger messages, data attributes, and business rules / logic must be documented in the conceptual Enterprise Object Model.

One starting point is a set of Enterprise System “Use Cases.” They ignore “How” and “Where” the functionality will eventually be implemented, and merely document invocation input, internal logic, and external output. They do not even have to specify what business events may invoke them, or who is interested in their output, since these concepts can be specified any time in the future in the business event Publish-and-Subscribe Middleware, Enterprise System Integration Model. Use Cases are published to potential stakeholders with a need to know. As they become aware of future system possibilities, they can help refine planned use cases and system functionality. They can register a subscription to enterprise-wide use-case-based system development negotiations, and optionally be added to sign-off approval lists.

Use cases are refined and evolve over time into the foundational basis for comprehensive system test cases, AND final System Acceptance criteria. It is like giving out the final exam with all of the correct answers on the first day of class. Zero-Defect Quality Assurance begins long before the first line of code is written. As system specifications change, and mid-course correction take place, the potential enterprise impacts are distributed to stakeholders in a matter of very few seconds. Mid-course corrections are INVITED at the earliest possible point and the impact of change, new governmental reporting requirements, etc. are dealt with far better and faster than in any other system development methodology.

Use cases specify the types of Business Objects that they can act upon. As use cases are iteratively refined, so are the requirements for new complex composite Business Object VIEWS (discussed above). The Enterprise System Integration (ESI) Model makes it easy to monitor and manage the rapid, cost-effective development and deployment process.

When a work-in-progress use case is ready to begin prototype coding, the Enterprise Object Model is used to GENERATE the Object-Oriented Programming Language (C++. Java, C#, etc.) CLASS statements. This ensures that the interface code precisely matches the Enterprise Model. If the coder needs to alter the CLASS statement, reverse-engineering resynchronizes the model with the current state of the code. The system software component interface documentation is thus written BEFORE the code, and always up-to-date and accurate. (Unlike after-the-fact, clerical-error-prone, manually-written, obsolete system documentation.)

For decades, certain types of “life critical” software development has known how to develop complex systems that have NEVER failed. This approach was largely abandoned in the era of small-scale software thinking (e.g., micro-soft). Bill Gates has often said that: “People don’t buy software quality, they buy features.”

The general disregard for propagating millions of subtle software defects (in pervasive software systems) is a very serious reliability and productivity problem that has been growing exponentially worse over time. The latest release of Microsoft Windows Vista is a very clear demonstration of the perils of haystack code development that is impossible to ever completely debug. It was distributed with thousands of lines of bad code that had NEVER been tested before it went into production sales.

Bill Gates taught his people that they should not waste time or money on comprehensive zero-defect quality assurance. His low-quality approach has surprisingly been extremely profitable. Naive consumers (with no critical thinking skills) continue to accept this low-quality foolishness, despite the fact that every new Microsoft release has MORE complex software defects than any previous release, and it is loaded with poorly-designed, awkward  features that few people appreciate or know how to use. New Microsoft systems are usually not even completely compatible with previous systems, making transition very costly AND error prone. Major application rewrites are required to move from non-standard immature concepts like COM, DCOM, DNA and C# .net. These rewrite introduce new, easily-avoidable software defects, that could have been greatly reduce by using highly-refined mature industry software standards.

In one-time-invocation life-critical software systems (such as the launch of a unique new billion-dollar spacecraft), it is impossible to rely on a Microsoft-style “Beta Test.” A “blue screen of death” is unacceptable under any circumstance when the lives of many people (such as fly-by-wire aircraft avionics) are involved. The old joke goes that IF Microsoft wrote the code for heart pacemakers, they would use the “blue SKIN of death” to display their many software defects. (Sad, but soooo funny)

We have understood how to Eliminate Software Defects Altogether for a very long time. In modern jumbo jets and military fighters, when pilots turn the wheel or move the control stick, they are NOT using metal cables to move the ailerons or control surfaces (as was done half a century ago). The pilots of modern aircraft are probably compressing a crystal at the center of the yoke, which uses absolutely flawless computer software to control the hydraulics. If small-scale (Microsoft) “features-instead-of-quality” thinking produced aircraft avionics, airplanes would constantly be falling out of the sky, and millions would die.

The very interesting thing to note at this point is that IT COSTS MUCH LESS TO PRODUCE ZERO DEFECT SOFTWARE than the highly-flawed irresponsible code that flows continuously out of Microsoft-like haystack hackers. It is NOT hard to produce life-critical zero-defect computer systems – It is just VERY DIFFERENT than pervasive careless computer-system coding.

Conditions of Formation: Block ice and snow are both states of H2O water. But, they form under very-different below-freezing conditions. If you take a foot of light fluffy snow and put it in the kind of freezer used to make solid block ice, the snow will NOT turn into ice. It stays snow no matter how cold you make it. It must be melted back down into liquid water before it can be made into solid ice.

Conditions of Formation: Block ice and snow are both states of H2O water – The same molecule produces very different substances. Ice and Snow form under very-different below-freezing conditions. If you take a foot of light fluffy snow and put it in the kind of freezer used to make solid block ice, the snow will NOT turn into ice. It stays snow no matter how cold you make it. It must be melted back down into liquid water before it can be made into solid ice.

So it is with haystack hackers. Once a Bill-Gates-era manager or college professor teaches them that “features are more important than quality,” their minds become set and they essentially can NEVER learn zero defect development, without a total mental reset about how to efficiently write reliable computer programs.