IBM Security Verify

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

And thank you Franz for pointing me to the SDI AssemblyLine Reports. They're not perfect (they put hooks in alphabetical order, the formatting is a little off in places, etc.), but they're a very, very good place to start.

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

That is probably a thing that could be easily solvable as the reports are "just" xsl transforms to xHTML.

You can try with a case or Idea if you feel for it to get it resolved. 

And thank you Franz for pointing me to the SDI AssemblyLine Reports. They're not perfect (they put hooks in alphabetical order, the formatting is a little off in places, etc.), but they're a very, very good place to start.

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

How do you go about generating these reports from an assembly line?

That is probably a thing that could be easily solvable as the reports are "just" xsl transforms to xHTML.

You can try with a case or Idea if you feel for it to get it resolved. 

And thank you Franz for pointing me to the SDI AssemblyLine Reports. They're not perfect (they put hooks in alphabetical order, the formatting is a little off in places, etc.), but they're a very, very good place to start.

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

Right click an Assemblyline and select "Create Assemblyline Report" from the context menu - it is the last option in the first section :-) 

How do you go about generating these reports from an assembly line?

That is probably a thing that could be easily solvable as the reports are "just" xsl transforms to xHTML.

You can try with a case or Idea if you feel for it to get it resolved. 

And thank you Franz for pointing me to the SDI AssemblyLine Reports. They're not perfect (they put hooks in alphabetical order, the formatting is a little off in places, etc.), but they're a very, very good place to start.

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

That is probably a thing that could be easily solvable as the reports are "just" xsl transforms to xHTML.

You can try with a case or Idea if you feel for it to get it resolved. 

And thank you Franz for pointing me to the SDI AssemblyLine Reports. They're not perfect (they put hooks in alphabetical order, the formatting is a little off in places, etc.), but they're a very, very good place to start.

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------

Thanks a ton for your help, Franz. I just want to add some information for anyone who stumbles across this link.

The issue is the "Assemblyline Overview" report isn't an XSL file. That one is an XML file that I'm gussing is processed by some custom Java. Some may argue that simply hand-editing the resulting HTML file is easier than modifying XSL, so maybe that's not a big issue :)

A reason one might want to hand-edit the HTML file is that several of the elements are placed in alphabetical order (as they are in the raw XML for the AL), which places them incorrectly for the order of the actual flow. For example, "epilog" for the AL is the first element, though it's the last to execute.

Due to the above, and the fact that the ALs I'm dealing with have a LOT of code in them including tons of global variables, etc., I broke down and manually created flow diagrams for them in draw.io. After going through that process, I think it really was the only way to go in this particular case. The included report capabilities are awesome, but I needed something that I could present to and discuss with a group of business (rather than technical) stakeholders.

Truly, thank you again for your assistance and for contributing to this community. It is very much appreciated.

Frank

That is probably a thing that could be easily solvable as the reports are "just" xsl transforms to xHTML.

You can try with a case or Idea if you feel for it to get it resolved. 

And thank you Franz for pointing me to the SDI AssemblyLine Reports. They're not perfect (they put hooks in alphabetical order, the formatting is a little off in places, etc.), but they're a very, very good place to start.

I have used to graphviz to "dump" the ISVG IM/ISIM workflows to static html making it possible easily get an overvieew of all workflows. I think a similar approach for ISVDI/SDI  would be a good idea - that would basically be graphical version of the SDI AL reports. 

That said is only a way of making the ALs readable "offline" - it does not solve any knowledge problems. I had a very significant eye opener in my IT youth working in the IBM backoffice (SW Manufacturing in Copenhagen) - in the late 1980's is was discussed whether our IT department should be ISO 9000 certified which require a lot of work on documentation. The senior architect team held a room with all the (mainframe based) documentation but after a while they found out that only the 4 binders holding their target architecture was really of value - that describer the PURPOSE and HOW the process SHOULD work - not how it was implemented - their realization was that most documentation was only valuable in the projects creating it - 5 minutes after it was anyhow not up to date and in most cases the bugs could anyhow only be found and validated by looking in the code and compare to the way it SHOULD work....

So - when talking documentation it is the WHY that is important - the HOW should normally be obvious from the code/implementation which is also why I always teach people to code their things in a simple readable manner - avoid "smart" algorithms/code/oneliners that only you understand - most code the basic algorithm is responsible for  performance/scalability/security - no need to complicate thinks because you code something in one line if a simple if/then is more readable...

I know this is a rather long answer with no solution - but I hope it gives you some valuable about what you need  to focus on...

And if I had 48 hours a day I would probably code a graphviz AL and publish it.....  

I am looking for suggestions on how to document an assemblyline in detail to include in project deliverables. The assemblylines I'm working with are pretty complex, and I can't think of any easy way to document their detailed behavior. I definitely need something better than the common "puzzle piece" visuals from the documentation, since there are literally hundreds of custom scripts involved. 

I am currently playing around with Draw.io flowcharts, but that's getting out of hand pretty quickly. I'm thinking I may just record a screenshare video to descibe each piece as I walk through it.

TIA,

Frank

------------------------------
Frank Tate
Gulfsoft Consulting
https://www.gulfsoft.com
AIOps Experts. Contact us for implementation help.
------------------------------