Don’t Forget the Indirect Actors

As a consultant in the technical space, I’m often not involved in the gathering of requirements and creation of the functional specifications of a Business Process Mapping (BPM) project. I usually get brought into the project whilst the Business Analysts are finalising these documents ready for me to design a solution. More often than not, I usually receive a document that covers the direct actors involved in the process. These are the people that will receive a task item to action. If I’m lucky it will also address the key systems involved directly with the process.

• Example: Person A will submit a request; Person B will approve a request; Person C will deliver the request; System A will store the request; System B will provide a report for the request;

This is important for the day to day usage of the process. It is what I refer to as the Workflow Process. This does not cover the Business Process. The Workflow Process is only a part of the Business Process. It describes exactly the example explained above: the direct actors within the process. If you went and implemented this solution with K2 BlackPearl/BlackPoint you would be implementing a fairly basic workflow process – but it would not cover all the needs of the business. This might be all the client wants and/or needs as to do more, would cost more money, time and resources. So what more do we need to ensure that we map the business process successfully? We need to define the Indirect Actors within the business. These are the people that don’t get assigned tasks, but will be required at some point to get involved.

• Example: Person A submits a request; Person B will approve a request; Person C will deliver the request; System A fails to store the request; Person D monitors the process through a Management Console and resolves the issue by manually uploading the request; Person D progresses the workflow; System B will provide a report for the request;

Hopefully you can start to see, by this very primitive example, the importance of defining the indirect actor here. Hopefully it was simple enough to spot, if you didn’t get it the first read, go again. Person D is not involved in the process at all. In this example, they are monitoring the K2 Workspace and getting involved manually in the process.
Defining this type of use case is critical to ensuring the business needs for the process are covered. It will go a long way to ensuring that the business users are comfortable with the solution being designed and delivered. If we don’t map this solution out properly, if it’s not defined in the functional specifications and is left up to the Technical Expert to come up with a something on their own, it would be even more dangerous than not defining it at all. That last part might be confusing at first, but if you think about it further, it makes perfect sense. If we are here to design a Business Process, then it requires that the business define the process. Not the solution, but the process – how they wish to interact with the system; how they expect the system to react to situations; if we rely on technical people to dictate or mandate a solution that does not fit the business expectations, then you will have a potentially failed process. If, for example, we didn’t define what would happened if the request in our little example. The request failed to get stored correctly and went into error. The technical expert decides that this is a likely scenario, and needs to be handled. They decide that the solution is to:

• Retry the upload three times; if still in error - email a notification to Person D to resolve;

What a nice and tidy solution. Pats on the back all round.
Not quite. We’ve now found ourselves in the dangerous position of prescribing a solution that the business did not request. We’re sending an email to a person that isn’t expecting a notification. We are retrying an upload to a system we don’t control potentially three times. We are forcing the business to accept something they didn’t ask for.
Notifications are nice, but not everyone is so receptive to them. If Person D in our example was a Group, maybe the local Help Desk at a large company, emails would be like spam to these people. They may receive hundreds a day. Sending an email to a group of people in this field is akin to giving a dollar to a millionaire. Bit of a waste of money. Retrying to upload a document to a system we don’t control could also cause us issues we might not see. There may be a perfectly legitimate reason that the Business Analyst did not suggest a retry at this point.
To design a Business Process we need to identify these indirect actors. We need to understand where a process might require some form of exception handling – be it manual or automated – and we need to ensure that the business is directly involved in determining the way they wish to handle it. Our job is not to prescribe the solution that they need, but to ensure that there is a business strategy to cover their workflow process.
To that end, our responsibility is to escalate these types of things back to the Business Analyst, to provide options for them to go back to the business with, and to clearly outline in the functional specifications. It’s usually in this area that I see a lot of workflow processes fall short of business expectations. Anyone can build a workflow, what we as Technical Experts need to do is ensure that all the actors, direct or otherwise, are accounted in our solution, and that the business is aware and accepting of it.
The types of indirect actors I generally keep an eye out for are your: Front Desk; Help Desk; Managers (usually those that like to get reports out of processes: completed in a month; started in a month etc); System Administrators; Personal Assistants; SharePoint; SQL Reporting Services; Log Files;
These types of interactions usually raise red flags for me, and I generally start the process of harassing the BA Team to get me more information around those particular things. Indirect Actors, don’t forget them. Make sure you have them defined. Don’t underestimate their importance just to get a process out the door, because chances are pretty good that they’ll find their way back you sooner rather than later. K2 or any other workflow tool won’t be able to save you. There’s no magic involved. There are lots of solutions available to you. K2 gives you quite a number of different ways to solve the majority of issues you may come across; but the only way to ensure that you map out a robust solution is with a clearly defined Business Process – which encompasses the business’ way.

K2 - SharePoint - InfoPath Design Concepts

In my recent travels as an IT consultant specialising in the delivery of internal business processes for large scale companies, the idea of: “knowledge transfer”, “point-and-click” or “configuration over customisation” of solution designs has become standard practice.

With this in mind, selecting applications that provide out-of-the-box functionality becomes quite significant. The general solution designs that are becoming more common place often include the following applications: K2 BlackPearl; SharePoint 2010; InfoPath 2010; and Reporting Services / PowerPivot / PerformancePoint.

This decision to introduce these types of products or applications are generally made before the likes of myself and others are brought into a project, and usually before any analysis has been completed. For good or bad, these decisions are made based on those ideas previously mentioned: knowledge transfer; and configuration over customisation. SharePoint 2010 lends itself to point-and-click applications, which makes it very much a configuration over customisation application. As most SharePoint lists and libraries interact with InfoPath fairly simply, this makes it a natural choice for the data entry user interface. This then leaves the business process engine.

There are a number of choices at this point for businesses to get a point-and-click style application that will handle the complexities that most large scale companies employ as their business process flow. In most cases I prefer the K2 BlackPearl option as it becomes quite a scalable and flexible solution whilst still meeting the point-and-click requirement. It also provides out-of-the-box reports to enable tracking as well as the ability to map Line-of-Business systems to forms and workflow easily.

Now that these applications have been brought together, in the eyes of most management team’s perspective it should be quick and easy to create lots of processes in a hurry. Start with the Form, just drag and drop some textboxes and dropdown fields; on to the process flow – form is submitted to launch the process, goes to the manager who makes the decision to approve or reject; create a site for this all to live with a Form Library to access the form. Done. Let’s go.

Or maybe not. Whilst these applications will allow you to do exactly that, the business in the long run, is not going to be happy. There are so many things to consider in a solution like this, but they don’t necessarily spring to everyone’s mind. As a technical architect, the previous paragraph is scary on a number of levels. First and foremost, this is how these types of solutions are sold to companies, creating false or unreasonable expectations. Second, the concept of going from requirements to development, without a proper design happens far too often, and is mistakenly called being agile. There’s nothing agile about it. It’s careless and leads to a lot of re-development.

Why? To answer that, we need to really understand these scary flaws suggested above. The more something is point-and-click, the more it requires patience and planning. Not because it is different to customised applications, but because it can become too easy to create a big unmanageable mess. The term most SharePoint people will use is: governance. The term I like to use is convention.

We need to understand the following: how users will access and interact with a site; how users will access and interact with a form; and how users will access and interact with a process. To do this, we need to understand the different types of users. Not just the users directly involved in the process, but also users indirectly involved. They might include: general managers; help desk; front desk; personal assistants acting on behalf of; support and maintenance team (developers). In the design phase we start referring to these as: actors. Actors don’t necessarily have to be people. They can also be systems such as: Active Directory; SAP; SharePoint (not just the form library but look up lists); K2 SmartObjects; and other Line-of-Business systems.

From there we need to start considering how often these processes are going to be used. Once a week, once a day; once an hour; once a minute; or 1000 times a minute? These types of considerations are often neglected at the gathering of the requirements; start to become apparent at the functional specification and become imperative at the technical design level.

Configuration-over-customisation and knowledge transfer become realistic and measurable outcomes when these things have been defined. Governance and design make building this type of process repeatable. Once we get to a point where a process is repeatable we can start handing over development to internal staff, meeting the knowledge transfer requirement. We can also start making logical decisions with regards to configuration through the use of conventions, which can be determined through a consistent application of governance.

So let’s make the assumption that the business has listened and have gathered detailed requirements, produced functional specifications for various processes and now expect you to deliver this design. What’s next? Unfortunately this is not as simple as it seems. However the process I go through to make a design is based on these key concepts:

• Data from Input Forms are stored external of the Form – through use of a SmartBox SmartObjects, or SmartObject pointing at an External Database;

• Forms are deployed as a Content Types to SharePoint rather than a Form Template;

• Workflow processes have short lives;

• Data captured during the workflow process are stored external to the workflow – through use of a SmartBox SmartObject, or a SmartObject pointing at an External Database;

• Workflow activities are stateless – an instance of a process should be able to be moved or dropped at any activity, and the workflow should be able to handle it. Shouldn’t have dependencies on previous activities.

What these simple concepts do is remove the dependencies on the form, SharePoint form library and workflow from each other and move them to a database. This comes down to areas of responsibility. A form is responsible for data input, not data storing. So we separate responsibility of form from the data. Forms deployed as a content type removes the dependency of the form on the library. This will allow any form library to consume the form. A workflow process instance will keep the version of the workflow it was initiated with. By this we mean that if a new version of a workflow is deployed, the running instances will keep the previous version. If a process was alive for a long period of time, it could have a detrimental effect on the business process. By making them short lived we avoid this headache. Data captured during the workflow should pass this responsibility over to a database, following the same principles as those defined for the form.

With these concepts, we are still far short on a design. But we have something to consider and discuss. For example, where this external database lives and how do we access the data within. The nice part about this is that reports are now simpler to design and create as all the data is in one area. Not stored in XML in a form, or as metadata in a library, or within the K2 process itself. We simply go to a database(s).

From this point onwards, we are now at the mercy of the functional requirements. The next steps in our process are heavily dependent on the expectations of the business owners and how they choose to operate. Things to be aware of are things such as:

• Ability to stop-the-clock: this is something that most service request processes require for meeting Service Level Agreements. It assists in reporting against how quick a request was actually completed versus elapsed time;

• Administration of the process: often help desk teams will get calls on where a request is at or that they’re not sure how to do something with regards to the process. This means that the help desk team needs to be able to monitor and at times manipulate the process;

• Maintenance: how do we handle changes in the site, form and workflow can have a significant impact in the longevity of the system. Systems that are hard to maintain offer are replaced in the short term;

• Recovery: when a system goes down for any reason, during any part of a process, we need to be able to pick up and move forward quickly. This can have some serious implications if this is not built into the design with due consideration. By storing all data in a database external to the form and workflow process, can go a long way to ensuring the robustness of the design;

• Notifications and task lists: how a person chooses to receive tasks can also make for quite the topic of discussion. This lends itself to the discussion of escalating and expiring of a process. Handled properly, it can lead to happy users. Handled poorly or not at all, can lead to spamming people to the point that they begin to ignore the process. Finding a balance between sending notifications of tasks, and training people to regularly monitor their tasks can be a big advantage. Making this a high priority in your design can become quite advantageous in the long term.

The design process in this regard would be no different to that of a normal custom built application. Even though this is point-and-click configuration, we still need use cases, functional tests and acceptance tests to ensure that our implementation of the design meets the requirements.

The design should leave no question for the development team as to how they approach a SharePoint-InfoPath-K2 application. In earlier blogs I discussed how having a development methodology was critical to the success of a workflow project, this I believe, would be just as critical. Following proper application lifecycle patterns, even when using point-and-click application, is critical. Make no mistake. Having a design, holistic and/or specific should be top of the agenda when discussing SharePoint-InfoPath-K2 applications. If it’s not, make it so, or prepare to start disappointing your end users, who ultimately will decide the success of the application.

In the absence of K2

In the absence of K2 being an available choice (consider expenses, resources, environment, support and maintenance that goes with selecting technologies and frameworks), Windows Workflow Foundation (WF) is becoming a viable option.

Not for everyone, but for those that understand Workflow, C# and need to interact with SharePoint in some way or another, it can be a nice option to have available.

Things to take in to consideration with WF is: what can I use for a User Interface if there is any Human to System interaction; how much do I need to know about the plumbing; how much do I need to know about SharePoint (if this is part of the solution)...

SharePoint 2010, InfoPath 2010 & WF seem to make a nice combination in the latest edition of the Microsoft tool sets. WF hasn't made in major leaps and bounds. People used to Visual Studio add-on WspBuilder and the like, will be happy to hear that this type of project set up is now out of the box.

A lot of the plumbing that was once a tedious affair in Feature.xml file, is now handled for you for the most part... not quite completely but with little effort, it all sings and dances together quite nicely.

Debugging through Visual Studio 2010 has also been taken in to account such that all one needs to do is hit F5 and the solution is deployed and awaiting an event to be triggered. For those that worked on previous incarnations of WF, this is quite amazing stuff. No more attaching the debugger manually after a painful deploy, or having to write batch files to automate the process.

InfoPath 2010 integration is a little painful still as the solution doesn't understand the .xsn extension still. But this can be manually associated with a little massaging.

Key to this is getting the Elements.xml (or workflow.xml depending on your preference for naming the elements manifest) to point to the right file path. In the new project structure, everything appears in a folder, which means you need to ensure that the .xsn files are in that folder correctly.

I used to try and avoid solutions that had MOSS 2007, InfoPath 2007 and WF as its technologies of choice like a dog trying to avoid worm tablets! However, these new solutions have had spared some thought for the lowly developer and tried to make our lives a little.

Whilst this still remains a very code dependant technology, and really Microsoft haven't put much effort in upgrading the framework (alot of it still using Framework 3.5), at least the deployment part has been simplified.

Not really fair to make a comparison between whether to use WF or K2, as a developer K2 is hands down the better tool (and is built on top of WF therefore providing you with everything WF would give you), in the absence of a choice, there's no need to be scared of WF.

Reading properties in the workflow of the Metadata columns from a SharePoint List or Library, creating user tasks to approve or reject tasks, notifications, workflow history etc are all things that are, with a little bit of configuration and programming, quite simple to establish. With the simplified way to debug these days, finding and correcting bugs in your code is also less painful than it once was.

I wouldn't say I am looking forward to more WF projects in the future, but I am definitely less apprehensive about it.

My recommendation would be to give it a go, create a simple approval workflow and check it out for yourself. If you have SharePoint 2010 and InfoPath 2010 as well, have a go at all three together and see how the experience compares.

Happy programming.

Agile misconceptions

Agile and Scrum are some really handy buzz words. A buzz word can be defined as a “…term of art or technical jargon that has begun to see use in a wider society outside of its originally narrow technical context by non-specialists who use the term vaguely or imprecisely…” (as stated in Wikipedia).

As a consultant I get the benefit of working in different environments and working with different methodologies across various industries. I've had the benefits of seeing highly skilled and motivated people impress upon me the ideals of a good working methodology to only then butcher the implementation of it in practice.

In almost all of the projects I’ve been involved with that stated they were either Agile or following a Scrum methodology were merely using buzz words to sound impressive. I’m not easily impressed.

Agile is not Scrum. Scrum is Agile. There are many implementations of the Agile methodology, Scrum is just one such implementation. There is Lean, TDD, eXtreme Programming (XP) and the list goes on and on. Agile means an iterative development where requirements and solution evolve through collaboration between self-organising cross functional teams. Essentially that the scope of work is not fixed. It is continuously reviewed and re-prioritised based on collaboration between the Client and the Vendor. You may here terms such as Product Owner and SCRUM Master blah blah blah.

Anymore buzz words? If the terminology has not been clearly defined before you use it, then it is a buzz word and either you don’t understand it, or the person you are stating it to does not understand it. Assume nothing.

More often than not projects fail to factor in how much the client affects the implementation of that methodology. Take for example the Waterfall methodology. Before you stop reading, I'm not about to suggest that this is good practice, there's a point coming. Waterfall is quite simple, it is not confused, misconstrued, misinterpreted... If someone was to say they were implementing a Waterfall project, you know straight away what it entails: heavy initial documentation; development of some type; UAT; and project completion. Simple, might not be that effective, but that’s for someone else’s blog.

If someone was to say they were following an Agile methodology and implementing a Scrum project, we might each of us have a difference of opinion on how this project would be implemented. The client would have a view, the Project Management Office (PMO) would have a view, and the development team would have a view. Those views might well be very different.

This is where I believe the process gets bogged down. People know the buzz word; they don't often know the definition. Very few people will say they don't know Agile, or they don't know Scrum in the city where I'm from. Seems everyone knows it. Great. Define it for me.

Maybe you come across someone that may have read the Agile Manifesto. Well done, but does that mean you understand what makes a successful implementation of it? Maybe, maybe not. The manifesto is a high level set of principles, it is not a definition.

If I am going to implement a methodology in to an organisation successfully, then it needs to be defined accurately. It needs to be defined in a way that the Client understands what it is they will get out of it (ROI) and how the project will be delivered (artefacts). Very few projects I have worked on do this, or do this well. The Client hears the buzz word, they are smart, we are smart, let's move on and we can argue at the end of the project when it is time to pay up!?

Take the time to go over each step of the process, even if it means making them listen to something they already know. What it will do is ensure that you, the Vendor, and they, the Client, are talking the same language. Not in principle, but in practice. We will do X, followed by Y, followed by Z in a continuous pattern and deliver you BLAH. If they have any questions, queries, concerns, it gets ironed out straight away, rather than when it is time to pay.

Agile does not mean: no documentation. It does not forsake planning and envisioning. These are still key and critical parts of the process. They ensure that there is a plan, a vision and later determine the Product Backlog. The Product Backlog is the high level plan of what is being delivered at a point in time. This should be continuously revised.

Back to documentation. How much is enough? How much is too much? Where do you draw the line with documentation? I was at a recent presentation from Dave Thomas and I asked the question of where this line is. His answer was simple, between 10-15% of the overall project length. He also phrased it in his slides as: “… to understand enough of the vision of ‘tomorrow’…”

So how do we get this vision of tomorrow? In Agile speak it comes down to:
• Define the Problem;
• Define the person affected by the problem (Persona);
• Describe the problem succinctly (Stories);
• Define the criteria of User Acceptance (Acceptance Criteria).

Defining the problem should include evidence that the problem exists. This will also assist later when we attempt to define the criteria for acceptance.
Each Persona described should have a definition of that Persona (description of their role and background information such as education) so that everyone is aware of the type of person the solution is to be aimed at.

Documentation shouldn’t just stop at “Envisioning” as Dave Thomas so eloquently called this process, he went on to suggest that this stage include common tasks such as: GUI Architecture and Design concepts (layouts; navigation etc); GUI Prototyping; Software Architecture (structure of new, changes to existing); Buy vs Build Evaluation; Product vision roadmap; Paper prototypes describing the final output; Wireframes and interface concepts; System architecture diagrams and models; Proof of Concept software; Return on Investment strategy…

I’m not going to plagiarise everything he went on to say, but as you can see, there’s a lot of documentation that he sees as essential to a successful implementation of an Agile project. It’s not just roll the sleeves up and start coding or delivering output.

Agile works. It works well. But like anything, it only works when all the parties involved have the same understanding. You, the Vendor, understand what the Client wants, and they, the Client, understand how they are going to get what they want.

The agreement between what the Client wanted, and what you delivered is in the Acceptance Criteria. Quite often you get to the finish line and go live, and the end users see the deliverable for the first time and what they expected wasn’t what you delivered. They expected an iPod, but we delivered a radio! They expected a laptop, but we delivered a desktop!
Even in Agile projects, especially in poorly implemented projects, this is a common occurrence. This is not just something that happens in Waterfall projects. In the typical projects that I seem to be involved with it is either: poor or lack of planning at the start (Scrum implementation); or too much planning at the start and the scope should have changed but remained static (Waterfall implementation).

Take the time to develop a clear vision of what the Client wants. Measure that in terms of how it will be accepted. Revisit the Vision and the Acceptance Criteria after each iteration to ensure that the vision is still accurate. Everything that is going to be delivered should have an accompanying Acceptance Criteria. Nothing should be considered completed until the Client accepts that the criteria have been met. The Acceptance Criteria should be a collaboration between the Client and the Vendor so that both sides understand the meaning of completed.

There are a lot of opinions on which implementation of Agile is a good one, or whether Agile is a good methodology to follow. What I think makes sense, is that whichever methodology you choose to follow, that you, the Vendor, and they, the Client, are on the same page. That you both understand fully the process of how the project is going to be delivered, and most importantly, there is an understanding of how the project will be measured as completed.

K2 Development Methodologies

Jumping straight in to any kind of development without some form of a plan or development structure is dangerous. Most people know this already and are probably saying, well of course. For whatever reason, however, most people don't have a plan or structure when developing a K2 BlackPearl workflow.

Everything is rushed. Right from the Project Manager to the Business Analyst through to the developer, it's all about getting the workflow out the door quickly. This has something to do with the way workflow is pitched to the decision makers. Workflows are easy. Easy correlates to quick. Structured development involves careful planning, development and testing.... that doesn't correlate to quick. So somehow, it seems to me in my experiences with workflow, that some changes need to be made people's mind sets.

Workflow should be treated like any other type of development project. Whether we are talking about Windows Application development or Web Based Application development, we treat this type of development no different.

Whatever your methodologies are, they should be consistent. If they are consistent, then they become easier for your Project Manager to plan around.

I'll share with you mine:

• Keep your workflow simple;


• Separate your business rules from your workflow rules;


• Don't automate poor processes!

These are my philosophies. But what does this mean? What if my process is a complicated one? What are the differences between business rules and workflow rules? What's a poor process, and how do you tell if you have one?

These are good questions. So let's break down what I mean by these three(3) simple statements.

Keep your workflow simple:
Workflow, like with any development application, relies on good planning. A good workflow will not only be easy for users to interact with, but also easy for administrators to manage, and manipulate. This needs to be at the forefront of your mind when designing the workflow. Ask yourself the question: what am I trying to achieve with this process? If you can't say it to yourself quickly and easily, then you are going to get in to trouble. Have a look at breaking your process up in to smaller bites. If you workflow as 40 steps in it, then it is too big. It will be too hard to maintain in the long run. See you can simplify this by creating re-usable bits. Can this be split in to 4 workflows of 10 steps?

An example of this might be a Capital Expenditure Request application. A business might have the need to have one where a line manager has a new starter and he requires that this new starter has a new laptop, mobile phone, chair, desk and personal car. He may need to fill out a form. This form may then need to go through the rigmarole of having it approved by his direct manager. Then approved by the CIO. Then sent to Purchasing to order the equipment. Then to Assets Accounts to register these new purchases, and finally to Internal Deliveries.
Now if we were to design this as a Sequential workflow, this would be fine. We'd have no issues here. There'd be two approval steps, two update steps and and a completion step. Pretty simple, easy to maintain and support.
If, in the same company, we also had a New Starter application. A new person was to commence at this same company. The Line Manager would complete a form that stated the new start's details and position. This new start form would then need to be approved by the line manager's direct manager. The approved by the CIO. Then sent to IT to have his IT Account (email, sign in etc) set up.

I hope you see where I am going with this. Now imagine if the Capital Expenditure (CapEx) application was created 2 months prior to the New Starter application becoming a project. If we create this workflow as another Sequential workflow, we would have the CIO and the direct Manager approving, essentially the same request - one for the person, one for the equipment he'd require. Now, I've met a few CIO's in my time, and that took a lot of careful planning, and a lot of rescheduling. The point I'm making is, these are busy people. Yet in our new workflow application, we've now got him doubling up on his work. I can't see him being too happy with this scenario. In fact, I'd be looking for a new place to work if I kept that up.

What can we do to simplify. We can create 3 workflows here. We can separate out the common steps here in to their own workflow. We can call that the Approval's workflow. All approvals can call this common workflow. We combine the New Starter form with the CapEx form so that the two share these details. When it is launched we kick off the Approval workflow. If it is approved we launch both the CapEx workflow and the New Starter workflow.
This ensures that the CIO only gets one task, but both the new starter and the cap ex are launched as required.
We have more workflows now, but they are smaller, which means each one is easier to manipulate. And each one can be launched on their own. This means they will be re-usable.

Separate your business rules from your workflow rules
This one is a tough one to grasp. Basically what I mean here by business rules are your complex statements of code that are nothing to do with workflow. They are to do with how the business operates. The way I determine the difference is by breaking down where the information required to complete the rule comes from, and how is it used?

I like to keep my workflows dumb. Workflows, in my way of thinking, shouldn't keep business specific data within them. They should only hold information required to make them functional. Anything to do with business related information should be stored within a separate layer.
Have I lost you yet? What am I going on about.
Applications should be broken down in to logical layers. You will have your Data Layer (database - SQL Server, Oracle, may be even SharePoint, SAP etc), your Data Access Layer (the way you will access your Data. Can use LLBLGen, nHibernate or even K2 SmartObjects), your Business Access Layer (a dynamic link library that stores all your complex business rules) and then your Workflow Layer followed closely by your user interface layers.

So going back to my point, work out what layer the information that you are needing to capture belongs to. If it is in your workflow (using the DataFields), make sure that it makes sense to be there. K2 BlackPear out of the box allows an administrator to use the "GoTo" functionality in the Workspace. If you have Business related data that is stored in your workflow, if the user "Jumps" over or to an Activity and misses out on running an important business rule that was only captured in the workflow.... trouble. Your workflow should be dumb. It shouldn't matter where they are in the workflow process, if the "GoTo" functionality is used, it shouldn't break your workflow. The workflow rules should only apply to how an Activity should be interacted with at that point in time. It shouldn't matter what happened before it. That type of information should be captured in your Business Access Layer.
If you are confused still, that's fine. It is quite confusing for most people. Most people will place all their Business Rules in the workflow, behind layers of succeding rules, preceding rules and line rules. All these rules are locked in to that specific space. They are not re-usable, and if there is ever a change in the business rule... hate to be the person that has to fix it.

If you had those types of rules in the Business Access Layer, then if the rule changes, it changes in one place, and your workflow doesn't need to be touched. It's all in one nice neat logical place.

Don't automate poor processes
Can't think of anything worse than being forced to automate a poor business process. To put it bluntly and succinctly, if it doesn't work nicely as a manual process, then it MOST DEFINITELY won't work with ANY kind of workflow tool. I don't care how good a product the workflow tool is, and K2 BlackPearl is one of the better ones, you put junk in, you'll get junk out.

That said, how do we determine how successful a business process will be? How do we pick out the best way. There's no easy answer to this. Many different people have different ways of doing this.

For me, it's all about priorities. What can the client live with, and what can't they live without. That last part is where a base my workflows on. What is the critical path for a successful workflow. What steps must be performed to make the project a winner.

I generally map out the most simple workflow first. The straight line workflow. Go from start to finish with Successes predicted. Get that up as quickly as possible and in front of the users and get feedback. Don't spend time making it perfect, and creating every scenario. Chances are, by the time the Client described the scenario to the Business Analyst, who passed the information in the form of a poorly worded document to the Solutions Architect, who converted it in to technical speak for you, the lowly developer to create... it's already wrong.

Draw a straight line from where your workflow begins, to where your workflow ends, in the quickest way from start to finish, and make that your platform to build on top of. And then get it to the users to view as you are developing. Remember, Junk in means Junk Out. So if it sounds like a complex workflow, ask the question, don't be afraid, is this the best way to do this. Force the Solution Architect to ask the question of the Business Analyst. Force the Business Analyst to go back to the Client. Don't assume they got it right.

Business processes change. The more a company moves in to the automated world, the more their processes, the way they work from day to day, changes. This is inevitable. So design your workflows with the view that this will change. Must change. And therefore whatever you create has to change with it.

These are my methodologies. Whilst it isn't important to follow mine, it is important to follow something. Just jumping in and creating workflows quickly and deploying them live is a recipe for disaster. Just because it can be done, doesn't always mean it should be done.

I promised code... in my next blog, I'm going to start throwing some around. Stay tuned.

K2 Lessons Learned

It's been well over a year since I have updated this blog... mainly due to neglect, but also due to the lack of any valuable information worth posting.

I have been busy in this space for the last year, K2 BlackPearl development is getting popular. It's fast becoming the buzz word. As such, I've been busy with K2 installs and upgrades.



Upgrading from version 0803 of K2 BlackPearl to version 0807/370 was a big step. This required a bit more foresight than I was told or thought.

• Install the upgrade over the top of 0803 is easy. Follow the wizard steps and restart your machine. That's what I was told. But I know better now.

What you need to do:
If you have already created a Visual Studio 2005 project in version 0803 and are doing the upgrade in the middle of your development project be careful. You can never be too paranoid in my oponion. Place your project in a nice safe place outside your development machine (don't just rely on Source Control here).

Install version 0807 over the top of 0803. Forget about any updates or patches at this point. Get this upgrade right first. Make sure your project(s) all compile and build in version 0807 first. If you have SharePoint installed, make sure your upgrade on the SharePoint server worked successfully. Especially with the "K2 for SharePoint" page in Central Admin.

Visual Studio Project Issues:

What if your project didn't build. Mine didn't. Don't panic, as it's not as bad as it may seem at first. In version 0803, there were 3 hidden projects that were created under the .kprx project file. Some of you probably already know this.

K2 have now moved these projects to a local destination in your Documents and Settings -> Local Settings section. The reason for this is to allow you to compile your projects while they are in Source Control without your hidden projects permissions blocking them. This is due to those hidden projects being referenced locally, when it compiles the dll's in the hidden projects needed to be checked out to properly build.

Now what happens is that when you open a .kprx file from source control and build it, the file will check the local file system for the hidden projects (which have now been rolled up in to one project) and if they do not exist, they will create a fresh copy, if they do, it will replace it.

This is a big change from 0803 to 0807 if you have already created your projects in 0803 and are converting them. Not all your projects will like this change, especially if you are like me and have referenced your own dll's in your .kprx project. In my case, I had issues with the project properly finding the hidden project on its own. What I had to do was open my .kprx project, go to the references section: Manage Project References, remove the reference to the old Extender Projects altogether and rebuild. I then deleted the Extender Project folder that was created under my project in the file system as it is no longer needed (also another reason for keeping a backup on another server rather than relying on Source Control).

Database issues:

The other change was with the SQL Server permissions. The K2 account on SQL Server in most instances is going to be a db owner on the databases that it controls. In 0807, this is no longer enough. Especially when you are using SmartObjects in your workflow.

Strangely enough, you will be able to Insert new records easily enough, but whenever you try a GetList call, you'll receive a permissions issue. The reason is the new level of permissions required. The K2 account will need SQL Server "sysadmin" rights on some of the databases. I am not sure to which databases as I didn't have enough time to fully test this. But I'd imagine on the SmartBox, SmartFunctions and SmartBroker databases as a minimum.

The reason I was given was due to the new functionality given to SmartObjects. The database can now be placed on a separate database server than K2's databases. This permission level is required for the K2 service to access two SQL Servers across the domain.... I'm not a network or infrastructure person, so please forgive the level of detail here. I just know that if you don't have sysadmin rights on some of the database tables, you're in for a shock.

Back on track:

Once this has been corrected and your Visual Studio projects all build, you've ensured that SharePoint's K2 for SharePoint page is running properly, you can then do your 370 patch update safely. I didn't have any issues with this (make sure you run all your upgrades and patches with the K2 Service Account).

My Way or the Highway

The Highway will be a blog that will attempt to cover key achievements, key findings, and keys (?) with regard to Application Development, SharePoint Development, Database Design and Reporting Services.

What I will be describing to those that wish to follow, are the pains and trials that I, as a senior IT consultant, have come across, and ways to go about mitigating some of the more tedious scenarios that most people seem to come across in this new wave of Microsoft (that's right, I like Microsoft, hope that hasn't scared any of you away) tools and applications.

This is just the start, look out for my next blog. Promise to peek your interest in that one.

From your friendly neighbourhood IT guy.