In a recent CLSA Excellence webinar, we focused our attention on the role CLSAs play in delivering successful projects using Pega Express. I think the value of the Prepare stage in setting a project up for success is often underestimated. The panelists on our webinar – CLSAs representing both Pega Consulting and Pega Business Partners – all agreed that the Prepare stage is the right time for the LSA to start design of the Enterprise Class Structure, application architecture and reusable componentry.
In other words, the Prepare stage is not too early to start thinking about critical architecture decisions. It is the right time.
Won’t somebody think of the LSA?
Some of our earlier CLSA webinars targeted specific domains where LSAs can take earlier action to maximize Delivery Excellence. Our Data Excellence webinar draws attention to that handful of actions which – when done early – yield a resilient Data Design for current and future needs, before a process rule has even been configured. So too our Security Excellence webinar discussed the early requirements-gathering and designing of the authorization matrix (that is, who can do what). An increasing number of data and authorization design tasks can be completed in App Studio now too, delivering applications faster, which are within guardrails and are ready to upgrade.
This is a lot for the LSA. Yes, the LSA may ultimately be accountable for the technical solution, especially its data and security, but they can always do with extra pairs of hands to get to Done. Besides, security is everyone’s responsibility, in ways that accord to their experience, skill and the role on the delivery.
What can System Architects and Senior System Architects do to help?
A common perspective I hear is that whilst System Architects (SAs) and Senior System Architects (SSAs) can more easily advance the data design and implementation of an application, the application’s security is “the LSA’s job.”
With so much focus in sprints on functional compliance, non-functional aspects – such as security – risk becoming deferred to a Go Live readiness task. Since they are left to last, regrettably there are times when non-functional requirements are not implemented at all.
11% of the questions asked in the Senior System Architect 8.5 certification exam come from the security topic. Comparing this with just 3% as recently as the 8.2 exam, it is clear that Pega developers simply cannot ignore that security is – more than ever before – fundamental to their role.
The security responsibility of each and every System Architect on a delivery team lies somewhere between these two extremes:
- The System Architect that configures a feature without any consideration for how to control access to it;
- The System Architect that worries about every security aspect that may foreseeably pertain to the application.
As I alluded to earlier, security is everyone’s responsibility. No member of an effective development team can be oblivious to security concerns.
I challenge SAs and SSAs to push themselves forward from where they are right now on that continuum. SAs don’t have to be as far along as SSAs, but they should be aware that even they have a role to play; know the Pega security building blocks; and be hungry to advance their position forwards.
No Pega developer (SSAs and SAs, included) would consider a feature Done if the feature has not passed the unit tests that verify its acceptance criteria. Could a feature be considered Done if its authorization needs had not also been verified? No way.
Configuring a process step, for example, requires more than simply deciding what data is shown and captured on its user interface. It also needs to solve for:
- Which Personas are authorized to perform this step?; and, more importantly
- Which Personas are not authorized to perform this step?
Catch yourself saying “I’ll make it work now; it is someone else’s job to lock it down.” When an unauthorized user can access your feature – or an aspect of it – the feature does not ‘work’.
Authorization-aware Pega developers consider feature-level access control as a first-class citizen of their development process for every feature. Sometimes there may be nothing to do. When there is, it may not even be that hard. One well-targeted Privilege applied to a Flow Action rule may suffice; perhaps a single Access Role applied to a Work Queue is all that is called for.
The very end of the security responsibility continuum
SAs and SSAs should not feel they are responsible for security at the application level. The LSA is the System Architect role closest to the end of the continuum, working in collaboration with the client’s IT Security stakeholders and third-party security testers.
The LSA:
- Defines the application-level access control vision, designing Personas, Access Groups, and Access Roles;
- Actions security checklist items; and
- Owns one-off application-level security tasks, such as Authentication configuration.
LSAs may delegate the design & implementation of some of these tasks to their most trusted Pega developers. This is at the LSA’s discretion, and according to their direction.
Set up for success
Two simple steps that can drive the required behavior from the delivery team are:
- Folding authorization test cases into the Definition of Done; and
- Requiring a user story’s authorization needs form part of its acceptance criteria.
Establishing the Definition of Done and readying the first 1 to 2 sprints of backlog items with complete acceptance criteria are each activities that are performed in that all-important Prepare stage. Set the project up for success by having this discipline in place before the Build stage starts.
Not every feature configured by a Pega developer may need additional locking down, but security-consciousness needs to be part of the fabric of every Pega developer.
Don't Forget
- JOIN THE CONVERSATION on Collaboration Center
- FOLLOW @PegaDeveloper on Twitter
- SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS
