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. 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