Dear community, last year I published a
blog on the 60th birthday of the
COBOL programming language. According to a new
study, COBOL will continue to accompany us in information technology, because according to the survey results, COBOL applications will be modernized rather than exchanged.
This is not surprising. Everyone who works with historically grown applications knows the difficult situation: Switching off is not possible, but also not exchanging. So it goes on ... and on ... and on ... as long as there are no reasons against it, that's okay.
But what reasons could "speak" against it? After reading the study, I had some thoughts about this. Ultimately, it's not unlikely that ABAP will eventually turn 60 - some systems in this world could then still run with ABAP applications
😉 As a developer, one should counteract these reasons at an early stage, so that one day it doesn't mean: This ABAP application urgently needs to be replaced.
I immediately thought of the topic "security". Security updates for the SAP NetWeaver Stack have been available regularly for several years, e.g. the integrated web server is secured. However, this is more the security of the runtime environment and is therefore a manufacturer topic. Developers are not directly affected. Unless they have to abandon development in certain runtime environments because they are no longer supported by the manufacturer. But I trust the manufacturer in this matter as I've been doing it for nearly twenty years
🙂
Security could also be understood in terms of stable, fault-tolerant, maintainable and expandable ABAP applications. So it is up to us developers - that's exactly our goal or at least what we would like to achieve every day
🙂 I immediately thought of
Clean ABAP, design and general programming principles.
Which I wouldn't bet a penny on in this context is additional project documentation, e.g. in the form of Word documents. Probably nobody will find the project documents in 30 years. Or he cannot open/display them. A positive exception might be the NASA
🙂 I would prefer to create development objects such as unit tests and describing class and method names. In addition, there will probably be better software tools. If you have no documentation, you can only examine development objects. The application idea that was implemented at design time and that is brought to life at runtime must be understood more quickly using suitable tools. In my opinion, that would be a real benefit for future developers.
Speaking of future developers. Of course there should be new developers. Anyone who wants to bequeath something needs heirs. The business decision to continue using COBOL applications is OK. However, there must also be experts who can maintain and expand these applications. Otherwise the decision fails in practice.
From this point of view, investing in training new developers and sharing your own knowledge and experience makes a lot more sense.
What does this mean for our ABAP developments? If we write our applications on the assumption of an infinite usage time, in which we maintain and expand them x times without worrying about the effects and we can one day hand them over to our successors without a guilty conscience, then it's ok ... probably
😉
Those were my thoughts. What do you think? Feel free to comment.
Best regards, thanks for reading and have a good time
Michael
