Tuesday, July 24, 2012

Towards a metamodel of business architecture ...

#bizarch #entarch I have been challenged to explain the constructs underlying my Six Viewpoints of Business Architecture (blogpost, draft book), so here is a rough schema. Comments please.

Key Elements
Structure / Behaviour / Function
Purpose View Motivation View Goal, Influence (Cause-Effect), Stakeholder, Outcome, Value Goals and outcomes are linked by chains of influence or production. A goal aims at an outcome, one outcome influences another (positively or negatively), therefore one goal supports or opposes another goal.

From the Business Motivation Model (BMM), I include here Ends, Means and Influencers, but not Directives (which I include in the Cybernetic View)

Some people like to arrange goals and objectives as a hierarchy ("Aim Hierarchy"). Alternatively, influence chains can be drawn as a network, using a notation such as i*.
Activity View Activity, Event (Condition/Trigger), Interaction, Outcome, Role, Work Activities are linked by process chains (sometimes called value chains/streams)
Capability View Activity, Capability, Component, Value, Work Components perform activities according to some abstract capabilities. Capabilities and components are linked by chains of dependency.
Knowledge View Concept, Event (Fact) Concepts (represented by entity types or classes) are linked by facts (represented by relationships and attributes). Simple and compound facts are linked by chains of inference or derivation.
Responsibility View Agent/Role, Outcome, Responsibility, Service, Stakeholder Agent/Role is responsible (accountable) to a stakeholder (or stakeholder proxy) for some outcome. Responsibilities and services are linked by chains of delegation.

Among other things, the Responsibility View allows us to view the Principal/Agent problem (which applies at every level of the management structure).
Cybernetic View Component, Control, Event (Signal), Regulation/Rule (Directive). Components are governed by regulations/rules, and are linked by control loops or feedback loops.

Some people like to arrange policies and rules as a hierarchy ("Directive Hierarchy").

Some important notes.

Firstly, note that some elements appear in more than one viewpoint, but they don't look the same. 

For example, in my schema an event appears in the activity view as a condition or trigger for one or more activity, in the knowledge view as a fact (e.g. a piece of information reporting a change of state), and in the cybernetic view as a signal (allowing control and regulation). The knowledge view defines the semantics of the event (what it means in conceptual terms); the activity view and the cybernetic view define the pragmatics of the event (what it means in behavioural terms).

Secondly, I am not ready to claim any universal applicability for this schema. I am aware of various paradigms that have particular (and conflicting) definitions for these terms, and I am not trying to accommodate every possible meaning of every term.

For example, I am aware that some paradigms have a slightly different notion of event. I am also aware that some paradigms regard a signal as an output (from a management information system) rather than as a control flow (into some management process).There are also conflicting views whether we should regard capabilities as abstract or concrete. (For this reason I have removed the word "abstract" to which David's comment refers.)

Thirdly, each viewpoint allows for both hierarchical and network structures. Although my own preference is to draw networks rather than hierarchies, I am not dogmatic about this.

Fourthly, there are some things I don't regard as part of the Business Architecture but as part of some other domain. These include Location, Requirement, Solution, System (including Human Activity System or SocioTechnical System), Transformation and Use Case. I shall try to justify these exclusions in a separate post.

And finally, I am aware of how much work would be required to turn this into a rigorous ontology or metamodel. If anyone is interested in funding this work, please send me a large cheque.


David Sprott said...

Hi Richard, Apologies I haven't yet got around to reviewing the book. In principle the idea of Views of the BA is a good one. I have some comments:
1. If the concept is to fly in business it needs to be strongly grounded in real world terminology
2. The Purpose View would be better worded as Business Case View. Integration of OGCSF&C etc with monetization is a good idea
3. Call a spade a spade - Process View
4. Capability View is spot on, but they are not abstract. Nor are they components, they are capabilities that by definition should have the highest level of independence
5. Knowledge View shouldn't include Event. I am not convinced that relationships and attributes are the level needed for the BA. I would like to see a structure for Knowledge in the broadest sense
that helps us make sense of structured and unstructured data
6. The Responsibility View is too narrow. Suggest the RACI View.
7. Call me old fashioned but I feel the Cybernetic View is not well named. I would make it the Control View and include Events, Rules and Regulations.
8. I would also posit a Technology View. In this day and age, technology and business are indistinguishable. Technology drives business much of the time.

Hope this is helpful; happy to talk, David

Alexander Samarin said...


A few comments:
- maybe add risks and records as key elements to one of the views
- maybe mention documents
- maybe consider "coordination" view (see http://improving-bpm-systems.blogspot.com/2012/07/coordination-techniques-in-bpm-social.html)
- did you cover locations? HQ and brunch offices
- how do you plan to express dependencies between those views?


Richard Veryard said...

Thanks guys. Lots to respond to there. Let me start with a few points.

Firstly, I am trying to avoid scope-creep - putting everything into the Business Architecture that has (or should have) a good link to business. I regard it as the task of Enterprise Architecture to coordinate between Business Architecture, Solution Architecture, Technology Architecture and whatever other domains the enterprise might need.

Which is why I am reluctant to add a Technology View to the Business Architecture. I am also reluctant to extend the Purpose View to include business case, because I regard the business case (despite its name) as belonging to the Solution Architecture. Documents are also part of the Solution Architecture.

I think what does make sense is to have a Purpose View within the Solution Architecture, including things like business case as well as solution risk. Obviously there needs to be a strong connection between the Purpose View in the Solution Architecture and the Purpose View in the Business Architecture.

(If there is any confusion caused by having two viewpoints in different domains with the same name, we could always call them Business-Purpose View and Solution-Purpose View.)

Where does Location belong? Traditionally this is regarded as part of the Business Architecture, but I believe it belongs somewhere else, along with buildings and working space and the kind of architecture associated with Le Corbusier and Frank Lloyd Wright. Ideally I'd want to call this the Physical Architecture, which would include a Geographical View or what Stewart Brand calls Site. I'd also include something I call Consilience - for an explanation of this see my appreciation of Steve Jobs (October 2011).

Of course, location doesn't disappear in a global organization, but it doesn't dominate business processes in the way it once did, and is often merely a cost factor or speed factor. As I wrote in December 2003, it is not geographical distance that matters any more, but abstract notions of distance, including commercial and semantic distance.

But the problem with the term "Physical Architecture" is that IT people would completely misunderstand it, and imagine it refers to computer hardware. Any other suggestions?

The term "Cybernetic View" is undoubtedly getting a mixed reception. I think the trouble with the term "Control View" is that people often have a very fixed idea of control (top-down command-and-control). However, I might be persuaded to adopt the term "Governance View".

That's enough to be going along with. I'll try and pick up the remaining points soon.

Paul Vincent said...

Richard - interesting work.

I concur with David's comment 7, and wonder if some "Organization model" would cover Alexander's point on locations.

The state / temporal view is possibly covered by the Activity View (I like that as larger than Process View), but that is intrinsic in models: they tend to necessarily be snapshots and have limited lifecycles.


Richard Veryard said...

For further discussion on the LOCATION question, see my subsequent post Is there a place for LOCATION in business architecture?