The role of channels

On the tnooz web site there is a whole lot of discussion about the pricing of travel through channels and what the responsibilities of the various players are. Specifically the link poses the question, "Should airlines be forced to disclose equal pricing and fees in all channels?"

Now pricing is an interesting and really important part of any business/business strategy, and thence business architecture. The fundamental question of "How do we price?" affects how we market, how we sell, to some extent how we produce. So for example in a business with only a direct sales model, the systems (in the broadest sense) that deal with sales don't have to handle other channels. But businesses with multiple channels have to make the role of the channel explicit in all systems that are concerned with sales.

If the channels don't control the pricing, what use are they? Surely the idea (really simplistically) is for the channels to provide the conduits for products from suppliers to consumers and thus to set the price for the product via that conduit.


To be successful as a channel, you presumably have to price items higher than what you get them for. Not all items - you can do loss leading if you wish. A pretty simple market place really.

The airlines are responsible for setting the cost to the channel, not the price to the consumer - except where the airline is the channel. The role of the airline acting as its own channel is different from the airline operating its own business. The travel business is a bit different from other retail businesses where, typically the manufacturer doesn't operate its own channel. Although when we see store within a store concepts (like the cases where a makeup provider sets up shop inside a retailer) the makeup provider is acting as its own channel. The store in which the make-up provider is operating is simply another supplier and associated costs must be factored in.

Purchasing is different again. In a world of competition the channels should be clamoring for the consumers' business. Through all manner of inducements. As a consumer I can choose which channel I purchase through depending on a number of factors. Just as I can choose whether to shop at Harrods (Cool, easily identifiable status symbol bag) or Walmart (Look, I am a thrifty person in the new economy).

So in the travel business we really do have to separate out the responsibilities of the various parties in the transaction. There are more parties than just the airline, channel, and purchaser involved. Hotels, rental car companies, restaurants, golf clubs, credit cards,.... All have parts to play. Each may have multiple parts - the part as the supplier, the part as the purchaser, the part as a channel. If we don't separate the parts, we can create interesting opacity. In some industries that is very desirable. However in a business oriented towards consumers, the consumers want transparency.

The job of the channel is to provide that transparency.

So any player in the relationship that wants to be in the role of the channel (whether it be a traditional travel agent, an airline, a hotel, an online travel agent,...) has to act like a proper channel and take the proper channel responsibilities. Simply put:

* Acquire "inventory" at the proper time/price

* Package acquired "inventory" into offers

* Offer the acquired "inventory" under terms that are attractive

* Accept offers to purchase such inventory
 
*  Fulfill those offers
 
It gets a bit tricky because there are actually multiple channels involved in the end. I can purchase the basic travel through, say, Travelocity or Orbitz. But when I eventually travel, I may end up buying something directly from the airline itself (say a meal). Actually, at that point the airline is acting as a channel for a meal preparation company, so it can choose how to set its prices.
 
In order really to understand a complex, network business, we architects really need to think through the roles in the ecosystem, and pay attention to, and manage business architectures that support the pricing models that matter.
 
When there is turbulence, aim for flexibility. When there is stability, aim for simplicity.

Controls and Trust

I am appalled as I look at systems in various companies with whom I have consulted, or who have employed me at the lack of system controls in key places. If you are in the data delivery business and you have agreements with your customers, wouldn't you want to know that you are meeting your service level agreements? Or better still when you are not going to (for whatever reason) and be able to issue warnings, do something about it, or whatever?

Similarly when looking at flow through from one system to another, can you reasonably be assured that everything that was supposed to be processed was?

Do you count your cash after going to the ATM. Maybe the machine didn't deliver correctly because a couple of notes were stuck together. Maybe a new software version caused a miscount under some weird circumstances. The ATM is a "black box" to me. That means that at its boundaries I have to decide what my trust relationship with it will be.

So when I have systems which are supposed to communicate in some way (e.g. by passing data) what controls should be in place to make sure everything is properly accounted for? Should a sending system keep a count of what it has sent? Should receiving systems similarly keep track? How do we reconcile? Should the reconciliation be in-band? Should it be out-of-band? Is logging adequate? Do we have to account for the "value" of the transmission as well as just counts? What tolerances matter if we are concerned with value (perhaps one system rounds off the value differently from another so at the end of the day the total value has a discrepancy)?

This need for controls is exacerbated by systems that use Events as the primary means of notification. Because at the individual event level we can indeed count, maintain value, etc. But often the controls need to be at an aggregate level. One would think in, for example, an airline boarding system that as long as every boarding event is properly received by the "flight", then the system should be in balance. Try telling that to Easyjet. There is a manual control system whereby the Flight Attendants actually count the number of passengers on the plane and attempt to reconcile that with the "expected" number. How the expected number is derived, I have no idea. It could be simply the number of boarding cards collected - but what about electronic boarding? It could be the "system's" view of how many bums there should be on seats. Whatever it is it doesn't appear to be reliable. Chris Potts (Twitter @chrisdpotts) told me the story of what happens when the count is wrong. they recount, they look for people in bathrooms, they delay the flight. It's all a mess.

In the 1960s when phone phreaking was at its peak, people could make free calls because the control signals (tones) for managing the connection system were on the same band of the infrastructure as the call itself. So when a signal tone was detected (and you could get whistles to generate these tones), the system went into a signalling state. By signalling the correct sequence you could generate the sequence to make free calls. Simple fix - put the controls out of band with what you want to transmit.

In a properly reliable infrastructure, the appropriate controls should be built in from the beginning. Again, you may ask, "What's this got to do with Enterprise Architecture?". I argue that it has a great deal to do with the architecture of the enterprise. Good controls make for good compliance and a high level of confidence in our business practices. Bad controls can make your corporation star in places you don't want to be - the front page of the WSJ, in anecdotes among the social networks, resulting in a loss of confidence in your organization.

Observations on Silos

In this posting Richard Veryard  examines the value of silos and silo thinking in organizations. In some ways silos are necessary organizational mechanisms because they place boundaries on functional activities. However they are also creatures of organizational politics - each silo is headed by "someone important". At the European  Enterprise Architecture Conference 2010, Alec Sharp  observed that silos have negative connotations and that perhaps we should use the term, "Cylinders of Excellence". That at least sounds more empowering.

Often, however, the success metrics of a silo are actually in conflict with those of the organization. Well intentioned success metric/motivational policy in a sales team (e.g. "Orders taken in the last week of the quarter will pay extra commissions") will in all likelihood have exactly the wrong outcome. Commissioned sales force team members are actually incented to do the wrong thing - to sandbag until the last few days of the quarter. This has potential downstream effects. It places extra burden on finance and other back office "systems" (silos?). It doesn't allow the organization to get a true picture of sales performance through the quarter. Somehow the miracle always seems to occur and some huge deal comes in at the end of the quarter to "rescue the quarter", keep the investors happy, commission the sales team...

So as architects we should look at the effects of the silos on organizational goals. Moving the silos around is likely to be a bad idea. Powerful people sit at the tops of silos and the only time to effect change at that scale is when new senior management take over. So rather than being perceived as people who are trying to undermine power, enterprise architects need to be seen as people who facilitate the planning and execution of the enterprise.

A fundamental (inside out) question then is, "How do the goals/reward systems in the current silos ensure that the goals and reward systems of the enterprise? are met" In the example above, the Sales silo would argue that it is helping the enterprise meet its goals by making sure that targets are indeed met. However, there is nothing in the enterprise goals that says "at whatever cost to the rest of the enterprise".

Enterprise architects are fundamentally enterprise level thinkers and thus must be thinking about the enterprise (and possibly the extended enterprise) as a whole. We must be able to understand the implications of conflicts in the enterprise - where Value systems in the silos are either at odds with each other, or at odds with the value systems of the organization as a whole.