For the past year, I\u2019ve been working on something that sounds simple when you describe it in one sentence:<\/p>\n\n\n\n
Migrating a Loan Origination System from ICE Encompass to Vesta.<\/strong><\/p>\n\n\n\n Of course, anyone who has actually worked on a mortgage system knows that \u201cmigration\u201d is one of those words that can mean anything from \u201ccopy some data over\u201d<\/em> to \u201cquestion every architectural decision you have made for the last ten years.\u201d<\/em><\/p>\n\n\n\n This one is definitely closer to the second category.<\/p>\n\n\n\n We were previously built around ICE Encompass<\/strong>, and our new platform is Vesta<\/strong>. Both are LOS platforms, both manage loans, borrowers, documents, workflows, and all the other wonderful things that make mortgage software what it is.<\/p>\n\n\n\n But once you start working with both systems every day, you realize that they have some very different ideas about how an LOS should work.<\/p>\n\n\n\n Here are a few differences that stood out to me during the migration.<\/p>\n\n\n\n The first difference is probably the most obvious.<\/p>\n\n\n\n Our Encompass environment has traditionally been based on the desktop client<\/strong>. Vesta, on the other hand, is browser-based<\/strong>.<\/p>\n\n\n\n And yes, you can feel the difference.<\/p>\n\n\n\n Vesta feels lighter and more flexible. Open a browser, log in, and you are there. There is no traditional desktop application to install, maintain, update, or wonder why it suddenly decided that today was a good day to stop cooperating.<\/p>\n\n\n\n Encompass, by comparison, feels a little more heavyweight.<\/p>\n\n\n\n To be fair, ICE has also introduced a Web version of Encompass<\/strong>, so the future of Encompass is clearly moving in that direction. But our environment has been using the desktop client for a long time, so our day-to-day experience has mostly been with the traditional application.<\/p>\n\n\n\n And after years of working with it, you get used to it.<\/p>\n\n\n\n Until you switch to a browser-based LOS and suddenly realize that your browser has been waiting patiently to become your new LOS client all along.<\/p>\n\n\n\n The more interesting difference is what happens when multiple people want to work on the same loan.<\/p>\n\n\n\n In Encompass, editing a loan generally involves locking the loan<\/strong>.<\/p>\n\n\n\n If one user has the loan locked for editing, another user can’t simply open it and start changing things.<\/p>\n\n\n\n This is a very understandable design.<\/p>\n\n\n\n A loan contains a huge amount of interconnected data. You don’t want User A and User B editing the same object at the same time and then discovering that whoever clicked Save last accidentally erased the other’s changes.<\/p>\n\n\n\n So Encompass basically says:<\/p>\n\n\n\n \u201cOne person at a time, please.\u201d<\/p>\n<\/blockquote>\n\n\n\n It works.<\/p>\n\n\n\n But it also means that collaboration can become a little awkward.<\/p>\n\n\n\n Vesta takes a fundamentally different approach.<\/p>\n\n\n\n Because the Vesta client is designed around real-time persistence<\/strong>, changes are saved as they happen. There isn’t the same traditional \u201copen \u2192 edit \u2192 save \u2192 unlock\u201d workflow.<\/p>\n\n\n\n That means multiple people can work with the same loan without the traditional loan-locking model getting in the way.<\/p>\n\n\n\n Architecturally, I really like this idea.<\/p>\n\n\n\n But, as usual, solving one problem creates another.<\/p>\n\n\n\n If everything is saved immediately, you have to be much more careful about accidental edits.<\/p>\n\n\n\n Imagine that you are just looking at a loan.<\/p>\n\n\n\n You scroll through the page.<\/p>\n\n\n\n Your mouse wheel moves.<\/p>\n\n\n\n Your keyboard accidentally hits a key.<\/p>\n\n\n\n You click something you thought was just a selector.<\/p>\n\n\n\n And suddenly…<\/p>\n\n\n\n Congratulations. You changed the loan.<\/strong><\/p>\n\n\n\n There is no comforting \u201cDon’t worry, you haven’t saved yet\u201d moment.<\/p>\n\n\n\n The change may already be persisted.<\/p>\n\n\n\n This is one of those interesting trade-offs in software design:<\/p>\n\n\n\n Traditional save-based systems protect you from some accidental changes, but make collaboration harder.<\/strong><\/p>\n\n\n\n Real-time systems make collaboration much easier, but make accidental changes more dangerous.<\/strong><\/p>\n\n\n\n Neither approach is universally better. They simply move the risk to different places.<\/p>\n\n\n\n The biggest difference I’ve noticed, though, isn’t the UI.<\/p>\n\n\n\n It’s the philosophy behind the data model<\/strong>.<\/p>\n\n\n\n Encompass is relatively permissive.<\/p>\n\n\n\n There are many fields that are related to each other. Change one field, and Encompass may automatically recalculate several others.<\/p>\n\n\n\n For example, changing one of the important loan or property values may cause things such as LTV, payment amounts, or other calculated values to change.<\/p>\n\n\n\n But here’s the interesting part:<\/p>\n\n\n\n The fact that a value is calculated doesn’t necessarily mean the user is forbidden from changing it.<\/strong><\/p>\n\n\n\n In many situations, Encompass allows users to override calculated values.<\/p>\n\n\n\n And sometimes something even more interesting happens.<\/p>\n\n\n\n A field may appear to be read-only in the Encompass client, but the underlying platform may still allow it to be changed through the SDK or API<\/strong>.<\/p>\n\n\n\n In other words, the UI and the underlying data model don’t always enforce exactly the same rules.<\/p>\n\n\n\n From a developer’s perspective, this creates a surprisingly flexible environment.<\/p>\n\n\n\n The general philosophy feels something like:<\/p>\n\n\n\n \u201cWe’ll calculate this for you, but if you have a good reason to do something different, we’ll let you.\u201d<\/p>\n<\/blockquote>\n\n\n\n That flexibility can be extremely useful in mortgage software.<\/p>\n\n\n\n Mortgage underwriting is full of exceptions. Not everything can be reduced to a clean mathematical formula.<\/p>\n\n\n\n Sometimes the system calculates something.<\/p>\n\n\n\n Then a human looks at the loan and says:<\/p>\n\n\n\n \u201cYes, but this particular loan is different.\u201d<\/p>\n<\/blockquote>\n\n\n\n And the system needs to allow that.<\/p>\n\n\n\n Vesta takes a very different approach.<\/p>\n\n\n\n If a field is automatically calculated, it is generally read-only<\/strong>.<\/p>\n\n\n\n And this isn’t just a UI rule.<\/p>\n\n\n\n This is the important part.<\/p>\n\n\n\n If the field is read-only in the Vesta UI, trying to modify it through an API may also fail.<\/p>\n\n\n\n In other words:<\/p>\n\n\n\n And yes, I have learned to respect that \u201cNo.\u201d<\/p>\n\n\n\n This makes Vesta’s data model much more strictly enforced.<\/p>\n\n\n\n From a system-design perspective, I actually think this is a very clean approach.<\/p>\n\n\n\n The system knows which values are derived and which values are inputs, and it tries hard to prevent developers from bypassing those rules.<\/p>\n\n\n\n But it also means that API integrations require much more careful planning<\/strong>.<\/p>\n\n\n\n You can’t simply look at a field, see that it exists, and assume:<\/p>\n\n\n\n \u201cIt’s an API field, so I can probably update it.\u201d<\/p>\n<\/blockquote>\n\n\n\n Nope.<\/p>\n\n\n\n Before updating a field in Vesta, you need to understand:<\/p>\n\n\n\n Otherwise, your perfectly reasonable API call may come back with a perfectly unreasonable-looking error.<\/p>\n\n\n\n At least from the developer’s perspective.<\/p>\n\n\n\n This is probably the biggest philosophical difference I see between the two platforms.<\/p>\n\n\n\n Encompass tends to favor flexibility.<\/strong><\/p>\n\n\n\n It gives users and integrations more freedom to manipulate the loan, even when the system has calculated a value.<\/p>\n\n\n\n Vesta tends to favor consistency and enforcement.<\/strong><\/p>\n\n\n\n If the platform says a value is derived, it doesn’t want you changing that value directly.<\/p>\n\n\n\n You could summarize the philosophies like this:<\/p>\n\n\n\n Neither approach is inherently right or wrong.<\/p>\n\n\n\n They simply make different trade-offs.<\/p>\n\n\n\n And those trade-offs become very obvious when you spend a year moving a real mortgage system from one platform to the other.<\/p>\n\n\n\n There is one more area where Vesta has a very interesting advantage: AI<\/strong>.<\/p>\n\n\n\n Vesta was built with a much newer architecture, and AI is much more naturally integrated into the platform’s overall design.<\/p>\n\n\n\n The idea of having AI agents participate directly in loan workflows is particularly interesting.<\/p>\n\n\n\n That is quite different from simply adding an AI assistant to an existing LOS.<\/p>\n\n\n\n I haven’t personally used Vesta’s AI capabilities enough yet to give it a fair technical evaluation, so I’ll leave that topic for another post.<\/p>\n\n\n\n I would rather say \u201cI haven’t used it enough to judge it\u201d<\/em> than write three paragraphs about AI based on a product demo and pretend I am now an AI expert.<\/p>\n\n\n\n The internet already has enough of those.<\/p>\n\n\n\n After working with both platforms, one thing has become very clear to me:<\/p>\n\n\n\n An LOS is not just a collection of screens and APIs.<\/strong><\/p>\n\n\n\n The platform’s philosophy shows up everywhere.<\/p>\n\n\n\n How does it handle concurrency?<\/p>\n\n\n\n How does it define a calculated field?<\/p>\n\n\n\n Who is allowed to change a value?<\/p>\n\n\n\n What happens when a user changes something?<\/p>\n\n\n\n What happens when an API changes something?<\/p>\n\n\n\n Where does the system enforce business rules?<\/p>\n\n\n\n And perhaps most importantly:<\/p>\n\n\n\n Does the platform trust the user, or does it trust its own data model?<\/strong><\/p>\n\n\n\n Encompass and Vesta answer these questions differently.<\/p>\n\n\n\n Encompass gives you a lot of freedom. Sometimes that freedom is exactly what you need. Sometimes it means developers have to be very careful about what they change and how they change it.<\/p>\n\n\n\n Vesta gives you stronger guardrails. That can make the platform more predictable, but it also means you have to understand its rules before you start writing integrations.<\/p>\n\n\n\n After a year of migration work, I’ve learned that moving from one LOS to another isn’t really about moving data from System A to System B.<\/p>\n\n\n\n You’re also moving from one set of assumptions to another<\/strong>.<\/p>\n\n\n\n And sometimes, the hardest part isn’t figuring out how to call the new API.<\/p>\n\n\n\n It’s realizing that the new system has a completely different answer to the question:<\/p>\n\n\n\n \u201cWhat should happen when someone changes a loan?\u201d<\/strong><\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":" For the past year, I\u2019ve been working on something that sounds simple when you describe it in one sentence: Migrating a Loan Origination System from ICE Encompass to Vesta. Of course, anyone who has actually worked on a mortgage system knows that \u201cmigration\u201d is one of those words that can mean anything from \u201ccopy some … Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-57","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts\/57","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=57"}],"version-history":[{"count":1,"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts\/57\/revisions"}],"predecessor-version":[{"id":58,"href":"https:\/\/barrymind.com\/index.php?rest_route=\/wp\/v2\/posts\/57\/revisions\/58"}],"wp:attachment":[{"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=57"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=57"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/barrymind.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=57"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\nDesktop vs. Browser<\/h2>\n\n\n\n
\n\n\n\nThe Loan Lock Problem<\/h2>\n\n\n\n
\n
The danger of the accidental change<\/h3>\n\n\n\n
\n\n\n\nTwo Very Different Ideas About Data<\/h1>\n\n\n\n
\n
\n
\n\n\n\nVesta Is Much Stricter<\/h1>\n\n\n\n
UI says: Read-only\n \u2193\nAPI says: Read-only\n \u2193\nDeveloper says: \"But what if I really, really want to?\"\n \u2193\nAPI: No.\n<\/code><\/pre>\n\n\n\n\n
\n
\n\n\n\nFlexibility vs. Enforcement<\/h1>\n\n\n\n
<\/th> Encompass<\/th> Vesta<\/th><\/tr><\/thead> Client<\/td> Desktop in our environment<\/td> Browser<\/td><\/tr> Editing model<\/td> Traditional loan locking<\/td> Real-time persistence<\/td><\/tr> Collaboration<\/td> More restrictive<\/td> More flexible<\/td><\/tr> Calculated fields<\/td> Often can be overridden<\/td> Generally read-only<\/td><\/tr> API enforcement<\/td> Relatively permissive in some areas<\/td> Much stricter<\/td><\/tr> Architecture<\/td> Mature \/ legacy-friendly<\/td> Modern \/ cloud-native<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nAnd Then There Is AI<\/h1>\n\n\n\n
\n\n\n\nWhat I Learned from the Migration<\/h1>\n\n\n\n
\n