Architecture and Process is about People!

Since the days of Ford and Taylor, businesses are managed through decomposition into automated and business-wide reusable functions, linked by simple cause and effect chains which are then controlled by common objectives. Not much has changed despite advancements such as Balanced Scorecards and Strategy Maps. Find in the following some thoughts regarding architecture and processes, triggered by Adam Dean’s weekly list of BPM posts.

The commonly used definition (i.e. Wikipedia) of Enterprise Architecture (EA) describes the terminology, the composition of enterprise components, and their relationships (behavior) between them and with the external environment, and the guiding principles for management. This includes enterprise objectives (strategy), business process outcomes, organizational capabilities, business information, software applications and computer systems.

One of the first such architectures was the Zachman Framework developed in the 1980s at IBM, consisting of a two-dimensional answer matrix of six questions (What, Where, When, Why, Who and How) mapped to the architectural layers. Enterprise, Business and Process Architectures cannot be seen as different ones, but they represent a hierarchy. Unfortunately there is no clear and agreed upon definition of that. One issue is that buiness strategy and business process are both seen as parts of Business Architecture, while processes must follow strategy and linked to goals and outcomes. Some see Business Strategy as input to BA and that is not wrong either.

I want to discuss mainly Business Architecture, which describes according OMG: “A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.” One can’t really disagree with that but it provides little clarity. Also other frameworks such as xBML Extendable Business Modeling Language use similar terms as Zachman to define the entities related to BA:

  • Activity (What?)
  • Responsibility (Who?)
  • Locality (Where?)
  • Temporal governance (When?)
  • Information (Which?)
  • Operation (How?).

I doubt that this actually represents an architecture definition. Why? Business Architecture as well as BPM too often share a common false perspective: They are seen as means to reduce complexity by enforcing structure. They are meant to create an illusionary predictability where there is none. Any architecture will be no more than a model that also will also be false, but one can hope that it will be useful. You may be surprised, but I say that Business Architecture is meant to manage complexity and not avoid it. Why I am saying this?

Simple, I have not yet seen a Business Architecture in use that is focused on real-world human business aspects or simply said, is about people. Just answering ‘WHO’ does not take into account that people aren’t controllable. That is the same mistake as for BPM that sees processes as assets and not the performers. Once you look at people it is not standardization and reuse that is delivering benefits, but people and knowledge variety and diversity, which an architecture must support and enhance and not suppress. Any manager of a minimum quality will tell you that a business is a loosely-coupled assembly of social structures and that this is the only reason that they actually work. Rigid architectures and processes can kill that in a cinch! Therefore empowerment and social collaboration are popular themes today.

Systems Thinking and Complexity Theory do consider loosely coupled systems, emergence and self-organization as the elements of evolutionary change and how they relate to the social structure in business and economy. They should be considered in creating future-oriented architectures and not TOGAF. Yes, maybe TOGAF and ITIL can be helpful pointers and checklists but I would rather not touch them with a long pole. They might be good for governments or like organizations, but NEVER EVER for a nimble, agile or even ADAPTIVE business. A Business Architecture must enable a business to DIFFERENTIATE itself from the competition through the best possible outcomes on a moments notice!

A great architecture isn’t bothered by the changes in the business or in the environment. The architecture can allow the people of a business to be adaptive, but the architecture itself must not be changed all the time. At best it has to be amended. Processes should only be defined through goals and outcomes from strategy/architecture. Which information is needed for which skill to make an outcome-relevant decision, is what I call a LEVERAGE POINT.

The architecture of a business follows the same principles as that of a building. An architecture is not the construction drawings and it doesn’t describe how the bricks are being laid or the steel is being welded. It doesn’t describe exactly which work steps people will perform in which room. A well architectured building is in most cases multi-use and flexible. It focuses on making people productive by making them feel comfortable. It improves communication and ensures security and safety. It reduces operating expenditure by being energy efficient.

Therfore process flows are for me never part of any architecture hierarchy. They are performed by the people that LIVE and WORK in those rooms, but they aren’t part of the building or business architecture. Therefore if you are running into the problem that your architecture needs to be changed all the time, then it is not an architecture, it is something else. It is however necessary to build processes on architecture, especially if they need to be more flexible than simple flowcharts.

You might know by now that I propose that it is not the process that produces value, but people even if they are guided by a process goal (not a flow) to achieve an outcome. So architects should not get involved in rigidizing processes further through principles, guidelines or rules, but simply ensure that the architecture models empower management, employees and customers to communicate by means of the architectured entities.

The core elements of Business Architecture:

  • Business Strategy: strategic objectives that are either linked to programs if new or linked to Business Capabilites. Operational business targets can be linked but they can also provide independent guidance to decision makers, because there is no simple cause/effect chain available. Not every objective produces a directly measurable KPI, because they are conflicting (investment versus cost).
  • Business Capabilities: describe customer-facing services, supply chain services, core business services, and business management services. They basically can be seen as a grouping of end-to-end processes.
  • Organizational Structure: defines the relationships among process owners, capabilities and business units. I propose that the business units are empowered to execute processes to goal-fulfillment and targets as they see fit, enabling adaptive innovation and optimization without the need for a central bureaucracy. Who owns which ‘Leverage Point’?
  • Business Entities: (some call this knowledge, which is nonsense) for example customer, order, and product data and their relationships. Without those entities neither goals, rules, activities or outcomes, and therefore processes can’t be described.
  • Business Processes: assigns process to process owners and describes outcomes, as well as authority and means (budgets) to achieve them. Process are defined through goals, roles, resources, rules, but should not contain a flow as part of the architecture as it is too limiting. The PO in the business is responsible for flow, activities and tasks. They can change at any time, while goals and outcomes are fairly stable and handle the process handover and completion.

Here a list of previous posts on the subject of architecture and process:

February 2nd, 2009 – Enterprise Architecture Reality

May 14th, 2009 – Why a Business Architecture?

June 2nd, 2009 – Making Empowerment Work

July 10th, 2010 – Adaptive Model Architecture

October, 24th, 2010 – Enterprise Architecture Consolidated

I am the founder and Chief Technology Officer of ISIS Papyrus Software, a medium size software company specializing in communications and process management. I wrote several books and hold a number of patents. My quest is to bring common sense to IT, mostly by focusing in human quality issues rather than cost saving, outsourcing and automation. I am also Chief Architect at VIPorbit software which provides mobile relationship management.

Tagged with: , , ,
Posted in Adaptive Process, Business Architecture, Business Strategy
8 comments on “Architecture and Process is about People!
  1. […] Enabling rules within processes requires an exposed Business Architecture with data entities that these rules can link into! That leads straight to the question what causes these exceptions? Actually there is no such thing as an exception in knowledge work! A process exception is only a mismatch with EXPECTATIONS! An exception is nothing more than a ‘Complex Business Event’ and the principle concept of ‘complex’ means that it is difficult to impossible to predefine those with rules. Most probably a business expert may be capable of recognizing such an event but not be able to encode the rule set that would identify this exception/event logically and accurately. Such a function must be supported by the software. So CEP is an important element of an ADAPTIVE approach as is SOCIAL and MOBILE BPM and not to forget that all of this has to be linked to a Business Architecture as  recently discussed on ‘Architecture and Process are about People!’ […]

    Like

  2. Lars Taxén says:

    Max, I found your comments quite interesting, and I fully agree with the view that people must be considered in EA work. You also say that you have not seen a business architecture in use that is about people. Well, you might want to take a look at the following papers: http://www.neana.se/lars-taxen_contribution1_2010-11-19.pdf
    http://www.neana.se/lars-taxen_contribution2_2010-11-19.pdf

    The key idea is that if we want to include people in EA work, we cannot start from commonly used but rather ill-defined organizational concepts like Business architectures, Business processes, Business strategies, Business Capabilities, Business Entities, etc. These concepts must be grounded in a more fundamental level, which I suggest is some kind of “practice”construct (or activity domain as I call it). In this way you will get a common point of reference that also includes people.

    More about this approach can be found at http://www.neana.se for anyone interested.

    Lars

    Like

    • Lars, thank you for a really interesting comment. I like the approach as a very practical description of goal-oriented processes. I agree that BA today does not well map your design elements into coherent practicable executables. BA needs to define people taking actions on resources for people. The terminology of Activity Domains can be mapped into object-oriented business entities quite easily.

      The MOTIVATION are objectives, targets and process goals leading to an outcome for a customer. The CONTEXT is the resources and actors needed to achieve a certain outcome. The relationships of the resources in the process/case are the SPATIALIZATION. The TEMPORALIZATION can be defined by rules, state transitions, dependencies, or prerequisites. Actor/performer autohization and rules define the STABILIZATION.
      The TRANSITIONS are the subgoals of processes/cases that encompass an end-to-end process in a business capability. Activity-relevant ACTIONS are defined by methods on objects, controlled by state transitions and user authorization. ENACTMENT is by assigning the activity to a performer.

      So I feel that a well-defined, people-oriented Business Architecture would encompass the approach that you defined with Activity Domains, which is a very thoughtful approach and modeling exercise. My concern is mostly how to make the creation and adaptation of processes much more people oriented and therefore I would be worried about using the scientific terminology. Thanks for reading an commenting. Much appreciated. Max,

      Like

  3. […] due to the unnatural acts that hijacking of BPM by vendors causes)? Do we, then, elevate BPM to culture sensitive Business Architecture, where depending on how you bring it about (hint: discipline or way of life again) will determine […]

    Like

  4. Chris Taylor says:

    Great read, thanks, Max.

    Like

  5. […] Max Pucher puts it, “Once you look at people it is not standardization and reuse that is delivering benefits, but …  All business needs to take place within a defined set of structures as a defense against chaos, […]

    Like

  6. […] Max Pucher puts it, “Once you look at people it is not standardization and reuse that is delivering […]

    Like

  7. Yes absolutely the “business architecture” that recognises how people actually work is a “killer” one for IT who failed to understand. Hopefully they now realise the old ways just not up to the job to empower people and let them drive better ways to achieve outcomes and over all business strategy. The required “measurement” which must come with effective empowerment will ensure “chaos” is effectively “managed”!

    Like

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

Max J. Pucher
© 2007-16
by Max J. Pucher. All rights reserved.
Real World Statistics
  • 200,855 readers

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

Join 8,157 other followers

%d bloggers like this: