On November 12 we hosted the second CLSA Community of Practice meetup featuring Don Schuerman, Pegasystems CTO and Vice President of Product Marketing. During this meetup Don has been talking about how the LSA role evolves from the perspectives of the App Studio lifestyle, FNX, Process Fabric and Cosmos.

The recording is available here: https://collaborate.pega.com/discussion/recording-meet-cto-event-clsas-november-12-2020

There was a number of questions asked say the participants that weren't answered during the session. Below you can find a number of those questions with their respective answers about the App Studio Lifestyle.

Don't forget to click the Show More link.

What are the main business drivers for Pega for this App Studio lifestyle?

There are two important business goals to mention here.

First of all we can deliver results faster for our clients. App Studio allows business subject matter experts and developers to work and create those micro journeys into an environment that is built to be easier to use. Unlike Dev Studio, the use of App Studio doesn't demand that you understand some of the internal class structures and mechanisms of Pega in order to work with it. The whole idea with App Studio is for every member of the delivery team to not have think about things like class hierarchy, build-on’s or rule forms. Instead, most of the delivery team can focus on the micro journeys or case types you want to build, to focus on the stages and steps, the people who interact with it, the kinds of screens and channels they need to have configured.

The second goal is the ongoing sustainability of the Pega product. We want to ensure that we can continuously upgrade the applications at our clients with minimal business impact. We want to make sure that every app that we build is ready to go in that kind of SAAS based model, becoming a matter of just applying updates to it including the impact of project FNX where some of the work reconstitutes the engine itself and the runtime environment. App Studio provides delivery teams of all levels of experience with a well-defined box of best practices, supportable functions, etc. Dev Studio continues to provide great power to do pretty much everything you want. While it is really useful when you are solving problems on a project, it has impact on the supportability of the product perspective.

The driver of App Studio is all about ensuring that we are inside the same common group of best practices so that we can rapidly develop Pega applications using delivery teams consisting of a broader mix of business and IT with varying Pega experience; all while minimising business impact during upgrade and promoting iterative development of future releases.

Probably most people will be on par about using app studio when implementing small case types that are manageable and purposeful with a micro-journey approach. However in existing projects some of the case types have become big and monolithic and then it can prove challenging  to align them with the micro-journeys evolution.  Is there any guidance we can offer to re-align existing landscape with micro-journey evolution?

Pega is working on creating academy training for this. At this point we can offer the following high level steps: make sure you understand the  the Life Cycle of your application and define if it is worthwhile for this application to move to the App Studio lifestyle. If so, start by preparing the application for effective use in App Studio. Assure case designer is used according to best practices,  identifying business rules that can be marked as relevant records. Convert or recreate your sections to be template-based, and make sure the applications are following all of the (new and old) guardrails. For new functionality bring in the  micro-journey approach and move into that direction.

Are there best practices and guidance around what can be done in app studio and when to move to Dev Studio in a way that it isn’t limiting further work in App Studio?

We urge everyone to take the Low Code App Builder and Low Code App Builder Extended missions on Pega Academy to understand the current features and capabilities that App Studio offers. The general guidance is to start with App Studio and use App Studio as much as possible. When you do need to step out to Dev Studio make sure to only perform the work in Dev Studio that cannot be done in App Studio, to follow the guardrails, and use the best practices you already use in Dev Studio. Be aware in Dev Studio of the consequences of creating custom code; which can affect the upgrade and maintenance of the application and introduce business impact.

UI gallery is a very good tool to include as part of App Studio. Also are there any other features we are planning to provide in App Studio , if any?

Nothing is planned right now, but if you have suggestions please reach out to the CLSA community team members. Additionally, for UI Gallery-type experience, visit design.pega.com which has our latest and greatest UI examples

How important is the use of Pega Express in the App Studio lifestyle?

The Pega Express methodology is meant to work hand-in-glove with App Studio. One of our key differentiators, and tenants of our Center-Out Business Architecture is that the methodology is baked directly into the product. This makes it easier to adhere to, resulting in quicker application development that achieve clients' desired outcomes, whilst scaling to their needs

When will Pega close outstanding branching gaps in App Studio, namely in app studio you can not specify a branch when creating/updating a property, class, view, case type, etc.

In App Studio when you make one change, you could be updating several rules. An example of this would be one change made to the lifecycle in case designer which results in updates to the case type, a flow, a flow action, validations and a section. The "Branch Development Preferences" feature (in App Studio and Dev Studio since 8.3) enables that the changes for a feature or user story can be made in a single branch. Branching in app studio works different than in dev studio but gets the job done. Please refer https://community.pega.com/knowledgebase/articles/application-development/85/implementing-branched-application-development

In Pega 8.1 automations were introduced as an interface or contract defining input, output and hiding the actual implementation. Change stage was an example. Can we expect to be able to develop our own “automation” rules and use them from the palette on the App Studio?

There is a plan to consolidate various 'automation' rules (activities, automations, data transforms) in our future architecture but at this point we cannot name anything concrete. That said - it would be extremely helpful to hear use cases for these automations. Please reach out to the CLSA community team members with ideas that we can channel to Product Management.

How to explain Pega Express vs App Studio vs App factory to customers?

Pega Express is our light, design-focused methodology that uses Pega's low code experience, best practices and Scrum to deliver meaningful outcomes quickly. It is built directly into our low-code design environment, App Studio, to help you build apps quickly, and efficiently. Leverage the Pega App Factory to super-charge your organisations ability to deliver low-code apps, empowering Citizen Developers to drive change throughout the organisation, while collaborating with IT to ensure quality, scalability and sustainability of your apps.

By pushing the use of App Studio more, aren’t we compromising on the full potential of Pega?

Encouraging App Studio does not mean there is no place for Dev Studio. We should not be looking at these as two competing products but instead as two complementary tools in our toolkit. Use App Studio to build out Case Lifecycles, Forms and simple integrations to systems, and use the more surgical Dev Studio for things like configuring security, more intricate business logic needs (like complex routing, less-popular integrations, etc).

What would be the role of LBA in this new App Studio lifestyle?

The LBA is typically a role that is involved in the early stages of the delivery; especially Discovery and Prepare where the LBA is instrumental in the setup of the case type backlog and defining the micro-journeys. While the LBA was already expected to work in the Pega Platform (DCO, case designer, defining UI, etc) it only becomes more obvious in App Studio where the LBA now can fully work within the guardrails and best practices by delivering business value through App Studio. The LBA is material in identifying Personas, Channels and Data. When talking about data, this is not so much the SOR and integration need but most definitely identifying business objects that the micro-journeys need and engaging client stakeholders at the start on reuse potential, emerging business needs, data relationships, etc. From an App Studio point of view, LBAs are ideally placed to capture the Data Objects from the micro-journey's point of view into App Studio.

in App Studio - can we still easily build for enterprise reuse using traditional ECS (that has enterprise, framework, and implementation class layer)?

When starting a new enterprise program, we expect not to build 1 or 2 large applications but 50 or 100 or even more smaller applications (micro journeys). Process Fabric extends the federated case management idea to leverage its interwoven worklist to feed work into different places and construct this overall experience to that actual customer journey. Process Fabric will deliver composability and reuse that is not necessarily built on rigid hierarchy, but is built on loose coupling of components that might live in physically separate applications. This starts to look a lot more like a true micro services kind of world where operations are distributed.

There will always be situations where the ‘classic’ pattern of a framework and multiple implementations be valid; if you're going to deploy an application that needs to run across 30 countries and 20 different business units, you probably need an enterprise class structure. Looking at it from the perspective of App Studio, we are generally in the context of one layer.

As a Pega developer why should we use App Studio when we have the entire capability available in Dev studio?

We expect everyone working in Pega to adopt the #AppStudioLifestyle - Not only because it is the best way to make sure applications are built Center-Out, but because it shows off the best that our platform has to offer. We should not use Dev Studio for those areas where using App Studio is possible, things like defining the life cycle (stages, steps and data), or common integrations, designing forms, etc. That's not to say we never go into Dev Studio, but use them as appropriate. We do expect the LSA will be using Dev Studio to create and package (business) features for App Studio users to "plug in" to their micro-journeys.