Someone asked on Linked-In Should EA be knowledgeable about accounting and its pitfalls? Here is a rewritten version of my reply.
Management accounting provides a view of the distribution of costs, benefits and risks. Costs include labour costs, materials and other purchases, and so-called overheads. So if we want to know the total production cost of a particular product, or the total cost of a particular activity, we need to work out what share of the total expenditure should be allocated to this product or this activity. These calculations are important for many reasons, including deciding whether to invest in improved systems and technology, deciding whether to keep some capability inhouse or outsource, determining how profitable a given product or service is at a given price and volume.
In One Strategy One PL (January 2013), John R Moran argues that a company can only have a unified strategy if it has a single unified accounting view, and suggests that "the entire logic of profit centers rests on the assumption that maximizing the pieces will maximize the whole". Clearly the relationship between the performance of the pieces and the performance of the whole is an important topic for architects.
Accountants use various simple methods for cost allocation, including so-called Activity-Based Costing. These methods all make some structural assumptions about the dependencies between activities, capabilities, resources and other things. They also involve rules about handling expenditure spanning more than one accounting period. These assumptions also affect project evaluation (e.g. return on investment).
If these structural assumptions are simplistic or incorrect, the management accounting view may lead management to make poor decisions - for example, about investment or cost-cutting or outsourcing. (See my post on Architecture as Jenga.) So business architects need to appreciate what structural assumptions are implicit in the management accounts, and be prepared to challenge these assumptions when necessary.
This is not just because business architects should understand the structure of the business, but also because architecturally-led initiatives may depend on producing a business case that relies on a correct allocation of costs and benefits. For example, architects often wish to advocate long-term investment in shared services and platforms, but such investment may sometimes appear unattractive or unfundable when viewed from a conventional accounting viewpoint, and may be hard to get through the conventional budgeting process. If architects don't understand the potential distortion of the conventional accounting viewpoint, and allow management to take the accounting viewpoint at face value, then they are effectively ceding control of the business structure to the accountants.
Business architects
need to pay attention to the structure of cost. Accountants allocate
costs according to implicit (and often simplistic) architectural
assumptions. For example, accountants use activity-based costing, based
on a very simple activity architecture. If left unchallenged, these cost allocation rules can create difficulties for architects in establlshing
the business case for shared services and shared infrastructure
platforms, and other architecturally-led initiatives. This is one reason
why architects need to take on the accountants rather than accept the
accountancy view at face value.
See also my post on the Calculus of Cost. This is one of a series of posts on The Purpose of Business Architecture.
See also Tom Graves, Financial-architecture and enterprise-architecture (30 September 2013)
Updated 2 September 2013
Showing posts with label viewpoint. Show all posts
Showing posts with label viewpoint. Show all posts
Wednesday, November 07, 2012
Sunday, August 12, 2012
At least three views of business architecture (TOGAF)
In a previous post, I looked at the five viewpoints of business architecture according to the OMG. In this post, I shall look at the architectural modelling viewpoints indicated in TOGAF 9.1. (Section 8.2). In TOGAF, these viewpoints are presented more as suggestions rather than as a recommended set.
According to TOGAF, "a variety of modeling tools and techniques may be employed, if deemed appropriate". Items 1-3 are offered as general examples.
Items 4 and 5 are described as follows. "Although originally developed for use in the Defense sector, these models are finding increasing use in other sectors of government, and may also be considered for use in non-government environments."
Item 6 is included in a list of "business models relevant to common high-level business domains". Whereas the other members of the list are specific industry models, the Resource-Event-Agent (REA) Model appears to be a modelling viewpoint - indeed Wikipedia calls it an ontology. TOGAF asserts that the REA model "has proved so useful for better understanding of business processes that it has become one of the major modeling frameworks for both traditional enterprises and e-Commerce systems", but this assertion is contradicted by Wikipedia which suggests that its main influence has been in the classroom and in the development of such standards as ebXML.
Wikipedia: Resources, events, agents (accounting model)
TOGAF's set of viewpoints strongly emphasizes the information processing and information exchange elements of business architecture, while neglecting a number of other elements that are included in the OMG five viewpoints or my own six viewpoints.
TOGAF lists a number of additional outputs from the business architecture work, which go beyond the modelling viewpoints it has specified. These are as follows.
Catalogs
Finally, TOGAF includes Business Scenarios, but I think this probably counts more as a requirements gathering technique than an architectural viewpoint.
I should welcome comments, especially from people who are familiar with TOGAF in practice.
| 1 | Hierarchical Activity Models (also called Business Process Models) | Functions, data/information exchanges, activities, inputs, controls, outputs, mechanisms/resources, business rules | General |
|---|---|---|---|
| 2 | Use Case Models | Business processes, system functions, use case, actor, | General |
| 3 | Business Class Models | Information (entities and implementation classes, attributes and relationships), information behaviours | General |
| 4 | Node Connectivity Diagram | Nodes (role, org unit, location, facility), information transfer/flow | Defence sector |
| 5 | Information Exchange Matrix | Information Exchange | Defence sector |
| 6 | Resource-Event-Agent Model | Resources (goods, services or money), Event (transactions and agreements), Agent (people and organizations) | Accounting domain |
According to TOGAF, "a variety of modeling tools and techniques may be employed, if deemed appropriate". Items 1-3 are offered as general examples.
Items 4 and 5 are described as follows. "Although originally developed for use in the Defense sector, these models are finding increasing use in other sectors of government, and may also be considered for use in non-government environments."
Item 6 is included in a list of "business models relevant to common high-level business domains". Whereas the other members of the list are specific industry models, the Resource-Event-Agent (REA) Model appears to be a modelling viewpoint - indeed Wikipedia calls it an ontology. TOGAF asserts that the REA model "has proved so useful for better understanding of business processes that it has become one of the major modeling frameworks for both traditional enterprises and e-Commerce systems", but this assertion is contradicted by Wikipedia which suggests that its main influence has been in the classroom and in the development of such standards as ebXML.
Wikipedia: Resources, events, agents (accounting model)
TOGAF's set of viewpoints strongly emphasizes the information processing and information exchange elements of business architecture, while neglecting a number of other elements that are included in the OMG five viewpoints or my own six viewpoints.
TOGAF lists a number of additional outputs from the business architecture work, which go beyond the modelling viewpoints it has specified. These are as follows.
Catalogs
Organization/Actor catalog, Driver/Goal/Objective catalog, Role catalog, Business Service/Function catalog, Location catalog, Process/Event/Control/Product catalog, Contract/Measure catalogMatrixes
Business Interaction matrix, Actor/Role matrixDiagrams
Business Footprint diagram, Business Service/Information diagram, Functional Decomposition diagram, Product Lifecycle diagram, Goal/Objective/Service diagram, Use-case diagram, Organization Decomposition diagram, Process Flow diagram, Event diagram
Finally, TOGAF includes Business Scenarios, but I think this probably counts more as a requirements gathering technique than an architectural viewpoint.
I should welcome comments, especially from people who are familiar with TOGAF in practice.
Tuesday, July 31, 2012
Is there a place for LOCATION in Business Architecture?
#bizarch #entarch Most enterprise architecture frameworks put LOCATION into the business architecture domain. So am I merely being contrarian when I ask whether it really belongs there?
My first point is that some IT people may regard the business architecture domain as a dumping ground for anything that doesn't belong anywhere else. For example, TOGAF 9.1 includes a skills matrix and set of job descriptions in the business architecture (Chapter 8), and I found a framework called Lite EA that includes staff demographics. There is perhaps an idea that the business architecture includes all non-IT aspects of the solution architecture, including physical processes as well as human activity.
My second point is that business architecture doesn't just mean a complete collection of business-oriented IT requirements. Maybe some of the staff work from home on Fridays, and this has some important implications for IT systems and infrastructure, including security. However, people sometimes working from home does not affect the structure and behaviour of the business, so it's not really business architecture.
My third point is that a lot of these frameworks have evolved from earlier work, dating from an era when geography was (a) more significant and (b) more straightforward.
My final point is that physical location belongs to an entirely different domain, which I want to call Physical Architecture, which might include office facilities, storage facilities, transport links, and suchlike. These are clearly necessary for the implementation of a particular solution to a geographically distributed business process, just as the computing and communication facilities are, but they aren't part of the business architecture.
This post has prompted two questions on Twitter.
Eric Stephens asked Are locations/buildings just tech? My answer: pretty much, yes. Le Corbusier said that a house was a machine for living in.
Alex Matthews asked Are you also going to separate time as a domain? My answer: I see neither time nor space as architectural domains, but as dimensions affecting one or more architectural domains. Clearly time affects several domains. The argument here is whether the business architecture domain is significantly affected by the spatial dimension. I don't think it is.
My first point is that some IT people may regard the business architecture domain as a dumping ground for anything that doesn't belong anywhere else. For example, TOGAF 9.1 includes a skills matrix and set of job descriptions in the business architecture (Chapter 8), and I found a framework called Lite EA that includes staff demographics. There is perhaps an idea that the business architecture includes all non-IT aspects of the solution architecture, including physical processes as well as human activity.
My second point is that business architecture doesn't just mean a complete collection of business-oriented IT requirements. Maybe some of the staff work from home on Fridays, and this has some important implications for IT systems and infrastructure, including security. However, people sometimes working from home does not affect the structure and behaviour of the business, so it's not really business architecture.
My third point is that a lot of these frameworks have evolved from earlier work, dating from an era when geography was (a) more significant and (b) more straightforward.
My final point is that physical location belongs to an entirely different domain, which I want to call Physical Architecture, which might include office facilities, storage facilities, transport links, and suchlike. These are clearly necessary for the implementation of a particular solution to a geographically distributed business process, just as the computing and communication facilities are, but they aren't part of the business architecture.
This post has prompted two questions on Twitter.
Eric Stephens asked Are locations/buildings just tech? My answer: pretty much, yes. Le Corbusier said that a house was a machine for living in.
Alex Matthews asked Are you also going to separate time as a domain? My answer: I see neither time nor space as architectural domains, but as dimensions affecting one or more architectural domains. Clearly time affects several domains. The argument here is whether the business architecture domain is significantly affected by the spatial dimension. I don't think it is.
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.
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 aslightly 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.
| Viewpoint |
Key Elements |
Structure / Behaviour / Function |
| 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 |
| 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
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.
Sunday, June 17, 2012
The Cybernetic View
#bizarch One of the Six Views of Business Architecture is the Management View or Cybernetic View. To understand this view, let's start by asking what kind of thing management is.
One way of thinking about management is as a particular bundle of capabilities, such as planning, resource allocation, monitoring and control. These capabilities can be mobilized according to some routine schedule of activity (for example, the annual budget cycle), or in response to various events inside and outside the enterprise. So we can view management from a Capability viewpoint, or from an Activity viewpoint.
Another way of thinking about management is as a particular bundle of role and responsibilities. These may be presented as a hierarchy or matrix, although such depictions are usually highly simplistic. Management responsibilities may be controlled by a select group of senior staff, with "manager" or "director" or "officer" in their job title. Alternatively, they may be wholly or partially distributed to other staff along with various operational responsibilities. In any case, the real (defacto) distribution of roles and responsibilities is usually much more subtle and flexible than the official (orgchart) distribution. (cf The Four Organizations of Lord Brown.)
We may therefore view management at different levels of abstraction - either specifying the concrete division of responsibilities between named roles or even named individuals, or merely identifying the total set of responsibilities without allocating them to specific roles.
Both the Capability view of management and the Responsibility view of management are useful, but neither of these viewpoints really captures what is distinctive about management. Instead, we need to turn to a systems view of management, inspired by such thinkers as W. Ross Ashby, Russell Ackoff, Stafford Beer and Gregory Bateson. Let's call this the Cybernetic View.
The Cybernetic View is based on the idea of goal-directed behaviour, based on feedback and feedforward loops. This is elaborated into various frameworks, including Stafford Beer's Viable Systems Model (VSM).
A conventional interpretation of the Viable Systems Model is that it models an organization from the viewpoint of a neutral and all-seeing observer. The cybernetic literature can be divided into First-Order Cybernetics, which accepts this interpretation, and Second-Order Cybernetics, in which the position of the observer is itself problematic.
Bateson's work on Second-Order Cybernetics has directly or indirectly inspired many generations of management and organization scientists, including Chris Argyris, Donald Schön, Kenwyn Smith and Peter Senge, and I have used many of their ideas in my own framework for Organizational Intelligence. Some researchers are currently exploring Third-Order Cybernetics, but this is not yet mainstream.
The Cybernetic View should also embrace Robert Rosen's concept of Anticipatory Systems -
The Cybernetic View provides a useful complement to a conventional process view. As I pointed out in my post on Collaboration Impact Zones, AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place.
See also my earlier post Organizations as Brains.
My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/
One way of thinking about management is as a particular bundle of capabilities, such as planning, resource allocation, monitoring and control. These capabilities can be mobilized according to some routine schedule of activity (for example, the annual budget cycle), or in response to various events inside and outside the enterprise. So we can view management from a Capability viewpoint, or from an Activity viewpoint.
Another way of thinking about management is as a particular bundle of role and responsibilities. These may be presented as a hierarchy or matrix, although such depictions are usually highly simplistic. Management responsibilities may be controlled by a select group of senior staff, with "manager" or "director" or "officer" in their job title. Alternatively, they may be wholly or partially distributed to other staff along with various operational responsibilities. In any case, the real (defacto) distribution of roles and responsibilities is usually much more subtle and flexible than the official (orgchart) distribution. (cf The Four Organizations of Lord Brown.)
We may therefore view management at different levels of abstraction - either specifying the concrete division of responsibilities between named roles or even named individuals, or merely identifying the total set of responsibilities without allocating them to specific roles.
Both the Capability view of management and the Responsibility view of management are useful, but neither of these viewpoints really captures what is distinctive about management. Instead, we need to turn to a systems view of management, inspired by such thinkers as W. Ross Ashby, Russell Ackoff, Stafford Beer and Gregory Bateson. Let's call this the Cybernetic View.
The Cybernetic View is based on the idea of goal-directed behaviour, based on feedback and feedforward loops. This is elaborated into various frameworks, including Stafford Beer's Viable Systems Model (VSM).
A conventional interpretation of the Viable Systems Model is that it models an organization from the viewpoint of a neutral and all-seeing observer. The cybernetic literature can be divided into First-Order Cybernetics, which accepts this interpretation, and Second-Order Cybernetics, in which the position of the observer is itself problematic.
Bateson's work on Second-Order Cybernetics has directly or indirectly inspired many generations of management and organization scientists, including Chris Argyris, Donald Schön, Kenwyn Smith and Peter Senge, and I have used many of their ideas in my own framework for Organizational Intelligence. Some researchers are currently exploring Third-Order Cybernetics, but this is not yet mainstream.
The Cybernetic View should also embrace Robert Rosen's concept of Anticipatory Systems -
"A system containing a predictive model of itself and/or its environment, which allows it to change state at an instant in accord with the model's predictions pertaining to a later instant." Wikipedia
The Cybernetic View provides a useful complement to a conventional process view. As I pointed out in my post on Collaboration Impact Zones, AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place.
See also my earlier post Organizations as Brains.
My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/
Important note - I haven't read all of these papers myself yet, so I'm putting them here for my own reference as well as yours. Update: Professor Vidgen kindly dug out a paper he wrote ages ago.
Sabine Buckl, Florian Matthes, Christian M Schweda, A viable system perspective on enterprise architecture management. 2009 IEEE International Conference on Systems Man and Cybernetics (2009)
Gil Regev, Ian Alexander, Alain Wegmann, Use Cases and Misuse Cases Model the Regulatory Roles of Business Processes. Business Process Management Journal, "Goal-oriented business process modelling" Guest Editors: Ilia Bider and Paul Johannesson Volume 11 Number 6 2005 pages 695-708
Richard Vidgen, Cybernetics and business processes: using the viable system model to develop an enterprise process architecture. Knowledge and Process Management, 1998.
Anders Jensen-Waud, Paradoxes in EA and Systems Research (April 2010)
Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Mapping the Enterprise Architecture Principles in TOGAF to the Cybernetic Concepts--An Exploratory Study (2012 45th Hawaii International Conference on System Sciences)
Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Reinterpreting TOGAF’s Enterprise Architecture Principles Using a Cybernetic Lens (Journal of Enterprise Architecture, May 2012)
Thursday, June 07, 2012
Six Views of Business Architecture
#bizarch Does it make sense to produce a business architecture from a single viewpoint, such as a Process Viewpoint or a Capability Viewpoint? Or do we need a proliferation of viewpoints, perhaps arranged in a 2x2 matrix such as the Zachman Framework?
In its Business Architecture Overview, the Object Management Group Business Architecture Working Group has identified five key views of a business, which it calls 1) the Business Strategy view, 2) the Business Capabilities view, 3) the Value Stream view, 4) the Business Knowledge view, and 5) the Organizational view. See my previous post on the Five Views of Business Architecture (OMG), in which I also identify a sixth one, which I've been calling the Management or Cybernetic view. (Strictly speaking these are viewpoints rather than views, but I'm trying to stick to the OMG terminology as far as possible.)
I have used all of these views for business modelling, and I am convinced that they are all useful - although they may not all be required on every project. (I don't expect you to believe this without further evidence, and I am currently assembling a set of worked examples.) I have presented earlier versions of this schema in the past, with slightly different names, but I believe the current names and explanations are clearer.
Outcomes may be described qualitatively or quantitatively, and there are different analysis techniques and notations associated with the transition from quantity to quality.
A more sophisticated view would consider the uncertainty associated with these outcomes, as well as the potential conflict between the goals and values of different stakeholders. It would also recognize that there is often a subtle difference between the official or espoused goals and objectives of an enterprise and its defacto goals and objectives. See my post on Enterprise POSIWID.
The OMG calls this the Business Strategy view, but I think this is a misleading name. The strategy doesn't reside in motivation, but in how the business mobilizes itself to satisfy some set of motivations.
The name Business Motivation view reflects the Business Motivation Model (BMM), which provides some limited coverage of this view. Alternatively, I could call this the Business Performance view.
At this level, I'm not distinguishing between data, information and knowledge. Classifying information as "structured" and "unstructured" is not as important to the business architecture as it is to the IT architecture. What is important, however, is the question of business epistemology - what it is possible for the business to know, and with what level of confidence. There are various sociotechnical mechanisms that may make it possible for a 21st century business to know all sorts of things that were simply not available before. But of course, the business architect is not directly interested in the mechanisms themselves - these belong to some other architecture.
See separate post on the Cybernetic View.
I am also convinced that business strategy is not contained within a single view (as the OMG would have it) but is about the relationships between the views.
This relationship between abstract and concrete is what Zachman calls reification, and everyone else calls realization. Note that both the partner-independent model and the partner-specific model belong to the business architecture and not to any other architectural domain.
My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/
In its Business Architecture Overview, the Object Management Group Business Architecture Working Group has identified five key views of a business, which it calls 1) the Business Strategy view, 2) the Business Capabilities view, 3) the Value Stream view, 4) the Business Knowledge view, and 5) the Organizational view. See my previous post on the Five Views of Business Architecture (OMG), in which I also identify a sixth one, which I've been calling the Management or Cybernetic view. (Strictly speaking these are viewpoints rather than views, but I'm trying to stick to the OMG terminology as far as possible.)
I have used all of these views for business modelling, and I am convinced that they are all useful - although they may not all be required on every project. (I don't expect you to believe this without further evidence, and I am currently assembling a set of worked examples.) I have presented earlier versions of this schema in the past, with slightly different names, but I believe the current names and explanations are clearer.
Business Motivation View (aka Purpose)
This viewpoint describes what the business achieves for itself and its stakeholders (direct and indirect value). It specifies desired, potential and actual performance in terms of goals and objectives as well as positive and negative outcomes. (For example, a risk is a potential negative outcome.)Outcomes may be described qualitatively or quantitatively, and there are different analysis techniques and notations associated with the transition from quantity to quality.
A more sophisticated view would consider the uncertainty associated with these outcomes, as well as the potential conflict between the goals and values of different stakeholders. It would also recognize that there is often a subtle difference between the official or espoused goals and objectives of an enterprise and its defacto goals and objectives. See my post on Enterprise POSIWID.
The OMG calls this the Business Strategy view, but I think this is a misleading name. The strategy doesn't reside in motivation, but in how the business mobilizes itself to satisfy some set of motivations.
The name Business Motivation view reflects the Business Motivation Model (BMM), which provides some limited coverage of this view. Alternatively, I could call this the Business Performance view.
Business Capability View (aka Component)
This viewpoint describes how the business delivers direct and indirect value in response to the challenges of the environment. Many business architects merely decompose the business into something that looks like an old-fashioned functional hierarchy, but there are several important architectural issues that need to be addressed within the business capability view.- Coordination of internal and external capability. When an organization chooses to delegate or outsource a particular capability, the coordination of the outsourced capability remains.
- Capability dependencies - how strength or weakness in one capability affects the performance of other capabilities.
- Requisite variety. An organization chooses what range and variety of events it is capable of responding to, and this variety is reflected in specific capabilities.
- Through-life capability management. Establishing a capability requires some level of investment, in terms of equipment and recruitment and training and so on. The costs of maintaining a capability may escalate, especially if the demands keep changing.
- Performance, quality and value-for-money. It is always possible to devote more energy and resources to improving any given capability, but this is only justified if it is reflected in business performance (aka "the bottom line"). Business excellence models (such as Baldrige and EFQM) address this kind of alignment.
Business Activity View (aka Process)
This viewpoint describes the day-to-day behaviour of the business, or what the OMG calls "business in motion". Traditionally processes are seen as a chain of value-adding process steps, thus the OMG calls this the Value Stream view. However, the value network paradigm looks significantly more powerful than the value chain paradigm, and I prefer to use the neutral term Business Activity.Business Knowledge View (aka Concept)
This is a well-established architectural viewpoint, previously known under various names such as Conceptual Information Model or Business Data Architecture. It basically captures what the business knows, and the semantics of how the business talks to itself and its partners. This viewpoint is critical for business interoperability. Knowledge also includes contextual knowledge, which is essential for providing differentiated services.At this level, I'm not distinguishing between data, information and knowledge. Classifying information as "structured" and "unstructured" is not as important to the business architecture as it is to the IT architecture. What is important, however, is the question of business epistemology - what it is possible for the business to know, and with what level of confidence. There are various sociotechnical mechanisms that may make it possible for a 21st century business to know all sorts of things that were simply not available before. But of course, the business architect is not directly interested in the mechanisms themselves - these belong to some other architecture.
Responsibility View (aka Organization or Relationship)
The OMG defines an organizational view in terms of the relationships between organizational units, so I think the term Responsibility View is a better name for this view. I have done a lot of work on business relationship modelling, looking in particular at questions of the organizational responsibility and accountability for activities and outcomes, and this work can be traced back to the ORDIT methodology of the early 1990s. These relationships and organizational interfaces may be represented as services, with various levels of formality in defining and measuring service levels. There are also important architectural issues in dealing with the idea of Business-As-A-Platform, in particular in relation to multi-sided markets.Cybernetic View (aka Management or Governance)
Finally, the cybernetic view describes how the organization and its management thinks. This covers all the aspects of organizational intelligence, from information gathering, through sense-making and decision-making, to organizational memory and learning.See separate post on the Cybernetic View.
Hybrid Views
These views are not sacrosanct, and there are some useful business models that may not fit neatly into these six viewpoints. For example, Martin Ould's Activity Role Diagrams seem to involve a combination of Activity and Responsibility, while Stafford Beer's Viable Systems Model combines the Capability View and the Cybernetic view.I am also convinced that business strategy is not contained within a single view (as the OMG would have it) but is about the relationships between the views.
Levels of Abstraction
Each of these viewpoints can be applied at different levels of abstraction. For example, in business relationship modelling, we may identify a partner-independent model (which merely defines an abstract relationship with a notional business partner) and a partner-specific model (which defines a concrete and contractual relationship with a real business partner). Meanwhile, in the capability view we may need to distinguish between abstract capabilities (which some frameworks regard as the only true capabilities) and sociotechnical lumps that implement these capabilities (which may be called components or nodes).This relationship between abstract and concrete is what Zachman calls reification, and everyone else calls realization. Note that both the partner-independent model and the partner-specific model belong to the business architecture and not to any other architectural domain.
My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/
Tuesday, March 13, 2012
Perspective in Depth
As the systems thinking pioneer Gregory Bateson pointed out, there is an important difference between seeing with one eye and seeing with two. With monocular vision even the much prized Big Picture can be merely a flat and featureless panorama. Binocular vision affords a sense of depth and contour, and enhances the view.
When I wrote recently about the "What the Business Wants" viewpoint, Nick Gall challenged me to state whether I was referring to nominal purpose or defacto purpose (POSIWID). My answer was that the "What the Business Wants" viewpoint gave us a vantage point from which we could view both nominal purposes and defacto purposes at the same time, and appreciate the rich dependencies and contradictions between them.
So what happens when I apply the same thinking to the other five viewpoints? Each viewpoint has a monocular version (simple, linear) and a binocular version (rich, multi-dimensional). Here are a few key differences.
But how should I label the two columns? Should I succumb to the temptation to label the first column "traditional"? Any suggestions?
When I wrote recently about the "What the Business Wants" viewpoint, Nick Gall challenged me to state whether I was referring to nominal purpose or defacto purpose (POSIWID). My answer was that the "What the Business Wants" viewpoint gave us a vantage point from which we could view both nominal purposes and defacto purposes at the same time, and appreciate the rich dependencies and contradictions between them.
So what happens when I apply the same thinking to the other five viewpoints? Each viewpoint has a monocular version (simple, linear) and a binocular version (rich, multi-dimensional). Here are a few key differences.
| Flat | Rounded | Links | ||
| Strategic View | What the Business Wants | Nominal purpose Nominal strategy | Defacto purpose Emergent strategy | Enterprise POSIWID |
| Capability View | How the Business Does | Operational capability Hard dependencies Top-down leadership | Sociotechnical capability and competency Soft dependencies Edge leadership | |
| Activity View | What the Business Does | Linear synchronous process (value chain) | Asynchronous collaboration (value network) | Changing Conceptions of Business Process |
| Knowledge View | What the Business Knows | Formal information systems | Informal information systems Sensemaking Appreciative systems | |
| Management View | How the Business Thinks | Goal-directed behaviour Management by objectives Single loop learning First order cybernetics (VSM) | Second-order cybernetics (Bateson/Maturana) Double-loop and deutero learning | Organizations as Brains |
| Organization View | What the Business Is | Enterprise | Business-as-a-Platform Ecosystem |
But how should I label the two columns? Should I succumb to the temptation to label the first column "traditional"? Any suggestions?
Friday, December 23, 2011
Three or Four Schools of Enterprise Architecture
#entarch @lapalj has written an interesting article on the Three Schools of Enterprise Architecture.
The schools are distinguished along two dimensions: scope and ends (purpose).
Besides scope and purpose, I have always considered it important to identify a third dimension of perspective (viewpoint). (For example, I talk about these three dimensions in my 1992 book on Information Modelling, pages 16-22.)
Among other things, perspective helps us to address the question: What kind of system is the enterprise being understood as? For example, the (micro-)economic perspective views the enterprise as a production system (value chain or value network), while the management cybernetic perspective (such as Stafford Beer's Viable Systems Model) views the enterprise as a thinking system or brain. Gareth Morgan's book Images of Organization contains a good survey of several contrasting perspectives.
Most enterprise architects in the first school adopt the traditional IT perspective of regarding the enterprise as an information processing system. Most of the well-known EA frameworks (such as those listed on the ISO 42010 website) are solidly within the first school.
Lapalme's second school explicitly invokes the socio-cultural perspective, and calls for all facets of the enterprise to be considered - this clearly implies going beyond the traditional IT perspective.
However, there is a considerable body of work that looks at the enterprise-in-environment, but remains within the IT perspective. This would include the Open Group work on the extended enterprise, as well as the Systems-of-Systems community. A key scoping question here is the exercise of governance over large distributed systems of systems. Mark Maier distinguished between directed and emergent systems (or we might think about directed and emergent enterprises), and this has been developed into a four-part schema by the US Department of Defense: Directed, Acknowledged, Collaborative and Virtual. Some useful work at the SEI, where this thinking has been connected into work on SOA and enterprise architecture.
Lapalme's article identifies James Martin as one of the leaders of the third school, based on a minor work published in 1995, but most of Martin's work belongs solidly within the first school. In his 1982 book, Strategic Data-Planning Methodologies, Martin shows how IBM's BSP methodology could be used to decompose the activities of the organization, as a precursor to planning IT systems. The primary aim of such methodologies from the 1980s onwards was to identify opportunities to install more computers and develop more software, and I think it is no coincidence that a number of the pioneers of enterprise architecture (from Martin to John Zachman) had worked for IBM. See my note on The Sage Kings of Antiquity.
So I think it makes sense to divide Lapalme's third school into two distinct sub-schools. There is clearly a lot of work in School Three A, which extends the scope of architecture without introducing the socio-cultural or other perspectives which Lapalme associates with School Two. There is as yet very little formal work in School Three B.
James Lapalme, "3 Schools of Enterprise Architecture," IT Professional, 14 Dec. 2011. IEEE computer Society Digital Library. IEEE Computer Society, http://doi.ieeecomputersociety.org/10.1109/MITP.2011.109
The schools are distinguished along two dimensions: scope and ends (purpose).
Scopes | Ends |
Enterprise wide IT platform (EIT). All components (software, hardware, etc.) of the enterprise IT assets. | Effective enterprise strategy execution and operation through IT-Business alignment. The end is to enhance business strategy execution and operations. The primary means to this end is the aligning of the business and IT strategies so that the proper IT capabilities are developed to support current and future business needs. |
Enterprise (E). The enterprise as a socio-cultural—techno-economic system; hence ALL the facets of the enterprise are considered – the enterprise IT assets being one facet. | Effective enterprise strategy implementation through execution coherency. The end is effective enterprise strategy implement. The primary means to this end is designing the various facets of the enterprise (governance structures, IT capabilities, remuneration policies, work design, etc.) to maximize coherency between them and minimize contradictions. |
Enterprise-in-environment (EiE). Includes the previous scope but adds the environment of the enterprise as a key component as well as the bidirectional relationship and transactions between the latter and its environment. | Innovation and adaption through organizational learning. The end is organizational innovation and adaption. The primary means is the fostering of organizational learning by designing the various facets of the enterprise (governance structures, IT capabilities, remuneration policies, work design, etc.) as to maximize organizational learning throughout the enterprise. |
Besides scope and purpose, I have always considered it important to identify a third dimension of perspective (viewpoint). (For example, I talk about these three dimensions in my 1992 book on Information Modelling, pages 16-22.)
Among other things, perspective helps us to address the question: What kind of system is the enterprise being understood as? For example, the (micro-)economic perspective views the enterprise as a production system (value chain or value network), while the management cybernetic perspective (such as Stafford Beer's Viable Systems Model) views the enterprise as a thinking system or brain. Gareth Morgan's book Images of Organization contains a good survey of several contrasting perspectives.
Most enterprise architects in the first school adopt the traditional IT perspective of regarding the enterprise as an information processing system. Most of the well-known EA frameworks (such as those listed on the ISO 42010 website) are solidly within the first school.
Lapalme's second school explicitly invokes the socio-cultural perspective, and calls for all facets of the enterprise to be considered - this clearly implies going beyond the traditional IT perspective.
However, there is a considerable body of work that looks at the enterprise-in-environment, but remains within the IT perspective. This would include the Open Group work on the extended enterprise, as well as the Systems-of-Systems community. A key scoping question here is the exercise of governance over large distributed systems of systems. Mark Maier distinguished between directed and emergent systems (or we might think about directed and emergent enterprises), and this has been developed into a four-part schema by the US Department of Defense: Directed, Acknowledged, Collaborative and Virtual. Some useful work at the SEI, where this thinking has been connected into work on SOA and enterprise architecture.
Lapalme's article identifies James Martin as one of the leaders of the third school, based on a minor work published in 1995, but most of Martin's work belongs solidly within the first school. In his 1982 book, Strategic Data-Planning Methodologies, Martin shows how IBM's BSP methodology could be used to decompose the activities of the organization, as a precursor to planning IT systems. The primary aim of such methodologies from the 1980s onwards was to identify opportunities to install more computers and develop more software, and I think it is no coincidence that a number of the pioneers of enterprise architecture (from Martin to John Zachman) had worked for IBM. See my note on The Sage Kings of Antiquity.
So I think it makes sense to divide Lapalme's third school into two distinct sub-schools. There is clearly a lot of work in School Three A, which extends the scope of architecture without introducing the socio-cultural or other perspectives which Lapalme associates with School Two. There is as yet very little formal work in School Three B.
School OneSingle EnterpriseIT Perspective | School TwoSingle EnterpriseMultiple Perspective |
School Three AExtended EnterpriseSystem of Systems | School Three BEcosystemMultiple Perspective |
James Lapalme, "3 Schools of Enterprise Architecture," IT Professional, 14 Dec. 2011. IEEE computer Society Digital Library. IEEE Computer Society, http://doi.ieeecomputersociety.org/10.1109/MITP.2011.109
Monday, October 17, 2011
Five Views of Business Architecture (OMG)
#OMG #BAWG The Object Management Group Business Architecture Working Group has identified five key views of a business.
While working with the CBDI Forum between 2002 and 2009, I developed an approach to business modelling for SOA, which included an emphasis on decoupling the WHAT (what the business does, what the business knows) from the HOW (how the business does). We felt that this decoupling provided the best basis for managing differentiation and integration across complex enterprises, and for achieving appropriate economics of scale and scope.
In my more recent work on Organizational Intelligence, I have sought to further decouple "What the Business Knows" from "How the Business Thinks". Different enterprises operating in the same ecosystem may be able to share a lot of common knowledge and information, but may each arrive at different judgements about What-Is-Going-On.
I shall be presenting the latest version of this schema in my Business Architecture Bootcamp and Organizational Intelligence Workshop, and explore how this schema helps to address a range of practical business problems.
book now Business Architecture Bootcamp (November 22-23, 2011)
book now Workshop: Organizational Intelligence (November 24th, 2011)
- the Business Strategy view ("What the Business Wants")
- the Business Capabilities view ("What the Business Does")
- the Value Stream view ("How the Business Does")
- the Business Knowledge view ("What the Business Knows", "How the Business Thinks")
- the Organizational view ("What the Business Is")
Source: Business Architecture Overview
While working with the CBDI Forum between 2002 and 2009, I developed an approach to business modelling for SOA, which included an emphasis on decoupling the WHAT (what the business does, what the business knows) from the HOW (how the business does). We felt that this decoupling provided the best basis for managing differentiation and integration across complex enterprises, and for achieving appropriate economics of scale and scope.
In my more recent work on Organizational Intelligence, I have sought to further decouple "What the Business Knows" from "How the Business Thinks". Different enterprises operating in the same ecosystem may be able to share a lot of common knowledge and information, but may each arrive at different judgements about What-Is-Going-On.
I shall be presenting the latest version of this schema in my Business Architecture Bootcamp and Organizational Intelligence Workshop, and explore how this schema helps to address a range of practical business problems.
book now Business Architecture Bootcamp (November 22-23, 2011)
book now Workshop: Organizational Intelligence (November 24th, 2011)
Saturday, October 30, 2010
Organizations as Brains
This post is based on Chapter 3 of Gareth Morgan's classic book Images of Organization (Sage 1986), which opens with the following question: "Is it possible to design organizations so that they have the capacity to be as flexible, resilient, and inventive as the functioning of a brain?"
To start with, Morgan makes two important distinctions. The first distinction is between two different notions of rationality, and the second involves two contrasting uses of the "brain" metaphor.
Mechanistic or bureaucratic organizations rely on what Morgan (following Karl Mannheim) calls "instrumental rationality", where people are valued for their ability to fit in and contribute to the efficient operation of a predetermined structure. Morgan contrasts this with "substantial rationality", where elements of organization are able to question the appropriateness of what they are doing and to modify their action to take account of new situations. Morgan states that the human brain possesses higher degrees of substantial rationality than any man-made system. (pp78-79)
Morgan also observes a common trend to use the term "brain" metaphorically to refer to a centralized planning or management function within an organization, the brain "of" the firm. Instead, Morgan wants to talk about brain-like capabilities distributed throughout the organization, the brain "as" the firm. Using the brain metaphor in this way leads to two important ideas. Firstly, that organizations are information processing systems, potentially capable of learning to learn. And secondly, that organizations may be holographic systems, in the sense that any part represents and can stand in for the whole. (p 80)
The first of these two ideas, organizations as information processing systems, goes back to the work of James March and Herbert Simon in the 1940s and 1950s. Simon's theory of decision-making leads us to understand organizations as kinds of institutionalized brains that fragment, routinize and bound the decision-making process in order to make it manageable. (p 81) According to this theory, the organization chart does not merely define a structure of work activity, it also creates a structure of attention, interpretation and decision-making. (p 81) Later organization design theorists such as Jay Galbraith showed how this kind of decision-making structure coped with uncertainty and information overload, either by reducing the need for information or by increasing the capacity to process information. (pp 82-83)
Nowadays, of course, much of this information processing capacity is provided by man-made systems. Writing in the mid 1980s, Morgan could already see the emergence of the virtual organization, embedded not in human activity but in computer networks. If it wasn't already, the organization-as-brain is now indisputably a sociotechnical system. The really big question, Morgan asks, is whether such organizations will also become more intelligent. (p84)
The problem here is that man-made systems (bureaucratic as well as automatic) tend towards instrumental rationality rather than substantial rationality. Such systems can produce goal-directed behaviour under four conditions. (p87)
To start with, Morgan makes two important distinctions. The first distinction is between two different notions of rationality, and the second involves two contrasting uses of the "brain" metaphor.
Mechanistic or bureaucratic organizations rely on what Morgan (following Karl Mannheim) calls "instrumental rationality", where people are valued for their ability to fit in and contribute to the efficient operation of a predetermined structure. Morgan contrasts this with "substantial rationality", where elements of organization are able to question the appropriateness of what they are doing and to modify their action to take account of new situations. Morgan states that the human brain possesses higher degrees of substantial rationality than any man-made system. (pp78-79)
Morgan also observes a common trend to use the term "brain" metaphorically to refer to a centralized planning or management function within an organization, the brain "of" the firm. Instead, Morgan wants to talk about brain-like capabilities distributed throughout the organization, the brain "as" the firm. Using the brain metaphor in this way leads to two important ideas. Firstly, that organizations are information processing systems, potentially capable of learning to learn. And secondly, that organizations may be holographic systems, in the sense that any part represents and can stand in for the whole. (p 80)
The first of these two ideas, organizations as information processing systems, goes back to the work of James March and Herbert Simon in the 1940s and 1950s. Simon's theory of decision-making leads us to understand organizations as kinds of institutionalized brains that fragment, routinize and bound the decision-making process in order to make it manageable. (p 81) According to this theory, the organization chart does not merely define a structure of work activity, it also creates a structure of attention, interpretation and decision-making. (p 81) Later organization design theorists such as Jay Galbraith showed how this kind of decision-making structure coped with uncertainty and information overload, either by reducing the need for information or by increasing the capacity to process information. (pp 82-83)
Nowadays, of course, much of this information processing capacity is provided by man-made systems. Writing in the mid 1980s, Morgan could already see the emergence of the virtual organization, embedded not in human activity but in computer networks. If it wasn't already, the organization-as-brain is now indisputably a sociotechnical system. The really big question, Morgan asks, is whether such organizations will also become more intelligent. (p84)
The problem here is that man-made systems (bureaucratic as well as automatic) tend towards instrumental rationality rather than substantial rationality. Such systems can produce goal-directed behaviour under four conditions. (p87)
- The capacity to sense, monitor and scan significant aspects of their environment
- The ability to relate this information to the operating norms that guide system behaviour
- Ability to detect significant deviations from these norms
- Ability to initiate corrective action when discrepancies are detected.
- Division of responsibilities cause a fragmentation of knowledge and attention.
- Bureaucratic accountability and asymmetric information produce ethical problems such as deception. (This is a form of the principal-agent problem.)
- Organizations also suffer from various forms of collective self-deception, resulting in a gap between "espoused theory" and "theory-in-use".
- Encourage and value openness and reflectivity. Accept error and uncertainty.
- Recognize the importance of exploring different viewpoints.
- Avoid imposing structures of action. Allow intelligence and direction to emerge.
- Create organizational structures and principles that help implement these principles.
- Redundancy of function - each individual or team has a broader range of knowledge and skills than is required for the immediate task-at-hand, thus building flexibility into the organization.
- Requisite variety - the internal diversity must match the challenges posed by the environment. All elements of an organization should embody critical dimensions of the environment.
- Minimal critical specification - allow each system to find its own form.
- Learning to learn - use autonomous intelligence and emergent connectivity to find novel and progressive solutions to complex problems.
- The realities of power and control. (p 108)
- The inertia stemming from existing assumptions and beliefs. (p 109)
Friday, February 22, 2008
Software + Services
This week I visited Microsoft campus in Reading, to hear some presentations on their Software-and-Service (S+S) strategy, and have a chat with Gianpaolo Carraro.
Phil Wainewright recently described Microsoft's S+S strategy as bunkum, and accused Gianpaolo of drinking too much Kool-Aid. Phil's point was that people didn't want to worry about buying software AND buying services.
However, Gianpaolo isn't really focusing on the commercial side of the equation. He spends most of his time talking about deployment. From this viewpoint, it makes sense in many situations to have a combination of stuff running on your own machines (called
But isn't it all software anyway? And who cares where the stuff is being run? Perhaps all of the people care some of the time, and some of the people care all of the time. I care when it affects my service level. For example, there are some places where broadband is unavailable, or at least very expensive. So if I want to work on an aeroplane, I may need to make sure the relevant documents are physically loaded onto my laptop beforehand.
The original vision of open distributed processing (ODP) included not only location transparency but other forms of transparency including migration and relocation. This means I don't notice when stuff moves around. Suppose I'm working on a bunch of documents that are currently on the server. Imagine my laptop knows my travel plans, knows that I'm going to be on an airplane this afternoon, works out which documents I'm going to need, and quietly and efficiently moves them while I'm in mid-edit, without dropping a comma.
I presume that Ray Ozzie, founder of Groove Networks and now Microsoft Chief Architect, understands these kind of requirements. He is pushing the S+S story hard.
But there is a conceptual problem with this semi-transparency - the fact that sometimes these aspects are visible and sometimes they aren't. ODP handles this by mandating several parallel viewpoints of a distributed system.
The CBDI method for service architecture and engineering (SAE) inherits this principle, although our viewpoints are not identical to the ODP ones. Meanwhile Microsoft has four perspectives, but these are defined in terms of process: Build, Run, Consume and Monetize.
When you want to think about deployment and location, you use one viewpoint; when you want to think about functionality and semantics, you use a different viewpoint; and when you want to think about commercial terms, costs and liabilities, you use a different one again.
I think this helps to explain the apparent disagreement between Gianpaolo and Phil. The S+S world looks very different from a commercial/organizational viewpoint and a deployment viewpoint. When I raised this with Gianpaolo, he made the valid point that these viewpoints cannot be totally isolated from one another. What happens from a deployment viewpoint inevitably has an impact upon the commercial viewpoint, and vice versa. Technological progress may help us reduce this impact, but it isn't going to disappear altogether any time soon.
But that doesn't mean the viewpoints simply merge into one unmanageable mess. The viewpoints are important precisely because they help us understand how things in one viewpoint relate to things in another viewpoint. And this in turn raises another important challenge. How are architects supposed to manage all this complexity? If you try to optimize the commercial/organizational arrangements alone, you may get unsatisfactory performance or service levels; if you try to optimize the physical deployment alone, you may not get the best commercial deal or organization structure; and if you try to optimize everything simultaneously, your head will explode. Gianpaolo's best advice at present is to do things at a very coarse level of granularity, which reduces the number of permutations to consider. But that's clearly not ideal.
The industry currently lacks decent tools to support this kind of architectural reasoning. We don't even have decent notations - you aren't going to get very far with colour-coded UML diagrams.
But what about enterprise SOA? Some people are working towards a world where all software is rendered as services - whether it is running on an enterprise server safely inside the firewall, or on a third-party server farm in Mumbai or Kiev. (By Day In Bollywood, By Night In The Ukraine.) Some of the same technical and conceptual issues here, but the terminology is different. S+S suggests that it only counts as a service if it is remote - this clashes with the enterprise SOA terminology.
Software-and-Services? The name may well generate some misunderstanding, especially if it is taken too literally, but that's probably true of any jargon. Not the name I'd have chosen, but then I'm not in charge of Microsoft's marketing strategy. Gianpaolo and his team have been working hard, producing some interesting material and examples, and the tools and techniques and future challenges coming out of this kind of work will undoubtedly be relevant to Enterprise SOA as well.
References
Gianpaolo Carraro: S+S: Real or have I drunk too much Kool-Aid? :) (Feb 2008)
Phil Wainewright: Microsoft Kool-Aid and the cloud
Gianpaolo Carraro: I think Phil drank the Kool-Aid too but he has not realized it yet :) (Feb 2008)
Ray Ozzie: MIX07 keynote, interview
Broadway Musical: "By day in Hollywood, by night in the Ukraine"
Reference Model for Open Distributed Processing (RM-ODP): Wikipedia, specification
Phil Wainewright recently described Microsoft's S+S strategy as bunkum, and accused Gianpaolo of drinking too much Kool-Aid. Phil's point was that people didn't want to worry about buying software AND buying services.
However, Gianpaolo isn't really focusing on the commercial side of the equation. He spends most of his time talking about deployment. From this viewpoint, it makes sense in many situations to have a combination of stuff running on your own machines (called
software) and stuff running on other people's machines (called
services). Actually that's what most users have anyway - both corporate users and domestic consumers.
But isn't it all software anyway? And who cares where the stuff is being run? Perhaps all of the people care some of the time, and some of the people care all of the time. I care when it affects my service level. For example, there are some places where broadband is unavailable, or at least very expensive. So if I want to work on an aeroplane, I may need to make sure the relevant documents are physically loaded onto my laptop beforehand.
The original vision of open distributed processing (ODP) included not only location transparency but other forms of transparency including migration and relocation. This means I don't notice when stuff moves around. Suppose I'm working on a bunch of documents that are currently on the server. Imagine my laptop knows my travel plans, knows that I'm going to be on an airplane this afternoon, works out which documents I'm going to need, and quietly and efficiently moves them while I'm in mid-edit, without dropping a comma.
I presume that Ray Ozzie, founder of Groove Networks and now Microsoft Chief Architect, understands these kind of requirements. He is pushing the S+S story hard.
But there is a conceptual problem with this semi-transparency - the fact that sometimes these aspects are visible and sometimes they aren't. ODP handles this by mandating several parallel viewpoints of a distributed system.
The CBDI method for service architecture and engineering (SAE) inherits this principle, although our viewpoints are not identical to the ODP ones. Meanwhile Microsoft has four perspectives, but these are defined in terms of process: Build, Run, Consume and Monetize.
When you want to think about deployment and location, you use one viewpoint; when you want to think about functionality and semantics, you use a different viewpoint; and when you want to think about commercial terms, costs and liabilities, you use a different one again.
I think this helps to explain the apparent disagreement between Gianpaolo and Phil. The S+S world looks very different from a commercial/organizational viewpoint and a deployment viewpoint. When I raised this with Gianpaolo, he made the valid point that these viewpoints cannot be totally isolated from one another. What happens from a deployment viewpoint inevitably has an impact upon the commercial viewpoint, and vice versa. Technological progress may help us reduce this impact, but it isn't going to disappear altogether any time soon.
But that doesn't mean the viewpoints simply merge into one unmanageable mess. The viewpoints are important precisely because they help us understand how things in one viewpoint relate to things in another viewpoint. And this in turn raises another important challenge. How are architects supposed to manage all this complexity? If you try to optimize the commercial/organizational arrangements alone, you may get unsatisfactory performance or service levels; if you try to optimize the physical deployment alone, you may not get the best commercial deal or organization structure; and if you try to optimize everything simultaneously, your head will explode. Gianpaolo's best advice at present is to do things at a very coarse level of granularity, which reduces the number of permutations to consider. But that's clearly not ideal.
The industry currently lacks decent tools to support this kind of architectural reasoning. We don't even have decent notations - you aren't going to get very far with colour-coded UML diagrams.
But what about enterprise SOA? Some people are working towards a world where all software is rendered as services - whether it is running on an enterprise server safely inside the firewall, or on a third-party server farm in Mumbai or Kiev. (By Day In Bollywood, By Night In The Ukraine.) Some of the same technical and conceptual issues here, but the terminology is different. S+S suggests that it only counts as a service if it is remote - this clashes with the enterprise SOA terminology.
Software-and-Services? The name may well generate some misunderstanding, especially if it is taken too literally, but that's probably true of any jargon. Not the name I'd have chosen, but then I'm not in charge of Microsoft's marketing strategy. Gianpaolo and his team have been working hard, producing some interesting material and examples, and the tools and techniques and future challenges coming out of this kind of work will undoubtedly be relevant to Enterprise SOA as well.
References
Gianpaolo Carraro: S+S: Real or have I drunk too much Kool-Aid? :) (Feb 2008)
Phil Wainewright: Microsoft Kool-Aid and the cloud
Gianpaolo Carraro: I think Phil drank the Kool-Aid too but he has not realized it yet :) (Feb 2008)
Ray Ozzie: MIX07 keynote, interview
Broadway Musical: "By day in Hollywood, by night in the Ukraine"
Reference Model for Open Distributed Processing (RM-ODP): Wikipedia, specification
Saturday, March 19, 2005
Component-Based Business
My book on the Component-Based Business was published in 2001. At that time, Component-Based Software Engineering (CBSE) was all the rage (kindof) and I wanted to demonstrate that the same principles could be applied to the design and construction of business as to the design and construction of software.
At that time, there was a fundamental tension in the CBSE world, which I can very crudely characterize as follows: On the one hand, there were OO people who, when they thought of components at all, saw them as glorified objects. On the other hand there were the ODP/CORBA people who thought of components as inherently distributed service packages, but who were often prevented from implementing interesting and viable solutions by the prevailing technological state-of-the-art. (I did say this was a crude characterization, I know there are loads of exceptions, but still ...)
My own alignment was always with the service-oriented rather than the object-oriented. (Historical note: I worked on ANSA/ODP in the early 1990s, participating in the Enterprise Computing Project within the ODSA programme.) In my book, I talk about the fundamental principles of decomposing business into independent chunks, from a component perspective, but I also devote a great deal of space to the (sociotechnical) relationships between the chunks, and to the emergent properties of the whole ecosystem that is composed of these chunks.
In the past few years, there has been some huge shifts both in the technology itself, and in the way people are thinking about the technology. People are starting to become much more comfortable in thinking about service-orientation, and the technology is becoming more credible. For my part, I have started to talk less about the Component-Based Business and more about the Service-Based Business, but I see this as a shift in emphasis rather than a fundamental shift in perspective.
Elsewhere, some people are starting to take much more interest in the potential business impact of web services and SOA. (In terms of RM-ODP, this is a perfectly valid separation of concerns: other people can worry about the Technology and Engineering viewpoints, leaving me to devote my attention to the Enterprise and Information viewpoints.) As one indicator of this, we can see people starting to talk seriously about the component-based business as well as the service-based business. For example, IBM has been promoting a method called Component Business Modeling (CBM), which serves as a front-end to its Service-Oriented Modeling Approach (SOMA). However, based on the materials I have seen, I don't think that IBM's CBM represents the full power of the component-based business approach. (See separate posting on my Software Industry Analysis weblog.)
In my view, the main challenges of the component-based (/service-based) business include those of governance. A component-based approach must have a clear strategy for managing complexity, not just denying or suppressing complexity, and is probably going to draw ideas from complex systems engineering (systems, not software). This calls, among other things, for new kinds of modelling and new approaches to architecture.
There are two reasons why it might be a good time for me to produce an updated edition of my book.
At that time, there was a fundamental tension in the CBSE world, which I can very crudely characterize as follows: On the one hand, there were OO people who, when they thought of components at all, saw them as glorified objects. On the other hand there were the ODP/CORBA people who thought of components as inherently distributed service packages, but who were often prevented from implementing interesting and viable solutions by the prevailing technological state-of-the-art. (I did say this was a crude characterization, I know there are loads of exceptions, but still ...)
My own alignment was always with the service-oriented rather than the object-oriented. (Historical note: I worked on ANSA/ODP in the early 1990s, participating in the Enterprise Computing Project within the ODSA programme.) In my book, I talk about the fundamental principles of decomposing business into independent chunks, from a component perspective, but I also devote a great deal of space to the (sociotechnical) relationships between the chunks, and to the emergent properties of the whole ecosystem that is composed of these chunks.
In the past few years, there has been some huge shifts both in the technology itself, and in the way people are thinking about the technology. People are starting to become much more comfortable in thinking about service-orientation, and the technology is becoming more credible. For my part, I have started to talk less about the Component-Based Business and more about the Service-Based Business, but I see this as a shift in emphasis rather than a fundamental shift in perspective.
Elsewhere, some people are starting to take much more interest in the potential business impact of web services and SOA. (In terms of RM-ODP, this is a perfectly valid separation of concerns: other people can worry about the Technology and Engineering viewpoints, leaving me to devote my attention to the Enterprise and Information viewpoints.) As one indicator of this, we can see people starting to talk seriously about the component-based business as well as the service-based business. For example, IBM has been promoting a method called Component Business Modeling (CBM), which serves as a front-end to its Service-Oriented Modeling Approach (SOMA). However, based on the materials I have seen, I don't think that IBM's CBM represents the full power of the component-based business approach. (See separate posting on my Software Industry Analysis weblog.)
In my view, the main challenges of the component-based (/service-based) business include those of governance. A component-based approach must have a clear strategy for managing complexity, not just denying or suppressing complexity, and is probably going to draw ideas from complex systems engineering (systems, not software). This calls, among other things, for new kinds of modelling and new approaches to architecture.
There are two reasons why it might be a good time for me to produce an updated edition of my book.
- This topic is now getting much hotter, and I think people may be more ready to accept some of my more radical suggestions.
- I am now in a position to update some of the material, reference more recent technological opportunities and threats, and introduce a lot of practical business examples.
Subscribe to:
Posts (Atom)