For administrative computing at the University, integration is one of our greatest strengths, but it also may be our greatest weakness.
Integration is a strength, because when different applications need to work together they do so easily.
Integration is a weakness, because when an application needs to change those changes must be coordinated with the other applications it works with. This is greatly highlighted when we consider possible projects like the proposed mainframe migration.
When I first started working here, integration usually happened at the Adabas file level. If application A needed access to application B’s data, application A was given appropriate database permissions. But now if application B wanted to change their file layout, it had to be coordinated with application A. Also, there are clearly security implications for this.
So we invented secured modules. This has helped with the security issues, but I don’t think it has decoupled applications as much as we might want.
Is there a next step, something to replace secured modules to decouple our applications more? Some way for applications to communicate more flexibly, so different areas can move in different directions more easily? Doing more with Broker might be one way, but at a significant cost in performance. Where one application is moving off the mainframe, Adabas Replicator might be a useful tool. Any other ideas?
While I’m sure there are many things that could be designed somewhat better, I think most of the integration and enmeshment of applications reflects the fundamental business processes; e.g., payroll and accounting really are linked, after all. When you have tightly integrated processes, the code is going to reflect that.
So my question is what is the problem you are calling on us to solve? Enabling platform evolution?
I think database replication is a potential solution for moving your own codebase (e.g., to Python and Oracle) while preserving the code that others depend on. Sounds expensive, though. I know a lot of us are watching the folks trying Adabas Replicator. Not sure what it would take to scale it to really active files, though, and it doesn’t handle pushing updates both ways.
“So my question is what is the problem you are calling on us to solve? Enabling platform evolution?”
That’s at least a big part of it.
Really a separate issue, but in addition to needing something like two-way database replication to get through the transition, I think you’d need to be able to handle processes that currently make lots of database calls in batch. I have trouble imagining how calling Oracle over a network could be as fast, and Python isn’t a very fast language either. (Although I’m doubtful that the speed of Python would matter in this case.) Not to mention that there would need to be a batch environment.
Some of that might be rearchitected to be done online instead of batch, but not all of it.
Of course, that might be a good opportunity to think about approaching batch in a different way — just as an example, hadoop.