Direct Capture of Objectives has a revamped the look and feel in Pega 7 but little has changed.
What is the same?
- Business Objectives
- Actors
- Requirements
What has changed?
- Work Types are now called Case Types but the underlying thing seems to be the same.
- Use Cases are now called Specifications, which allows the specification to capture Use Cases or User Stories, depending on the project approach.
What has been taken away?
- Discovery Maps seem to be gone. Click here to see why this delights me.
- You no longer have the Application Profile Wizard to guide you through DCO. However, the wizard was not necessarily the best route through DCO anyway; moreover, you were never restricted to that route (which meant it was never really a wizard). Removal of the APW is not a loss.
What has been added?
- The ability to document User Stories instead of Use Cases (both are variations of a Specification).
By and large, my original appraisal of DCO still stands, which is disappointing, as I would have liked Pega to make other than cosmetic changes and turn it into a real set of tools for the business analyst.
Strengths
- Traceability continues to be the only real strength in DCO and the Application Profile but it’s not a trivial one. If you relate a model in the business architecture to either a Specification or a Requirement in Pega, then you give the developer something to anchor the Pega Rules to. If developers are rigorous about maintaining backwards traceability, when the business architecture changes in any way, you can the trace forwards to see what Pega Rules are affected.
Weaknesses
For me, the main weaknesses of DCO continue to be:
- It ignores logical data modelling completely! Click here to see why that is a critical miss. I have known more than one Pega implementation that failed to satisfy the customer simply because the physical data architecture underlying the application failed to address the basic nature of the business data. Once a physical data architecture is in place, there is no “tweaking” it if it is wrong because it is the very foundation of the application.
- It fundamentally still sees the business need in terms of requirements, rather than a set of models that express the needs of the To Be business architecture, which are then supported by requirements.
- Somewhat redundant if your business architecture (and therefore your requirements) is going to be implemented by several technological solutions (i.e., Pega is only part of the solution).
- It gives the impression that simply putting requirements into DCO automatically builds an application for you (“But we DCOed it!” I have heard customers say when their Pega implementation failed to live up to their expectations – not Pega’s fault, I hasten to add, but the customer’s failure to clearly and unambiguously articulate what they needed).
If you are a Pega Business Architect, DCO is not a magic bullet and it will not replace the skill-set of an experienced business analyst.
Kind regards.
Declan Chellar
Related posts:
Completely support your points here Declan.. I for one, whilst trained and certified in DCO, SmartBPM and APW, am yet to use any of these supporting features or tools in anger as, in FIs with whom I’ve worked, there’s always been a mandate to use ‘RRC’ for traceability and chaining.
That being said, I’ve never even used RRC as anything other than a retrospective repository of requirements documentation as it’s always seen as too ‘esoteric’ a tool to force upon the business who prefer their documents in word or excel forms.
Yes you can export from both sets of tooling in to whatever format you like, but when only the BAs are bought in to the approach, you fail to achieve the optimum benefits of using it.
Better are tools that allow or support us in data or process modelling and help and aid us in sharing these concepts in consistent, easy to understand means and that can readily dropped in to whatever traceability tool or methodology that we need to.
For me, as you highlight here, it’s trying to be all things to all people with little room to leverage the best, or useful bits and extend in ways that support whatever delivery, methodology, platform, services, partners and stakeholders you’re working with.
Thanks, Ryan. It’s good to have someone else’s perspective. Of course, the problem (as I see it) is much deeper. All will be revealed in my latest blog post titled “Business analysis is about more than software requirements”.