Process versus Service.... Fiiiiiiight!!!!

I read this comment recently in a BPM forum: "Learn the language of the senior management and find that they do not talk 'processes', they talk functions".

This comment made me wonder, is there a process versus service divide between senior management within enterprise firms and those delivering the service?

If so, who is 'right' here? From my experience, 'do-ers', front-line staff and subject matter experts do indeed tend to work in a 'process-centric'/'process-oriented' manner (since that’s the world that they occupy), whereas senior management, as the comment above seems to suggest, seem more focused on the ultimate function or service.

I may well be wrong here, but ultimately I feel the trouble is the relationship between processes and the ultimate service offering is typically many to one (many process components fulfil one service offering) – those at the top of the food chain don’t have the bandwidth to focus holistically on granulation – merely the ultimate service offering that they champion.

My thoughts are, when service offerings ultimately fail the customer, they do so because the underlying processes that drive the service are too clunky and possibly not even ‘concrete’, static, accessible, fit-for-purpose and maybe even transient in nature (i.e. there may well be a rough set of processes; but then there’s that bit that Joe Bloggs does, and then the enrichment that Jane Doe normally does every Tuesday that has an even number date, and after that we need to get Department X to add their 5 cents worth).

Without having visibility and control over a complete end-to-end process topography, understanding the full service-machine can be a headache. And if one component fails; the result can be nasty.

Something I think BPM technology does quite well (and obviously PRPC is my main reference point), is allow an agile platform through which senior management can command service improvement (as is their desire), which is ultimately achieved by using business experts to bring processes directly in to the servicing backbone (rather than have such processes reside solely in their minds), and so enforce a kind of harmonious process conformity – after all, as a customer myself, something I find more infuriating than just general poor service is inconsistent service; the end result of capricious processes.

In the BPM world, something I would like to see gain momentum is the recognition of processes as components of service – so improving service can then become about replacing, adding or inter-changing process components rather than having service commandments dictated to the lower-echelons, with then middle management and the business experts having to rely on a ‘rabbit-out-of-hat’ approach to getting the customer serviced to the letter of the overarching service promise.

With the opportunity of bringing the time-to-market ratio for end-to-end solutions down to sub 90-days, and then near immediate (agile) change being possible through business-led customization & configuration, perhaps 2010 is the year we will start to see granular process improvement really driving customer success?

What do you think?

Fail to plan; plan to Fail

What we have here is one of my favourite business adages; perhaps of all time.

I don’t know why I love it so… is it the alliteration, the symmetry, or the fact that I can actually remember it? I’m not sure.

One thing I do know is that it has only recently resonated with me…

I had this axiom proclaimed to me a long while ago by a great Business Analyst… perhaps the greatest Business Analyst I’ve ever met. I nodded along in feigned agreement when he said it… at the time it went through one ear and out the other and got stored away in my ‘sayings to use when patronising a Project Manager’ box.

Why, all of a sudden, has this 6 word sentence become my mantra? Well, I shall tell you.

Dishes.

Yes; Dishes. You see, despite my insatiable tech-lust, my household doesn’t have a dishwasher. There is room for one, however, all available funds are presently being diverted to the ‘new bathroom’ and ‘new windows’ projects.

It is therefore my responsibility, nay my *duty* to undertake the washing up of the dinner plates, cutlery, pots, pans, cups, and goodness knows what else in the evenings when I am home.



When I enter the kitchen, and see piled high practically the entire contents of every cupboard sullied and grimy sat menacing and taunting by the kitchen sink, it is fair to say a part of me feels it may be prudent at that time to close the kitchen door, and run… run like I have never run before… and not to stop until my legs are overrun with lactic acid, my lungs stop functioning, my heart-rate is unregisterable and I have sweat 90% of my available hydration (yah… that would be about half-way down the road then…)

However, as a man born of process optimisation, and armed with the proverb “Fail to plan; plan to fail”, I have come to realise, that when something seems insurmountable… take a step back, assess, plan and execute.

I rinse everything off first, which get’s rid of 80% of the grunge anyway (and stops the water getting really dirty), and then organise everything in to appropriate sections (which makes the whole task seem more manageable since everything is compartmentalised and structured).

I then wash up… put everything neatly on the drainer and marvel at my accomplishment for about half an hour.

Ok, so the fact that the next morning Jodie tells me that she had to re-do 2/3rds of my washing up because half of it is still dirty we can overlook I think… but you get the picture! Plus; it most perfectly and literally demonstrates the truism “Rinse:Repeat”.

This whole concept is wholly transferable… in fact, I take exactly the same approach when I change my son (obviously I refer to the “planning before execution” and "outsourcing to Jodie" parts… not rinsing, washing and leaving him on the drainer… that would surely get me in to far more trouble than the quality of my washing up).

So, in conclusion, adequate and appropriate planning can lessen the daunting prospect of holistic delivery by offering the opportunity to step back, assess, resource and deliver against strategic milestones.

Furthermore and most important, I think this clearly demonstrates that all problems can be addressed and resolved with the introduction of technology solutions; in this case, a dishwasher. (If you’re a bit gullible… you may wish to take that last part with a pinch of salt. Dishwasher salt is fine, sea salt would be better).

Advise and Consult

Yesterday as a citizen of the Commonwealth of Massachusetts I got to participate in Jury Duty. It gave me a lot of time to think.

So I was thinking how our role as jurors, even folks showing up for Jury Duty itself, is not unlike our jobs as consultants. "How?" you ask. Excellent question.

We have a system which is "adversarial." We have inherited, and continued to grow a system that assumes the best way to pursue, determine, and carry out justice is to allow opposing sides to advocate within the law, to represent their case, to raise questions, doubts, bring evidence, and attempt to persuade a neutral party of their position. Through conflict, we expect the truth to manifest, to be found. In fact, the judge who opened the video we were shown told us that our job was to "find the truth."

When implementing business solutions, it is seldom enough to listen to one Subject Matter Expert (SME). It is generally not sufficient to get one person's idea of what success is for the project or for the business. We need to bring a variety of perspectives together and see in the light of sameness and differences what the scope of the engagement and the criteria for success are. As consultants we should seek out ideas different from our own and learn from them, use them to "find the truth."

Depending on the type of case, criminal or civil, you have a different standard to achieve in order to win your case. For matters of criminal law, guilt must be determined "beyond a reasonable doubt." For civil matters, the court will find for them based on a "preponderance of evidence."

Think about this. When it comes to determining someone's freedom, their ability to participate freely in all the rights they have as US citizens, our standard is very high. "Beyond a reasonable doubt" means that guilt is determined past 99%. It's not just "likely" the defendant did "it," but it is unreasonable to assume anyone else did and it is unreasonable to assume he didn't "do it."

How many projects implementing software as parts of business solutions need this standard when making decisions? How many projects could reasonably allocate the time, resources, cost to sustain such a standard?

When it comes to civil cases, our standard is a lower. The court will find for one party or the other in a civil case based on a determination that it is "likely" that either the plaintiff is correct, or it is "likely" that the defendant is correct. We're looking for "good enough" or "sure enough."

Is this not a model by which most of us live and work through our projects? Is this not sustained in every aspect of Agile projects? We build something likely to fulfill the requirements and which is likely to be flexible enough to be augmented, changed, or added to in subsequent slivers or phases.

In Massachusetts, the jury determines the "truth" by making two vital decisions:

1. What are the facts of the case? Literally what of the evidence, testimony, etc. presented are factual.


2. What is the verdict? Guilty or Not Guilty vs. Verdict for the Plaintiff or Verdict for the Defendant

What happens in the courtroom is that the judge runs the trial, wrangles the attorneys, and instructs the jury as to what law should be applied in the case. In Massachusetts, once the jury renders the verdict it is the judge who imposes sentencing.

Now I know that when I work with a client I like to feel useful, and part of that is really feeling utilized. I like to share my experience, my expertise, participate alongside the client, really dig in. Also, I'm a fan of control. Generally I feel like I have something to lend in terms of the structure and process through which we will work and by which our results will be judged.

What I have found, and increasingly find, is that it's impossible to "control" a client. They may be persuaded by you, but they will not be "run" by you. Even if you think you know better how to do something, or what should be done, you're going to have to let this go or really create conflict. This is exactly the opposite of "helping" our client "do it better."

We must remember that no matter how many engagement we have worked, even with the same software in an identical application, in the same exact industry (and there are NONE of these repetitions in my experience, something is ALWAYS unique)...

• We cannot be the arbiters of success for a client. They have internal bodies, mechanisms for this.


• We are not more expert than they on their business environment, drivers, politics, or processes.


• We cannot mandate cooperation, collaboration, or a change in tactic to people who do not report on us and are not incented by us when we do not govern their position descriptions, performance evaluations, bonuses, benefits, etc.

So, when it comes to determining the success factors for a project, we cannot play the role of judge. That's for our client to do. We can influence, but we cannot mandate. They determine the laws that apply. See?

It is imperative that we treat our client with the respect, the deference that they deserve. We should recognize their expertise even as we are proud of and wanting to share our own.

How does one influence a judge? Well, present a good case. Base your case on facts, on evidence. Carefully structure it so that the holes are plugged and the leaks are filled. If any remain, acknowledge them honestly and offer your best advice as to what to do about them. Don't create mayhem, chaos, distraction. You have some options, and generally speaking, committing contempt of court -- winding up in jail, paying a fine, or both -- isn't the best one.

Don't let this become you. Don't turn the project into a circus just to get attention. Though it might feel like you're on the winning side, it's bound to be held against you later on.

The thing is too, that as much as I find myself as a consultant craving a spotlight, craving the action, it gets hot in that spotlight and it's tiring after a while being the guy always leading the charge, making every objection, cross-examining every witness, and there's always a losing side.

No one wants to be on the losing side of anything, especially not your client. Do you think that gladiatorial combat with your fellow vendors will pay off well in the long run at this site? How about the next site where tales of carnage and chaos are carried from the battlefield into the new engagement.

Hm. So maybe taking such an adversarial tact might be ill-advised. Now what?


Well, you can certainly be a witness, even an expert witness. Present your research and credentials in a way that substantiates our expert opinion. Cool. That can work.

Offer a pilot, a paper, a proof of concept. Offer a model from another engagement as evidence that your recommendations were successful elsewhere.

Use the tools of your trade. As a consultant, advise, consult, persuade, enable, and empower the client. Help them make decisions. At least provide the best possible information and your suggestion, your opinion.



The key here is to persuade and enable. Remember that when it comes to being expert, your client is the ultimate judge. So engage them. Educate, enable, empower them. HELP them do it great. Make them your expert witness. Let them make the case.





So what's this about juries? Well, as a juror, you can determine the facts of the case and you can render a verdict.

Determine the facts. These are the critical factors for success. Find them and then set them out as guardrails for your strategy and tactics. In consulting, that can be about negotiating, learning your client, educating yourself on the information available. Do your research. See what makes the most sense to you.

Render your verdict. As a consultant, you can offer a project plan, a strategy, an application architecture. Offer a guide based on careful deliberation of both the law (the criteria for success) and the facts (the requirements and other criteria for the business solution). Build the application as best you know how according to the requirements, the critical factors for success.

Then step back. Remember you may not always agree with the client, but this is their project. It is they who are responsible for it in the end, and we want to help them, no matter what the course they choose. Don't make it personal. Render your services and let the client be the judge.

Advise and Consult. Be an advocate for your client, but not an adversary. Let go the thrill of combat, of being a hero, and instead figure out how to let your client do what they must in order to achieve success. That's not always following behind you as you cut through the jungle with a machete.

As I also learned from Jury Duty yesterday, sometimes it's enough just to show up. Yesterday I wasn't selected for a jury, but neither were any of my peers who showed up. Yesterday, for justice to be done, for the eleven cases that were going forward to trial or reach an agreement, all we had to do is be willing to do our jobs. The presence of people willing and able to participate in trials allowed the parties in each case to decide whether to go forward or settle. Everyone settled, and that was justice as it was performed yesterday.

Sometimes, the hardest, and best job we can do is just show up. Allow our presence to facilitate our client's goals, to "Help them do it great."

References: "About My Juror Summons" http://www.mass.gov./courts/jury/aboutmy.htm

John Adams, President of the United States, framer of the US Constitution and one of the authors of the Massachusetts Constitution, http://en.wikipedia.org/wiki/John_Adams

"Thoughts on Government", by John Adams, spring 1776, http://en.wikepedia.org/wiki/Thoughts_on_Government

Massachusetts Constitution, drafted by John Adams, Samuel Adams, and James Bowdoin between September 1 and October 30, 1779, ratified on June 5, 1770, effective as of October 25, 1770, and the oldest functioning written constitution in continuous effect in the world. http://en.wikepedia.org/wiki/Massachusetts_Constitution

We Help YOU to do it GREAT!

I guess that our official brand message is already well known to all of you Knowledge Warriors. As you might imagine, this message is not a simple advertisement (actually is not an advertisement ) made by some creative folks from a marketing company. This in fact is the result of sophisticated analytical review of our company profile which identifies it's personality, it's strengths, but most importantly what has to be done to align our approach to our customers.

Well I don't know if the brand message had the same effect on you, but when I heard it, it really impressed me. I knew I had previously heard it in a context related with our everyday work but I wasn't sure where. Once back to my room I started to think about it again..."Help you to do it great ... that sounds to me like give a good service ... Yes, that it is the word I was looking for :SERVICE! A company with SERVICE CULTURE" I thought. Rapidly I started to search through the books I recently read and I found it! The name of the book is Service Oriented Enterprises (Setrag Khoshafian - Auerbach Publications) and the related paragraph is the following:

"Serving is praised as a virtue, yet it seems much more difficult to realize it in practice. Inspiration and goose bumps well up when stories are told of unselfish sacrifice and service for noble causes:in social service, in politics, in religion and - why not - even in the military. However, there is a flip side. Our culture sometimes places the wrong emphasis when it rewards greed, aggrandized egos, and cut-throat approaches in climbing the corporate ladder. In a flattered world, we cannot afford to reward selfish ambitions. The service culture sees the success of the customer, shareholder, employee, and partner as essential requirement to fulfillment. It is service oriented. In a service oriented enterprise, greed is not good. Success is a side effect, not the focus. Success is not just about finances; it is about how well others are served and elevated. A service oriented culture means our main function and purpose is found in serving others: helping them achieve their potential"

It might seem like a coincidence but honestly I don't think so. This to me is the demostration that we are on the right path; the gratefull feelling that I am working for a company with a vision and that this vision is in line with the vanguard in our field.

Atomic Use Cases - Fission or Fusion

With the advent of Pega's DCO features has come the rise of the term "atomic use case.” As with so many terms which become popularized "atomic use case" means many things to many people.

The question is: What does it mean to you?

Well, for starters, it means you've got to formulate your opinion of what the term means or you're going to be powerless to participate in any DCO-enabled projects. You CAN sit there and nod sagely without a clue. You can make up your own meaning. You can do some research on the internet on these and other UML terms. These are but some of your choices, but so far none of them puts you in the position of participating in a valuable capacity on your client project.

Let's start with "use case.”

Lots and lots of folks have talked about use cases forever. Interestingly, it turns out that this terminology is as old as Pega. It goes back to Ivar Jacobson's work in UML back in 1986. http://en.wikipedia.org/wiki/Use_case

In 1986 Pega was architected using the bold choice of PL/1 in VMS and MVS/CICS environments at that moment in time. The PegaSYSTEM was hardly object-oriented at that moment. In point of fact, as the Wikipedia article points out, use cases themselves aren't necessarily object-oriented although they've originated in the object-oriented community. They are, in fact, by definition procedural because they describe a process in time order.

Use cases detail a sequence of events or actions initiated by an actor in order to achieve a goal. Yes, it can be one or more actors, so long as they are set on achieving the same goal. For example, someone in a retail store could help a customer fill out an online application for a store credit card. Via the web, that same customer could do the same thing themselves. The goal is to complete the application and send it off for processing/approval. So in this case we have two actors who will use the system to achieve the same goal – the same usage.

In our world, actors can be people or other systems. For example, in a SmartPAYMENTS setting, it could be a Swift, CHIPS (the kind without Ponch and Jon), or FEDWire message that kicks off the creation of a new case.

A use case is going to capture a sequence of actions or events then. You can see how this would be a good way to capture requirements around various system features and functions. You learn who does what and in what order. You should uncover the decisions they make as they go. This process will start to get you into the DNA of the system and the business functions it must enable.

Done properly you will capture a lot of the requirements, at least the functional ones. Note: You will need something else to help catalogue your non-functional requirements – things such as, "The system must be available 24 hours per day, 7 days a week, 365 days a year."

So why atomic use cases?

Well, frankly use cases come in all shapes and sizes and lengths. It's easy to get lost in all the information you've gathered, and it's even harder to know what you don't know yet.

If a use case can have an unlimited number of steps, then it can be as hard to break down, analyze, design, and build, as any other form of requirements-based documentation.

If a use case can be at any level of detail, the overall project sizing, design, and build can be compromised. In some cases you'll have every little mouse click. In others you'll be missing entire screens and critical interfaces. How do you size and manage that reliably? How do you know you've accounted for what you don't know? How do you cope with resourcing? One developer per use case? Two?

The industry has started to popularize the term "atomic use case" of late, as people recognize that the devil is indeed in the details.

Breaking use cased down into their smallest size also enables us to break them into their most reusable, most common elements. From there sizing, planning, designing, and building become much more predictable. With predictability comes reliability and common practices for risk mitigation, communication, etc.

So atomic refers to sizing. Is that it for Pega and DCO?

Pega doesn't require only "size" to define or limit a use case. There are other criteria which drive the definition or identification of an atomic use case.

An atomic use case:

• Specifies one or more actors
• Specifies a single event or method that triggers it
• Does not involve a change of ownership during processing
• Corresponds to one particular step or series of steps within a screen flow or a single flow action in the processing of a work type
• Describes the processes to be performed including the steps involved in completing the use case, applicable edits, and the expected behaviors and outcomes
• Provides enough business detail so that a developer can implement it
• Should only take a few minutes to enter into the PRPC Application Profiler

Think again about reusability, about tracking, reporting on your design and build progress in a project. You have people who need to track how much is built to support the stated requirements, as well as how much is tested and ready for promotion to production. And then there are milestones and invoicing as that project progresses.... You literally need to know what requirements are "built out" and "testable" and "delivered" and which are not.

Pega's DCO features enable you to create, edit, and maintain (yes even delete, but careful as always with this) atomic use cases. The intention is to connect them to the actual rules in the application that manifest and enable them.

Atomic use cases are referenced by:

• Flow Rules
• Activities
• Local Actions and Flow Actions
• "New" Harnesses

As such, it does you little good if you have one gigantic use case referenced to every single "New" Harness and Activity and Flow Rule you've created for the 250+ features you're building. What you must do is limit the size and scope of the use case so that you truly know whether it's been built, and whether it can be tested, and whether it's ready for delivery/promotion to Production.

So, it's fission? How do I know when I'm there?

You need to know the scope of your engagement. Whether you're working on an Agile or waterfall project, scope is critical. From there, you need to work the business process flows out at a high enough level that you can identify connections, commonalities, and at least some of the actors.

If you're working within a solution framework, then a lot of the groundwork is already done for you. Generate the use case catalogue for your framework. Generate the list of actors, etc. already accounted for by the framework. Work with your client to identify the differences. Identify what's not accounted for, what must be built custom to support the client. Zero in on these areas.

Your client can also help you cross use cases and actors off the list, where the framework is not applicable to the current project. Don't delete them. Just set those aside for now. Keep moving.

Whether you're working with a framework or a custom solution, start mapping out the business processes (diagrams of any kind, especially vanilla flowcharts can be of use here). Work with your SMEs to drill into enough detail that you can tell the difference between a large, complex process, and a smaller, more straight-forward one.

As the detail emerges, start applying the guidelines Pega has given for atomic use cases. For example, make sure your work object doesn't transfer to a new party or system for further processing. If it does, your use case stops and a new one starts. If your process requires that you make multiple interface calls to gather data, then each one of those calls should be its own use case.

Be sure and think about your functional design tools here, including flowcharts and other pictorial representations of processes. http://www.knowledgerules.com/blogs/life/2009/08/functional-design-picture-is-worth-1k_757.html It may be easier to identify use cases by reviewing diagrams and marking boundaries between handoffs. It’s easier to keep consistent with sizing in this fashion too.

Make sure to engage your LSA in this process. He or she will be able to apply not only a keen business eye but a keen technical eye to the use cases you're discovering. Your LSA may be able to find further places to break business use cases into smaller pieces.

Educate your client at all levels of the project as to why you need to get to this level of detail, and the risks you run where this level cannot be obtained. On tight deadlines, lack of detail in the requirements compounds the work for design, build, and test. Lack of detail also adds risk to each stage of the project, where risk can manifest as additional time, money, and resources.

You will experience a time period where more and more use cases are identified. That's ok. Keep listing them. Prioritize. Not all have to be fleshed out immediately and you'll even find some may be outside the scope of the current project (especially if you're working with slivers). Set those aside, keep moving on the critical path.

It's also fusion.

Be especially sensitive to things that are common. It could be that a customer accesses a system over and over again, picking up one data element and then another during data gathering. It could be that because the access is really the same, but the property you're picking up is different that you're really in the same use case. All that needs happen is to parameterize the call.

Work with your LSA especially to be sure that you don't unnecessarily fragment your use cases, where you have several that are all alike except for one thing.

Also, be sure that once your atomic use cases are all identified that you can build back up from them to the business process you're enabling. If you can't, something is missing. Find it. Address it.

Again working from process maps, not just heavy text documents should help you perform this "reverse check.”

Is that all?

Identify your atomic use cases by name and get them as fleshed out as possible so you can move on to the next steps. With DCO and the Application Profiler, you can identify your use cases as you find them – just name them. You can then associate your steps, requirements, actors, and complexity. When the profile is generated, DCO will yield a sizing with which you can work to tune the rest of the stages of your implementation.

That's not the only time you can create or add atomic use cases, though. Once the application ruleset has been created and people are working away, you can always come back and add new use cases directly into PRPC and associate them to the rules which bring them to life.

Doing this improves traceability not only for requirements but at a project management level. You can continually generate your DCO documents to show the build against the requirements and design. This is an extremely useful tool in your arsenal when managing scope and relationship dynamics. A simple mouse click can enable you to list the use cases and the application rules necessitated by them. Whether in spreadsheet form or Word Document, this can be very insightful, and a great tool to communicate progress, risk, and start the conversations to close any gaps.

Atomic use cases are the building blocks in this puzzle, no doubt. The consulting skills it takes to identify, analyze, and catalogue them are the critical tools you need to create them and a solid foundation for your project.

Functional Design - A Picture IS Worth 1K Words

“It’s the requirements, Stupid.” Let’s face it. Projects get obsessed, enmeshed, mired, off-track, and so many other things so early on....

Using Agile or Waterfall approaches, everyone’s trying to get to the end faster, and with hopefully better results. The thing is that many folks arrive at a deadline and then discover that they had differing opinions on what was supposed to be delivered and whether something is complete, or how complete it is. The billing disputes arise even as testing kicks off, solidifying and entrenching these expectation differences, threatening the success of the phase, the project, and the relationships.

Often all sides go back to the “requirements” documents and “design” documents to compare against what’s been delivered. The purpose:

• What’s in scope and what’s out of scope – hey, what’s “scope” go to do with it anyway?
• What’s a change request – do we have change requests? Where are those little buggers?
• What’s a bug and what’s an enhancement – does this even matter?
• What’s a missed requirement – can I say it’s your fault?
• Determine whether the expectations as documented have been met or could be construed to have been met – time to bring in your most conservative BSAs and Developers to “interpret” the constitution...I mean the requirements and design docs
• If there’s time to fix any of this mess...and keep the relationships on track and stable

In many projects these documents are vague, out of date, misunderstood, and more. Most were never read, though they had many contributors and lots of meetings around them. They were created as a necessary step in the process and signed off.

They are created as necessary evils, artifacts, out of date as soon as they’re published, and inaccurate and incomplete from the start.

No wonder there were many and varied disconnects between expectations and generations of Word documents generated on the way to build and thereafter. The documents stayed static. The code was dynamic. There were demos, emails, meetings, phone calls, and hallway conversations that all impacted what was built and why, and all while those requirement documents collected digital rust.

Everyone’s busy inventing new formats for words as if it's the formatting that's going to make the requirements gathering effort yield better results. There are use cases, atomic use cases, RTMs, Business Requirement Documents, and a whole smorgasbord of document templates begging to be filled out.

What we’re missing is pictures, good old-fashioned diagrams. For every process, for every flow or subflow, you have a set of tasks to accomplish and an order in which they must occur. You have to identify the timing, the delays, the sequences, things that happen in parallel, the dependencies, and so on.

The more people stare at words, the more they write words, the more words there are. People fret about wording decisions and conditions in the negative or the positive, and so on.
Note also that document writing is generally “best” a solitary endeavor. It doesn’t lend itself easily (or efficiently) to collaboration. Sure, you can all gather around your internet meeting site and watch someone type while people shout, go for coffee, text one another, etc. Collaboration, inspiration, creativity, team-building and more aren’t fostered typically during that typically fragmenting and boring process.

What can foster creativity, participation, interpretation, and a fresh look is drawing pictures – mapping the process.

It’s so much easier to share the marker on the whiteboard or the pen on the tablet PC than to turn over the “driving” (I mean typing) to someone in a Word document complete with formatting, auto-generated section numbers, and more. ;-)

What you can’t see for all the words is what’s not there, and whether things are really in the right order.

You can’t tell how one document connects to the other, if there are common processes, common attributes amongst objects, if you’ve got all the actors accounted for, and so on.

What you need are pictures, diagrams to describe your business process, the BUSINESS FUNCTION.

The diagram below is from one of our favorite customer projects. It depicts about 50% of the actions that must occur before rendering the next screen (literally decisions and data that must be gathered between 2 screens).

Translating a lengthy text description of a process into a drawing forces you into an order. One box goes first, another goes second, and so on. Inevitably you are forced to connect things (using arrows generally) as you describe the process beginning to end. As you read a paragraph, page, or set of bullets, it finally dawns on you: You have no idea in what order these things must occur given the description. You aren’t even sure what happens AFTER these things take place, or before. In fact, you can find entire missing paths by discovering that you know what happens when a decision is true, but not what happens if it’s false. Voila! Flaws in the documentation are revealed quickly, effectively in ways that a 28^th (don’t laugh they do happen) revision of the Word document never would.

Note also that it’s far easier to recognize patterns in images than in words. You start to recognize common processes, actions, when you realize you’re drawing them again. Remember with words people can vary them enough in specific word choice and order so as to disguise repetition of various things. Pattern recognition gives you the chance to lift up and get multiple common items visited together, corralled for detail and design.

Pictures can reach people that words don’t.

Here’s something else to consider: not everyone’s primary or best method of communication is verbal or written. A third or less of your clients and TEAM MEMBERS are reached better by a different communication method.

The lesson: PICTURES and WORDS will reach a far broader audience, and they will illustrate the process far more effectively and efficiently if used together. It’s really easy to communicate questions, issues, etc. when you can literally SHOW it to someone without making them READ and PARSE dense text.

With a flowchart, you can point to something and ask, “What happens here?”

Pega and DCO make a stab at this, but note that these days you have to break large processes down into “atomic use cases” before you can get them into the system. You have to get your application defined inclusive of the atomic use cases (using the Application Profiler) BEFORE you can build a single flow rule. That means you’ve already identified all your processes, all the steps, and all the common processes, etc. before you’ve generated a single application rule.

To get your use cases broken out at any level, let alone the atomic level, you’ve got to define the process. It’s right there that diagrams, flowcharts, process maps can really ease communication and cut right to the heart of the matter.

Functional design makes it possible for the business to look at a chart (or a series) and say “Yes, that’s what we want the system to DO,” and sign off. Requirements documents, textual descriptions, can capture the details, and also the “non-functional” requirements. Wireframes, and other tools can describe the look and feel of the desired user experience.

Note also that it’s really easy to show scope creep in a diagram. You can literally say, “This process was 1 page when we diagrammed it and it was signed off. Now it’s 3 pages, and the steps are in a totally different order than built.” Ah. How many pages of a MS Word document, and the various email threads, and non-existent meeting notes would one have to read to identify the scope of the changes and the ramifications for a Senior Manager with 15 minutes to consider your change request?

From functional design and requirements documents the technical design can flow. The technical design will design the code solution, how the system will function technically. It should not be confused for the functional design – defined in business terms and steps.

Get the right design in front of the right audience.

Just as business users should not be required to evaluate technical design – to say “Yes, this should be custom Java”, technical consultants should not have to parse a myriad of dense documents to SEE what the business processes are that must be enabled, to see what the system should “do” when it’s completed. Functional design should let your LSA and technical consultants digest quickly what a process does and literally SEE whether various components are reusable, common, already existing in the framework, and so on.

The next time you’re bogged down in a meeting about requirements, think about whether you should be working together, collaboratively, over an image of the process and then break that out for detailed description and design, instead of debating endlessly whether section 5.4.3.2.1 is correct as stated.

As they say, a picture is indeed worth a thousand words.

Coming soon will be a follow-up article discussing how to incorporate these tools into an iterative project. Stay tuned.

This is just a varning!!

As developers, we always strive for efficiency and the hope of doing our work the best possible way. Sometimes this mentality drives us into solid walls. But being the smart people that we are, we create our own holes in the wall, break the obstacles, and allow ourselves to see the big picture.

One such example of efficiency revolves around PRPC activities and variables. There are three common ways we can store some data in memory. We can either use properties, parameters, or local variables. Properties are great in that they are static, and can be referenced basically from anywhere (assuming we know the correct clipboard page). Their downfall is that, as intended, they are static. Any temporary property that is created will always remain in the ruleset used.

The other two variables are dynamic, created as necessary, and reside only during the processing of the running activity. There are, however, distinct differences between the two. Local variables can only be used within a single activity. Parameters are more flexible and they can be passed from one activity (or flow) to another. This added flexibility adds to a higher overhead memory allocation, and make them not as efficient for quick processing. Likewise, when a process does not require the sharing of memory space, there is no reason to use a parameter over a local variable.

For troubleshooting, however, there is a bigger problem. Parameters can easily be viewable in the Tracer, where as local variables cannot.

There is a solution for this!

Since PRPC 5.3, Pega has introduced the Log-Message method. This method allows the activity to log any type of a message into the physical log file, or if necessary, to the tracer. In our activities, we can use this method to log anything we need (including local variables), depending on our logging level. More importantly, for real time tracing, we can have those same messages be displayed in the tracer for us.

Below is a screenshot of a tracer run which shows such tracer messages with local variable values.

For the tracer options, the only thing we need to do is enable the "Log Messages" option in the Events to Trace section.

Now.... just because we are using a more efficient variable, that does not mean that should start logging it every chance we get. It would probably make more sense to have the Log-Message step conditionalized, so that it runs only when needed (lets say we're running our application in Debug mode).

Of course, all of this is really irrelevant information, since we all know that our code is perfect :)