Communicating a Business Process Solution

In a typical Business Process Solution project there will be a number of key members of the Project Team.  These might include a: Project Manager; Information Architect; Business Analyst; Solution Architect; Technical Architect; and the Development Team.  Their might also be key stakeholders such as a: CIO; IT Manager; System Administrator; and business users who may be directly involved in process itself.

These team members might come and go throughout the project and might not necessarily be full time in the project in the first instance.  Given that, how do we communicate the business process in such a way that the various levels of the project team, both the technical and non-technical alike  - not all of whom are on the project at all times – can quickly and/or easily be brought up to speed on the business process solution?

Let’s take a step back and understand the described Project Team:

·     Key Stakeholder(s) (Non-technical): Their interest is along the same lines as the Project Manager.  They want to see the Return on Investment promised to them.  Their interests in a Business Process Solution? Budget, time estimates, ROI.

·     Project Manager (Non-technical): in IT projects in general, PM’s usually come from an IT background at some point in time.  They might not understand the very technical elements of a solution; however they are generally IT savvy.  But what are their interests in a Business Process Solution?  Budget, scope, resources, time estimates.

·     Information Architect (Non-technical): bridges the gaps between the business, the information consumed, and how that data is utilized (governance plan) through the Business Process Solution.  Their interests in a Business Process Solution? Content or structures, governance of content.

·     Business Analyst (Non-technical): the face of the business user, they not only gather requirements but validate and verify those requirements.   This ensures that when this is communicated to the Technical Team, it is done so in a consistent way.   Their interests in a Business Process Solution? Requirements gathering - both business and functional.

·    Solution Architect (Technical): following on from the SOA and SOE and along with the information received from the Information Architect, to design a technology stack that confirms the business and functional requirements.  Their interests in a Business Process Solution? Solution design conforms to existing architecture models defined at the enterprise level, systems.

·    Technical Architect (Technical): creates the framework that will allow for the implementation of the solution design at a task based level.  Their interests in a Business Process Solution? Technologies, Tasks and systems.

·    Developers (Technical): purely technical, they follow the framework and complete the assigned tasks validated by unit tests.  These tests will also include some functional tests to meet the requirements gathered by the Business Analyst which will have been translated into test cases by the Technical Architect.  Their interests in a Business Process Solution? Test cases and tasks.

·    Business Users (Non-technical): these are the users that will be affected most by the Business Process Solution.  They will have described their duties to the Business Analyst.  Their interests in a Business Process Solution?  That they get what they asked for.

Imagine these types of people in terms of Levels.  Each Level of Person has a different agenda within the Project Team.  Given these diverse roles and responsibilities of the people within the team, how can we document the Business Process Solution in a way that each member(s) of the team understands what is being delivered.  How do we ensure that everyone is on the same page, when each of the Levels has very different interest or focus within the solution?

Before you jump to the conclusion: “well you just write a document at each level” – consider this: if each of the various team members wrote a document – who is the target audience of that document?  Essentially it is the Level below them in the chain.   If you’ve ever played the game Chinese Whispers, the more times someone passes what they heard to someone else etc; by the time it gets back around to the originator of the message, it generally sounds like something else.

You might then argue that: “we’re writing and not speaking; and we’re reading and not listening; therefore the above statement is mute”.  However, you can describe the above in terms of translation; each team Level reads the document passed down to them, and translates it into a document targeted for the Level below them.  Each translation changes the original description to the point that when it is presented back, it generally sounds like something else… sound familiar.

Example: I want something that has four wheels; a steering wheel; a seat; an engine; uses petrol… and they were describing a lawn mower. 

Example: There’s a similar one about the radio/iPod etc.  What’s this got to do with the Business Process Solution?

Back on point, how do we currently document business process?  There’s quite a number of ways – BMPN (Business Process Management Notation) diagrams; swim lane diagrams using software such as Visio; UML diagrams…. These are great for the Business Analyst to describe to the Solution and/or Technical Architects; but what about to: the Business User; or the CIO; or the Project Manager.  They don’t really care about interpreting the curved edge activity with an arrowed line adjoining it.

Information Architects might throw in a data flow diagram or something similar; Solution Architects will draw a type of technology stack diagram depicting the communication boundaries of each layer; and so on. 

How do we ensure that all these documents are being interpreted the same way?  Solving this question will go a long way in making a successful Business Process Solution.  An abstracted document containing parts of each Level within it would be a pointless exercise – no one would read it.  Pictures speak a thousand words, but just looking at a picture can leave too much to the imagination – does a picture of the Eiffel Tower let you know I’m talking about: amazing constructions; France; or Holiday Tours?  Maybe I was talking about screen resolution and the Eiffel Tower itself actually didn’t mean anything at all.

The answer I give to this problem, which I find works very well for Business Process Solutions, is: Story Boards.  Often a technique used for Web Sites and User Interface designs, this works well for Business Process as well.  

They can then be translated well into UML diagrams; they can describe a technology stack; they can describe the Actors (or end users); It can describe where the Return of Investment is, by highlighting key areas of improvement from the old process to the new process; It can highlight gaps where a new implementation has to be created and where we are piggy backing on legacy systems;  they can show how the data moves from one system to another and which user(s) are in control of that data; User stories and use cases are also a natural progression from here; most importantly, they can grow and shrink throughout the lifecycle of the project.

How?

How do we use the story board to do this?

Return of Investment:

Draw the current story and start colour coding the border of each story board can quickly show or highlight key stories that show how the process has improved.  Red, green, amber.  Red for things that are creating bottlenecks in the process; green for things we’ve improved or added to reduce the process, and amber for the status quo.

Then draw the new story and walk through this process in the same fashion highlighting again where the value-add is.  Before versus after images paint a very clear image to the key stakeholders of how and where they are going to see the improvements.  Even if they don’t go any further than this in the project, this still gives them value.  It shows where they are being inefficient, and how they can streamline their processes, if not now, in the future.

Budget/Time:

This goes to the core of the project and interests both the PM and the Stakeholders of the project.  When will this be delivered, and how much will it cost.  By highlighting very clearly and distinctly where the changes are occurring, we can then focus our attention on these types of matters.  Lots of green story boards would represent a lot of change, which in theory could represent lots of work.  Therefore more resources, budget and time required.

Content and Structures:

Defining the structure and the content of the story is key.  If we think about it in terms of a movie, the Information Architect would be providing the words coming out of the Actors mouth.  Or, in the case of a Business Process Solution, the information flowing from: the system; to the end user (or Actor); and back.  The story boards can move from an image of the Help Desk Actor staring at his computer as a new message comes in; and the next image can be the message itself as we imagine the Help Desk Actor reading it.

Technologies:

The Solution Architect can then provide the background descriptions on the Story Board, describing which technology the Help Desk Actor is using to see the message coming in: SharePoint 2010 through a K2 Worklist WebPart; and in the next image, using Outlook to open the email.

Tasks:

The Technical Architect can then provide the notes at the bottom of the Story Board describing the type of development or change needed to implement the technologies described in the story.

With all this, we can then walk both the Key Stakeholders and the general Business Users affected by the new process definition; and describe this in a simple and clear way.  It is at a level of abstract enough that it cuts through each of the levels of the Project Team.  They can then go and create their normal documents, but they can now do it with a common understanding of what they are describing; the person reading the document can then review it with a common understanding of what they are reading.  When you have a story that combines the picture with the description, it becomes a very powerful tool.  Handing this project over to the Change Management Team or a new Project Team member is also made simpler.  They don’t have to read streams of documents across the Levels, just read the before and after story boards and they are up to speed.

The Business User, who just wants what they asked for, well they still might not get it.  Budget, time, scope, resources and technologies will all contribute to them having to forgo something.  But chances are the project will go smoother, and if the communication lines are direct and often enough between the Technical Team and the Business Team, then they at least won’t be disappointed.  Henry Ford once said, “If I had asked people what they wanted, they would have said faster horses”… hopefully by documenting in this way before starting development, you’ll be able to deliver the car, and not another type of horse.

How to setup the Story Board:

I won’t go into the “before” story as this can be done in a similar way, this will just go through the “after” story.  The technology you use to present the story is completely up to you.  PowerPoint is a simple way, but you may have other tools that will do something better.

Actors: Start with the Key Actors… Just like they do in the movies, we do here.  Start with the Actors that this Story is mainly about.  If it’s across the organisation, then start with the big named ones.

Starring:

·         Human Resources;

·         Help Desk;

·         Middle Management; with 
·         Asset Management; and 
·         New Employee; 

Project Title: Give the Project a name if it doesn’t already have one. 

Presents:

·         The On Boarding Process

Story Board One: Give each story board a name.  This is something that can be used as a reference point from here on in.

          The Initiation:

·         Border Colour: Amber

·         Boxed Caption: Commencing the On Boarding Process through SAP system;

·         Picture: Two people shaking hands in an office;

·         Talk Caption: Person on the right: Congrats Bill, you’re hired for the position of Analyst, and will report to Joseph on Monday.

·         Notes Caption: Person’s name; position; manager; start date; SAP HR Form; Office access area; induction material;

Story Board Two:

           Initiation Form Details

·         Border Colour: Amber

·         Boxed Caption: SAP HR Form; SAP Database;

·         Picture: Wireframe of a SAP system Form with the fields to fill out being:

o   Person’s name: Bill Bilson;

o   Position: Analyst;

o   Start Date: Monday, 1^st February 2026;

o   Manager: Joseph Johnson;

o   Office Access Area: Level 1, Desk 286;

·         Talk Caption: Human Resources filling out SAP HR Form raised through Portal;

·         Notes Caption: SAP Form Details; Data stored in SAP;

Story Board Three:

Birth of Bill Bilson

·         Border Colour: Green;

·         Boxed Caption: SAP Database; K2 Workflow Process;

·         Picture: Database Server Cluster showing the SAP Database(s); typical K2 View Flow diagram depicting a workflow process.

·         Talk Caption: SAP informs the On Boarding Workflow Process to begin by passing the UserID for Bill.

·         Notes Caption: SAP Database; K2 Connect Event occurs; K2 Workflow process launch; User ID and Process ID captured and stored; K2 SmartObject storing these details;

Story Board Four:

Notify Help Desk

·         Border Colour: Green

·         Boxed Caption: K2 Worklist Task;

·         Picture: Help Desk Office with a group of users sitting at their desks, looking at their computers.

·         Talk Caption: I have a new task to do today; Looks like Bill Bilson needs a new Network Account created.

·         Notes Caption: Active Directory account creation; Email account creation; added to appropriate AD groups and Distribution Lists based on his role and position;

Story Board Five:

Create the Account

·         Border Colour: Red;

·         Boxed Caption: Add user to Active Directory; Add user to Exchange; Add users to AD Groups; Add user to Network Drives and other key source systems;

·         Picture: Four different source system data input screens; Source System (SS) 1 in top left, SS2 in top right; SS3 in bottom left; SS4 in bottom right: Ie.  |+|

·         Talk Caption: I need his: name, position; office location; and his manager to create this person in our systems;

·         Notes: Manual step that the Help Desk Person does; Closes the K2 Worklist Task once completed;

Story Board Six:

           Get some Hardware

·         Border Colour: Green

·         Boxed Caption: K2 Workflow Process; Asset Management Process;

·         Picture: Person dressed in blue overalls and yellow hat, picking up a box in a warehouse style Store Room filled with boxes and levels;

·         Talk Caption: Looks like I have an order for: a laptop (#236A); mouse (#237A); monitor (#238A); mobile phone (#987Z); IP Phone (#986Z) for User ID: #23;

·         Notes: Email notification sent to Asset Management Team; Assigns User ID to Hardware Asset Number through system integration;

… and so on…

I hope this is enough information to get the point across.  We can quickly see here where we are improving the system (through the Green slides: #3; #4; and #6); where we are continuing on with the current system (Amber – and we can look at ways to improve: #1; and #2); where we aren’t really providing anything that will improve the system, and at the same time potentially causing a bottle neck (Red Slides: #5).

Let’s look a little closely then at slide 5.  Certainly this would draw attention at the meeting room and would require further explanation.  Why is this slide Red? 

It’s the colour Red because it is manual.  It currently requires the Help Desk person to read the information coming from one system, and type it into another system(s).  There’s risk that they neglect to add the user to any one of the other source system cause Bill Bilson to come into work on Monday and not be productive.  It’s also Red because the information has already been collected and entered into a source system – SAP.  So why should we need to enter it manually into other source systems at all from that point onwards?  There would surely be valid answers to these types of questions: lack of resources available to extract information from SAP and auto-generate an AD Account or a DMS Account or to a specific location(s) in the Portal etc.     

We highlight it Red so that we know that this is an area that we can improve upon in the future.  It becomes something that everyone can quickly see and understand.  It can be a way of highlighting how the process did something similar at the Asset Management step, to show that it is possible.  How we’ve sync’d the data from SAP through the Workflow down to the source system and commenced the process of getting the user: Bill, set up for Monday with everything he needs; whilst also enabling the Asset Manager to see that User ID #23 has assets: #236A; #237A; #238A; #987Z; and #986Z; with the only human step being to physically deliver the hardware.

You might need more story boards, you might need less, but what this gives you is that distinguishable story that everyone across the various levels can understand and discuss.  From the very technical to the complete opposite of very technical… you still need the: Design Doc; Tech Spec; User Stories; Use Cases; Test Cases; and head cases to make it work.  For me, the story board exercise in a Business Process Solution is the missing link, and needs to start being the consistent link.

Post Go-Live Strategy

What happens after you have completed the application lifecycle of a Business Process and implemented the solution?

You’ve launched the workflow and the organisation have signed off and gone live with your masterpiece.  It’s a work of art.  You couldn’t be happier.  The Business Analysis Team was switched on; your key users were involved throughout the lifecycle; the stakeholders are counting how much money they’ll save with this magnificent piece of work you have created.

What’s your next move?  Is it to go on to the next project?  Have you thought about your post Go-Live strategy?  If you’re not following me yet, then we’re probably not as good as we were looking in the above paragraph.  If you are following me and you think you’re still moving on to the next project straight after, then we’re still not looking as good as we were in the above paragraph. 

If you’re next move was to implement any of the following: 

• a “Continuous Improvement Register”– something that will enable users to add “nice to haves”, “should haves”, “must haves” for your process;
• a support strategy – known issues list of what typically might go wrong with your process and how to quickly resolve it; which will be maintained by the support team;
• a maintenance strategy – a way for the owner of the application to see both the Continuous Improvement and Known Issues list that will enable them to see how they can ensure that the business adapts to the process, and that the process can adapt to the business.

These things are critical to the overall success of the application.  You’ve just put all your blood, sweat and tears into a Business Process, the last thing you’d want to see is that in six months’ time, the business has outgrown your process.  They are critical strategies; there should be no doubt about it.  Yet it doesn’t seem to be obvious to everyone in the projects that I’m involved in.  It seems to follow me around, this constant discussion and/or battle that these things should also be part of the application lifecycle planning and budget.

This goes beyond just your usual: Quick Reference Guides; user training; and handover notes or walk throughs.   Businesses change how they do things constantly.  With every change in personnel, or systems or the policies that organisations put in place, your Business Process Model needs to change with it.  The only way it can do that is to constantly capture these changes.  Encourage users and support teams to capture (or capture it for them) these and then react to the change.

Even a great process will still have a limited shelf life.  It might be three months, it might be a year, it might be longer, but it will eventually become out-dated.  If it doesn’t, you’re either not looking, or the users have worked out ways to “get around” the limitations of your once perfect process.  All of a sudden, those pretty pennies that the stakeholders thought they had saved have now turned into pieces of paper with “IOU” written on them. 

Application Lifecycle: gather requirements; specify functionality; design solution; build solution; accept solution; implement solution; strategy to support solution; strategy to maintain solution;

Let’s stop the battle, let’s all just agree with me on this, that the process isn’t complete after Go-Live.  The process grows (more integration with systems, more automation, more data capture, more reporting capabilities) and shrinks (less approval steps, less human validation steps, less bottle necks) with the business.  Let’s start planning in our projects that this is a key element that needs time and budget.  It’s not tacked on to the existing budget; it’s carefully and strategically placed as part of the budget.   Whilst you, the K2 Expert, won’t have to be there to support or to necessarily maintain the process, the strategy for both should be part of your responsibilities. 

The planning of these strategies occurs at the design and doesn’t stop… ever.  So start asking the questions: how do we support it; how do we maintain it; how do we ensure its longevity?  If these are taken seriously at the start of the project, then your Business Process Model will remain as perfect as it was when you first released it into the wild, otherwise... I’m all talked out about otherwise…

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.