Enterprise Architecture Reality

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.

I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.

Posted in Application Lifecycle, Business Architecture
3 comments on “Enterprise Architecture Reality
  1. Karin says:

    I believe that your first paragraph states the problem quite clearly.

    Therefore the solution has nothing to do with software – it has something to do with persons following a common goal – which is to simplify life and as the environment is a changeable and ever-changing one the one clear approach is to enable simple change and ensuring that understanding is not lost.

    What software can do is to allow simple adaptability to outside change – where processes do not change as quickly as environments. It is more likely that some processes disappear and additional ones are required. It may happen, that functions are redistributed to different persons, but the functions are not lost, unless some business (process) on the whole is lost, removed, or moved.


  2. Peter Bakker says:

    Max, I think that Enterprise Architecture has a problem selling itself because:

    1. it is unclear what the real value is, there are surprisingly few stories from business people who are telling in what great ways enterprise architecture has helped them to achieve their goals
    2. enterprise architecture is based on the assumption that everything can, should and must be planned in advance while the business world is asking for agility which can only be achieved by implementing organic generative processes and feedback loops.

    Maybe business architecture will solve some of these issues otherwise it will go the same way as Enterprise Architecture…


    • Peter, thanks for reading and commenting. I totally agree with you. EA by itself has a huge problem. Especially because it will always be behind technology capabilities. But technology empowering people is the competitive edge not some architecture or methodology.

      The reason that I promote a Business Architecture is because there has to be some business wide consensus on how to represent objectives, targets and goals related to business entities in a process environment as otherwise these will be disconnected from the execution. Standalone, neither EA nor BA stands a chance. BA should not be done as a huge enterprise project but grow as needed into the process environment. Without the perspective of a common BA all IT and all processes will continue to be fragmented.

      A Business Architecture is the common denominator that allows an adaptive envionrment with social collaboration about business entities to evolve. It is in principle like DNA that once it evolved became the basis for lifeforms. Thanks again. Max


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Max J. Pucher

Max J. Pucher - Chief Architect ISIS Papyrus Software

© 2007-17
by Max J. Pucher. All rights reserved.
Real World Statistics
  • 216,893 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 9,038 other followers

%d bloggers like this: