Refactoring OnBase Solutions

[Eric_Beavers]

I had a fun conversation with a System Admin earlier in the week. This admin came from a strict software development background. They shared with me a frustration that OnBase Solutions are not Refactorable. I don't think I have ever heard a Sys Admin use this term or heard this perspective before.

https://en.wikipedia.org/wiki/Code_refactoring

TLDR: restructure (the source code of an application or piece of software) so as to improve operation without altering functionality.

"developers might be asked to review the architecture and, where possible, refactor code to create smaller and more manageable components"

I found the conversation interesting. I feel like parts of OnBase can definitely be refactored. Maybe I am using the context incorrectly here. For example, I have "redesigned"(my vision of refactoring) workflows with different logic to do the same process with less rules and actions (especially when Set Property to Expression was introduced). Other places, I know changes are challenging if not impossible. Shoutout to all my Sys Admins with lots of ZZZ AFKS  and zzzz MIKGs : )

What do you think? Have you ever "refactored" your OnBase Solution?

[David_Hankes]

There is always refactoring going on in the Hyland product(s), especially with Workflow.  I cannot tell you how frustrated I was with workflow when I first worked with it in 2004. As the product and modules get more mature, there are definitely ways to refactor the original process (readability, reusability, or structure) to make it act more like "getters and setters". 

Refactoring is a natural process that helps reduce your original project scope and make the workflow process more flexible for future upgrades and extensibility. If the scope is not fully divulged at the beginning of the project and you are not running an agile development environment with OnBase I could see where the project could make the product seem archaic and less flexible from a refactoring method.

I am currently in a process now of refactoring document types, keywords, and processes that were setup by previous management direction.  It has hurt the product's reputation in certain departments. However, using service design principles and UX methodologies were are patching the past wounds and consolidating bad decisions.  It has really turned the end users' thoughts of the product and future use cases.

[Eric_R__Patalin]

It's an interesting point to consider.

In some respect, I would agree with the thought that it may be hard to do optimization of a configuration because the code layer is mostly abstracted by OnBase. For example, if you wanted to make a query more efficient, you are limited to what OnBase lets you configure. That's a natural trade off the higher you get away from the actual code itself.

My question here is, "What are you trying to do that requires further optimization and refactoring?" 

[William_Howell]

Absolutely! As Hyland introduces new features, rules and actions, we've gone back in and "refactored" where it made sense to improve performance, simplify code, or just add tool tips or documentation. 

Refactoring should be an integral part of any OnBase Admin job. You can either wait until you've made so many patches to your code that it no longer makes sense even to you, or you can go to the other extreme of making busy work for yourself. Finding a good balance is key.

Maybe because most OnBase coding is performed by configuring abstracted objects, code junkies might feel there's less opportunity for refactoring in OnBase than some other programming languages.

[Jim_Baad]

The biggest problem I see with achieving refactoring in an onbase solution is the lack of revision management for Workview objects, filters, workflows, system actions etc.  So if I work at improving something and really screw it up I can't roll back.  

We need enterprise revision management like git.  This would be an important step into making it much easier to refactor solutions without fear of breaking everything.