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.
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.
No comments:
Post a Comment