Post from the tarmac

The life of a knowledge warrior can be a trial. Writing from a stranded, poorly air-conditioned plane in the dead of a Philly heat-wave brings this point into focus. An appropriate question to ask at this point might be why do I do this? My answer for your consideration is this: to be in the game.

What is the game? I can't tell you precisely, but know it when I see it. The game happens out in the world, most often, in conference rooms and airport bars. Sometimes the walls are oak paneled, but usually they are whitewashed cinderblock or smudged cube fabric. It is played near our clients. It arises from meeting other players and looking them in the eye; a simultaneous testing and test taking. It looks like a challenge. It revolves around relationships. It is something you might tell your grandkids about someday.

Good news from the flight deck, we are #10 for take-off. With only 2 hours on the tarmac, I should be home by 1 am. Before I shutdown, I will leave you with this: home is comfortable, predictable, safe. I love my home. A safe haven is important and time to enjoy peace critical, but in the end the game is out HERE not in my living-room. I crave challenge, I always have. I need to be in the game to create that challenge, to deliver that validation. I am good on a good day, but how good am I with 4 hours sleep wearing a shirt sweat-stained from an early morning run to a closing gate? The game answers the question and challenges me further.

 

Maybe this sounds macho or perhaps a tad delusional—I am hot and tired, so I may regret the phrasing. Still, I know that I am not alone in my aspirations (or in my mild suffering). If you are reading this in comfort then shrug and tuck this away for later. If you are in the game or waiting for your match, take heart; what you do matters. And discomfort stretches you, makes you a better player. The road is sometimes exciting, but mostly uncomfortable. Still, they call it 'the road' so it must lead somewhere, right?

The difference between escalation and buck passing is…

…diligence. As a issue rises through an organization, the costs of handling the problem rise with it.

Diligence is the key to making escalation work for you and the organization. What does it mean? It means that before you pass off the problem, do your homework. Collect information, analyze it to the best of your ability, and try to summarize clearly and concisely the main parameters of the problem. When you forward the email, attach relevant log files and screenshots (watch out for Reply To All which strips-out the files). Each person who handles a problem should add clarity—a foundation for those who follow to build from. Even if you cannot solve the problem, you will be contributing to the solution and reducing the overall cost of solving the problem.

To escalate well, you must focus your request. Not only are the costs to the organization large when a number of people are CCed on a request, it also means that each receiver can assume that someone else will deal with the issue. For best results, try to determine who the most appropriate single party is to take the next steps, contact them directly, confirm their availability, and then forward the research. Allow them to follow the escalation path forward if necessary. Establish ownership and make a point of staying involved.

Buck passing, on the other hand, is more like the hot potato approach; passing a problem along as quickly as possible, to as many people as possible, in the hopes that someone else will catch it. Consider, for example, the simple act of CC'ing 5 people on a short email. Each incident costs the company $14.50 in billable revenue. If each staff member sent one such email per day, the company would lose $730 in billable revenue for the day; a staggering $182,291 in lost revenue per year. The approach costs the organization and damages your reputation. This behavior is noticed.

In our jobs, problems are a daily occurrence; they must get resolved in a timely manner. Do not try to reduce the organizations costs by spinning your wheels. You are expected to escalate problems that are beyond your capabilities, but you are also expected to be diligent and follow good escalation hygiene.

Pattern Finding and Following

Patterns guide all human action. We have instincts that call for repetition of behaviors that have proven successful (or at least not lethal) in the past. We walk in the literal and figurative footsteps of those that have come before us. In application design and development we should exploit these instincts to create unity in form where the form is initially set through thoughtful intent.

Cornerstone patterns are macro-patterns that define the majority of the application's internal structure and guide the application of more granular patterns in the fulfillment of the intended features. For within each level of a pattern are embedded sub-patterns mirroring the symmetry of nature.

As a designer, your job is to define the cornerstone patterns that suit the constraints of a project. Project constraints are formed by functional needs, architectural mandates, team skills, project economics, and the like. A designer may also identify sub-patterns that should govern the approach solving smaller problems within the project.

As a developer, your job is to understand and enact the patterns identified as cornerstones of the project, to recognize and repeat the sub-patterns established by fellow developers, to contribute to a collective pattern-spinning. The use of the right patterns is critical to producing an application which is maintainable and a creative process which is efficient.

Programming to Interfaces not Implementations

What is an implementation?

An implementation is a specific approach to fulfilling the desired operations on a given page.

What is an interface?

An interface is an abstraction of specific operations into higher-level meta-operations; abstractions provide activities and properties that are common not only to a specific page format but to a whole set of similar pages.

How does PRPC make interfaces possible?

1. Polymorphism




Abstract class definitions can have activities defined without steps but with parameters defined. These activities are the interface.


A subclass can have the same activity defined but with specific steps that actually do something. These activities are the implementations.


An application that uses the class can define a property as being one of the abstract parent class and use Call method to invoke one of the interface activities on the property.


The Page-Change-Class or Page-New can be used to create a page structure that reflects a specific subclass of the defined abstract parent class.


At run-time, the specific version of the Activity in the subclass is fired even though the validation occurred against the abstract version.




2. RuleSet Prerequisites and Run-time RuleSet Lists




PRPC allows the creation of two different RuleSets that can contain identical activity definitions.


One is created as xxxBase has activities with empty steps. This RuleSet forms the Interface.


Another is created as xxxImpl has the same activities with actual steps defined. This RuleSet forms the Implementation.


The RuleSet version of the calling application is has the xxxBase RuleSet added to its prerequisites.


Activities are called from within the application and validate against the versions in the xxxBase RuleSet.


The xxxImpl RuleSet is placed above the xxxBase RuleSet in the Application records list of associated RuleSets.


At run-time, the specific version of the Activity in the xxxImpl RuleSet is fired even though the validation occurred against the abstract version from the xxxBase version.

KROME modules make heavy use of the latter approach to allow the possibility of changing system behavior through deployment action and security tweaks rather than through programming.

OOP in BPM

BPM is still something of an exotic animal compared to most other IT tools. BPM tools represent a blend of features inherent in 4^th generation programming languages with some tools such as Pega's PRPC adding a strong flavor of 5^th generation facilities. In the rush to distance such tools from the practices employed by developers of 3^rd generation (Java, C#, C++ etc.) object oriented applications, BPM developers have so far failed to emphasize those computational best-practices that still apply to application development using these new tools. The promise of these higher-level generations is to remove the programmer from the development chain; perhaps this promise precludes those mental models that require professional mentality to understand and exploit. Whatever the case, we Knowledge Warriors are clearly members of the professional caste of BPM practitioners and, as such, will need to balance best-practices in computation with business savvy.

Object Oriented Programming techniques as a computational best-practice are very much germane to our development of BPM-enabled applications. By extension, OO Design Patterns should also be part of our toolbox. For a good, basic intro to OO Design Patterns that a quasi-geek can understand, check-out the book "Head First Design Patterns" published by OReilly. For a nerdier treatise, check-out the, now classic, "Gang of Four": Design Patterns: Elements of Reusable Object-Oriented Software.

I will try to give you a brief review of this thinking and draw parallels to PRPC development over the course of the next month. Here are the major OO Design principles to be aware of with links to some detailed articles on what each one means.

The first five principles are principles of class design. For the most part these OO Classes translate into PRPC Classes. The principles are:

SRP	The Single Responsibility Principle	A class should have one, and only one, reason to change.
OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.
ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.

The next six principles are about packages. In our context a package is a unit of deployment rather than of programming: usually this means a RuleSet but might also be an Application or Product collection.

The first three package principles are about package cohesion, they tell us what to put inside packages:

REP	The Release Reuse Equivalency Principle	The granule of reuse is the granule of release.
CCP	The Common Closure Principle	Classes that change together are packaged together.
CRP	The Common Reuse Principle	Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

ADP	The Acyclic Dependencies Principle	The dependency graph of packages must have no cycles.
SDP	The Stable Dependencies Principle	Depend in the direction of stability.
SAP	The Stable Abstractions Principle	Abstractness increases with stability.