Register | Login
RIPPLE-TRAC™ OFFERS A SOLUTION FOR INFORMATION SILOS

 

Legacy systems have been tuned and streamlined over many years, and they most likely perform very well. Leveraging these existing assets in place, where possible, is the best approach to capitalizing on the investment and years of work spent perfecting them.
An information silo is a management system incapable of shared operations with other, related management systems. A bank's management system, for example, is considered a silo if it cannot exchange information with other related systems within its own organization, or with the management systems of its customers, vendors, or business partners. "Information silo" is a derogatory expression that is useful for describing this type of relationship. 

The silo effect is a phrase that is currently popular in the business and organizational communities to describe a lack of communication and common goals between departments in an organization. It is the opposite of systems thinking in an organization. The silo effect gets its name from the farm storage silo, probably because there could be five silos right next to each other and if people were inside them they would not be able to communicate, since silos are tall, narrow buildings with no windows and are even supposed to be airtight.[WIKIPEDIA] http://en.wikipedia.org/wiki/Information_silo

 

Request our white paper on silos and RIPPLE-TRAC™.

See how a RIPPLE-TRAC™ session might work below.

We requested an impact on field ‘VARIABLE-START-POS’. We wish to change the size of this field. As you can see below, this field was found in module ZRULES seven times. Once in WORKING STORAGE (WS) and 6 times in the PROCEDURE DIVISION. (P)

 

 

 

MODULE

TYPE

PROJECT

BACKREF

COMPONENT

NAME

COMPONENT

DESCRIPTION  

ZRULES

C

   

COPY

XDCOMNC

 

ZRULES

F

   

(WS)

VARIABLE-START-POS

OFFSET NUMBER

ZRULES

C

   

COPY

XDLMID2C

 

ZRULES

C

   

COPY

XDLMIDC2

 

ZRULES

C

   

COPY

XS2034W

 

ZRULES

   

&XS2034W

..NO COMPONENTS

­

 

ZRULES

C

   

COPY

XS3300W

 

ZRULES

   

&XS3300W

..NO COMPONENTS

 

 

ZRULES

C

   

COPY

XS3300R

 

ZRULES

   

&XS3300R

..NO COMPONENTS

 

 

ZRULES

C

   

COPY

XSSTATE

 

ZRULES

   

&XSSTATE

..NO COMPONENTS

 

 

ZRULES

C

   

COPY(P)

XS2034P

 

ZRULES

   

&XS2034P

..NO COMPONENTS

 

 

ZRULES

C

   

COPY(P)

XS3300P3

 

ZRULES

   

&XS3300P3

..STATIC CALL

XD2137

 

ZRULES

F

   

(P)

VARIABLE-START-POS

OFFSET NUMBER

ZRULES

F

   

(P)

VARIABLE-START-POS

OFFSET NUMBER

ZRULES

F

   

(P)

VARIABLE-START-POS

OFFSET NUMBER

ZRULES

F

   

(P)

VARIABLE-START-POS

OFFSET NUMBER

ZRULES

F

   

(P)

VARIABLE-START-POS

OFFSET NUMBER

ZRULES

F

   

(P)

VARIABLE-START-POS

OFFSET NUMBER

ZRULES

   

&XS3300P3

..STATIC CALL

XD2137

 

ZRULES

   

&XS3300P3

..STATIC CALL

XD2137

 

ZRULES

   

&XS3300P3

..STATIC CALL

ILBOABN0

force an abend and obtain a system dump.

 

Now we will map ‘VARIABLE-START-POS’ to where it is used in the ZRULES module and extract the business Rule. (Done manually in this release)

 
The routine that ‘VARIABLE-START-POS’ is used in:

 

7000-020-LOOP-SOURCE.

      * ......setup for space check before and after data....

           MOVE START-POS TO VARIABLE-START-POS.

           SUBTRACT +1 FROM VARIABLE-START-POS.

           COMPUTE VARIABLE-END-POS =

                   VARIABLE-START-POS + LENGTH-OF-LABEL + 1.

           IF SOURCE-DATA(START-POS:LENGTH-OF-LABEL)

             = ARG-LABEL(AT1-SUB), (1:LENGTH-OF-LABEL)

             AND SOURCE-DATA(VARIABLE-START-POS:1) = '.'

             MOVE SPACE TO SOURCE-DATA(VARIABLE-START-POS:1)

           END-IF

           IF SOURCE-DATA(START-POS:LENGTH-OF-LABEL)

             = ARG-LABEL(AT1-SUB), (1:LENGTH-OF-LABEL)

             AND SOURCE-DATA(VARIABLE-START-POS:1) = SPACES

             AND SOURCE-DATA(VARIABLE-END-POS:1)   = SPACES

             MOVE SOURCE-NAME TO IMP-MODULE-NAME

             MOVE SOURCE-DATA(START-POS:LENGTH-OF-LABEL)

               TO IMP-MODULE-COMP, GENERIC-DESC-HOLD-AREA

             MOVE ARG-PROJECT(AT1-SUB) TO IMP-MODULE-PROJECT

             MOVE ARG-TYPE(AT1-SUB) TO IMP-MODULE-TYPE

             PERFORM  VARYING TT-SUB FROM +1 BY +1

                   UNTIL TT-SUB > GENERIC-DESC-VIRTUAL-AT-END

                IF GENERIC-DESC-NAME(TT-SUB)

                                  = GENERIC-DESC-HOLD-AREA

                  MOVE GENERIC-DESC-DESC(TT-SUB)

                    TO IMP-MODULE-COMP-DESC

                  PERFORM 7000-030-CHECK-ON-MODEL

                     THRU 7000-030-EXIT

                END-IF

             END-PERFORM

             PERFORM 9000-EDIT-IMP THRU 9000-EXIT

             ADD +1 TO HIT-COUNT

             WRITE IMP-RECORD

             MOVE SPACES TO IMP-RECORD

             ADD +1 TO START-POS

      *      MOVE 'F' TO FOUND-SW

      *      MOVE +72 TO START-POS

           ELSE

             ADD +1 TO START-POS.

       7000-020-EXIT. EXIT.

This routine is fairly complicated, so we will flowchart it. But first let’s look at the complexity metrics.

 

COMPLEXITY METRICS

The following metrics measure the complexity of executable code within procedures. This includes both the internal complexity of a single procedure and the complexity of the data flow in and out of a procedure.

High complexity may result in bad understandability and more errors. Complex procedures also need more time to develop and test. Therefore, excessive complexity should be avoided. Too complex procedures should be simplified by rewriting or splitting into several procedures.

Complexity is often positively correlated to code size. A big program or function is likely to be complex as well. These are not equal, however. A procedure with relatively few lines of code might be far more complex than a long one.

 

VALUES OF CYCLOMATIC COMPLEXITY

A high cyclomatic complexity denotes a complex procedure that's hard to understand, test and maintain. There's a relationship between cyclomatic complexity and the "risk" in a procedure.

CC

Type of procedure

Risk

1-4

A simple procedure

Low

5-10

A well structured and stable procedure

Low

11-20

A more complex procedure

Moderate

21-50

A complex procedure, alarming

High

>50

An error-prone, extremely troublesome, untestable procedure

Very high

The original, usual limit for a maximum acceptable value for cyclomatic complexity is 10. Other values, such as 15 or 20, have also been suggested. Regardless of the exact limit, if cyclomatic complexity exceeds 20, you should consider it alarming. Procedures with a high cyclomatic complexity should be simplified or split into several smaller procedures.

Cyclomatic complexity equals the minimum number of test cases you must execute to cover every possible execution path through your procedure. This is important information for testing. Carefully test procedures with the highest cyclomatic complexity values.

Bad fix probability

There is a frequently quoted table of "bad fix probability" values by cyclomatic complexity. This is the probability of an error accidentally inserted into a program while trying to fix a previous error.

CC

Bad fix probability

1-10

5%

20-30

20%

>50

40%

approaching 100

60%

As the complexity reaches high values, changes in the program are likely to produce new errors.

As you can see, this routine received a 5 on the complexity scale.

See additional info at en.wikipedia.org/wiki/Cyclomatic_complexity

Automatically flowchart the code:

Forward engineer the flowchart into VISIO.

 

 The business rule is now ready to include into the use case.

  

RIPPLE-TRAC™ (continued)

MEASURE QUALITY
 
With RIPPLE-TRAC™ you can achieve speed and time-to-market without off-shoring your project. Without RIPPLE-TRAC™, speed and time-to-market has the regrettable side effect of “lowering the bar” of quality.
 
Please refer to this great article on quality by Lockwood Lyon, z/journal
 
 
 
Some managers say we can off-shore the impact analysis phase of the project but off-shoring is far from a silver bullet. Many organizations expect to see a substantial cost savings when they offshore development, but without a reliable method of measuring application quality and managing the quality of any new developed code, the expected savings are consumed through additional management time and local developers fixing issues.
 
CPU CONSUMPTION
 
In a March 2007 report titled "The State of the Mainframe,” Ovum analyst Carl Greiner states: "Mainframe MIPS growth is averaging around 20 percent per year and large mainframe-centric enterprises have been consistently averaging 35 percent-plus MIPS growth.”
 
RIPPLE-TRAC™ helps IT departments take a proactive approach to controlling MIPS.
 
When one company ran RIPPLE-TRAC™ and then did the same work manually the results were astonishing. One person performed an impact analysis on one field that needed to be increased in size. The application had approximately 3 million lines of code. Using TSO, the results follow:
 
          The manual way (TSO search) (Hourly rate $65)
 
1 PERSON 8 HOURS = $520
MISSED 4 COMPONENTS
27 ON TEAM 8 HOURS
= $14,040
260 WORKING DAYS PER YEAR FULL TEAM = $3,650,400
 
The result showed one person worked 8 hours to complete the task
and missed 4 components at a cost of $520 for the day.
 
In a hypothetical situation: A project has 27 team members at a rate of $14,040 per day for all 27. If this project goes out for a year or 260 working days, the cost would be $3,650,400 and this does not include CPU cycles to perform the manual impact analysis.
 
The RIPPLE-TRAC™ way (Run a Job) (Hourly rate $65)
 
1 PERSON TO RUN JOB 10 MINUTES = $11
NO COMPONENTS MISSED
27 ON TEAM 10 MINUTES = $297
260 WORKING DAYS PER YEAR FULL TEAM = $77,220
 
SAVINGS OF 98% OR $3,573,180 AND MINIMUM CPU CYCLES.
ALL REMAINING 26 TEAM MEMBERS GET TO CAPITALIZE ON THIS
ONE RUN.
 
One of RIPPLE-TRAC’s™ options is to off load the Impact Analysis to an excel spreadsheet on the developers desktop or laptop.
 
This option completely eliminates CPU cycles for all developers on the project.
 
 
TRACKING MODIFICATIONS
 
RIPPLE-TRAC tracks the ripple effect of a modification to the source code of a software system and is able to discover the consequential effects on other parts of the system resulting from that modification.
 
Ø A radically simple way to assess software modifications
Ø Make the most of your current software assets
Ø Maximize your IT software budget dollars
Ø Improve the maintenance team’s efficiency and job satisfaction
 
HOW IT WORKS
 
Researches application components
Builds:
Ø Software Item Master File
Ø Software Bill of Material
Ø Software Assemblies
Ø Software Where Used
 
OPERATING ENVIRONMENT
 
IBM Mainframe
 
Ø z/OS series to the original IBM 360 series
Ø Backward compatible to any IBM mainframe
 
CAPABILITIES
Ø Extract Metadata
Ø Provide inputs to logical & physical data modeler
Ø Provide inputs to map business rules and processes
Ø Support Sarbanes-Oxley requirements
Ø Support trace-ability requirements
Ø Regulatory reporting requirements
 
RUN TIME
 
Example of RIPPLE-TRAC value determined from a medium scale installation:
 
Ø 3 million lines of code
Ø 25,000 components researched
Ø 5000 sorts
Ø 325 DB2 tables
Ø with 3 billion rows
 
Run time was 1.5 hours on a z/os
 
BENEFITS
 
Business user’s benefit from new visibility and metrics, faster time to new capabilities, eliminating non-value added work; and gaining agility, flexibility, and self-sufficiency.
Information technologists benefit from meeting business needs quickly — being off the critical path, reusing IT assets, scaling, achieving lower costs, and spending more time in
development and less in support. Customers, partners, and suppliers gain improved customer service and satisfaction, value-stream alignment, faster response — and in general, making you easier to do business with!
 
 
ERADICATE THE GAPS!
 
RIPPLE-TRAC removes not only the gap between IT and business groups, but also gaps between all business functions. Teams communicate more seamlessly and effectively, shed mundane and non-value-added work, operate more strategically, and adapt faster to change.
 
IN SUMMARY
Software development has seen individual practitioner activities, such as functional and performance testing, become automated. And today’s build engineers use timesaving build scripts and tooling. But more needs to be done to automate the process and steps between roles to improve organizational efficiencies, save money and speed time to market (e.g., RIPPLE-TRAC™).
The RIPPLE-TRAC™ solution can help your team test software more thoroughly and more quickly. Manually analyzing your software applications can result in late releases or inconsistent results. Ad hoc processes for managing your analysis efforts can’t ensure the kind of quality you need. By automating your more labor-intensive analysis tasks with RIPPLE-TRAC™, you can avoid introducing errors into your analysis. The potential payoffs include higher quality and faster time to market—for less money.

Rework is much more costly than building the right solution from the start. To avoid wasteful spending, RIPPLE-TRAC™ is an effective process for defining, capturing, prioritizing and managing modifications to your requirements. RIPPLE-TRAC™ will ensure that IT focuses on the required modifications, so you can deliver what the marketplace is demanding—faster.

 

 

  

LINKS/DOWNLOADS

WIT AND WISDOM

 

The only opinion about your dream that really counts is
yours. The negative comments of others merely reflect
their limitations - not yours.


~ Cynthia Kersey Author of Unstoppable
Published 05.15.10 

 

 

Please follow the link below to request additional information.

 

Thanks for reading!

Contact Us

 

 

 

  

Menu
  

Copyright 2008 by Logic Online, Inc. Terms Of Use | Privacy Statement