A cabbie asked @jkuramot to enter his destination into the GPS. @dahowlett suggests this is because he didn't speak good English. @jkuramot confirms that the driver didn't speak English very well but adds that "this was his go-to move".
The reason we are talking about this fragment of service design is that it is unusual in this context: we normally expect the driver to enter the destination into his navigation device. But the normal procedure is prone to error; the pasenger may not speak clearly, the driver may not understand correctly, there may be a lot of background noise: the passenger arrives at the wrong destination and it's the driver's fault.
However, if the passenger enters the destination directly into the navigation device, then any error is the passenger's fault. Many service providers in other areas now follow this pattern; shifting responsibility onto the customer may help to reduce administration costs, but more importantly reduces the service provider's liability. But if the customer is not able to perform these tasks easily and accurately, this kind of shift adds more to the cost and risk for the customer than it reduces for the supplier, and therefore diminishes total value. See my review of The Support Economy.
Asking the customer to do the work makes an assumption about the customer's capability. I don't know Jake personally, but he looks from his photo and his Twitter profile like someone who would know how to operate this kind of device. The driver may have had the same impression; it is conceivable that he would have treated Jake's grandmother differently. Whereas if the device (belonging to the driver) is unusual and difficult to use, we would always insist that the driver should operate it. Self-service only works if the interface design offers a reasonable level of usability.
The other difference between the passenger and the driver is the question of which is more familiar with the destination. When I get a cab home from the airport, obviously I know my address better than the driver does. But when I arrive in a strange city, I expect the cab drivers to be more familiar with the hotels than I am: if I get the name of the hotel slightly wrong, the driver should ask if I really meant something else, rather than drive for an hour to a hotel in the next city whose name exactly matches what I said.
By the way, Google has been correcting our searches for a long time now, but has now chosen to issue a series of advertisements in which this correction (and the collection of vast amounts of data to make this correction possible) is highlighted as a service enhancement feature. See my note Towards a VPEC-T analysis of Google. This kind of service enhancement is unavailable if the driver takes himself out of the loop, and regards his job as merely enacting a specification agreed between the customer and an electronic device.
Tuesday, November 29, 2011
Thursday, November 17, 2011
Meta-Architecture (Yawn)
#entarch people seem to spend a lot of time defining the building blocks of architecture, and insisting on the correct definition. Some of my friends have been doing it on Twitter recently, and I've certainly participated in this kind of debate myself in the past.
There are several different reference models that attempt to answer such questions, at varying levels of detail and abstraction. Here are just a few of these models.
The Wikipedia page on Technical Architecture contains the following paragraph on Meta-Architecture, lifted practically word-for-word from a white paper on the Visual Architecting Process (Bredemeyer Consulting, pdf) by Ruth Malan and Dana Bredemeyer. Malan and Bredemeyer also appear to be behind the EWITA (Enterprise-Wide Information Technology Architecture) initiative.
Yawn. I can see that this kind of thing might be necessary for architecture management, especially across a large organization or sector. Tom Graves points out that we can view a reference model as a set of job descriptions. But explicitly allocating time to meta-architectural research??
My worry about meta-architecture is that it distracts from real architecture. If I have a lump of business activity, I'm not sure I understand it any better whether I label it as a function or a process or a capability or a service. What really helps me to understand this lump better, and to use that understanding in improving the business, is analysing how it varies by context (differentiation) and how it interacts with other lumps of business activity (integration). And it's more important to see whether a strategy or roadmap is any good than whether it's been correctly labelled. The challenge of architecture isn't classification, it is coordination and quality.
For my bootcamp next week, I don't want to spend any time on Functions versus Capabilities, Goals versus Objectives versus Principles, Strategies versus Roadmaps, and all that meta-architecture stuff. Some architecture courses seem to spend so much time on meta-architecture that they don't have any time left for real architecture. And one can waste a lot of time on the Internet trying to promote one's favourite definition of any of these terms. My winter's resolution - to keep out of these debates. (I may not always manage to do this.)
book now Business Architecture Bootcamp (November 22-23, 2011)
book now Workshop: Organizational Intelligence (November 24th, 2011)
- @chrisdpotts Appearing to not know the difference between a strategy and a roadmap can damage your reputation and influence.
There are several different reference models that attempt to answer such questions, at varying levels of detail and abstraction. Here are just a few of these models.
- ISEB Enterprise and Solution Architecture Reference Model (BCS Version 3.0 pdf)
- CBDI Service Architecture and Engineering Reference Framework (recently updated to include Cloud Computing)
- SOA Reference Model (OASIS pdf)
The Wikipedia page on Technical Architecture contains the following paragraph on Meta-Architecture, lifted practically word-for-word from a white paper on the Visual Architecting Process (Bredemeyer Consulting, pdf) by Ruth Malan and Dana Bredemeyer. Malan and Bredemeyer also appear to be behind the EWITA (Enterprise-Wide Information Technology Architecture) initiative.
"First, the architectural vision is formulated, to act as a beacon guiding decisions during the rest of system structuring. It is a good practice to explicitly allocate time for research in documented architectural styles, patterns, dominant designs and reference architectures, other architectures your organization, competitors, partners, or suppliers have created or you find documented in the literature, etc. Based on this study, and your and the team’s past experience, the meta-architecture is formulated. This includes the architectural style, concepts, mechanisms and principles that will guide the architecture team during the next steps of structuring."
Yawn. I can see that this kind of thing might be necessary for architecture management, especially across a large organization or sector. Tom Graves points out that we can view a reference model as a set of job descriptions. But explicitly allocating time to meta-architectural research??
My worry about meta-architecture is that it distracts from real architecture. If I have a lump of business activity, I'm not sure I understand it any better whether I label it as a function or a process or a capability or a service. What really helps me to understand this lump better, and to use that understanding in improving the business, is analysing how it varies by context (differentiation) and how it interacts with other lumps of business activity (integration). And it's more important to see whether a strategy or roadmap is any good than whether it's been correctly labelled. The challenge of architecture isn't classification, it is coordination and quality.
For my bootcamp next week, I don't want to spend any time on Functions versus Capabilities, Goals versus Objectives versus Principles, Strategies versus Roadmaps, and all that meta-architecture stuff. Some architecture courses seem to spend so much time on meta-architecture that they don't have any time left for real architecture. And one can waste a lot of time on the Internet trying to promote one's favourite definition of any of these terms. My winter's resolution - to keep out of these debates. (I may not always manage to do this.)
book now Business Architecture Bootcamp (November 22-23, 2011)
book now Workshop: Organizational Intelligence (November 24th, 2011)
Sunday, November 06, 2011
Conceptual Modelling - Why Theory
@dougnewdick asks Why Bother With Concepts? In his answer, he quotes the Gang of Four song Why Theory. "Each day seems like a natural fact/but what we think changes how we act."
I think there is a critical difference between two interpretations of the term "Conceptual Architecture". I'd describe Doug's sample conceptual architecture as essentially a component architecture, which happens to be at the "conceptual" level of abstraction. In other words, it provides a conceptual understanding of how the components work together.
That's not at all the same as understanding how the concepts themselves work together, which is what I think one needs to satisfy the Gang of Four requirement for an architecture-of-concepts, and which would also be implied by Doug's reference to the Wikipedia article on Philosophical Analysis.
The Wikipedia article mentions critiques of the traditional approach to philosophical analysis by Quine and Wittgenstein. I have used some of their ideas - although with no claim to profundity - in my own approach to conceptual modelling. See for example my 1992 book on Information Modelling.
To take a concrete example, if we are going to build systems and management practices to anticipate competitor behaviour, it might help have to have a robust concept of COMPETITOR. I once worked with a company that thought it knew which its competitors were, and were quite indignant when a competitive threat appeared from an entirely different quarter. Traditional philosophical analysis implies you can fully characterize a concept like COMPETITOR in advance, but Wittgenstein and Quine teach us to be cautious of monothetic, appearently objective conceptual definitions.
One of the problems with conceptual models is that they are often too generic, and therefore insufficiently meaningful. Anyone who has ever been on a data modelling course can produce a model with CUSTOMER and ORDER and PRODUCT. But proper conceptual analysis entails taking concepts apart to understand how they work in a particular business context. Where do products come from, what does it mean to be a product, how do products evolve, what are the essential and non-essential differences between products? Why do we have this many products, and what are the forces that would result in increasing or decreasing the number of products? What does the business know about products, and what does the business want to know?
Doug's post was prompted by Peter Bakker's post Factual Architecture, which expressed a concern that concepts can be too abstract and unverifiable – failing to connect with audiences, failing to connect with reality. The way that some architects try to verify concepts is to demonstrate how the concepts could be represented in some technical system - but I prefer to encourage stakeholders to verify concepts in the business domain itself. This leads me to a slightly different notion of Factual Architecture, which would provide an empirical business context in which the business concepts and knowledge can be grounded.
Is this really the way it is? Or a contract in our mutual interest?
I think there is a critical difference between two interpretations of the term "Conceptual Architecture". I'd describe Doug's sample conceptual architecture as essentially a component architecture, which happens to be at the "conceptual" level of abstraction. In other words, it provides a conceptual understanding of how the components work together.
That's not at all the same as understanding how the concepts themselves work together, which is what I think one needs to satisfy the Gang of Four requirement for an architecture-of-concepts, and which would also be implied by Doug's reference to the Wikipedia article on Philosophical Analysis.
The Wikipedia article mentions critiques of the traditional approach to philosophical analysis by Quine and Wittgenstein. I have used some of their ideas - although with no claim to profundity - in my own approach to conceptual modelling. See for example my 1992 book on Information Modelling.
To take a concrete example, if we are going to build systems and management practices to anticipate competitor behaviour, it might help have to have a robust concept of COMPETITOR. I once worked with a company that thought it knew which its competitors were, and were quite indignant when a competitive threat appeared from an entirely different quarter. Traditional philosophical analysis implies you can fully characterize a concept like COMPETITOR in advance, but Wittgenstein and Quine teach us to be cautious of monothetic, appearently objective conceptual definitions.
One of the problems with conceptual models is that they are often too generic, and therefore insufficiently meaningful. Anyone who has ever been on a data modelling course can produce a model with CUSTOMER and ORDER and PRODUCT. But proper conceptual analysis entails taking concepts apart to understand how they work in a particular business context. Where do products come from, what does it mean to be a product, how do products evolve, what are the essential and non-essential differences between products? Why do we have this many products, and what are the forces that would result in increasing or decreasing the number of products? What does the business know about products, and what does the business want to know?
Doug's post was prompted by Peter Bakker's post Factual Architecture, which expressed a concern that concepts can be too abstract and unverifiable – failing to connect with audiences, failing to connect with reality. The way that some architects try to verify concepts is to demonstrate how the concepts could be represented in some technical system - but I prefer to encourage stakeholders to verify concepts in the business domain itself. This leads me to a slightly different notion of Factual Architecture, which would provide an empirical business context in which the business concepts and knowledge can be grounded.
Is this really the way it is? Or a contract in our mutual interest?
Thursday, November 03, 2011
Dimensions of EA maturity 2
#entarch @Cybersal asked me to expand on my previous post on three dimensions of EA maturity.
This is about regarding EA as a tool, a means to some ends. What outcomes are expected from EA?
For example, do we regard EA as a planning tool, a coordination and governance tool, or an asset management tool? Or some combination of these?
This is about the power and responsibility of EA as a function. What tasks are delegated to EA, and by whom? How is EA held accountable for a given set of outcomes?
For example, does EA play an advisory role or gatekeeper role? Does EA report to the CIO or the CEO?
How large is the system for which EA is accountable? What issues and concerns are a legitimate part of the EA agenda? Is EA restricted to formal IT systems, does it include informal IT systems (such as social networking), or does it also include business and organization issues? In other words, does Enterprise Architecture really mean Enterprise IT Architecture or Enterprise Data Architecture?
And does EA include ways of understanding the enterprise as a complex and dynamic human activity system, not merely as a fixed array of automated and bureaucratic functions?
In What is Enterprise Architecture? and What's Wrong With Enterprise Architecture?, I analysed EA from five perspectives, but not all these perspectives are relevant to understanding EA maturity. The three dimensions I'm defining here can be mapped as a rough simplification from these five perspectives for maturity purposes. When people (including myself) talk about Next Generation EA, this usually means some shift in one or more of these three dimensions.
Instrumentality
This is about regarding EA as a tool, a means to some ends. What outcomes are expected from EA?
For example, do we regard EA as a planning tool, a coordination and governance tool, or an asset management tool? Or some combination of these?
Agency
This is about the power and responsibility of EA as a function. What tasks are delegated to EA, and by whom? How is EA held accountable for a given set of outcomes?
For example, does EA play an advisory role or gatekeeper role? Does EA report to the CIO or the CEO?
Scope
How large is the system for which EA is accountable? What issues and concerns are a legitimate part of the EA agenda? Is EA restricted to formal IT systems, does it include informal IT systems (such as social networking), or does it also include business and organization issues? In other words, does Enterprise Architecture really mean Enterprise IT Architecture or Enterprise Data Architecture?
And does EA include ways of understanding the enterprise as a complex and dynamic human activity system, not merely as a fixed array of automated and bureaucratic functions?
In What is Enterprise Architecture? and What's Wrong With Enterprise Architecture?, I analysed EA from five perspectives, but not all these perspectives are relevant to understanding EA maturity. The three dimensions I'm defining here can be mapped as a rough simplification from these five perspectives for maturity purposes. When people (including myself) talk about Next Generation EA, this usually means some shift in one or more of these three dimensions.
Tuesday, November 01, 2011
Found in Translation
Vaughan Merlyn explains Why the Notion of the IT Organization is Deeply Flawed!
Gartner's definition of enterprise architecture is also based on the concept of translation
But we know that translation is prone to error (as Carl Bate and Nigel Green demonstrate in their book Lost in Translation) and indeterminacy (Quine).
Deloitte Consulting uses the term "Lost in Translation" to market its enterprise architecture practice,
illustrated with what appears to be a Chinese version of the Zachman framework.
"Having an IT organization that translates business requirements into IT specifications and solutions is always, at best, a flawed approach" [via Ross Jimenez]
Gartner's definition of enterprise architecture is also based on the concept of translation
"EA is the process of translating business vision and strategy into effective enterprise change." [via Nick Gall]
But we know that translation is prone to error (as Carl Bate and Nigel Green demonstrate in their book Lost in Translation) and indeterminacy (Quine).
*****
Deloitte Consulting uses the term "Lost in Translation" to market its enterprise architecture practice,
illustrated with what appears to be a Chinese version of the Zachman framework.
 |
"Many IT infrastructures are set up without a common language in place that cuts across different enterprises, making it difficult for strategic decisions to be effectively translated into the organization’s technology foundation. That’s where enterprise architecture (EA) can make a difference."
"Deloitte has access to a full range of capabilities in consulting, tax, audit and finance worldwide. This broad range of capabilities allows us to provide services to assist with any enterprise architecture challenge."But just because a large service firm has access to a broad range of different capabilities, it doesn't automatically follow that these capabilities are joined up, or that the firm is able to translate effectively between different professional disciplines. See my post From 'Organizational Intelligence' to 'Ability to Execute'.
Subscribe to:
Posts (Atom)