Pega Express™ is about achieving high quality, high value business outcomes for our clients’ customers, as quickly as possible. However, to any seasoned software developer, going live with an enterprise-grade software solution in only 90 days seems like an unrealistic expectation. The thought that this 90-day period includes input from the business and citizen developers? That the eventual users of this system will love the product? It all seems a bit hard to believe. Developers may look for reasons why the 90-day deliverable cannot be true.
Software developers often have doubts, and “future-proofing” the software is one of the most common. They fear that leaving the development to the citizen developers, or the business, risks releasing badly designed code into the wild. They may fret over object-oriented best practices, their data structures, and that holy grail of software development: software reuse.
Developers are often used to spending weeks designing and refining data structures and class structures. They implement elegant but time-consuming patterns to cater to all the possible scenarios for which they might one day be thankful. Sometimes the focus may be 80% on technical elegance rather than 80% on delivering immediate business benefit.
Technical design is good practice, of course, however, through applying design thinking techniques and collaborating with the business and its users/customers, time is spent on identifying the right simple solution rather than focusing on heavy design. This is because the thoughts behind the 90-day minimal lovable product (MLP) with Pega Express™ begin from a different place. Pega Express is built on a set of process and technical best practices. It provides a solid technical foundation that supports the MLP through many future iterations. As software developers, we need to accept these practices and embrace them.
With Pega Express™, the best practices that developers always follow are all there. However, the best practices are laser-focused on getting that first genuinely lovable product that delivers the business impact to delight the users within those 90 days.
Traditional software development approaches put a lot of the work “upfront”; it is difficult to change, and expensive rewrites of code are all too common. In attempts to reduce future challenges, developers can spend a lot of time building architectures to mitigate any possible changes to requirements that might occur months and years down the line. Traditional approaches can mean that time is wasted without any changes taking place, or the changes that do happen are never envisaged in the first place. Expensive rewrites happen after all. A design with excellent potential for reuse that is never reused is not a good investment.
With Pega Express™, the concept of best practice shifts; system architects focus on what the business needs now, not what we think it might need next year. Pega solutions always have the principle of Build for Change® at heart. Whatever changes that come after the MLP are rapidly incorporated into the solution in future phases and continue to follow the best practices of the Pega Express™ approach and application adoption.
For low code developers, increased effectiveness comes with using App Studio to create applications. App Studio takes the business concepts of the case types, steps, stages, personas, and data. Business users define these concepts directly in Pega solutions without the complexity. System architects can be confident that the application models the real world and delights the business users who are involved in the inception of the application.
Pega implementations do this while following the industry best practices of scrum, manual and automated testing, DevOps pipelines, and security hardening. The Pega Cosmos design system means that development teams avoid spending weeks tweaking the UI, and with Agile Workbench built in, time is spent on managing work efficiently instead of wasting time with spreadsheets and external applications.
So, what about the more traditional best practices that Pega technical teams have always embraced in the past? Branch-based development, Pega Unit tests, enterprise class structure, class-based inheritance, and reuse?
All these traditional best practices still have a place in the enterprise, and nobody would argue against them. But as developers, we can be flexible, use them to our advantage where appropriate and focus our attention on delivering in the here-and-now to leverage the most business benefit from the 90-day minimum lovable product.
On many projects, business priorities change rapidly in the first 90 days. As soon as business users see their application coming to life as they work, they realise what potential they can unleash. By leveraging Design Thinking throughout the project, business users can change tack collaboratively and without fuss.
During this time of rapid change, software developers focus on supporting those changes by following Pega Express practices rather than having to land on a final enterprise class structure before the business users themselves have settled on a firm direction.
So, what are we left with at the end of the 90-day minimum lovable product? A product that the users love, of course. But technically, “under the hood,” is the resulting application fit for purpose as the basis of future, on-going development?
The actual rules, the building blocks of the application are all there as you can expect.
The rules might have names that you may prefer now to update, but does this matter, really? In a few cases, it might, but the time of stability after the MLP completion is the right time to review and make any refactoring changes that you need. All the rules can be “polished” if needed without affecting the development or the application.
What about the class structures? The MLP leaves us with a data model that represents the real-world, so we are on a solid base. Maybe there are concepts that users can group into abstract base classes, properties that are realigned into a hierarchy that makes more sense for reuse in future. These are easy to spot and refactor once the users are using their application.
The beauty of Pega and our delivery approach is, that we do not necessarily have to get all these technical concerns defined and agreed before we develop. With a Lead System Architect on the project, the technical details and refactoring can occur when it needs to happen. This flexible approach does not abandon the best practices of the past; instead, it keeps practices on hand for use once there is a firm understanding of when they provide the most benefit and prevents needless use just for the sake of it.
Delivering a solution that users love that meets the needs of the business from inception to completion in 90 days is a realistic outcome with Pega Express. The approach does not abandon best practices for configuring an application; instead Pega Express is built on industry-standard best practices that are proven to deliver high quality results, quickly.
The best practices to which we’re accustomed still apply, too, but they just are applied in a different order. This approach is not a bad thing; it makes the most of the changes that Pega Express brings to application development, and the implementation only improves the result further. It’s time to embrace those changes and start building a minimal lovable product in 90 days to delight our users.
Learn more about Pega Express, see Pega Community, or get your Pega Express delivery badge today!
Don't forget
-
JOIN THE CONVERSATION on Collaboration Center
-
FOLLOW @PegaDeveloper on Twitter
-
SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS
