6 days ago

The Idea of Showrooming

According to Wikipedia, the word “showrooming” was coined in the 2010s. The earliest reference I can find is in a Wall Street Journal article dated April 2012, which opens as follows:

“Shoppers who scope out merchandise in stores but buy on rivals’ websites, usually at a lower price, have become the bête noire of many big-box retailers.”

By September 2012, showrooming is being described as a “commonly held belief”, and being dismissed as a falsehood by the CEO of Best Buy.

But the idea of showrooming was mooted many years previously, in discussions between Jeff Bezos and HP.  @nearle, then an executive with HP, mentioned this in a keynote speech in June 2000.

During his speech, Earle recalled a conversation he had with Jeff Bezos, the founder and chief executive of Amazon.com Inc., an HP client. When Earle asked Bezos to describe a “killer application” from Amazon.com’s perspective, he described a handheld device with a wireless link and a bar-code reader that would enable customers to scan in a book from another retailer, find out how much cheaper it is sold at Amazon.com, and then order it online for next-day delivery. “We will make one,” Earle promised.

I cited this conversation in 2004, as evidence that Bezos got ecosystem thinking. What I hadn’t realised at the time was that he had basically invented the iPhone. (I don’t recall HP ever making such a device.) And he had had the idea of showrooming, over a decade before the word was coined.


David Jastrow, HP Keynote embraces ecosystem thinking (CRN, 15 June 2000). I have corrected the misspelling of Earle’s surname.

Thomas Lee, Best Buy’s new chief is selling from Day 1 (Star Tribune, 8 September 2012)

Ann Zimmerman, Can Retailers Halt ‘Showrooming’? (Wall Street Journal, 11 April 2012) (paywall)

Wikipedia: IPhone (1st generation), Showrooming (retrieved 15 July 2017)

Related Posts: Jeff Bezos and Ecosystem Thinking (Feb 2004) Showrooming (Label)

4 months, 12 days ago

Inspector Sands to Platform Nine and Three Quarters

Last week was not a good one for the platform business. Uber continues to receive bad publicity on multiple fronts, as noted in my post on Uber’s Defeat Device and Denial of Service (March 2017). And on Tuesday, a fat-fingered system admin at AWS managed to take out a significant chunk of the largest platform on the planet, seriously degrading online retail in the Northern Virginia (US-EAST-1) Region. According to one estimate, performance at over half of the top internet retailers was hit by 20 percent or more, and some websites were completely down.

What have we learned from this? Yahoo Finance tells us not to worry.

“The good news: Amazon has addressed the issue, and is working to ensure nothing similar happens again. … Let’s just hope … that Amazon doesn’t experience any further issues in the near future.”

Other commentators are not so optimistic. For Computer Weekly, this incident

“highlights the risk of running critical systems in the public cloud. Even the most sophisticated cloud IT infrastructure is not infallible.”

So perhaps one lesson is not to trust platforms. Or at least not to practice wilful blindness when your chosen platform or cloud provider represents a single point of failure.

One of the myths of cloud, according to Aidan Finn,

“is that you get disaster recovery by default from your cloud vendor (such as Microsoft and Amazon). Everything in the cloud is a utility, and every utility has a price. If you want it, you need to pay for it and deploy it, and this includes a scenario in which a data center burns down and you need to recover. If you didn’t design in and deploy a disaster recovery solution, you’re as cooked as the servers in the smoky data center.”

Interestingly, Amazon itself was relatively unaffected by Tuesday’s problem. This may have been because they split their deployment across multiple geographical zones. However, as Brian Guy points out, there are significant costs involved in multi-region deployment, as well as data protection issues. He also notes that this question is not (yet) addressed by Amazon’s architectural guidelines for AWS users, known as the Well-Architected Framework.

Amazon recently added another pillar to the Well-Architected Framework, namely operational excellence. This includes such practices as performing operations with code: in other words, automating operations as much as possible. Did someone say Fat Finger?


Abel Avram, The AWS Well-Architected Framework Adds Operational Excellence (InfoQ, 25 Nov 2016)

Julie Bort, The massive AWS outage hurt 54 of the top 100 internet retailers — but not Amazon (Business Insider, 1 March 2017)

Aidan Finn, How to Avoid an AWS-Style Outage in Azure (Petri, 6 March 2017)

Brian Guy, Analysis: Rethinking cloud architecture after the outage of Amazon Web Services (GeekWire, 5 March 2017)

Daniel Howley, Why you should still trust Amazon Web Services even though it took down the internet (Yahoo Finance, 6 March 2017)

Chris Mellor, Tuesday’s AWS S3-izure exposes Amazon-sized internet bottleneck (The Register, 1 March 2017)

Shaun Nichols, Amazon S3-izure cause: Half the web vanished because an AWS bod fat-fingered a command (The Register, 2 March 2017)

Cliff Saran, AWS outage shows vulnerability of cloud disaster recovery (Computer Weekly, 6 March 2017)

3 years, 9 months ago

Don’t fret being misunderstood, Bezos on change via my Tumblr

Bezos has a different view — a long view. “Everything we’ve ever done people have said this. People said customer reviews were a bad idea, third-party selling is a bad idea, personalization is a bad idea,” and he does have a point. “In 1994, typing your credit card [info] on the internet is a bad idea. Every single thing that’s new is a bad idea.” And then Bezos repeats one his best rehearsed and most convincing soundbites. “Willingness to be misunderstood is one of our greatest strengths.”

via Tumblr http://bmichelson.tumblr.com/post/62900280822

4 years, 7 months ago

Showrooming and Multi-sided Markets

As a retail phenomenon, #showrooming exposes a conflict of interest between online and traditional retailers. Many shoppers will examine a product in a traditional store, and then buy it from an online retailer or discount warehouse. The first retailer incurs costs – including cashflow, wear and tear on the product, as well as unproductive use of staff time and knowledge – while the second retailer takes the revenue.

To complete the story, there may be another class of customer, who is happy to buy the
ex-demonstration product from the first retailer at a discounted price. Thus there are five
distinct roles in this game: the product supplier, the first and second
retailer, the first and second customer. (In addition, if the customers are using their mobile phones in the stores, we should add the players in the mobile ecosystem.)

The earliest manifestation of this I can remember was buying records. You could listen to an LP in the record store, and then get a pristine copy (without the shop assistant’s fingerprints) by mail order from a company appropriately called “Virgin”.

Many retailers believe they lose out from this phenomenon, and some have attempted to prevent it. (Ever wondered why you don’t get a good cellphone signal inside a large store?) Earlier this year, both Target and Wal-Mart decided to stop stocking Amazon devices, although continuing to stock Apple devices. More recently, Wal-Mart has changed its position, and now claims to embrace showrooming.

By singling out Amazon, Target and Wal-Mart were making it clear that it is Amazon’s role as a retailer that they regard as a competitive threat. Although Apple also sells its devices online, it is presumably not regarded as an equivalent threat. In which case, banning Amazon products looks like a gesture of despair rather than an effective tactic.

Thinking of this as a multi-sided market prompts us to look at the direct and indirect flows of value between the players. It is as if the first retailer is providing an unpaid “service” to the second retailer, and the first customer is providing an unpaid “service” to the second customer. At present these are not genuine services, but it is possible to conceive of an ecosystem in which the product supplier or second retailer paid some form of commission to the first retailer. For all I know, that may already happen in some sectors.

Wal-Mart hopes to control showrooming by encouraging its customers to use its own mobile app, which attempts to steer customers towards its own online store. I wonder how many customers will accept this control, and how many will take the trouble to resist it.

Some large High Street retailers seem to have given up the idea of stocking goods: if you like something on display, you can order it. This has long been true for large furniture items such as beds, but is becoming more common for smaller items, as Simon Heffer complains.

Meanwhile, showrooming can work both ways. Last week I ordered a book from my local bookshop, having previously looked it up on Amazon. It was 5pm Friday when I placed the order, and they phoned me at 11am on Saturday to tell me it had arrived. (If I’d ordered it from Amazon, paying extra for 48 hour delivery, when would it have arrived? Monday, Tuesday?) So that’s showrooming in reverse.

Finally, instead of selling individual products, the showroom itself can become the experience. @KBlazeCarlson sees IKEA as a prime example, and quotes Alan Penn, professor of Architectural and Urban Computing at UCL, describing the IKEA experience as “psychologically disruptive”. “Part of their strategy is to take you past everything,” he says. “They get you to buy stuff you really hadn’t intended on. And
that, I think, is quite a trick.”

Chris Petersen adds, “Instead of product centric merchandising, IKEA’s showroom is perhaps the ultimate place merchandising, where the consumer solution is focused on the most personalized dimension – the consumer’s own lifestyle and living space.” Whether IKEA can replicate this experience online in the virtual world, as suggested in Patrick Nelson’s piece, is another matter.



Kathryn Blaze Carlson, Enter the maze: Ikea, Costco, other retailers know how to get you to buy more (National Post, June 2012)

Simon Heffer, My futile hunt for a lamp in John Lewis reveals why the High Street is doomed (Daily Mail 15 January 2013)

Brett Molina, Is ‘showrooming’ behind Target move to drop Kindle? (USA Today, May 2012)

Patrick Nelson, Brick-and-Mortar’s Showrooming Scourge (E-Commerce Times, Nov 2012) via First Insight

Chris Petersen, To beat showrooming … change the showroom! (IMS results count, June 2012)

Marcus Wohlsen, Walmart.com CEO: We Embrace Showrooming (Wired, Nov 2012)

Amazon’s Showrooming Effect And Quick Growth Threaten Wal-Mart (Forbes, Sept 2012)

Related posts: Showrooming in the Knowledge Economy (December 2012), Predictive Showrooming (December 2012)

Updated 16 January 2013

4 years, 8 months ago

Agile Architecture

The English language is well known for its subtlety. Sometimes it’s a delight, but on other occasions it can be very frustrating. If I use the term Gothic Architecture you will immediately understand I am describing a style of architecture that flourished in medieval times. And if like me you are interested in ecclesiastical architecture you will know that this style was used in many of the great cathedrals and churches across Europe, which were distinctive because of key architectural patterns that enabled great increases in height and internal light of the buildings without increasing the size of supporting pillars.
Now if I use the term Agile Architecture, what am I referring to? In today’s Agile world I would hazard a guess that most readers will think I am referring to the architecture techniques and tasks undertaken in the context of an Agile software development project, not the collection of patterns and practices that enable agile business systems. That is, an architecture that enables agility.

This potential for miscommunication is a core issue for enterprises. There is ample evidence that Agile Architecture is a primary contributor to business agility, yet we do not have a well understood architecture management system that integrates with Agile methods.
 

Let’s use an example readers may be familiar with. Amazon CEO Jeff Bezos famously[1]issued an edict that laid down some key architecture principles to Amazon development teams that I will summarize as:

·       All teams will henceforth expose their data and functionality through service interfaces.

·       Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed.

·       It doesn’t matter what technology they use.

·       All service interfaces, without exception, must be designed from the ground up to be externalizable.

·       No exceptions.

What Bezos did here was to lay down key business and technology architecture principles that you might reasonably conclude were central to the extraordinary level of business agility that we have seen demonstrated by Amazon.com, Inc. That widely circulated edict contained the foundations of the Amazon reference architecture.  

In the October 2004 CBDI Journal[2] we commented, “Two of the most successful and enduring dotcom start-ups, Amazon and eBay, now expose their core applications as Web Services. In doing so they have created a new class of platform that could have a profound impact on end-user organizations and IT vendors alike.”

And so the reference architecture became the enabler of growth and agility for the Amazon business, not we understand[3] as a grand plan, but through natural technological evolution. The services formed the platform that allowed the extraordinary expansion of the Amazon business that I would be certain not even Jeff Bezos imagined, back then in 2004. That is real business agility, and it was delivered by smart architecture backed up by clear policies and realized by agile processes.

Although Amazon has clearly evolved in pursuit of solutions to specific business opportunities and challenges, it’s also clear they have established a de facto architecture and architecture management system that guides the work of the many product delivery teams and ensures consistency of approach where it’s required. Let’s consider how an enterprise might establish a similar agile architecture management system.

A reference architecture articulates primary principles that are typically central to an entire enterprise. Principles should be focused on establishing the product and solution independent environment in which agility can be delivered and maintained, so they would be stable over time. We might refer to reference architecture as a Level 1 architecture perspective (L1) that exists purely as a set of models and guidelines.

Larger enterprises should explore the business value potential of platform based architecture as a mechanism to deliver cross enterprise consistency of core reference architecture behaviors and to enable closer integration with the wider ecosystem including customers, suppliers, end consumers etc. This is an extended management services platform which encapsulates the technology infrastructure and enables rapid delivery of business services.
The platform architecture defines common services that manage business delivery including security, life cycle management, change management, release management and operations, as well as catalogs, eCommerce, B2B, regulatory control and risk management, standardizing these key capabilities and reducing the footprint of business domain services. The platform will also manage important behaviors that deliver on specific business goals such as scalability and availability. For example, Amazon services are usually very fine grained, specifically to reduce the scope of each service in order to facilitate narrow focus SLAs and maximize scalability by reducing individual service complexity. We might refer to platform architecture as a Level 2 architecture perspective, engineered to be relatively stable in support of  large numbers of business services and consumers, but also engineered to evolve and respond rapidly to business and technology change. Not all enterprises will see business value in making their platform and business services available to their ecosystem, but some will.
Enterprises clearly vary considerably in their make up in terms of geographic and organizational, product and process standardization and differentiation, but typically there will be considerable potential for an inventory of shared assets that leverage agile architecture to support business agility. The assets may include:

·       Common services, frameworks and components that are designed to deliver common behaviors to all parts of the enterprise. For example core services that establish genuinely enterprise wide services such as Customer, Ticket, eCommerce etc; services that deliver business value by standardizing common business services and processes.

·       Configurable services, frameworks and components that are designed to provide common behaviors but are engineered to be customizable in local situations to accommodate many aspects of localization ranging from the simple – taxation, geography etc, to the complex – variant ordering patterns, variations in event and process sequence dictated by local de facto business practices. Configurable services may provide business value simply by providing reusable components, or they may establish a common core of business process and information that establishes common reporting and regulatory control in a local context, or both. Configurable services may also be an important time to market strategy for service providers who customize their services for each client or customer group.

·       Information architecture and services. Establishing a coherent approach to information is commonly a major issue for large enterprises and this architecture level defines an integrated approach for structured and unstructured (big) data, transactional and reference, enterprise reporting and regulatory control and so on.

Common and Configurable assets together with the Information Architecture might form a Level 3 architecture perspective and be widely applicable across a large, distributed enterprise.  

We then have two further levels which are closely related, Family Architecture and Product Line Architecture. Whilst many architects chose to view Family and Product Line as synonyms, I recommend that they are kept separate. A Family architecture is a domain framework that is much more specialized that L3 assets that would be applicable on a broader basis. The Family architecture establishes core business (domain) services and possibly other artifacts specific to the domain, where the domain is likely to be a subject area or a cluster of major types. For example Customer, Supply Chain, Manufacturing, Risk etc. Families are also commonly acquired products.
In contrast Product Line architecture is what it says – it’s the architecture for a product offering. The product is an offering that has direct relationship to end customer revenue and usually continuity of purpose over multiple releases. Although from a narrow technical perspective the Product and Family architectures might be similar, the way a product is managed must mirror the business product life cycle. Family architectures may therefore be engineered for stability, whereas, depending on the industry sector, product line architectures may be engineered for maximum agility and minimum response time.  

Finally we have the Solution architecture level, the architecture specific to solution project delivery, where the focus is on feature architecture and integrating solution architecture with the Level 1 to 5 architecture perspectives. It’s important to note that where product line architecture is used, then this may subsume the Solution architecture.
These six architecture levels provide us with a nomenclature for agile architecture that will be central to managing agility into the delivered product/solution. The architecture perspective guides the structure of programs and projects and the incorporation of architecture and reuse goals into delivery charters. The architecture also provides traceability and governance over realization of core architecture principles.
The question of how Agile Architecture integrates with Agile delivery is likely to prove contentious because architecture introduces a form of direction that contradicts Agile concepts. Yet the lessons from Amazon are insightful. The most senior business management need to be fully engaged and actively leading the development of architectural direction. Further in large enterprises customer project demand needs to be managed and aligned with business strategy and architectural direction.

There’s no reason why these Demand and Definition processes shouldn’t adopt Agile concepts, notably cross functional teams, time boxes and backlogs. The outcomes should be excellent visibility and traceability of key strategies and policies that provide real clarity of purpose for projects, that will increase the probability of success. In a typical large enterprise use of existing (or well understood) organizational concepts, adjusted to use aspects of Agile methods as discussed, will meet less organizational resistance. For example:  

1.     Architecture Review Board (ARB) or equivalent, a cross functional team (senior representatives of business, product management, architecture and delivery), that provide direction and funding to all architecture development.

2.     Design Authority (DA), also a cross functional team (domain specific expert level representatives of business, product management, architecture and delivery), that transform raw customer demand stream into project charters and manage the portfolio view. It is the DA that takes responsibility for aggregating and decomposing customer and strategic demand, chartering Common, Product Line and Family architecture, typically as integral elements of delivery projects, which can demonstrate business value.

3.     Investigatory architecture projects – short duration projects that validate assumptions prior to chartering composite architecture/delivery projects. Sometimes carried out as part of a Definition Phase activity concurrent with outline requirements and knowledge discovery. Using patterns as a mechanism to increase consistency of architecture decisions and communicate them to delivery projects at sensible level of detail that is useful to delivery teams.  Recommend includes delivery team members as appropriate.

Note this is a recursive model, and the process may executed at enterprise and program level.

You may ask where Enterprise Architecture is in this. The answer is that enterprise architecture is a role and responsibility that must coordinate and govern all levels of architecture. Enterprise Architects are most likely to be assigned to a specific architecture perspective level. The notion of, “one architecture to rule them all” really doesn’t exist.

  

Each enterprise should develop its own architecture management approach, and integrate this into an end to end architecture, delivery and governance process. The term Agile Architecture should be used to describe and deliver architecture that facilitates the agile business by compliance with reference, platform and other architectures that facilitate evolution, customization and plug and play. Faster cycle time and quality outcomes are then a function of both the reusable patterns and parts available for assembly and the Agile delivery process.  

In medieval times the builders of the Gothic cathedrals didn’t start their designs from scratch. But equally they didn’t have finely detailed (ivory tower) plans – the technology didn’t exist to support that. Master builders moved from city to city bringing their proven architecture in their heads, often together with experienced craftsmen, to new projects. Craftsmen and master builders together tried out new designs and gradually evolved core patterns such as the flying buttress, which became standard components in cathedrals across Europe. Sometimes the great buildings fell down during construction and the builders had to adapt the architecture and try again. They were truly early adopters of Agile methods as they combined architecture and build in what clearly was from time to time an empirical delivery approach, but they also had their equivalent of a reference architecture and patterns that enabled systematic reuse of proven designs. Of course their delivery cycle time was a little longer than today’s Agile project!
Talk to Everware-CBDIabout the Agile Enterprise Workshop. This is currently available as an in-house, intensive workshop. Public scheduled classes will hopefully follow next year.


[1] Amazon and eBay Web Services, The New Enterprise Applications? By Lawrence Wilkes, CBDI Journal October 2004


[2] Inadvertently published by Steve Yegge, 2011, in a comparison of Google and Amazon practices. http://upalc.com/google-amazon.php

[3] Werner Vogels, 2006, SOA creates order out of chaos @ Amazon, Rich Seeley, Search SOA