Blog Archive

Home
Business Processes

ski_and_snowboard_snowsport1Enterprise level software can provide marvelous benefits with process automation; yet, how many tales can you recount of the company that has implemented Enterprise level procurement / ERP / BPM, etc and it was a death march. Pure and simple it was a nightmare, accounting couldn’t close the books for over 5 weeks, and this continued for almost a year. True story.

This post is not to be seen as refutation of automation, business process management, statistics, and economics. People, organizations, and companies need direction, require a director to set the tone, the pace and cadence for reaching goals. But there is a danger that we treat processes like science with the belief that when business behaves in a more rational fashion, things will operate like physics or mathematics. While it is true that applying scientific approach and principals to business can help, at its essence, business is not science. Here’s another analogy – while you should apply science to the field of medicine, in the end, the body and mind heal in manners that are not scientific. Ask any doctor about misdiagnosis and miracles. If he or she hasn’t been humbled by their lack of understanding of healing, change doctors!

We have to careful with model-abstraction worship. Let me tell you, the model is not the process – it’s a representation. Look at the two intrepid skiing figures above. Do you think they are thinking of the mechanics or the physics of what they are experiencing? Torque on the knees? Now put yourself in their instructors or trainers shoes and ask “how would I really go about communicating what needs to be learned to survive this type of run?”

General_Consultation_Workflow_diagram_v68An organization is comprised of the interactions of people, and these series of steps, while seeming out of control, create the cadence of your business. At the level where the work is completed, if you were to ask someone to describe what they do, it will start with a list items, not a diagram like the one above. At the level where the work is done,the people pushing the buttons, experience a different reality than what management experiences. If your goal is to assist those people, then your first step is not to alienate them by diagramming their busy day with pseudo scientific terms and weird charts. Remember, the director who can’t get her actors to relate to the story makes an awful film. You have to relate to others on a fundamental level, and for the most part in business, people don’t relate to this diagram. A picture is worth a thousand words, but for those whose inbox is flooded with requests, a diagram is not a picture, it a a thousand confusing questions. “Why is the box blue? Can I have a diamond instead?”

“Ok”, you ask, “what do we do instead?” Well, as luck would have, there is a good way to implement process, get approvals, and have consistency without over orchestrating business process and creating confusion. The approach is to view the decisions that people make as gateways between important steps. This is best illustrated with an example, so let’s model a bonus approval process for a sales organization.

We have a sales team who is closing deals weekly, and for each deal a manager and vice president will need to weigh in on the merits of the award. Fairly standard in most businesses, and in many cases this is managed with email. The bonus manager is the fulcrum of this process, as it he who currently reminds the sales agents that they have not supplied the correct supporting materials, as well as gently nudging the vice president of sales that she needs to get into the system and complete approvals so that the request can be released to payroll before the Wednesday paycheck run. Your role, dear reader, is to get the steps of this process that are inside the bonus managers head and create something that they will engage in. To create a fan of the new process, it’s better that the process come from the bonus manager – they have to do it, so if they create it, they own it!

Remember the diatribe against diagrams? You can’t ask the bonus manager to diagram their process, as they’re too busy. But have them list the steps – yes a simple list. It may be a very limited set of items. You get this:

  • Fill Out Bonus Request
  • Bonus Manager Reviews
  • Vice President Reviews
  • Payroll Issues payment

You can prod the bonus manager further, and get them to categorize the end states of this process. We’ll add Bonus Denied and Bonus Paid, as this will represent all the stops in the process. Now the list looks like this:

  • Fill Out Bonus Request
  • Bonus Manager Reviews
  • Vice President Reviews
  • Payroll Issues payment
  • Bonus Denied
  • Bonus Paid

The next thing to do is ask “What decisions get you from step to step? For example, what do you do when work is incomplete from the Sales Agent?” The answer – “Today? I email them and request more info”. Lets model this action as a phrase starting with a verb:

Request More Info

Now you start a helpful chart that looks like this:

Step Decision Next Step
Bonus Manager Review Request More Info Fill Out Bonus Request

 

Simple. It’s in English, and there is direct understanding of what happens. What’s more, these are the phrases, thoughts, and language used by the key person of the process. Their “vocab” is the context of how they think, and it’s not a stretch for understand what is occurring, no threat from the oppressive science of process modeling. You could even do this at lunch! Here is what the end product will look like:

Step Decision Next Step
Fill Out Bonus Request Complete Bonus Manager Review
Bonus Manager Review Request More Info Fill Out Bonus Request
Bonus Manager Review Approve VP Review
VP Review Deny Bonus Denied
VP Review Approve Payroll Issues Payment
Payroll Issues Payment Complete Bonus Paid



There’s more good news. ActiveEngine Software has a product that will take this list and create a workflow. Here is a demo video. Thanks for reading.

faradaypennytwinsOf late, Sensei needs to keep a clear head.  That has meant learning to segment ideas and really, really, really focus on streamlined features.  This is hard.  Not because Sensei has a plethora of great ideas.  That would be a nice problem to have.  Many times in software development you end up this guy:

This is the state where you have things you want to accomplish, yet even when you pair things down to the “essential”, other essential, critical factors must be taken into consideration before you create a mess.  This is life calling, and that string which suspends that giant sword that you noticed hovering over your head is about to snap.  There is a good chance that you need more discipline, better execution tactics, far better honed chops, you name the metaphor.  Sensei has been at this game for over 22 years, and still the speed that thought takes to become reality is way too slow.

With great sarcasm you can remind your self that some of the best work lays ahead, but the reality is that you still need to fight to be fluent, you have to claw your way to a Zen state of mind / no-mind.  So chose, the art of bushido or the art of BS.  Or maybe work smarter and enjoy life.

Before Sensei leaves you, ponder this:  does “being done” mean that you’ve dropped off a product but have to get on the phone in order to make changes, and maybe now that you are struggling why couldn’t you figure out to take time when it was more critical to be fluent with your productivity?

 

This post focuses on getting started with RavenDB, so we’ll set aside our focus on workflows for a bit.  It’s included in the ApprovaFlow series as it is an important part of the workflow framework we’re building.  To follow along you might want to get the source code.

RavenDB is a document database that provides a flexible means for storing object graphs.  As you’ll see a document database presents you with a different set of challenges than you are normally presented when using a traditional relational database.

The storage “unit” in RavenDB is a schema-less JSON document.  This takes the form of:  Because you are working with documents you now have the flexibility to define documents differently; that is, you can support variations to your data without have to re-craft your data model each time you want to add a new property to a class.  You can adopt a “star” pattern for SQL as depicted here, but querying can become difficult.  Raven excels in this situation and one such sweet spot is:

Dynamic Entities, such as user-customizable entities, entities with a large number of optional fields, etc. – Raven’s schema free nature means that you don’t have to fight a relational model to implement it.

Installing and Running RavenDB

The compiled binaries are easy to install.  Download the latest build and extract the files to a share.  Note that in order to run the console you are required to install Silverlight.  To start the server, navigate to the folder[] and double click “Start.cmd”.  You will see a screen similar to this one once the server is up and running:

The console will launch it self and will resemble this:

How To Start Developing

In Visual Studio, reference Raven with Raven.Client.Lightweight.  For CRUD operations and querying this will be all that you will need.

First you will need to connect to the document store.  It is recommended that you do this once per application.  That is accomplished with


var documentStore = new DocumentStore {Url = "http://localhost:8080"};
documentStore.Initialize();

Procedures are carried out using the Unit of Work pattern, and in general you will be using these type of blocks:


using(var session = documentStore.OpenSession())
{
   //... Do some work
}

RavenDB will work with Plain Old C# Objects and only requires an Id property of type string.  An identity key is generated for Id during this session.  If were were to create multiple steps we would have identities created in succession.  A full discussion of the alternatives to the Id property is here.

Creating a document from your POCOs’ object graphs is very straight forward:


public class Person
{
    public string FirstName { get; set; }
	public string LastName { get; set; }
	public string Id { get; set; }
	public int DepartmentId { get; set; }
    // ...
}

var person = new Person();

using(var session = documentStore.OpenSession())
{
   session.Store(person);
   session.SaveChanges();
}

Fetching a document can be accomplished in two manners:  by Id or with a LINQ query.  Here’s how to get a document by id:


string person = "Person/1";  //  Raven will have auto-generated a value for us.
using(var session = documentStore.OpenSession())
{
   var fetchedPerson = session.Load<Person>(personId);
   //Do some more work
}

You’ll note that there is no casting or conversion required as Raven will determine the object type and populate the properties for you.

There are naturally cases where you want to query for documents based on attributes other than the Id. Best practices guides that we should create static indexes on our documents as these will offer the best performance. RavenDB also has a dynamic index feature that learns from queries fired at the server and over time these dynamic indexes are memorialized.

For your first bout with RavenDB you can simply query the documents with LINQ.   The test code takes advantage of the dynamic feature.  Later you will want to create indexes based on how you most likely will retrieve the documents.  This is different that a traditional RDMS solution, where the data is optimized for querying.  A document database is NOT.

Continuing with our example of Person documents we would use:


int departmentId = 139;

using(var session = documentStore.OpenSession())
{
   var people = session.Query<Person>()
                          .Where(x => x.DepartmentId == departmentId)
                          .ToList();
}

In the source code for this post there are more examples of querying.

Debugging, Troubleshooting and Dealing with Frustration

Given that this is something new and an open source project you may find yourself searching for help and more guidelines.  One thing to avail yourself of while troubleshooting is the fact that RavenDB has REST interface and you can validate your assumptions – or worse, confirm your errors – by using curl from the command line.  For example, to create a document via http you issue:

curl -X POST http://localhost:8080/docs -d "{ FirstName: 'Bob', LastName: 'Smith', Address: '5 Elm St' }"

Each action that takes place on the RavenDB server is displayed in a log on the server console app.  Sensei had to resort to this technique when troubleshooting some issues when he first started.  This StackOverflow question details the travails.

Another area that threw Sensei for a loop at first was the nature of the RavenDB writing and maintaining indexes.  In short, indexing is a background process, and Raven is designed to be “eventually consistent”.  That means that there can be a latency between when a change is submitted, saved, and indexed in the repository so that it can be fetched via queries.  When running tests from NUnit this code did not operate as expected, yet the console reported that the document was created:


session.Store(teamMember);

int posttestCount = session.Query<TeamMember>()
                .Count();

According to the documentation you can overcome this inconsistency by declaring that you are willing to wait until RavenDB has completed its current write operation.   This code will get you the expected results:


int posttestCount = session.Query<TeamMember>()
              .Customize(x => x.WaitForNonStaleResults())
              .Count();

Depending on the number of tests you write you may wish to run RavenDB in Embedded mode for faster results.  This might prove useful for automated testing and builds.  The source code provided in this post does NOT use embedded mode; rather, you have need your server running as this gives you the opportunity to inspect documents and acclimate yourself to the database.

There is much more that you can do with RavenDB, such as creating indexes across documents, assign security to individual documents, and much more.  This primer should be enough to get you started.  Next post we’ll see how RavenDB will fit into the ApprovaFlow framework.  Grab the source, play around and get ready for the next exciting episode.

 


ActiveEngine Software by ActiveEngine, LLC.