Business process management challenges present channel opportunities

Business processes and the businesses themselves are inseparable; you can't have one without the other. One of the keys to the success, or failure, of service-oriented architecture (SOA), therefore, is the ability to map the activities and tasks that a business depends on to the IT capabilities that automate or enable those activities.

Learn about Service Oriented Architecture (SEO) Service Oriented Architecture Crash Course IBM to certify VARs for service oriented architecture Enterprise Service Architecture

Business Process Management (BPM), or workflow tools, often present a flowchart-type visual interface or natural language business rules engine that enables business analysts or their proxies in the IT organization to build a representation of the business process in a step-by-step fashion and then attach individual activities in a process to the company's operations.

Often the person who is responsible for creating the representation of the process either doesn't know all the details of the business process at hand in sufficient depth, is not up-to-date with the current state of how a business process is actually working in the company and/or doesn't have knowledge of the whole process from end-to-end. As a result, most business process definition exercises often produce little more than "shelfware" – that is, they end up creating nothing more than writing on paper that represents either the business process as it used to be or the business process as it's supposed to be, but never the business process as it actually is or will be.

Understanding the best practices for implementing such service-oriented processes is essential to any successful SOA initiative. One such practice for solving our long-lived problems with IT-enabling business process is to separate the notion of business logic and process from the underlying code that implements an individual task or step in a process. Moving process from the underlying code into a separate process layer considerably facilitates business agility for a number of significant reasons. First, a change in the process definition does not require a modification of underlying application functionality. People can rapidly amend and redeploy processes as business requirements demand with minimal, if any, programming.