Creating A Business Architecture

Many - including me - evangelize on the noble goal of creating a Enterprise Architecture before setting out on an IT project. One of the key issues with that is that the ‘Enterprise’ hardly ever acts as such. The typical enterprise is at best a federation of little fiefdoms, that more often than not are in constant political warfare against each other. That gets even worse when the enterprise has been assembled by acquisition and worst with hostile takeovers. It is highly unlikely that these fiefdom chiefs will be too happy to collaborate with other chiefs on creating a new Enterprise Architecture. Even if there is c-level buy-in and a champion has been chosen, bureaucratic resistance makes many projects falter. I am quite certain that one reason is wrong expectations set by over-hyped marketing.

Several BPM and application vendors promote the benefits of model-driven development and some even claim that they make that available to the business user (fiefdom chief). Some BPM vendors want the business user to work with a flowcharting tool and others with a requirements wiki/blog thing. This amazing business user would then ‘model’ the necessary business entities. I am sure that comes natural for most, right? This ‘ExtremlySMART’ process software would then generate the process CODE to execute those models. I have to admit that I am in awe. Supposedly that functionality - as simple as described here - ensures a dynamic enterprise with the agility to handle rapid change. Hmm? The user not only can create enterprise models and deploy them automatically but can foresee the necessary changes and how those will impact the current generated code? Amazing. A few abstract models supposedly do the trick. Astonishing. In less than three month those users make it all happen? Wow!

We propose to make much simpler features than architecture models available to business users and more often than not that fails quite miserably. So our software must be less good than our competition? I think not, it is just our marketing that is less blunt. Business users aren’t architects. They do not care about architecture. Just defining what processes one business unit needs and to get them tested takes certainly already longer than three months! Without architectural considerations. No implementation yet. Certainly not the final thing.

But I agree that the reuse and sharing of conceptual business knowledge would be the only chance to properly sell the benefits of a business architecture to business users. It has to be made visible and usable and allow them to not only participate but utilize the existing models to speed up their own implementation and deployment. Business users think in business terms, in content and what they see. Some may even think in rules. Finito. Thats as far architecture will go.

The benefits of creating a consolidated process and content driven architecture are:

• Create a reusable business architecture by doing local projects that are managed in a repository
• Grow the applications by involving business users iteratively within the project to define content, views and processes (not models!)
• Utilize version controlled change management to deploy the architecture models into a scalable production environment
• Processes are not rigid flows that require analysis effort but are assembled by users and controlled by rules and trained patterns
• Enable business users to enter simple natural language business rules

For the business user the application has to look different than to the architect. It has to start with the business organization that represents effectively the role/policy definition for the actual process authorization. Data entities must be real-word plausible things that a business person can make sense of - a so called business object. Not SOA/XML data structures for the service interface. Certainly not BPMN or BPEL. The connection of the service interface to the business object (with or without SOA) must happen once by an IT expert to be reused all across the enterprise given the right authorization.

The next element to be created by business is the business content. Not documentation or descriptive text, but documents that contain relevant business data and information. There is no content without process and process without content you don’t need. (Here I go again …) Based on their authorization business users can assemble and create new business content from a library of texts and logic building blocks. These are linked to task/activity/todo and stored in a business library of processes.

To be able to work with the content the users have to be able to define their processes/cases. I propose (as you know) that there should not be any rigid processes. Users simply drag and drop content and business objects into the case. The process is owned and created by the relevant business users. Creating content outside the context of a business case/process should ideally be impossible.

Now, how can the process/case be controlled and propagated? I propose further that if you start with the right user role/policy authorization and your content is assigned the right role/policy definition for its executable methods, then many complex process definitions fall by the wayside. If only one user role is authorized to change the case state then no further business rules or decision blocks are necessary. But obviously it is possible that a fairly complex rule has to be added that controls what can or can not be done. In this case the business user or analyst can add business rules to the case model, ideally in a non-technical manner. Rules that are linked into the context of the business process are connected to it by events that trace the relationships and therefore complex resolution algorithms such as RETE are not required.

• The first level of task assignment should be by role authorization and queue visibility.
  
• If one or more users or departments share the same role assignments then automatic load balancing must take over (load, availability, priority).
• Rather than coding complex decision trees, decision maps, and decision tables the training if decision patterns is more efficient.
  
• Simple time controlled state changes can ensure that service level agreements are adhered to in the process.
• Event listeners can trigger rules and rules can send events to interconnect object attribute value changes
• Rules can not only be simple IF/THEN statements but also commands and object-relational queries and searches.
• The context of the rule in the process and its event linkage avoids the need for conventional forward or backward chaining.
• Process state can simply decide whether a process requires human interaction or can run in lights-out mode. (aka straight-through processing).

Let’s  not forget that each user likes his own very special way how the workload should be presented to him/her. I suggest that the users should be allowed and enabled to freely customize their own user interface to their liking. With your typical forms, Java or Ajax interfaces that is not feasible or maintainable.

Last but not least: would it not be nice if the system could discover by itself what summary content state will drive the process state forward. I propose that this has to be the future.

Yes, we can and we should strive to empower the business user. But it has to be more than a marketing announcement. Those you will find predominantely in the BPM community. From giving away flowchart design tools to business users, to requirement wikis there are many so-called revolutionary ideas that at best are incremental progress if at all. The revolutionary ideas are found in the Papyrus Platform.