POA is a new and evolving concept. The easiest way to think of POA is as the scaffolding for BPM within an organization. Just as the scaffolding provides access and structure to builders constructing a building, POA does the same for BPM. What makes POA so valuable in its role as "scaffolding" is that it allows the view (what the user sees on a screen) and back-end systems to be separated from the processes. When these two elements are separated, we have greater re-use of process components, which means it's faster and cheaper to apply BPM across an organization. The structure that is built can be tailored, decorated and enhanced. Developers can access critical components of the system and adapt them to the ever-changing needs of the organization.

 

 

For the technical audience, software development is making the most of OOD and AOP techniques to create versatile and extendable enterprise applications. However, the business process has not yet taken advantage of OOD and AOP concepts like polymorphism, inheritance and aspects. The reason for this has been due to a tight coupling between front-end views ("user interfaces") with the business process. Likewise, integration with back-end systems and the processes are also so tightly coupled and integrated that business processes cannot morph into other scenarios. By creating architectures that decouple these components from the business process, we can design business processes that are more abstract, and can be re-used and extended into many uses and situations. The effort required to build out BPM across communities of users or across an organization can now focus on the particular needs of the community or department. These users can leverage what they can from these existing processes or have them customized to suit their particular needs. Developers can do this quickly and easily by gaining access to process, just as builders gain access to structures using scaffolding.