Following my post on Ghetto Wifi, I passed a pub yesterday with a sign "Free wifi for customers only".
Thought of another perspective on this problem. How long do you remain a customer after you have bought a drink? One hour? One day? Is there some kind of dwindling right to use the facilities as time passes? If you bought a coffee within the last half hour then you are a full-status customer with full rights; if you haven't bought a coffee in the last two hours, then maybe your customer rights are weaker.
Let's look at some more examples. If you have lunch in a restaurant, and then do some shopping, can you then go back to the restaurant to use the toilet before driving home? (If you left a reasonable tip, then maybe the aura of "customerhood" still lingers.) If you have lunch in a pub, can you leave your car in the "customers only" car park for the rest of the day? Some establishments have strict limits - for example, some supermarkets have free parking for two hours, and then start clamping or ticketing people who stay longer.
Obviously there will always be some people to try to cheat - to use the facilities without buying anything at all. The point here isn't whether this is possible, or the extent to which the establishment tries to make you feel welcome (in order to convert you to future customer) or unwelcome (to reserve its facilities for genuine customers), but what moral rights you have in the first place.
Some people might think that the "customers only" goes without saying - you shouldn't need a notice - but presumably there are some people whose behaviour will be influenced by a reminder that these facilities are intended for genuine customers.
So it comes down to a question of what counts as a genuine customer, and for how long.
Showing posts with label unbundling. Show all posts
Showing posts with label unbundling. Show all posts
Friday, June 04, 2010
Wednesday, June 02, 2010
Ghetto Wifi
@TimHarford answers a reader's letter in his Financial Times Dear Economist column: "Why do cafes offer free wireless if I'm not allowed to use it?"
The reader complains about being politely asked to vacate a table at lunchtime, so that more paying customers could be accommodated. Should the coffee shop offer wireless internet access if it isn’t willing to accept the opportunity cost associated with it, rhetorically asks said reader?
As a matter of fact, the wireless is irrelevant. The problem of customers hogging tables for hours existed long before computers. The scarce resource (especially at lunchtime) is the table. (Especially the table next to an electricity socket.)
As Tim points out in his column, the lunchtime opportunity cost of letting someone take up a table for four is substantial, while the wireless access, cheap to provide at any time, is a side-issue. But Tim is more polite to his reader than the reader probably deserves, and he fails to point out the false premise in the question. Of course the customer is expected and encouraged to use the facilities of the cafe (table, wifi, toilets) as well as helping herself to milk and sugar. But there is an implicit notion of proportionality: you don't walk off with half a kilo of sugar; you are allowed to use the free wifi, but that's not an unrestricted right; and buying a single cup of coffee doesn't entitle you to sit there all day. (There is a similar dispute about the ethics of making Ghetto Latte.)
Even impoverished writers, who try to make a cup of coffee last as long as possible while writing the next Harry Potter, are aware that there are limits. JK Rowling herself says on her website "the best writing cafe ... has staff who don't glower at you if you sit there too long" (Places to Write). In other words, she doesn't think she has an automatic right to sit there too long, and she appreciates those cafes that tolerate her stretching the limits.
As a non-economist, I'd like to draw attention to two aspects of this. The first is the readiness of Tim and his readers to frame the consumption of coffee and wifi as an economic transaction. "I bought this coffee with free internet access, and I'm entitled to my economic rights." There is no sense of a social relationship between the cafe owner and the customer, or the idea that the customer might vacate the table at lunchtime before being asked, out of consideration for the cafe owner's ability to make a reasonable living.
The second is the irrelevant foregrounding of the wifi issue, suggesting that the reader wishes to see internet access as a primary economic issue. Perhaps this reader is one of those who would make a fetish out of net neutrality, and would see any restrictions on internet access (including this dastardly cafe owner denying me free and unlimited wifi) as a gross violation of some fundamental principle.
See also Ghetto Wifi 2 (June 2010), Ghetto Workspace (August 2025)
In January 2014, a flurry of press stories about a radical new way of solving this problem. A cafe in East London (called Ziferblat) now offers free coffee, free biscuits and free wifi. You pay for the time - 3p per minute.
Sources: Ziferblat website, Daily Mail, Daily Telegraph, The Guardian, Time Out.
See also: @BBCNewsMagazine, The Etiquette of Coffee Shop Lounging (16 Jan 2014)
See also @BBCNewsMagazine, The generation dependent on the phone charger (15 March 2014)
Update 15 March 2014
The reader complains about being politely asked to vacate a table at lunchtime, so that more paying customers could be accommodated. Should the coffee shop offer wireless internet access if it isn’t willing to accept the opportunity cost associated with it, rhetorically asks said reader?
As a matter of fact, the wireless is irrelevant. The problem of customers hogging tables for hours existed long before computers. The scarce resource (especially at lunchtime) is the table. (Especially the table next to an electricity socket.)
As Tim points out in his column, the lunchtime opportunity cost of letting someone take up a table for four is substantial, while the wireless access, cheap to provide at any time, is a side-issue. But Tim is more polite to his reader than the reader probably deserves, and he fails to point out the false premise in the question. Of course the customer is expected and encouraged to use the facilities of the cafe (table, wifi, toilets) as well as helping herself to milk and sugar. But there is an implicit notion of proportionality: you don't walk off with half a kilo of sugar; you are allowed to use the free wifi, but that's not an unrestricted right; and buying a single cup of coffee doesn't entitle you to sit there all day. (There is a similar dispute about the ethics of making Ghetto Latte.)
Even impoverished writers, who try to make a cup of coffee last as long as possible while writing the next Harry Potter, are aware that there are limits. JK Rowling herself says on her website "the best writing cafe ... has staff who don't glower at you if you sit there too long" (Places to Write). In other words, she doesn't think she has an automatic right to sit there too long, and she appreciates those cafes that tolerate her stretching the limits.
As a non-economist, I'd like to draw attention to two aspects of this. The first is the readiness of Tim and his readers to frame the consumption of coffee and wifi as an economic transaction. "I bought this coffee with free internet access, and I'm entitled to my economic rights." There is no sense of a social relationship between the cafe owner and the customer, or the idea that the customer might vacate the table at lunchtime before being asked, out of consideration for the cafe owner's ability to make a reasonable living.
The second is the irrelevant foregrounding of the wifi issue, suggesting that the reader wishes to see internet access as a primary economic issue. Perhaps this reader is one of those who would make a fetish out of net neutrality, and would see any restrictions on internet access (including this dastardly cafe owner denying me free and unlimited wifi) as a gross violation of some fundamental principle.
See also Ghetto Wifi 2 (June 2010), Ghetto Workspace (August 2025)
In January 2014, a flurry of press stories about a radical new way of solving this problem. A cafe in East London (called Ziferblat) now offers free coffee, free biscuits and free wifi. You pay for the time - 3p per minute.
Sources: Ziferblat website, Daily Mail, Daily Telegraph, The Guardian, Time Out.
See also: @BBCNewsMagazine, The Etiquette of Coffee Shop Lounging (16 Jan 2014)
See also @BBCNewsMagazine, The generation dependent on the phone charger (15 March 2014)
Update 15 March 2014
Monday, October 09, 2006
Ghetto Latte
It seems that some Starbucks customers have developed the practice of ordering a cheap coffee, and then using the free milk and other condiments to convert it into a more expensive product. This is known as a ghetto latte or bootleg latte. There has been some discussion as to the ethics of this practice.
As Randy points out, this raises a more general question "under what circumstances can users deviate from the intended uses of producers" - a question that Randy links to digital rights management and the Digital Millennium Copyright Act.
Let's look at this form of arbitrage from a service-oriented perspective. The provider (in this case Starbucks) provides two products - one relatively expensive (the latte) and one free (the milk). The consumer composes these two products in a manner that deviates from the provider's evident intentions and expectations, in order to obtain something of an equivalent value but at a lower price. This can be regarded either as a form of clever repurposing, or as a minor form of abuse. The provider apparently tolerates this not just because the cost of tolerating the practice is less than the cost of enforcing compliance with the intended pricing scheme, but also because the opportunity of expanding its business more than compensates for any extra complexity and confusion.
Could Starbucks have anticipated this? Well this is a pretty simple case, but in general, it may not be possible for a service provider to calculate every possible combination of its products and services, and it may not be desirable for the service provider to suppress or preempt the imagination and ingenuity of its customers. (There are lots of consumers, many of them using the service every day, so we should expect a considerable proportion of such innovations to emerge from the consumer side.) Instead, service providers need to be flexible and robust enough to provide a reasonable service under unforeseen conditions.
HT @sladner
Related Posts
Ghetto Wifi 1 2 (June 2010)
Starbucks Test (November 2006)
Notes
Charles Leroux, The bootleg latte: Would you make one? (Chicago Tribune, 5 October 2006)
Randy Picker, Hacking Starbucks (University of Chicago Law School Faculty Blog, 6 October 2006)
Hat Tip Tomorrows Fish and Chip Paper
Updated 19 September 2019
As Randy points out, this raises a more general question "under what circumstances can users deviate from the intended uses of producers" - a question that Randy links to digital rights management and the Digital Millennium Copyright Act.
Let's look at this form of arbitrage from a service-oriented perspective. The provider (in this case Starbucks) provides two products - one relatively expensive (the latte) and one free (the milk). The consumer composes these two products in a manner that deviates from the provider's evident intentions and expectations, in order to obtain something of an equivalent value but at a lower price. This can be regarded either as a form of clever repurposing, or as a minor form of abuse. The provider apparently tolerates this not just because the cost of tolerating the practice is less than the cost of enforcing compliance with the intended pricing scheme, but also because the opportunity of expanding its business more than compensates for any extra complexity and confusion.
Could Starbucks have anticipated this? Well this is a pretty simple case, but in general, it may not be possible for a service provider to calculate every possible combination of its products and services, and it may not be desirable for the service provider to suppress or preempt the imagination and ingenuity of its customers. (There are lots of consumers, many of them using the service every day, so we should expect a considerable proportion of such innovations to emerge from the consumer side.) Instead, service providers need to be flexible and robust enough to provide a reasonable service under unforeseen conditions.
Just recalled, as I was readying to go grab afternoon coffee, that I was so broke in first year uni that I couldn’t afford to buy coffee on campus. I’d bring tetley tea bags and ask for hot water at the cafeteria and then I’d sneak milk and sweetener from the condiment stand.— Dr Fish Philosopher🐟🌿 (@ZoeSTodd) September 19, 2019
HT @sladner
Related Posts
Ghetto Wifi 1 2 (June 2010)
Starbucks Test (November 2006)
Notes
Charles Leroux, The bootleg latte: Would you make one? (Chicago Tribune, 5 October 2006)
Randy Picker, Hacking Starbucks (University of Chicago Law School Faculty Blog, 6 October 2006)
Hat Tip Tomorrows Fish and Chip Paper
Updated 19 September 2019
Tuesday, April 11, 2006
Loose Coupling 2
Is loose coupling a defining characteristic of the service-based business and/or a core principle of SOA? ZDnet's analysts have been producing a set of IT commandments (13 at the last count), and Joe McKendrick's latest contribution is Thou Shalt Loosely Couple.
Joe quotes John Hagel's definition of loose coupling, which refers to reduced interdependencies between modules or components, and consequently reduced interoperability risk. Hagel clearly intends this definition to apply to dependencies between business units, not just technical artefacts. I think this is fine as far as it goes, but is not precise enough to my taste.
In his post The Developer's View of SOA: Just adding complexity?, Ron Ten-Hove (Sun Microsystems) defines loose coupling in terms of knowledge - "the minimization of the "knowledge" a service consumer has of a service provider it is is using, and vice versa".
(It is surely possible to link these defining notions - interoperability and interdependency, risk and knowledge - at a deep level, but I'm not going to attempt it right now.)
I want to have a notion of loose coupling that applies to sociotechnical systems of systems - and therefore needs to cover organizational interdependencies and interoperability as well as technical. I have previously proposed a definition of Loose Coupling based on Karl Weick's classic paper on loosely coupled organizations.
The trouble with proclaiming the wonders of loose coupling is that it sounds as if tight coupling was just a consequence of stupid design and/or stupid technology. It fails to acknowledge that there are sometimes legitimate reasons for tight coupling.
Ron Ten-Hove puts forward a more sophisticated argument for loose coupling. He acknowledges the advantages of what he calls a mixed service model, namely that "it allows for creation of a component model that combines close-coupling and loose-coupling in a uniform fashion". But he also talks about the disadvantages of this model, in terms of reduced SOA benefits and increased developer complexity, at least with the current technology.
Loose coupling is great, but it is not a free lunch. It is not simply a bottom-up consequence of the right design on the right platform. Sometimes loose coupling requires a top-down forcing-apart. I think the correct word for this top-down forcing-apart is deconfliction, although when I use this word it causes some of my colleagues to shudder in mock horror.
Deconfliction is a word used in military circles, to refer to the active principle of making one unit independent of another, and this will often include the provision of redundant supplies and resources, or a tolerance of reduced utilization of some central resources. Deconfliction is a top-down design choice.
Deconfliction is an explicit acceptance of the costs of loose coupling, as well as the benefits. Sometimes the deconflicted solution is not the most efficient in terms of the economics of scale, but it is the most effective in terms of flexibility and interoperability. This is the kind of trade-off that military planners are constantly addressing.
Sometimes coupling is itself a consequence of scale. At low volumes, a system may be able to operate effectively in asynchronous mode. At high volumes, the same system may have to switch to a more synchronous mode. If an airport gets two incoming flights per hour, then the utilization of the runway is extremely low and planes hardly ever need to wait. But if the airport gets two incoming flights per minute, then the runway becomes a scarce resource demanding tight scheduling, and planes are regularly forced to wait for a take-off or landing slot. Systems can become more complex simply as a consequence of a change in scale.
(See my earlier comments on the relationship between scale and enterprise architecture: Lightweight Enterprise.)
In technical systems, loose coupling carries an overhead - not just an operational overhead, but a design and governance overhead. Small-grained services may give you greater decoupling, but only if you have the management capability to coordinate them effectively. In sociotechnical systems, fragmentation may impair the effectiveness of the whole, unless there is appropriate collaboration.
In summary, I don't see loose coupling as a principle of SOA. I prefer to think of it as a design choice. I think it's great that SOA technology give us better choices, but I want these choices to be taken intelligently rather than according to some fixed rules. SOA entails just-enough loose coupling with just-enough coordination. What is important is getting the balance right.
Joe quotes John Hagel's definition of loose coupling, which refers to reduced interdependencies between modules or components, and consequently reduced interoperability risk. Hagel clearly intends this definition to apply to dependencies between business units, not just technical artefacts. I think this is fine as far as it goes, but is not precise enough to my taste.
In his post The Developer's View of SOA: Just adding complexity?, Ron Ten-Hove (Sun Microsystems) defines loose coupling in terms of knowledge - "the minimization of the "knowledge" a service consumer has of a service provider it is is using, and vice versa".
(It is surely possible to link these defining notions - interoperability and interdependency, risk and knowledge - at a deep level, but I'm not going to attempt it right now.)
I want to have a notion of loose coupling that applies to sociotechnical systems of systems - and therefore needs to cover organizational interdependencies and interoperability as well as technical. I have previously proposed a definition of Loose Coupling based on Karl Weick's classic paper on loosely coupled organizations.
The trouble with proclaiming the wonders of loose coupling is that it sounds as if tight coupling was just a consequence of stupid design and/or stupid technology. It fails to acknowledge that there are sometimes legitimate reasons for tight coupling.
Ron Ten-Hove puts forward a more sophisticated argument for loose coupling. He acknowledges the advantages of what he calls a mixed service model, namely that "it allows for creation of a component model that combines close-coupling and loose-coupling in a uniform fashion". But he also talks about the disadvantages of this model, in terms of reduced SOA benefits and increased developer complexity, at least with the current technology.
Loose coupling is great, but it is not a free lunch. It is not simply a bottom-up consequence of the right design on the right platform. Sometimes loose coupling requires a top-down forcing-apart. I think the correct word for this top-down forcing-apart is deconfliction, although when I use this word it causes some of my colleagues to shudder in mock horror.
Deconfliction is a word used in military circles, to refer to the active principle of making one unit independent of another, and this will often include the provision of redundant supplies and resources, or a tolerance of reduced utilization of some central resources. Deconfliction is a top-down design choice.
Deconfliction is an explicit acceptance of the costs of loose coupling, as well as the benefits. Sometimes the deconflicted solution is not the most efficient in terms of the economics of scale, but it is the most effective in terms of flexibility and interoperability. This is the kind of trade-off that military planners are constantly addressing.
[See earlier post on Deconfliction and Interoperability]
Sometimes coupling is itself a consequence of scale. At low volumes, a system may be able to operate effectively in asynchronous mode. At high volumes, the same system may have to switch to a more synchronous mode. If an airport gets two incoming flights per hour, then the utilization of the runway is extremely low and planes hardly ever need to wait. But if the airport gets two incoming flights per minute, then the runway becomes a scarce resource demanding tight scheduling, and planes are regularly forced to wait for a take-off or landing slot. Systems can become more complex simply as a consequence of a change in scale.
(See my earlier comments on the relationship between scale and enterprise architecture: Lightweight Enterprise.)
In technical systems, loose coupling carries an overhead - not just an operational overhead, but a design and governance overhead. Small-grained services may give you greater decoupling, but only if you have the management capability to coordinate them effectively. In sociotechnical systems, fragmentation may impair the effectiveness of the whole, unless there is appropriate collaboration.
In summary, I don't see loose coupling as a principle of SOA. I prefer to think of it as a design choice. I think it's great that SOA technology give us better choices, but I want these choices to be taken intelligently rather than according to some fixed rules. SOA entails just-enough loose coupling with just-enough coordination. What is important is getting the balance right.
Friday, June 10, 2005
Apple and Intel
My CBDI colleague Lawrence Wilkes has just posted a commentary (Proprietary or What?) on the Apple/Intel controversy, pointing out some of the SOA implications.
This example also illustrates something I've discussed before - that bundling/unbundling and questions of architectural flexibility look different from different stakeholder positions. Flexibility FOR WHOM. As Lawrence points out, Apple chooses its technical architecture not purely on abstract technical arguments, but according to its view of commercial forces.
Another colleague once had an expensive German car, where he needed to replace the entire engine to fix a wonky sparkplug (or something like that). I used this example in my 2001 book and elsewhere, because it nicely illustrated some important issues about the granularity of components and the potential architectural conflict of interest between supplier and customer. The supplier deliberately constrains the ability of the customer to reuse and reconfigure, and chooses an architecture that retains control over what the customer is able to do, in support of its own commercial objectives.
This entails a very strong link from the business modelling to the architecture. Where business situations are at all complex, architectural questions of granularity and coupling/decoupling may have real business significance, and cannot be determined purely on technical grounds.
Note also that for flexibility to be maintained, it has to be exercised. Upgrades are always a bit problematic for platform vendors with a large community of independent application developers. Apple developers who have used pre-OSX services are now apparently being forced to upgrade to Cocoa. Although there might be some short-term pain for some of them, the likely medium-term benefit would be an increase in the overall flexibility and robustness of the Apple ecosystem. Furthermore, Apple is sending an important message about change and flexibility to its developer community. Perhaps it should make a point of changing chip vendor more often.
Technorati Tags: Apple Intel SOA service-oriented
This example also illustrates something I've discussed before - that bundling/unbundling and questions of architectural flexibility look different from different stakeholder positions. Flexibility FOR WHOM. As Lawrence points out, Apple chooses its technical architecture not purely on abstract technical arguments, but according to its view of commercial forces.
Another colleague once had an expensive German car, where he needed to replace the entire engine to fix a wonky sparkplug (or something like that). I used this example in my 2001 book and elsewhere, because it nicely illustrated some important issues about the granularity of components and the potential architectural conflict of interest between supplier and customer. The supplier deliberately constrains the ability of the customer to reuse and reconfigure, and chooses an architecture that retains control over what the customer is able to do, in support of its own commercial objectives.
This entails a very strong link from the business modelling to the architecture. Where business situations are at all complex, architectural questions of granularity and coupling/decoupling may have real business significance, and cannot be determined purely on technical grounds.
Note also that for flexibility to be maintained, it has to be exercised. Upgrades are always a bit problematic for platform vendors with a large community of independent application developers. Apple developers who have used pre-OSX services are now apparently being forced to upgrade to Cocoa. Although there might be some short-term pain for some of them, the likely medium-term benefit would be an increase in the overall flexibility and robustness of the Apple ecosystem. Furthermore, Apple is sending an important message about change and flexibility to its developer community. Perhaps it should make a point of changing chip vendor more often.
Technorati Tags: Apple Intel SOA service-oriented
Monday, April 11, 2005
Business Unbundling
One of the key concepts of the component-based business or service-based business is that you can change the nature of the coupling or coordination between enterprise units. So we are seeing significant quantities of demerger, unbundling, outsourcing and so on.
Much of this unbundling is being pushed by regulators, especially in utilities (including telecom). See my previous note on Local Loop Unbundling. Think also of the structural changes that various regulators have threatened Microsoft with.
These are often formulated in terms of unbundling services, products or platforms. But they have obvious implications for organizational structure as well. (At one time it looked possible that Microsoft might be split into separate organizations, just as Standard Oil and ATT were previously broken up. And many years before that, IBM was also threatened.)
But the regulatory agenda should not make us think there is always a going to be a conflict of interest here. (Someone in a large telecom company once told me that the unbundling forced upon the company by the regulator had actually turned out to be beneficial for the company as well, because it had increased internal management visibility and innovation.) So sometimes unbundling is the right thing all round.
SAP has been making moves to support unbundling, and the SAP Roadmap includes guidance for unbundling (ECRM Guide, Feb 2005). There is also some standard IT support for inter-company collaboration and data exchange (SAP Press Release, Feb 2005).
John Hagel III and John Seely Brown have been writing about these issues for ages. John Hagel and Marc Singer had an article in Harvard Business Review called Unbundling in the Corporation (1999) (abstract only, purchase reprint). Hagel has been promoting a standard demerger pattern, which splits the enterprise into three standard chunks: infrastructure management, customer relationship or product innovation and commercialization. (This pattern has evolved in his writing, and his terminology has shifted somewhat.) In a recent blog posting (March 2005), he interprets recent developments at 7-Eleven as a successful implementation of this idea.
Hagel points out that these three activities operate with a different business logic on different timescales. Referring to Disney, HP and Morgan (April 2005), he comments: "Product innovation businesses and customer relationship businesses have completely different economics, skill set requirements and cultures. These are incompatible business types that cannot co-exist successfully within a single corporation. By trying to straddle both, these companies found that they could not be excellent in either."
Hagel has identified some of the relevant factors for determining the best way of unbundling the business - but this is not the whole story.
There are two contrasting approaches for unbundling. The approach favoured by Hagel assumes we can establish broad patterns and practices of demerger and subsequent collaboration. This has some advantages - among other things, it suggests that there will be multiple organizations offering broadly similar interfaces, yielding commercial flexibility. But we have some doubts about the generality of this approach. The alternative is to carry out specific analysis for each particular situation. More effort, but sometimes justified.
Much of this unbundling is being pushed by regulators, especially in utilities (including telecom). See my previous note on Local Loop Unbundling. Think also of the structural changes that various regulators have threatened Microsoft with.
These are often formulated in terms of unbundling services, products or platforms. But they have obvious implications for organizational structure as well. (At one time it looked possible that Microsoft might be split into separate organizations, just as Standard Oil and ATT were previously broken up. And many years before that, IBM was also threatened.)
But the regulatory agenda should not make us think there is always a going to be a conflict of interest here. (Someone in a large telecom company once told me that the unbundling forced upon the company by the regulator had actually turned out to be beneficial for the company as well, because it had increased internal management visibility and innovation.) So sometimes unbundling is the right thing all round.
SAP has been making moves to support unbundling, and the SAP Roadmap includes guidance for unbundling (ECRM Guide, Feb 2005). There is also some standard IT support for inter-company collaboration and data exchange (SAP Press Release, Feb 2005).
John Hagel III and John Seely Brown have been writing about these issues for ages. John Hagel and Marc Singer had an article in Harvard Business Review called Unbundling in the Corporation (1999) (abstract only, purchase reprint). Hagel has been promoting a standard demerger pattern, which splits the enterprise into three standard chunks: infrastructure management, customer relationship or product innovation and commercialization. (This pattern has evolved in his writing, and his terminology has shifted somewhat.) In a recent blog posting (March 2005), he interprets recent developments at 7-Eleven as a successful implementation of this idea.
Hagel points out that these three activities operate with a different business logic on different timescales. Referring to Disney, HP and Morgan (April 2005), he comments: "Product innovation businesses and customer relationship businesses have completely different economics, skill set requirements and cultures. These are incompatible business types that cannot co-exist successfully within a single corporation. By trying to straddle both, these companies found that they could not be excellent in either."
Hagel has identified some of the relevant factors for determining the best way of unbundling the business - but this is not the whole story.
There are two contrasting approaches for unbundling. The approach favoured by Hagel assumes we can establish broad patterns and practices of demerger and subsequent collaboration. This has some advantages - among other things, it suggests that there will be multiple organizations offering broadly similar interfaces, yielding commercial flexibility. But we have some doubts about the generality of this approach. The alternative is to carry out specific analysis for each particular situation. More effort, but sometimes justified.
Monday, November 22, 2004
Local Loop Unbundling
The UK telecom regulator Ofcom published a long-awaited report last week, widely seen as a further challenge to BT's near-monopoly over the local telecoms network. Ofcom's action is partly triggered by a view of technological change, leading to a key forking point: BT opportunity versus regulator opportunity.
All quotes taken from report "The New Age of Communication: Ofcom forces BT to overhaul and open up" by Robert Budden in the Financial Times, November 20th 2004.
Ofcom's actions have already driven a wedge between BT Retail and BT Wholesale, and create an internal conflict of interest inside BT. For example, if BT Retail were to invest in local loop unbundling, it would be able to compete more vigorously with rival telecoms retailers, but this would damage revenues at BT Wholesale.
From the point of view of the service-oriented enterprise, this is an extremely important issue. The design (geometry) of the service network - how services are bundled or unbundled, where the added-value is created and controlled - becomes a strategic issue across the industry, and a matter for close regulatory scrutiny. In regulated industries, the players look to get maximum advantage within a given set of constraints, while also lobbying for advantageous regulatory changes. In unregulated industries, the players simply look to get maximum short-term and long-term advantage. In both cases, the design of business services is now much too important to be regarded as merely a matter of technical efficiency, to be delegated to technological specialists; it is now (more clearly than ever) a matter for the business itself, affecting the profitability and sustainability of the business as a whole.
| Technological
change | "There is a fundamental change going on from a technological point of view. If that had not been going on, Ofcom might not have been so keen to come up with a brand new regulatory framework."
| Emma Gilthorpe, head of regulatory affairs at Cable & Wireless (BT's biggest rival) |
| BT opportunity:
dominance | "Rival operators stressed that they did not want BT to make life more difficult for them by adopting a closed path with its new network which would allow it to leapfrog its rivals on technology and cost structure."
| Mark Page, head of telecoms at A.T. Kearney
|
| Regulator opportunity:
equivalence | "It's a timely intervention. The whole network is being built from scratch so it is an ideal opportunity to design it with 'equivalence' in mind."
| Richard Sweet, head of regulation at Thus.
|
All quotes taken from report "The New Age of Communication: Ofcom forces BT to overhaul and open up" by Robert Budden in the Financial Times, November 20th 2004.
Ofcom's actions have already driven a wedge between BT Retail and BT Wholesale, and create an internal conflict of interest inside BT. For example, if BT Retail were to invest in local loop unbundling, it would be able to compete more vigorously with rival telecoms retailers, but this would damage revenues at BT Wholesale.
From the point of view of the service-oriented enterprise, this is an extremely important issue. The design (geometry) of the service network - how services are bundled or unbundled, where the added-value is created and controlled - becomes a strategic issue across the industry, and a matter for close regulatory scrutiny. In regulated industries, the players look to get maximum advantage within a given set of constraints, while also lobbying for advantageous regulatory changes. In unregulated industries, the players simply look to get maximum short-term and long-term advantage. In both cases, the design of business services is now much too important to be regarded as merely a matter of technical efficiency, to be delegated to technological specialists; it is now (more clearly than ever) a matter for the business itself, affecting the profitability and sustainability of the business as a whole.
Subscribe to:
Comments (Atom)