Solution architects should consider the enterprise impact of architectural decisions.
Solution architects must ignore enterprise directions if these lead to local inefficiencies or have other predominantly negative local effects.
There is a significant difference between the clean 30000-foot view (sometimes referred to as the air castle) and the muddy reality on sea level.
Photographers tend to suffer from Gear Acquisition Syndrome. They believe they will make better pictures with new gear and buy new lenses, cameras, and flashlights.
Then they find their work does not improve.
In IT, we do the same.
We have our old relational database management system.
But now we have this great Spark, MongoDB, CouchDB, or what have you. (I’m just taking a not-so-random example.) So now everything must be converted to Spark or Mongo.
We even forget that this old technology, the relational DBMS in this example, was so good at reliably processing transactions. It worked!
The new database is massively scalable, which is great. Unfortunately, it does not improve the reliability of processing our transactions.
But it’s hot, so we want it—because Google has it. Errr, but will you also use it to process web page indexes? Ah, no. You want to store your customer records in it. So, is it reliable? No. But it is satisfying our GAS.
Beautiful things are easier to use.
We can also apply this to technical designs. This often surprises a non-technical audience, but techies will recognize the beauty that can be present in technical solutions.
For example, symmetrical diagrams not only give a quick insight into an orderly, robust solution but are often also very appealing to the eye.
Symmetrical and well-colored diagrams are easier to read and understand.
Old PowerPoint presentations using the standard suggested colors were horrendously ugly, and I am sure the people using these colors did not want to be understood. (Nowadays, PowerPoint comes with more pleasing color schemes)
The success of the Python programming language is not in the least its forced readability. No crazy abbreviations as in C that make code unreadable (but programmers look very smart).
Beautiful code (yes, such a thing exists) is easier to read and understand.
If a
Then b
Else If c
Then d
Else If e
Then f
…
versus
Case a
b
Case c
d
Case e
f
…
It is pretty evident.
But do we care about the quality and beauty of code nowadays? Throw-away software is abundant. Software systems are built with the idea to throw them out and replace them within a few years.
That is the idea. But the Lindy effect tells us differently.
Good programming is a profession that should be appreciated as such. Bad coding may be cheap, but only in the short run.
We don’t hire a moonlighter to build our house. We employ an architect and a construction professional who can make a comfortable house that can be used for generations.
Last week, the De Technoloog, a BNR program, had a very nice interview with Professor Chris Verhoef of VU University. The interviewers, Herbert Blankesteijn and Ben van der Burg, were surprised to find that COBOL is not bad and is very good for programming administrative automation processes. Legacy is not an issue. Not allowing time for maintenance is a management issue. He mentioned the Lindy effect which tells us that the life expectancy of old code increases with time. The established code is anti-fragile.
Anyone in the product chain can pull the Andon Cord to stop production when he notices that the product’s quality is poor.
Stopping a system when a defect is suspected originates back to Toyota. The idea is that by blocking the system, you get an immediate opportunity for improvement or find a root cause instead of letting the defect move further down the line and be unresolved.
A crucial aspect of Toyota’s “Andon Cord” process was that when the team leader arrived at the workstation, they thanked the team member who pulled the Cord.
The incident would not be a paper report or a long-tail bureaucratic process. The problem would be immediately addressed, and the team member who pulled the cord would fix it.
For software systems, this practice is beneficial as well. However, the opposite process is likely the practice we see in our drive for quick results.
We don’t stop the process in case of issues. We apply a quick fix, and ‘we will resolve it later’.
The person noticing an issue is regarded as a whistle-blower. Issues may get covered in this culture, leading to even more severe problems.
When serious issues occur, we start a bureaucratic process that quickly becomes political, resulting in watered-down solutions and covering up the fundamental problems.
In software systems, backward compatibility is a blessing and a curse. While backward compatibility discharges users from mandatory software updates, it is also an excuse to ignore maintenance. For software vendors, omitting backward compatibility is a means to get users to buy new stuff; “enjoy our latest innovations!”.
You can not run Windows 95 software on Windows 11.
You can not Run MacOS X software on a PowerBook G4 from 2006.
You can not use Java version 5 software on a Java 11 runtime.
You can, however, run mainframe software compiled in 1980 for 16-bit hardware on the latest z/OS 64-bit operating system and the latest IBM Z hardware. This compatibility is one of the reasons for the success of the IBM mainframe.
Backward compatibility in software has significant benefits. The most significant benefit is that you do not need to change applications with technology upgrades. This saves large amounts of effort and, thus, money for changes that bring no business benefit.
Backward compatibility also has very significant drawbacks:
The problem may be even more significant. Because you do not touch your code, other issues may appear.
Over the years, you will change from source code management tools. During these transitions, code can get lost, or insight into the correct versions of programs gets lost.
Also, compilers are upgraded all the time. And the specifications of the programming languages may change. Consequently, the code you have, which belongs to the programs running in your production environment, can not be compiled any longer. When changes are necessary, your code suddenly needs to catch up with all these changes. And that will make the change a lot riskier.
Establish a policy to recompile, test, and deploy programs every 2 or 3 years, even if the code needs no functional change. Prevent a pile of technical debt.
Is that a lot of work? It does not need to be. You could automate most, if not all, of the compilation and testing process. If nothing functionally changes, modern test tools can help support this process. With these tools, you can automate running tests, compare results with the expected output, and pinpoint issues.
This process also has a benefit: your recompiled code will run faster because it can use the latest hardware features. You can save money if your software bill is based on CPU consumption.
Don’t let backward compatibility make you backward.
Assembler program that gets the name of the current address space from the PSA’s current ASCB block.
Documentation: PSA description and ASCB description.
ASCBNAME CSECT
EQUATES
SAVE (14,12),,TST/NDG/&SYSDATE/&SYSTIME/
USING ASCBNAME,R12 SET UP BASE ADDRESSABILITY
LR R12,R15 LOAD BASE REG WITH ENTRY POINT
LA R14,SAVE GET ADDRESS OF REGISTER SAVE
ST R13,4(0,R14) SAVE CALLER'S SAVE AREA ADDR
ST R14,8(0,R13) SAVE MY SAVE AREA ADDRESS
LR R13,R14 LOAD SAVE AREA ADDRESS
*
INIT DS 0H
OPEN (OUT,(OUTPUT))
*
DOE DS 0H
SR R1,R1 R1 = 0
USING PSA,R1 ADDRESS PSA
L R2,PSAAOLD GET ADDRESS CURRENT ASCB
DROP R1 RELEASE PSA ADDRESSING
USING ASCB,R2 ADDRESS CURRENT ASCB
L R1,ASCBJBNS GET ADDRESS ADDRESS SPACE NAME
DROP R2 RELEASE ASCB ADDRESSING
MVC ADDRSPC,0(R1) GET NAME
PUT OUT,OUTREC SCHRIJF
RETURN DS 0H
CLOSE OUT
SLR R15,R15
L R13,4(R13) LOAD CALLERS SAVE AREA ADDRESS
RETURN (14,12),RC=(15) RETURN TO CALLER
*
*
*
DC C'********** ************* WERKGEBIED ******'
SAVE DS 18F
OUTREC DS CL80
ORG OUTREC
ADDRSPC DC CL8' '
REST DC CL72' '
OUT DCB DDNAME=OUT, *
DSORG=PS, *
MACRF=(PM)
*
IHAASCB DSECT=YES
IHAPSA
END ,
Not sure what I used it for, but here is a simple program in assembler to create an ABEND with a completion code of your choice.
Look here in the IBM manuals for more specifics on the ABEND macro.
ABENDIT CSECT
EQUATES
SAVE (14,12),,ABENDIT/OURDEPT/&SYSDATE/&SYSTIME/
USING ABENDIT,R11 SET UP BASE ADDRESSABILITY
LR R11,R15 LOAD BASE REG WITH ENTRY POINT
LA R14,SAVE GET ADDRESS OF REGISTER SAVE
ST R13,4(0,R14) SAVE CALLER'S SAVE AREA ADDR
ST R14,8(0,R13) SAVE MY SAVE AREA ADDRESS
LR R13,R14 LOAD SAVE AREA ADDRESS
* Business Logic
ABEND 4321 4321 or some other code up to 4096
* Epilogue
RETURN EQU *
L R13,4(R13)
RETURN (14,12) RETURN TO CALLER
LTORG
SAVE DS 18F
END ABENDITHappy ABENDing!
The abstraction principle in software systems allows us to create more generically usable software components.
Abstraction removes details from the problem space and thus makes it easier to think about problems and solutions. This principle lets us focus on problems by reducing complexity.
Abstraction makes software components more reusable: code for specific problems is abstracted to code that applies to a broader class of problems.
The process of abstraction, or generalization, removes specific attributes or functions and replaces these with general counterparts. The abstract components can be made specific through parameters or inheritance.
Abstraction is also a modeling technique that allows logical grouping of software structures so they can be better designed, realized, and maintained. Through this grouping, a complex software solution is methodically chopped up into smaller pieces that can be handled better in all phases of a software system lifecycle.
Examples of abstraction in software systems:
The OSI networking model abstracts communication protocols in functional layers.
Messaging middleware solutions abstract the connectivity logic from the application.
I have discussed in another article how you can convert data from one codepage to another.
Also I have described a method to copy unix files to MVS datasets.
This article summarizes a method to copy an MVS dataset to Windows, while keeping records and converting from ebcdic to the utf8 codepage.
This job copies the MVS dataset to a UNIX files, indicating to keep record indicators with the Windows CR character (UNIX uses the CRLF typically as record / line separators). The dataset below ‘YOUR.TEST.PS’ should be a PS – physical sequential – dataset or a PDS(E) member.
//STEP1 EXEC PGM=BPXBATCH
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD DUMMY
//* Values in STDENV below are kept but have no meaning for this function
//STDENV DD *
JAVA_HOME=/usr/lpp/java/J8.0_64
PATH=/usr/lpp/mqm/web/bin:/bin:/usr/sbin
LIBPATH=/usr/lpp/mqm/java/lib
//STDPARM DD *
SH cp -v -F cr "//'YOUR.TEST.PS'" /your/unixdir/tst.txt You can now convert the EBCDIC data to UTF-8 as follows:
iconv -f 37 -t 1208 /your/unixdir/tst.txt > /your/unixdir/utf8-tst.txtNow you can transfer the file to Windows. Transfer the file in binary mode, otherwise another unwanted code page conversion will happen.