In my experience, not many people distinguish between “Requirements Analyst” and “Business Architect”. I consider them very different roles and here are some of my thoughts on the subject.
A Requirements Analyst
A Business Architect
Asks what the user wants.
Asks what the business needs.
Asks how the user benefits from performing a task.
Asks how the business benefits from the user’s performing a task.
Traces everything back to the requirements.
Traces everything back to the strategic goals of the business.
Asks: “What are the data attributes for this screen?”
Asks: “What defines X? Why is it important to the business? What are its characteristics? What other things is it related to? Why do different areas of the business have different definitions of X? Why are there several data stores for X?
Is focused on the success of one software development.
Is focused on the success of a business change (including that one, of many, software developments).
Takes into account the constraints of the chosen technology.
Is technology-agnostic.
Seeks to enumerate.
Seeks to understand, describe, categorise, model and test.
I am recognised by Pegasystems as a Certified Business Architect. But what does that mean?
As you may know, Pega has Direct Capture of Objectives (DCO), a useful set of tools which can be used by experienced requirements analysts during the Inception and Elaboration phases of a Pega development to directly capture information about the business need. The certification means that I have a degree of competence in using those tools. However, the title can be misleading, because Pega uses the term “Business Architect” in a sense specific to Pega projects but a Pega Business Architect has nothing to do with the competencies and tasks of a business architect as set out in the BIZBOK. (see my blog posts “Requirements Analyst versus Business Architect” and “What is a Business Architect“).
What you might commonly think of as a Business Analyst working to describe the needs of the business, Pega calls a ‘Business Stakeholder’:
‘Business stakeholders define a business problem.’1
In its training materials, Pega describes the role of the CPBA as follows:
‘A business architect clarifies what the customer must have and proposes Pega solutions to add value to the business.’2
‘Business architects plan the application to address the problem.’3
In other words, the CPBA designs the high-level Pega solution. If you think there is something missing from the three quotes above, you’re not wrong. Sitting between the definition of business problems (I prefer to say ‘needs’) and the high-level design of the Pega solution, there should be a set of technology-agnostic models of the business solution to the described business needs. Business problems first need business solutions. Some of those business solutions require automation and from there you go to technology solutions.
I believe that when when business analysis is limited to (or centred around) the software development lifecycle, it ceases to be about defining the needs of the business and instead supports the main need of the solution provider: deliver software to schedule, which should be a means and not an end in itself.
It often surprises business analysts, project managers and scrum masters when I tell them the business architecture work I do is not (just) about their software development project. This slide deck explains my reasoning. What have been your experiences?
Before attempting to model a business process, you should first define its scope so you know how it starts, how it ends and whether it is really one process or many.
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 continueto 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.
I’ve read a lot of CVs (resumés) presented by people who are looking for work as business analysts.
It always surprises me (I guess it shouldn’t at this stage) that when they list their skills, they almost never list the kinds of technique you might find in the BABOK; rather, they list the tools they have used, Visio often appearing at the top of the list.
I hate to break it to you, kids, knowing how to use Visio makes you a business analyst in the same way that knowing how to use Word makes you a writer (don’t get me started on Powerpoint/presenter). I once drew a conceptual data model relating to insurance products on sand using a stick (not in a formal setting, of course). What was my skill? iStick? MS Sand?
If you present a list of tools instead of a list of BA skills that you expect to be tested on, then you don’t know what a BA does or what skills a BA should have and I won’t even read past the word “Visio”.
“In the 1930s, a tomboyish girl runs away from her guardian to join her single father who is 2,000 miles away, because there was work there.”
Judging by the title, I think it’s reasonable to expect Natty Gann to be the protagonist and for the story to be about what she does and the trials and tribulations she goes through along her journey.
I would be somewhat bemused if the film turned out to be about the people Natty Gann interacted with along the way, if the story were told from their point of view and her character were just a shadowy figure in the background. While this version might still be a good film, I would consider the title misleading.
Similarly, if you are presented with an artefact titled “Customer Journey”, I think it would be reasonable to expect the journey of the customer, told from the customer’s perspective, revealing the trials and tribulations of the customer.
And yet when I see such artefacts, they usually tell the story of the customer interactions from the perspective of the business, what the nature of those interactions is from the perspective of the business and what the trials and tribulations are from the perspective of the business.
Of course, that is a very interesting story and it’s an important one to tell. But it is not “The Journey of The Customer”.
In business analysis being precise in our use of language is important. Ambiguity is our enemy. So if you are going to tell the story as experienced by those who deal with your customer, tell that story and title it accordingly.
And if you are going to ask your business analysts to produce a Customer Journey, make sure you clarify what you need the story to tell and make sure you give them access to actual customers who can tell them about the journey.
It seems nowadays that when anyone in business wants to communicate a lot of detailed information, they gather a bunch of people in a room and read the information to them off Powerpoint slides.
And to judge by the number of seasoned business professionals who choose to communicate detail in this way, it must be the best way to do it. If only my lecturers at university had had Powerpoint! I would have learned so much more if, for example, instead of getting us to read Homer at home and then discuss themes, imagery, characterisation, etc., in class, Mr. O’Nolan had read out the verses in bullet-point form from Powerpoint slides.
How foolish it is to expect university students or business professionals to be able to read to themselves!
And educational opportunity missed because we were born too soon.
For your edification, I present Book 1 of Homer’s Iliad, as it should have been presented to me in lectures, as most business professionals would present it to you nowadays. For the full effect, have someone with an awful, dreary, monotonous voice read it to you in a stuffy room after a heavy lunch.
Seriously though, if you read out text to me during a presentation, you run the risk of being spattered with blood when I apply a shard of glass to my throat.
Continuing on from Use Cases in PRPC – Part 3, the following tables will give Pega Business Architects an idea of how to use PRPC’s “Use Case Rule” to capture details about your Atomic Use Case.