The evolution from traditional application development to workflow and business process management (BPM) resulted in a much more human-aware application design. Toward the end of this chapter we take a look at the next step in the evolution, setting the stage to get a clear vision of what that application is and how we can refer to it.
In this chapter, we cover the following topics:
Defining BPM
Common failures of traditional applications
Defining a new type of application
Approaching process design
Process-driven application examples
You might have a good idea of how workflow and BPM are related, but we haven't defined yet what BPM means. According to the article "ABC: An Introduction to business process management (BPM)"[3] published CIO.com:
BPM is a systematic approach to improving a company's business processes. For example, a BPM application could monitor receiving systems for missing items, or walk an employee through steps to troubleshoot why an order did not arrive. It is the first technology that fosters ongoing collaboration between IT and business users to jointly build applications that effectively integrate people, process and information.
BPM gives an organization the ability to define, execute, manage, and refine processes that:
Involve human interaction, such as placing orders
Work with multiple applications
Handle dynamic process rules and changes, not just simple, static flows (think tasks with multiple choices and contingencies)
Important components include process modeling (a graphical depiction of a process that becomes part of the application and governs how the business process performs when you run the application) and Web and systems integration technologies, which include displaying and retrieving data via a Web browser and which enable you to orchestrate the necessary people and legacy applications into your processes. Another important component is what's been termed business activity monitoring, which gives reports on exactly how (and how well) the business processes and flow are working.
Optimizing processes that involve people and dynamic change has been difficult historically. One barrier to optimization has been the lack of visibility and ownership for processes that span functional departments or business units. In addition, the business often changes faster than IT can update applications that the business relies on to do its work, thus stifling innovation, growth, performance, and so on.
Alluded to in the brief history of enterprise application development in the first chapter, the struggle between the business and IT causes friction that, in the modern business environment, is counterproductive, potentially harmful, and unnecessary.
By adhering to an outdated method of application development, companies will find themselves involved in the same struggle that leads to common problems with traditional applications as outlined in the following table:
Problem | Description |
|---|---|
Inflexibility | When the business changes, the representation of the business must be changed in the application. Rules, processes, roles, and logic that are hardcoded into the application require a lot of effort to alter and redeploy. This long turnaround time makes the business less agile in responding to changes. |
Lack of visibility | Reporting, tracking, and auditing are often afterthoughts for traditional applications. These things are seen as a "nice to have" feature for the next version. In a process-based application these items are critical for seeing how the business is doing and making good decisions. |
Traditional applications are often departmental in nature, limiting the scope of the application to a subset of the company's users. Furthermore, active collaboration among departments, from design to deployment to the production use of the application, is not possible because the toolsets for each department are different. | |
External partners not involved | The application and sometimes the infrastructure are unable to handle variability when it comes to involving those outside of the firewall. |
Business forced to adapt to the application | Many applications, either built or purchased, require the business to adapt to the application, not the other way around. For some industries this is acceptable, but for most industries an application that can incorporate industry-specific data, methods, and context is more likely to be successfully deployed and to increase the efficiency of the business. |
BPM is a methodology for improving application development that allows for rapid business change and crosses functional boundaries. But not all BPM strategies and software suites are the same, and they cannot be compared across feature sets or product capabilities. In contrast to traditional application development, following a strict "workflow" or "BPM" strategy may be difficult for companies that don't have a process management team. Some common mistakes that companies find when trying to introduce BPM to the organization are:
Trying to do all departments and all processes at once: It is better to start small and identify those areas of the business that are most critical to the functioning of the business. Then, start with one complex process or a handful of smaller processes.
Getting lost in the implementation phase: There is sometimes a complex mix of systems, departments, internal and external customers, and data requirements for processes. Following a strict BPM method may prove too time-consuming and ultimately end with a failed project.
User revolt: Many times, if the interface of the business application is too difficult to use, if it doesn't save people time, or if it interferes with a user's actual job, the system will not be used. Users will find ways to short-circuit the application or process, using backchannels to get their work done. Since Return on Investment (ROI) is in many respects based on an application's adoption rate, this can have a drastic effect on the business value an application brings.
K2 blackpearl, while not a panacea for all BPM implementation problems, allows for rapid application development by both business users who understand their work and more technical users who can solve some of the data and process problems that may exist when integrating data from other systems into a single user interface. Calling K2 blackpearl a BPM platform, while accurate in many ways, does not illustrate the full power of the platform for delivering business applications. K2 blackpearl is a different type of platform for quickly assembling business applications that people will use. Furthermore, the business applications that you can design with K2 blackpearl may not have any processes associated with them, or may have processes that are only instantiated when certain conditions are met. These types of business applications would use the K2 platform to aggregate information from line-of-business (LOB) systems and present a user interface that allows for easy data aggregation, retrieval, and updating. If processes such as escalations or management approval were required, the user could launch a process to handle that aspect of the application. These types of applications are sometimes referred to as composite applications and bear resemblance to Web 2.0 and mash-up applications.
Whatever the type of business application, developing them with K2 blackpearl is advantageous for a number of reasons, including:
The business is involved: When the business is involved in the design and testing of the application, the user interface (that is, forms and reports) can be designed in a way that the users of the application will be comfortable with and actually use. This, combined with the next point, solves two of the problems of traditional applications discussed earlier.
IT is involved: IT can use the features of the platform to bring together disparate systems through Web services and the built-in SmartObject Services data layer; the entire process builds upon the existing investments but is modeled at the business level rather than being limited at the technology level. For more information about SmartObjects, see Chapter 7. Active collaboration between the business and IT results in a better application that is tailored to the business. The business can draw their process in Visio or K2 Studio and hand that project over to IT, who can then extend it in Visual Studio. For more information about how this collaboration works, see Chapter 14.
Processes can be rapidly built and deployed: Processes that don't require a lot of design and collaboration between business and technical users can be quickly put into production use. Even those that require a lot of collaboration are much faster to develop than traditional applications. The platform and the infrastructure on which it operates enable an incremental approach for process-driven applications to enter production.
Maintaining the process is simplified: When business rules change, the process needs to account for those changes. Processes designed with K2 blackpearl can be very dynamic, but sometimes the process design must be updated and redeployed. Often this type of change can be handled by the business without the need to involve IT.
Subsequent chapters will discuss process design best practices, including how K2 blackpearl enables collaborative design (see Chapter 14), how processes can integrate with enterprise systems through SmartObjects (see Chapter 7), and how to design very flexible processes that are easy to maintain and actually get used in the day-to-day operations of the business. You will also learn much more about the K2 blackpearl platform and how to take advantage of it to make your business more successful. But the key points to be made here are that your K2 blackpearl application design should:
Not be stifled by traditional application development approaches or by adhering to a strict BPM-based approach. While using BPM methodologies is very important, if an aspect of BPM does not fit with your business application, ask yourself "Can I safely ignore this point?" If the answer is "Yes," continue on with more important aspects of the project.
Have business ownership. A successful project almost always has executive level sponsorship if not outright ownership.
Not underestimate the time it will take to gather business requirements. Often identifying key players, data, and metrics is more time-consuming than actually building and deploying the process.
Be made up of a cross-functional team and builds high-value applications quickly. These applications should be designed to provide immediate value and possibly tie in to corporate goals and current strategies. Once people from all levels in your company see the value this new type of business application provides, they will want more and more process-driven applications identified, built, and deployed.
So what is this type of application?
This new type of application has many names and is supported by evolutions in the underlying information systems. Referred to by some as a dynamic business application, by others as a process or process-driven application, and by still others as a business process solution, this type of business application combines aspects of a traditional BPM solution with a collaborative, multidisciplinary implementation team that can work toward a common goal. Many technologies and methodologies have given rise to this type of application. All of these methodologies identify the need to discover, optimize, and improve complex business processes. These include Business Process Reengineering (BPR), Business Process Discovery (BPD), Process Driven Development (PDD), and Workflow Management (WFM). Though these methodologies are beyond the scope of this book, there are many resources available online for learning about them.
Technologies that support these methods include generic and well-understood architectures such as Web services, Extensible Markup Language (XML), Service-Oriented Architecture (SOA) and Enterprise Application Integration (EAI), as well as the more specific terms such as Process Aware Information Systems (PAIS). PAIS is defined as a "software system that manages and executes the operational processes involving people, application, and/or information sources on the basis of process models."[4] Microsoft defines the evolution and state of a business's infrastructure in their Business Productivity Infrastructure Optimization (BPIO) campaign.[5] The following table illustrates the evolution of a Microsoft-based infrastructure and how K2 blackpearl fits in:
BPIO Model | Basic | Standardized | Rationalized | Dynamic |
|---|---|---|---|---|
Business application capability | Document Routing | Workflow | BPM | Process-Driven Applications |
Microsoft products | Windows SharePoint Services (WSS) v3 | WSS/Microsoft Office SharePoint Server (MOSS) 2007 Visio | WSS/MOSS Visio InfoPath | WSS/MOSS Visio InfoPath OCS BizTalk SQL BI PerformancePoint |
K2 products | K2 blackpoint | K2 blackpoint K2 blackpearl | K2 blackpearl | K2 blackpearl K2 connect |
The Dynamic column represents a process-oriented, flexible infrastructure that can adapt to a changing business environment. Yet, according to Microsoft, most companies are at the Basic or Standardized level.
According to Forrester,[6] a dynamic business application is:
A software system that embodies a business process
Built for change
Adaptable to business context
Information-rich
These applications are built for rapid modification and extension, to change as the business rules change. The processes adapt their behavior to respond to variable conditions, and contextualize information and processes for people. These processes may be short-lived, ad hoc tools as the situation demands.
There are two key requirements of dynamic business applications:
Design for people: The application should be dynamic and developed by business people and IT together, with appropriate contextualization of information and tasks. The application interface is designed for the work, not dictated by application boundaries or a strict adherence to an interface standard.
Build for change: The application must be able to evolve at a pace designed to match the business change, with flexible points built into the structure of the design.
Building a dynamic business application requires that the business users and the IT department work together to design the application. Because this collaboration crosses organizational boundaries, the team dynamics can be challenging. However, the K2 platform provides different design experiences for different types of people with varying technical skills. The platform is designed with collaboration as a key value point, and every K2 Designer generates the same underlying project structure to facilitate collaboration and reuse of design work.
Some organizations have fairly rigid standards for building and deploying business applications. It does not matter whether you mandate that IT must be responsible for all software builds and changes or you allow other people in the business to actively participate. K2 blackpearl is designed to handle these scenarios and all variations in between. The next sections take a closer look at the scenarios.
IT teams can design, build, and deploy dynamic business applications within the context of a team. K2 includes libraries for sharing environmental information and items within the K2 design environments. Developers can also version code and deploy the solution through multiple development and production environments.
IT deploys the K2 server environment and set of core items that can be shared and used by the business to create solutions. The solutions created may include some business-user-defined logic (built with wizards and browser-based tools) but also require some customization available only with developer tools (K2 Designer for Visual Studio). IT may also require that its own staff manages quality assurance (QA) and deployment for the organization. Reports can be designed and deployed by either the business users or IT.
IT provides the business users with a set of tools that they can use to model what they need. For example, business users can leverage Visio to model a business process or write policies in common language. IT has the ability to leverage these designs and quickly bring them to life by consuming them within K2 Designer for Visual Studio, extending the applications and then managing the QA and deployment process. IT can deliver a standard set of reports that allows for some personalization.
IT deploys the K2 server environment and a set of core items that can be shared and used by the business to create solutions. For example, the IT team may create reusable wizards, business entities, and policies for use by all business users. A business user could then design, deploy, modify, and report on a process-driven application that leverages these items through Visio or a browser-based designer without any IT involvement.
Regardless of the physical makeup of the team building it, who ultimately maintains it, or which department drives the adoption of process-based applications within the company, a successful process-based application is different from a traditional application. Other chapters (including Chapters 3 and 8) include more specific details about how to successfully design process-based applications, but at a high level they include the following aspects:
Pursue an incremental adoption. Each initiative is focused on a specific goal that provides value to the business. Don't try to automate everything right away. Start with one department and a few processes that can show immediate value. Not being able to show some tangible value from the first few process-driven applications that you create, while unlikely, does not help users of the application or decision makers have faith in the platform.
Give people tools and applications they already know. Making people who are designing and using process-driven applications use a different toolset than they normally use will make them uncomfortable. This will dramatically slow adoption of process-driven applications. A slow adoption means that the first point will be more difficult to achieve.
Leverage the platform you already have. Many companies already have an infrastructure that enables process-based applications to thrive. Some companies may have to increase some of the infrastructure's capabilities with some custom development or product purchases. However, if your company uses a Microsoft-based platform and has enterprise licenses, most of the capability should already be in place to deploy K2 blackpearl.
Make the application easy to use and relevant to the people using it. Design the application from the user's perspective. Contextualize information and business data as it relates to each task in the process. This aspect of a successful process-driven application is enhanced by the two previous points, that is, integrating task-based information in the environment and applications people already know that leverage your existing systems. Users will require less training and recognize how the application makes it easier for them to get their job done.
These aspects of a successful process-driven application make sense from business investment (ROI) and user adoption perspectives. They are interrelated and build on each other, and once you internalize a successful approach to process-driven application design, you may start accepting these as common sense. From a historical perspective this approach to application design might seem unattainable or even a bit nonsensical. But given the Web 2.0, the growing technical skills of the average employee, and the state of the typical infrastructure in a company today, this dynamic approach to application design is achievable.
Two examples of real-world scenarios can illustrate the power of this dynamic approach to application design. Both of these scenarios have a few things in common, namely:
A Fortune 500 company found itself navigating the Sarbanes-Oxley compliance waters around IT User Access and Provisioning. This included creating new accounts for contractors and employees and granting access to the various applications and systems that were used within the company.
The first attempt was a quick-and-dirty, one-page Word document where end users were required to fill out cryptic fields, get the document signed by their manager and whoever was responsible for the application, then put it in an inbox next to the IT secretary's desk. Someone on the IT Help Desk staff would check the box when they remembered and then grant the access, if they could read the form. Requests for new accounts generally took 3–5 business days. The onus was put back on the business to request access well ahead of the time when they would actually need the access, which with new employees was generally set by a start date. But for contractors, this was always difficult and usually ended up with the contractor being on-site, billing the company for hours wasted while waiting for IT access to be granted.
The second attempt was the first attempt at automation and just involved adding a fax number to the equation. Now, users could fax the filled-out request to the number, which would send the electronic copy to the inboxes of the IT Help Desk staff. This was marginally better, as there wasn't a reliance on checking a physical inbox for forms.
However, both of these attempts failed miserably when it came to the IT audit. Once a quarter, Internal Audit would come through and demand to see the stacks of forms and would ask IT to cross-reference them against a list of new employees. Digging through stacks of forms and file cabinets and people's desks took up to 2 weeks of the Help Desk's time, adding further delay to the backlog of IT access requests.
The company decided to automate the process using K2. Over the period of 6 months, a team came together to define the process and the actors. A list of all the applications, roles, and the information owners was collected for the corporate office. This was the first time that all of the data was collected into a single source of "the truth." The act of defining the approvers and roles for each application was a huge boost to the IT staff, as before they had to track down someone to sign an application, and they were never sure who to ask in the first place. Once that list of applications, roles, and approvers was in a single place, the process was automated rather quickly. Using SharePoint lists to store the data, IT used InfoPath forms to surface the list of applications and roles for the end user to select from. A Web service allowed tight integration with Active Directory and allowed new accounts to be created, complete with Exchange mailboxes and access to certain default distribution lists and groups. For application access, if membership in an Active Directory group was all that was required, upon approval the access was granted immediately, with no human interaction required. If the system had other authorization mechanisms built into the software, the fully approved request was sent to the system administrator to be fulfilled. After the request was fulfilled, it was archived in a document library in SharePoint.
Towards the end of the project, lunch and learns were held with the staff members to describe the new process and forms. Each session ended with a standing ovation. After the forms and workflow were rolled out, department secretaries could go back to doing their regular job and didn't have to fight with IT access forms. New accounts were created in 20 minutes after approval. Access to many systems was almost immediate. Because all requests were stored electronically, when Internal Audit came through it was a matter of minutes to pull a report and print out the evidence they requested. No forms were misplaced, and no form was approved by the wrong person. Bottlenecks were identified for those requests that took a long time to get approval, and adjustments were made to ease the burden on the business owners.
A global manufacturing organization had three main needs:
Document Management: They needed a single place to store and manage documents. They were trying to move away from network file shares.
Workflow: They needed a workflow system that would tightly integrate with the document management system to allow for true document-centric workflow. The ability to control access to documents at various steps in the approval process was also a requirement. They needed a system that was flexible enough to integrate with existing LOB systems, including custom and off-the-shelf systems like SAP.
Dashboards: IT needed a way to build meaningful reports against information in various systems to surface to management. The current system was comprised of paper-based wall charts that engineers manually updated using a pen.
They needed to start a design review process from an existing in-house application. The data collected during the review process had to be uploaded to SAP upon completion of the review. They also needed to surface reports that combined LOB data from SAP with data about the workflow, including metrics collected on the workflow itself. The current review process was manual, so the opportunity for gaining efficiency was great.
They spent a significant amount of time and money attempting to develop this solution with a different product. However they were not able to seamlessly integrate the various workflow, user interface (UI), reporting, and SAP pieces in a timely manner.
The development of the process-driven application lasted a total of 2 weeks. In this timeframe, K2 blackpearl and K2 connect were installed. K2 connect SmartObjects were developed against the appropriate SAP function modules. The workflow and an InfoPath form were created to interact with the process and the LOB data. Finally reports were created to display the SAP and K2 workflow data within a SharePoint dashboard.
Forrester summarizes in the report cited earlier that dynamic business applications "can provide much more productive experiences for businesspeople, make breakthroughs in the automation of decisions and business processes, and provide the points of flex that businesses need. Our applications don't do this today. Our businesses need them to."
The evolution of the business application, by whatever name, is the next step for companies. There are many advantages to this approach. The next chapter provides a high-level overview of identifying processes in your company, a framework for thinking about the various pieces of the process, and some best practice guidance on how to put a project team together.
[3] "ABC: An Introduction to Business Process Management (BPM)" by Mark Cooper and Paul Patterson. CIO.com, 2007. www.cio.com/article/106609/ABC_An_Introduction_to_Business_Process_wManagement_BPM_/1
[4] Process Aware Information Systems: Bridging People and Software through Process Technology by Marlon Dumas, Wil M. P. van der Aalst, and Arthur H. M. ter Hofstede (Wiley, 2005).
[5] Microsoft Corporation, Business Productivity Infrastructure Optimization: Overview. Accessed at www.microsoft.com/business/peopleready/bizinfra/campaign_overview.mspx
[6] "The Dynamic Business Applications Imperative" by John R. Rymer and Connie Moore (Forrester Research, 2007).