UI Architecture Topic - Need further elaboration on Intent-Driven , Model-Driven UI
The notes provided in the course are more of theoretical.
Can you highlight some real time implementation examples?
It would be great if you could elaborate the above with some real-time use cases along with the actual implementation.
This would help us in providing additional insight for the Enterprise Architects who are technology agnostic and not well versed with Pega UI.
A set of buzz words indeed. I will try to elaborate on them.
Intent Driven: In other systems you will quite often see generic screens for a user to fill in. You can say the process is part of the person filling in the screen as he knows what parts to fill and what he/sh can skip. For me this was quite obvious when I bought my last phone. The seller had to switch between 4 or 5 different applications and had to open multiple screen to get all the information he needed to create a new contract for me. Intent driven means you should have all information you need, at hand, for your intent: Create a new contract for me. The user interface guides the user what he/she needs to do to complete the task at hand. Depending on your background this might or might not be obvious for you, but I can ensure you this is not that common as you would like to think.
Model Driven: In may development processes the screens are modeled using third part tools. Drawing tools, mock up tools or pen and paper. This models than have to be translated to the system at hand. It has to be coded into HTML, system calls and data models by programmers etc. Model driven hear means the Business annalist here using our tools to mock up screens. This model is then automagic and direct translated to HTML or whatever needed to run your application. Change the model and your application is direct changed as well. For many web developer tools and software system this might be quite standard, but for many enterprise system not always so.
Also remember that many enterprise class application have quite long change request cycles. For banks and insurance companies we might talk about 1/2 a year for moving a field or adding a item, Depending how we have set up our Pega system we talk about minutes or hours, seldom days. That is Build for Change.
Keep in mind that traditionally enterprises have very separate and disjunct departments for the direct business and IT and operations. Pega tries to bridge that gap by letting IT do IT things: Keep the server running and happy and letting on security and have business adapt their application in a secure way to changing business conditions.