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