Thoroughly Modern: Latest IT Trends – Bring Security, Speed, And Consistency To IT With Automation
August 8, 2022 Alan Hamm and Chris Koppe
The irony of many IT departments is that they have spent many decades automating aspects of the business, literally encoding business processes and interactions with customers, partners, and suppliers to make those processes consistent and fast, but many of the processes used in the IT department itself are done manually and rely on the “tribal knowledge” of the system and application experts.
This is not only not necessary in many cases today, thanks to a myriad of automation tools that can be brought to bear on IT operations, but it is also dangerous and extremely risky. The systems that run your company are very likely both unique and complex, and finding a way to preserve that tribal knowledge – to move it from the heads of the system and application elders into some form that is sharable and malleable – is of paramount importance. This is one aspect of automation.
The other aspect of automation is to use tools that can radically speed up tasks that are being done manually, which gives the IT department itself more throughput and greater odds of success as they do projects. Such tools automate business process and workflows and thereby remove the risk of human error, cut the costs of operations and development, and ensure best practices in the systems, databases, and applications.
Both kinds of automation are necessary to help IBM i shops better adapt applications and databases to future business conditions, which is, in fact, the job of the IT department. It is not enough to just encapsulate the present business processes, but to find a way to allow new business processes, and new technologies, to be woven into the mix – and in a way that does not compromise security.
So where are companies seeing the best return with automation? There are four key areas:
#1 – Security Automation
If the past several years have taught IT shops anything, it is that security has to come first, not last and not as an afterthought. And that is why we are talking about security automation first, not last. There are several ways that security can be automated in the IBM i system, and they are all interrelated and mutually reinforcing.
Tools like Fresche’s security software TGAudit can show that user profiles and resources in the system are properly locked down and then automatically schedule and generate reports that are necessary for both internal and external audits. This automation gives everyone a better chance to review what’s going on and to catch things before it is time to present it to an auditor. But the TGAudit tool goes beyond this. It knows what best practices are in the industry as a whole and what regulatory requirements there are in specific industries, all of which are encoded into policy controls for system resources. That means reports can be generated to show where the system is out of compliance, and a specific policy can be enforced at configuration or compile or runtime (depending on the situation) to prevent the system from ever going out of compliance in the first place. TG Audit has over 500 reports that encompass all of the various industry regulations in the world that IBM i customers have to deal with, and those reports can be used to adjust policy templates that in turn lock down the system.
And if something is found that is out of compliance, TGAudit can automatically remediate the situation based on best practices encoded in policies in the tool.
The mindset that we need to get to as administrators is this: Instead of just going to the operating system or the database or the application making changes, we need to actually make the changes within a policy and then enforce that policy.
Of course, we also need to automate the monitoring of the system, the alerting of critical situations to the appropriate people, and possibly the automated response to alerts. There are simply too many logs and too much data in a modern system for a human being to sift through it. Automation is not just convenient here. For proper security, automation is necessary.
#2 – Modernization And Transformation Automation
This is another area where tools really shine. First, let’s consider the database.
Many IBM shops are still using old DDS databases instead of the more modern DDL databases, which have full-on relational capabilities as well as data integrity protocols embedded into the database. With DDS databases, foreign key constraints are between database tables and therefore the integrity of the data is managed at the program level, not within the database itself. This means it is very difficult to have a consistent means of data integrity. It is far better to simply let the Db2 for i database embedded in the IBM i platform do this itself. These old DDS databases also have short cryptic names and no relational information to connect the database tables together. This means you cannot simply use a report generation tool or dashboard to cull information from various databases to run the business as you can do thanks to the long names employed in the modern DDL database structure. The modern DDL database also has row column access control (RCAC), which enhances security.
There are tools like X-DB Transform that can automatically convert IBM i databases from DDS to DDL formats, and the upside is that the resulting relational databases will look more familiar to programmers who might be used to Microsoft SQL Server, Oracle Database, or various open source databases. You don’t have to do this database conversion all at once, either. You can do it piecemeal. Depending on the size of the databases, it takes weeks to months – a database with thousands of tables probably takes a few months.
Now, let’s talk about application development automation, which is another aspect of modernization. There are tools that can convert from old fixed format RPG to the more modern free format RPG, which makes the syntax similar to that of other modern programming languages and therefore makes RPG more accessible to programmers more familiar with Java, PHP, and so on. There are also development tools that can automatically generate the architecture of a modular, object-oriented, API and microservices architecture and then all programmers have to do is create business logic modules and design their user interface. Once again, this brings speed and consistency to application development, and this is precisely how the hyperscalers have been coding for decades now. The point is, you don’t have to refactor applications by hand, you can use automation to make it easier. The X-Elevate tool predefines the API layers, the connectivity, and data access patterns, so you don’t have to code all of this. You just focus on the business logic and the interface.
Once code is created, it needs to be tested, and there is no reason in the 21st century that this business logic, user interface, and data verification testing should be done manually.
#3 – Developers Need To Use Automation Every Day
What is the one thing that most IBM i shops skimp on? Documentation. You all know it’s true. But what if big chunks of this never-ending documentation task were automated – and not just in a one-off fashion, giving a static view of the system and application at one point in time, but actually updated itself as the system and applications change?
That would be automagical, right?
The X-Analysis tool can not only do impact analysis on changes to the system, but it can fully document the entire system, and it can even document older applications that you have retired so you have an understanding of how they work, how they were interconnected, and why they were architected the way they were.
That’s one aspect of documentation automation, at the developer level. But if you really want to document a system so others can understand it in the future, you need to document the business requirements that drove the development in the first place. This is where tools like Confluence (and SharePoint to a lesser degree) come in. These tools allow everybody to contribute knowledge about a system, business processes, and workflows – and the knowledge is organized by business function, not by program as developers think about things. So, you can have that complementary business level knowledge and augment it with the tribal elder knowledge, so you know not only where things happened, but why both from a technical perspective as well as a business perspective.
The final piece of data that can feed into the automated documentation of the system is all of the information culled from a modern ticketing system such as Jira, which incidentally works very well with Confluence. When a ticket is issued to make a fix or change to the system, lots of information is generated and there is a trail of testing that is done, too, so you can document what worked and what didn’t. This is all valuable information that needs to be preserved for future reference.
Here is another area where developers need to use automation tools every day: Impact analysis. And a classic example of impact analysis that a lot of IBM i shops are facing is resizing fields in their databases and applications. This sounds simple enough, but it is not at all trivial.
In the IBM i RPG and COBOL world, for good reasons like forward compatibility and making sure people don’t corrupt the database, developers cannot just expand the database field and have that field change cascade across that field in every database table. Every program that touches that field has to be changed or at least recompiled. If you change your account number, for instance, it is like doing open heart surgery on an application.
We went into an IBM i shop recently that was expanding a field and their search showed it appeared in 192 different places in their application stack. When we looked with X-Analysis, we found it in 384 places. And if they had changed the field and almost certainly would have corrupted their databases because it was not found everywhere – and they would not have known it until it was too late. Field resizing is a place where automation must be used, and we would argue that impact analysis should be done for all changes to the applications.
#4 – New Applications, Rapid Development
With products like Presto, we can take existing greenscreen applications, or even particular interfaces in RPG programs, and expose them to be consumed by a browser on a PC, tablet, or smartphone. We can only take certain elements of the greenscreens for the new Web and mobile interfaces, or we can consolidate multiple screens into something that looks native to these graphical devices. And because Presto makes use of existing RPG code, you know they are already locked down – you are coming in through the front door of the system, not a new side door off the kitchen.
If you want to go a bit more modern in creating applications, you create APIs that access system resources and you stitch these together to create that application. And that is where tools like WebSmart and X-Elevate come in. WebSmart lets you rapidly create RPG or PHP responsive web and mobile applications and APIs using templates and powerful IDE – effectively new digital solutions and better integration. X-Elevate takes the business logic already inherent in your applications and exposes it as RESTful APIs. The great thing about X-Elevate is that if you no longer had your own source code, or that of a third-party application provider, then you can still create these RESTful APIs out of the blocks of business logic in the application. No source code required.
This integration of applications at the API level is how you integrate with cloud-based applications like Salesforce or how you hook applications from disparate systems together, say after a merger or acquisition. Creating those APIs consistently and automatically – and securely – is the only way to go.
One last thought. The recurring theme we see in the IBM i developer community, which we have always found to be strange in contrast to other platforms, is that IBM i developers associate their value to the organization with their knowledge of code, as opposed to their knowledge of the business processes. The latter is what the organization really values, and the former is just one particular implementation of it at one particular time. That means, with the right attitude, modernization is not scary but natural and can be well governed and documented. And, in fact, the more developers automate, the more time they get to do more interesting things for the business and actually demonstrate their value.
For decades, Fresche’s IT and IBM i experts have been helping companies implement automation and deliver better value to the business. If you have a project in the works, one in mind or simply want to explore more, talking to a strategist can help uncover new ideas and get you started. You can set up a meeting and learn more by sending an email to: Info@Freschesolutions.com.
Alan Hamm is senior Security Services Engineer and Chris Koppe is senior vice president of Transformation & Modernization Services at Fresche Solutions.
This content is sponsored by Fresche Solutions.