Thanks for purchasing Debunkum Beaver Pega How-to
Guide! In order to fully maximise the book, it is important to understand the
purposes and positioning of this How-to series.
Why Create a Pega How-to Guide?
Strictly speaking, information on Pega “how-to”
can be found in Pega Community, Pega Academy, as well as throughout the
Internet.
Even if the information is not readily available,
all that is needed is simply to create a new Pega Community post; and somehow,
after some time, there would be people from the community, Pega GCS or even
Pega Engineering, jumping in to provide the answer, so isn't such a how-to
guide unnecessary?
Well, technically, you could argue it in
that way. However, in any engagement, one of the most challenging things is “deadline”.
Often, a go-live date would be defined well before requirement specification is
signed off.
Therefore, there is basically no time to
search for information, wait for replies, or learn and explore how to implement
certain features/requirements in an actual project scenario, at the time when it
is required.
Apart from that, the replies are often not
an end-to-end, step-by-step guide, complete with screenshots and do not include
validation and testing steps. Thus, it would require prior Pega knowledge and
additional effort to clarify, test and finally implement it.
To add on to the challenges, the profile of
the team members often creates another dimension of issues. This problem has 2
extremities:
2) Senior and Experienced Pega SSA/LSA: Those who have many years of experiences, some even spanned across Pega V5.x and V6.x
For New
Users of Pega, they do not know how to implement a lot of things in Pega, thus
a lot of hand-holding and samples are required to guide them along and get them
to be efficient.
There is technically not much issues with
them, just the need to provide them with some relevant examples, or even
implement one instance of the solution, explain to them how it works, and they
would be able to get started and replicate the implementation across other
parts of the application.
The downside is that a lot of time is
required to create relevant samples and also to help them in debugging issues
that may occur.
On the other hand, Senior and Experienced
Pega SSAs/LSAs, although are self-starters and able to start implementation
without much guidance, they introduced another kind of problem – their solutions
to all problems are often “activities” and “agents”!!!
Any other issues that cropped up along the
way, would often be yet another activity, custom Java codes or some HTML,
JavaScripts; the worst that I have seen, was creating multiple Boolean
variables to cater for various flows and decisions throughout the whole
application for handle difference scenario and business changes!!!
With all those Boolean variables, in order
to understand the whole logic (and ensure it is correct), you need to kept
track of all the Boolean variables that are set/unset throughout all the activities,
data transforms, flows, UIs, button clicked, etc.! Isn’t that a BIG pain? How
could the application ever be reliable?
Technically, they can implement the
required features, but whatever they had touched, can no longer be easily
modified by another SSA/LSA without the corresponding number of years of
experience, not to mention about the underlying performance and maintenance
issues that were introduced!
In
view of all these challenges, Debunkum Beaver has decided to embark on this
path: A How-to Guide for Pega.
For New Users of Pega, this series provide
a step-by-step guide to implement any given feature; for Senior and Experienced
Pega SSAs/LSAs, this guide shows the best practices and a standardised way of
implementing the intended features, leveraging on the newer Pega capabilities
to simplify the implementation, as much as possible.
With the Debunkum Beaver Pega How-to Guide series,
you would have an arsenal of tools at your disposal. Whenever there is a new project,
or a new feature required, all you have to do is just to pull out one of these
guides. Cool right?
Can you visualise a situation, where all
similar features have the same way of implementation, with the same sequence of
steps and number of rules; and anyone who looked at the rules knew exactly how
and why each rule was implemented as such; any deviations and bugs that were
introduced due to carelessness would simply stand out by itself, easily
identifiable and easy to fix, wouldn't this be a wonderful Pega World?
Well, that is the core objective of the Debunkum Beaver Pega How-to Guide series!
With the direction set, the next question
is: “How Should I Categorise the Pega How-to Guide?”
How Should I Categorise the Pega How-to Guide?
Given that there are so many features, I
couldn't just write ONE book, it would take ages, and by then, a new
Pega version would be released!
Of course, I could potentially do a
high-level grouping, e.g. Pega
Integration, Pega Reporting, Pega Case Management, etc...
But there is one big problem...
Take Pega
Integration as an example, there are so many types of integrations: SOAP,
REST, OAuth2, etc. Does that mean that I should write all the integrations
before publishing the “Pega Integration” book?
That would also take a long time, increase
the overall price of the book and force readers to pay for things they don’t
need or are not interested in; worst, it would just end up as another version
of Pega help file.
On top of that, if one of the integration
methods changed, do I need to update the whole book as a new version?
Apart from the above issues, you may have
realised another problem: I have not mentioned about another dimension of
Integration: Service Packages vs Service Connectors!
So, should I have a book on Pega Integration Service Connectors and
another on Pega Integration Service
Packages? But I cannot separate them because I need to use the Service Connectors to invoke the Service Packages to test!
As you can see, things just get more and
more messy...
I shared my problem with my boy, and asked
him what books he enjoyed the most, and this is what he showed me - His private
Mr Men Collection!
Figure 1: Mr Men Collection
He went on to explain how much he enjoyed
the book. Although each single book is short, it is concise, and he can easily
look for any Mr Men he wants; at the same time, priding himself as Mr Happy...
Well, although I feel Mr Messy is a better
match for him , I agree on his concept: small little book that is concise, and
easy to be used as a reference!
Yes! That is exactly how the Debunkum
Beaver Pega How-to Guide would be released!
The next question is: How should I organise
each Pega How-to Guide, so that it would achieve the core objective?
How Should I Organise Each Pega How-to Guide?
I want to have a how-to guide suitable for
both beginners and experts, one that could be used as a quick reference, yet
without the unnecessary theories and documentation.
Yes, this is really a tall order, but
anything less than that would not serve the purpose and would just end up being
another Pega Community post or simply an excerpt of the Pega help file!
It must be able to provide something like a
2-mins run-through to illustrate the purpose and concept, like the typical
“Hello World!” of programming, yet able to be expanded further into more useful
stuff!
So
here, Debunkum Beaver Pega How-to Guide is born! It sets out to achieve the
above by applying the following:
2) A quick implementation using the typical “Hello World” style, demonstrating the feature in the simplest form
3) Expansion of the example using various scenario and extension of the feature to cover related areas
In order to provide a quick explanation and
make understanding of Pega concepts a breeze, at times, I might “state” that a
given Pega feature is equivalent to something that is more commonly understood,
followed by a series of scenario that further extend its capabilities and
enable users to slowly appreciate the differences.
For example, I might start by stating: “Think
of Pega Data classes as Database tables…”, and then proceeded with some
scenario on how to use Pega Data Classes to add, update and delete records,
followed by other interesting features, that would extend it capability and
moved beyond just database tables.
So, take note of this unique approach in the
guide.
No comments:
Post a Comment