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 architectural changes in Pega.

Don't forget to click the Show More link.

Will multi-tenancy remain as an option in the product and if so where is this going?

Pega is moving towards a multitenant model, but not in the traditional sense of multi-tenancy. As the infrastructure layer, the use of Kubernetes and Docker allow clients to be clustered into PODS, effectively delivering multi-tenancy at this layer. Within the platform architecture, Pega is taking a hybrid approach to evolve our tenancy model that balances the cost benefits of multi-tenancy models with the need for data privacy and security. Therefore, Pega's microservices-based architecture will contain both single- and multitenant services.

What is Pega's vision on aligning with microservices architecture that the industry is moving towards?

Pega has been on the forefront of the shift to microservices. We began work on this in 2018 and announced Project FNX in 2019, which is the internal name for the work we have been doing to separate our platform into discreet services. Since then we have been moving to a complete microservices architecture every release. We expect to continue this work and evaluate services that can be extracted from the core platform when it makes sense. Pega will also always continue to evaluate new technology that brings benefit to our clients and adopt it as quickly as possible. Client applications that utilise Pega's center-out and Pega Express methodology will automatically leverage these microservices as they are released.

If a client stays on premise or utilises Cloud Choice, how much do I have to learn about containerisation, or do I just have to click "Run" somewhere? How much does an LSA need to know?

Clients who opt to stay on premise will be required to install and maintain their own container environments. Pega has standardised on Kubernetes based container deployments. While we will supply guidance for deploying on Kubernetes, it is expected that there will be sever administrators who understand how to deploy, maintain, upgrade and scale containers in Kubernetes.

What will change about administering a Pega environment on FNX?

Pega has simplified the deployment and administration of environments since standardising on Kubernetes based deployments for Cloud Choice users. We have also streamlined the administrative functions into Admin Studio, and enhanced Deployment Manager to make managing environments quick and easy.. Clients who use Pega Cloud can rest assured knowing that a dedicated team are ensuring their environments are running properly at all times.

PegaCloud is fully built on AWS. Do we expect that PegaCloud will also be possible on different cloud technologies for clients that are fully on those stacks, for example Azure?

Pega offers support for AWS, Azure, GCP, VMWare Tanzu (formerly Pivotal), and RedHat OpenShift through our Cloud Choice program. Clients wishing to build and operate Kubernetes environments for Pega Infinity may do so under the cloud choice guarantee. Pega Cloud is our fully managed service. We build and operate the environments in Pega Cloud as part of your full service subscription.

Will the LSA role to shift away from hands on development and more towards guiding other developers and collaboration with the business?

The LSA role has always been a role that includes mentoring, coaching, working with business and other client resources to assure co-production and adoption of the Pega technology. Although this component of mentoring a team or teams might grow, there will always be an element of hands-on development for the LSA where these senior technical skills are required for creating the complex functionality and for the creation of reusable features and making them available as plug-able components for the business users to utilise these in App Studio.

Can we see Process Fabric as a replacement for Pega Web Mashup?

Process Fabric encompasses a number of new capabilities to provide orchestration and visibility to processes which cross a number of applications. Process Fabric is not replacing Pega Web Mashup - which will still be used to deliver embedded web-self-service.

With Process Fabric, we plan to make it simple (through App Studio) to develop cross-application UX integrations which leverage the DX API under the covers (e.g. embed a worklist from one Pega app in the UX of another Pega app).

Are we going to release third party connectors as part of Process Fabric in a similar way that Microsoft is doing with Power Apps connectors?

Yes - and you will be able to build your own.

Can Process Fabric work within different Pega applications? Is DX API the way to integrate different Pega applications going forward?

Yes - you can connect/orchestrate across various independent applications/Pegasystems. We envision that instead of building large applications we will be creating many small applications that contain one or a few 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.

DX API will be more and more core to our app-level integrations going forward.. Traditional Pega API will still be supported.