Why a Business Architecture?

The main goal of a Business Architecture is to enable the business to improve customer service quality through a better transparency, flexibility and adaptability of business operations. The market environment changes more rapidly and the use of technology by customers dramatically influences how a business can operate. Financial services calculation processes, marketing programs, business rules and content change already weekly rather than monthly.

However, if a business architecture has to be modelled, encoded and assembled by using a large number of tools and software components it cannot provide the benefits. Today’s heavily fragmented and hardcoding-integrated IT systems (including SOA) are too rigid to enable rapidly changing business environments. Most IT departments do not focus on adaptability and innovation because they have been requested to focus on lowering cost and system stability. Therefore, six month rollout cycles are the norm with three month being the exception. Business users expectations of stability and executive demands for lower cost are incompatible with the ability to achieve a flexble and adaptive, competitive IT infrastructure. Efficiency is still the main IT goal, with effectiveness a far-off second and agility being no more than an overused buzzword.

Combine this with the misconception that running a business can be pre-planned and therefore encoded into processes and rules, with decisions being taken by predictive analysis based on historical (or better outdated?) business data. I propose that good business decisions are always taken by experienced people who use intuition to combine relevant data in business context. After billions of IT investments neither process management nor business intelligence have delivered the promised wonderland of the automated enterprise that the board can run remotely from the beach. Why?

Neither BPM nor BI consider the human side of running a business and therefore fail to produce a nimble, agile organization. Based on unproven management theories and over-optimistic information technology benefit claims a huge IT bureaucracy is now necessary to manage a complex technology stack. Control and use of the technology stack is only feasable through outsourcing partners and the necessary complex contracts reduce corporate agility even more. Billions are spent by the IT monopolists for marketing to sell an illusion of the IT-controlled business that does not exist and is not achievable by the proposed complex means.

The above situation was the reason for ISIS Papyrus to develop a new IT platform that does not require a huge technology stack and does not need complex programming but a simple modeling and rule definition methodology to build a flexible and adaptible Business Architecture that is mostly under the control of the business and not the IT department.

Agility AND innovation happen on the people level. BPM and SixSigma trash out the people empowerment slogan but fail to deliver because in neither approach people are given the freedom to do things as they see fit as long as the goals are achieved. Enterprise 2.0 is a countermovement to the bureaucratic IT-Governance approach, but if it is simply putting Web 2.0 behind the firewall without giving the user access to plausible business data entities there is not such thing as empowerment.

William of Ockham wrote in Numquam ponenda est pluralitas sine necessitate: “The explanation of any phenomenon should make as few assumptions as possible and not invent further entities to explain a theory.” He was a friar and felt that the one entity of God would explain everything. Bertrand Russel translated it to: “The simplest explanation is usually the best.” Translated further to IT means that coded software systems or process solutions that require substantial resources to be model a business and even more to then adapt it to changing needs make things more complex than necessary. Flexibility AND adaptability by the user – while ensuring transparency and maintainability – are the key capabilities of modern systems. SixSigma adds a lot of bureaucratic complexity that is certainly not in line with Occam’s Razor. Let’s simplify …

A detailed description of Business Architecture features of the Papyrus Platform you will on my Papyrus Architecture blog.

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.