- Workflow Challenges
- Translating the Business Flow into an Application
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Translating the Business Flow into an Application
You now have an understanding of your business process in the back office. It meets most of the requirements as to why we would choose this as a perfect Management layer solution. Your next challenge is to translate the business flow into an application to support and improve upon this process. Before we begin to analyze it and break it down into a more automated solution, let's make some assumptions about the project approach.
Workflow Application Assumptions
The following are assumptions to determine how the DuvalShock requirements will be delivered in a workflow application:
The workflow application will be built using a web interface. We need to keep in mind the limitations of the web as we design our application.
DuvalShock uses Microsoft's Active Directory as the standard for intranet, extranet, Internet, and desktop authentication. Users and groups already exist in this repository. We will be expected to build our solution toward this security model.
Understanding the development limitations of web technologies, the interface needs to be simple with little or no business training necessary to manage content.
Of these assumptions, the most important to understand is the challenges the web technologies present us. These challenges clash considerably with our desire to make the application easy to use, dynamic, and client rich, which is similar to traditional Client-Server applications that are written for a Microsoft Windows operating system. The web is stateless in nature, so a request-response model is dealt with in creative and not-so creative ways. Developers continually try to meet this challenge by extending web languages to their limits and sacrificing browser compatibility and performance of an application to get the most out of a better user experience.
If you have worked on a web application before, you most likely have been asked in the requirements to make your application perform a task that is not quite possible. The developer will come out with options for how to meet this requirement, but in all cases, the requirement needs endless explanation to your business group and many hours of a developer's time to meet expectations somewhere in the middle. Building a workflow application has many of these challenges. It will be tempting to try technologies like ActiveX Controls or Java Applets through a browser; ultimately, however, you will run into security, performance, and web browser compatibility issues. This is why most development teams have chosen to stick to simpler methods to build their web applications. This is also why building complex applications can be so difficult for the web.
Creating the Workflow Solution
With a basic understanding of the roles of an automated workflow and of the current business process for the content that needs to be managed, let's look at how this can be pieced together to create a workflow solution. Refer back to Chapter 1, "Overview of Dynamic Publishing," to refresh your memory of the elements that need to be managed on the DuvalShock web site. The content management process on the business end will compliment the publishing rules and user experience process on the company web site.
After reviewing this section, look at Figure 13.3. By using the Basic Workflow model earlier in this chapter, we expanded the requirements out to meet the business process.
){kind=link}
Figure 13.3 Example of a creation and approval process for DuvalShock marketing development.
Relating back to the business process earlier in this chapter, at this point we step through the illustration as a workflow application. Next, we describe the roles and authority of an automated workflow application.
Note
These are just some of the workflow application components that can be introduced. The possibilities are unlimited to meet the business processes that your organization follows. The goal is to simplify the business process when building this solution. When stepping through what a business unit goes through to create, approve, and publish content, you should be able to go back and compare your application design and show improvements to the process. You should be able to quantify where you are saving time, resources and cost by eliminating or streamlining certain manual tasks that took place. The requirements and design need to be well thought out before development begins. The architecture of the application should be considered for growth and change as additional requirements and business processes evolve.
Marketing Manager
In our workflow application, the marketing manager initiates a task requesting that his employee begin to create a product description for the Big Spark 200 Generator. After this is initiated, an automated task sends an email to the employee with a link to the task.
Creator or Author
The marketing employee receives the request and begins to create the content. If you built a feed from another digital asset into your content repository, you might have some of your content to work with to complete this task. The employee steps through a process of screens that ask for items such as title, date, and body description. You can also build in other items, such as metadata tagging and the target audience. In addition, you can provide tools like a word processing editor to format the content through this process, or you can require that a standard font size or style be used when the content is entered at this point. A WYSIWYG word processing HTML editor that includes features like spell checking can be an important piece of your workflow application. When this task is complete, the author submits the content into the repository for publishing approval.
Approver
In Figure 13.3, the requirements show that the marketing manager receives the completed task from the marketing employee. The role of the approver is to read over the content that is created for the new marketing news that needs to be released. If the approver decides the content is not complete or needs other changes, he can reject the content request and send it back to the author with information related to why it was not approved. If it is not approved at this point, it could be published to production or passed on to additional levels of approval.
Legal Approver
In this example, the requirements ask for additional sign off from the DuvalShocks legal department. This task can have the same characteristics as the marketing manager's approval. There is a key difference after the legal department approves the content. The end of this task is the final step before the content repository marks it staged for publishing.
Publisher
After the final approval occurs, the last task in this automated workflow is to publish the content to the DuvalShock web site. For the end user, this should be as easy as clicking a Submit button and having the content publish to the web site in the predefined format that is defined in the publishing requirements. Chapter 19, "Basics of Publishing," explains the publishing elements in detail as the next logical layer.
Increasing Efficiency and Accountability
We described the core components of an automated workflow, but now let's look at the other elements of your application that can assist in better business efficiency and accountability. The following components can add valuable functionality to your workflow application.
Authentication and Roles
Before you can enter a workflow application, you need to have a user login with an ID and password. Ultimately, they should authenticate against your organization's strategic user repository. By doing this, you have an opportunity to reuse groups that are already created for certain departments and granular roles that exist within the organization. Personalizing the workflow application becomes possible if a role is only allowed to manage certain categories in your web site. If your web infrastructure is mostly Microsoft IIS web servers, you are most likely going to be using an NT domain or Active Directory. Web infrastructures that use UNIX predominately go with a more open LDAP solution.
Integration with your organization's email is a powerful facilitation and communication tool to assist the business process. It can be an automated event that can occur at certain points of the workflow. For example, if the marketing employee has completed a content contribution, an email event can send a message to the marketing manager notifying that a task is complete. In the email, can be a full description of the task along with a hyperlink to the content description that needs approval.
To take it a step further, if the task to approve or deny is not executed, then another email can be triggered to the marketing manager as a reminder that the task is still waiting for his action. Email can also be handy for senior executives who have read-only full-task descriptions and deny or approve important pieces of content via wireless devices.
Overuse of email can also be detrimental to your workflow application. Triggering emails at strategic points of a process ensures users that receiving an email from the workflow application is an important one and needs to be attended to.
Audit Tracking
Another feature that your internal audit or compliance unit might require in your workflow application is an audit tracking feature. This can be a utility that tracks completed tasks, dates completed, rollbacks, and, of course, which user is changing, deleting, editing, and approving content published to your web site. It can be a powerful reporting utility for a company that is concerned about the management activity of its web site.
Entry of Metadata, Keywords, and Categories
During the workflow, it is critical that the content being created is identified accurately and consistently. The workflow process can step a user through choosing the correct keywords for the category he is providing content for. Refer back to Figure 4.3 from Chapter 4.
The marketing employee can begin by choosing a category for which to edit content. In our business requirement case, the user might step through a screen flow to be certain that the category "Products" and the subcategory "Generators" is where the new keyword "Big Spark 200" is created. By forcing the user down a path on how and where the new content is created, you have ensured that the new content is located in the accurate taxonomy for proper searching and navigation.
Authoring of Content
Several options are available when a user needs to create or edit a content for font size, italic, bold, indenting, and so on. If you're creating a new keyword heading, or title that you can reuse in navigation, a page title, or a heading, you might not allow for full authoring capabilities and just provide a simple text box to enter the keyword "Big Spark 200." The body of text that describes the generator might have requirements to have full authoring capabilities.
Full authoring solutions in browsers allow for HTML and XHTML editing with most of the capabilities of a typical word processing interface. After a user completes editing using the tool, the content is submitted to the repository with the formatting intended for publishing to the web site.
Task Status
A business manager might request that he be able to view the status of content that is being created. As each task is completed, the status screen can show information like this:
Date task assigned
Date task completed
User assigned for creating, editing, or approving a task
Overall workflow status
User comments field
Of course, task status should not be limited to just business managers. Occasionally, some components of a status will be available for all audience levels in your workflow application.