LONDON Nine of the world’s biggest banks including Goldman Sachs and Barclays have joined forces with New York-based financial tech firm R3 to create a framework for using blockchain technology in the markets, the firm said on Tuesday.
Commonwealth Bank of course joined earlier.
from: http://www.reuters.com/article/2015/09/15/us-banks-blockchain-iduskcn0rf24m20150915
I would have loved to have seen the presentation that’s been given some positive press here. Westpac are putting some meat around their transformation agenda after having learnt from the experiences of other banks.
Many of these large scale transformation programs (think ERPs, CRMs, core systems replacements, etc) have a tendency to teach the organisation about a product. The whole organisation will learn how to implement that product – they’ll learn it’s strengths and weaknesses, and the right and wrong ways to successfully exploit them. Those in the organisation who aren’t part of the solution will at least learn that they have an opinion about these things.
Now, the actual benefits of these programs aside, this is a strange way to for your organisation to spend a few years. These programs become a distraction that take up executive, management, and operational attention. But what if you changed the conversations so that rather than learning about a product, you completed the same program but what you where really doing was learning about your customers and how to better orientate your organisation towards their needs?
I think the approach Dave Curran has managed to convey (again, based on the reporting – I wasn’t there) starts to do that. This approach means that effort is first and foremost about the customer. Now I’m the first to say it’s not that simple. There is still a lot of work to make that vision operational. But it completely changes what the organisation will primarily be learning during program.
The key lessons now will be about customers – what Westpac knows about them, what they don’t, what decisions they are making every day, and how that might be understood by Westpac staff when making their decisions. The other lesson they will be learning is how technologies they already have, combined with technologies available in the market, can be used together to support various customer scenarios. Not trying to find “the best” solution without any context, but trying to design solutions across a well informed view of what is important to customers.
I think too that if this is done right, the discussions won’t be broad sweeping generalisations. They won’t be “is this one monolithic system really customer focused?” Likewise, there shouldn’t be that tendency to continuously revert to “yeah, but what is a customer?” That conversation seems out-of-the-box but is typically only asked because the people in the room have never met a customer (!) so they revert to broad open questions rather than use their experience.
Done right, this approach will draw out rich, informed conversations that admit that we have to bring components together to support specific customer scenarios. It will draw out conversation about what we don’t (!) and ensure we find out. Done right, this approach keeps up the sustained momentum these programs need to do the hard work that will truly transform the organisation.
I have a few grounding concepts that I think are relevant here. They are quite simple in their nature but powerful as the basis for governing change. I’d suggest these should be established for the program.
The Customer Advocacy Office
We talk about the importance of customers all the time but often the question we don’t ask is “what is the business unit in our organisation that advocates for our customers?” I don’t mean lets give somebody the responsibility for customer and then split the role into “Contact Centre” and “Web site”. I mean real, serious thinking about customers. Being able to understand and back up with facts. Being able to offer targeted operational changes – backed by evidence – that will improve the experience of customers.
Customer Experience Campaigns
Your organisation is probably comfortable with marketing campaigns. But what if the concept of a campaign was expended to include any situation where your customer had a defining positive or negative experience with your brand? Customer Experience Campaigns apply the basic concepts that are used to manage a marketing campaigns to all of the individual experiences of your customers. This is actually really difficult, and really important. And it’s what we mean when we say we want to be customer focused – but do we actually do it?
Customer Information Management
There is a lot of work required to get a single view of a customer. There is even more work required to repurpose that view so that it highlights the information required for different groups to make decisions (i.e. single core data, multiple views). But that’s still not “customer information” – that’s just consolidating and presenting data effectively. A true responsibly for customer information management means knowing what you don’t know about your customers, and understanding the value of finding out. It also means understanding how modern technology allows us to understand and predict the complex decisions that our customers are making by using big, social, cheap, integrated data to act as a proxy for intimacy when you can’t always get inside your customer’s heads.
Customer Return on Operations
Things like Net Promotor Score (NPS) are great but they are the tip of the iceberg when it comes to using customer-driven metrics to improve your organisation. These “voice of the customer” metrics are great but they are “lag” indicators until you do the correlation required to make them “lead” indicators. Measuring you customer return on operations combines how your customers think you perform with how you think you perform. It’s hard, it takes a prolonged effort, but who could argue that it’s not important?
Competency Centre -based Business Transformation
Many transformation programs are top-down. This means they are limited to the types of transformation that you can achieve top-down. The Westpac approach will required a middle-out approach. There are many functions within the organisation that will need to be transformed to execute on the vision. Thankfully, competency-centre based business transformation is an excellent alternative to top-down transformation – if your transformation team “gets it”.
This approach also includes the question of which type of “core” you want your organisation to have (accounting, versus product customisation, versus customer hub). When you’ve done the right homework, you can then make clear and informed decisions on whether something is differentiating or not differentiating. This decision drives standardisation but it is so mixed up in a tight bundle or current power struggles it needs an informed third party to arbitrate.
I’m not saying just talk about the concepts above in the executive management team. I’m saying that in addition to the other governance required for this sort of program there are executive roles for each of the above areas. There are charters and terms of reference for each of the above areas. Each of these areas should be managed as a business capability where the executive in charge is responsible for working across functions so that the people, process, information, and technology all work together to support the capability.
By the way, I’m not sure I get the title “Dancing About Architecture” that the article I link to above uses. I’m assuming it’s a reference to the “Writing about music is like dancing about architecture” quote that I, like everybody else, mis-attributed to Elvis Costello until I just looked it up. It’s a nice image – the idea that you might use something other than architecture (such as your customers) to guide the direction of your architecture. You dance around (or “about”) your architecture so it knows where to look. Though by alluding to the music quote the author seems critical of the approach. Anyway – looking forward to part 2…
Principles
“1. Introduce a common unit of currency – must be scarce”
“2. Provide a marketplace for buyers to bid on units of supply using common unit of currency”
“3. Provide just-in-time information to promote market liquidity”
Excellent overview on Industrialised Adhocracy and The Future of Work:
Okay, so this has the scientific due diligence of an art installation rather than an actual proof of utility. But it shows why market-based management is so important.
One project is Michael Marcovici’s Rat Trader. The book describes the training of laboratory rats to trade in foreign exchange and commodity futures markets. Marcovici says the rats “outperformed some of the world’s leading human fund managers.” The rats were trained to press a red or green button to give buy or sell signals, after listening to ticker tape movements represented as sounds. If they called the market right they were fed, if they called it wrong they got a small electric shock. Male and female rats performed equally well. The second generation of rattraders, cross-bred from the best performers in the first generation, appeared to have even better performance, although this is a preliminary result, according to the text. Marcovici’s plan, he writes, is to breed enough of them to set up a hedge fund.
From http://marginalrevolution.com/marginalrevolution/2014/09/hedge-fund-rats.html
If the above scenario actually works it means a dramatic change in the way we think about the “decision-making” part of the management process.
If the stream of data (think “big data”) can be processed by an arbitrary meat-based neural network – and proven to be effective – what is the point of performance management on the rats?
| Market Stereotype | Description | Examples |
| Competitive game | Gaming performance where team’s are made of individuals with similar goals | Sales team leaderboards |
| Cooperative game | Gaming performance where only team performance matters but individual team members contribute in different ways | Collaborative workforce management |
| Discovery & scoring | Add discovery of information by scoring of information and collective curation | elancer |
| Redundant production | Make more than you need to find quality | RFIs, competitive development |
| Unwanted feedback | Ensuring feedback isn’t filtered | Business Intelligence |
| Interface versus interpretability | Designing for unintended uses | Open data |
| App store analogy |
Using the model of an “app store” in a different context
|
Defence app store initiative |
| Separate management from measurement | Separate the management process from the measurement process | Business intelligence + separate performance management function |
| KPI exchange | Making a high-level metric tradable rather than using derived metrics | Allowing employees to trade their “utilisation” performance metric |
| Lean business case | Making a market for project portfolio ideas; ensuring ideas are tested quickly while capturing intelligence | Idea factories |
| Agile development | Dealing with uncertainty through iteration, continuous feedback, and no-fixed-plan | Everywhere in IT |
I like the idea that Seth Priebatsch is ‘determined to build a game layer on top of the world’ in the same way I like Jane McGonigal’s work to save the world with games.
Seth says in his TEDxBoston talk linked above that while the last 10 years have been about ‘building the social layer… has been building this framework for connections’ the next 10 years will be about perfecting the management of the rules that get the desired outcomes from the connections – the games.
I think this is very close the market-making and collaboration architectures of the MWT Model – so I’m excited and pleased.
I also like the reference in Seth’s talk to Loyalty schemes. Basically he is saying that the rules of Loyalty schemes and airline mile programs can be redesigned into a game rather than as they are now (“that actual do use game dynamics… they are using the game layer… they just suck”).
Is the enterprise architecture a town plan? I’m not sure I agree with the idea that the enterprise architecture is analogous to a town plan. For example, under the work-in-progress ‘Coherent Enterprise Archiecture’ (CEA) e-book maintained here, the follow definition applies:
“The CEA strategy [is to] to lay out the Notional and holistic enterprise master plan at the high level, establish the common foundation and building blocks at the low level. The high level master plan serve[s] as the master [guideline] similar to a city plan for a city for holistic consideration. The low level common foundation and building blocks enable agility and simplicity. “
This idea of a ‘master plan’ leads the discussion into teritory best avoided. It is at odds with the MWT Model in that it is planning rather than market/architecture focused It implies that development of the enterprise architecture is a planning process that might result in a plan that should be executed.
Where the town planning analogy is helpful is in zoning. In this respect the town plan is useful in that it enables decisions. The enterprise architecture, rather than containing the organisation, enables decisions about the organisation to be made.
It also allows for anybody to raise an exception by means of identifying the a zoning law is being broken. Not only that but it’s the basis for configuration management for the town because making changes to the town will require various notices to be posted depending on zone that relates to the proposed change.
You can see other parts of the CEA framework address Buy In (http://www.liteea.com/lea.php?catid=298&blogid=1). This seems to imply that somebody else is deciding an enterprise architecture presenting it for approval. This isn’t really the purpose of EA. The purpose of EA is to allow joint decision making at the executive level.
An ‘architecture’ under MWT definition is a deliniated shared understanding. A collaboration architecture is a delinitaed shared understanding specifically for collaboration. In the case of enterprise architecture, this is collaboration during the executive decsion making processes on business process sharing and/or standardisation and data sharing and/or standardisation (which in today’s world tends to be technology spend and TEBT (http://www.managewithoutthem.com/tebt).
I’m not picking on CEA here. I think it’s well thought out and it represents a very useful ontology providing terms of reference talking about enterprise architecture. However, as I’ve said before an ontology is not a management process in itself. More importantly, the process of execution is likely to not be isomophic to the solution under development. The process is in fact likely to look conceptually like the opposite of the solution.
So while the CEA material (again, referenced here http://www.liteea.com/lea.php?catid=135&blogid=1?) effectively shows a hierachy of ‘master plan’, ‘segement architecture’, ‘solution architecture’, and ‘building blocks’ these are trying to build a picture the enterprise which fits together. Which is interesting, important, and certainly descriptive of the enterprise – but is it the enterprise architecture?
Specifically, regarding the idea of a ‘segment architecture’ I’ve seen discussion (such as here http://it.toolbox.com/blogs/lea-blog/what-is-segment-architecture-25945) which describes the rational as:
… EA [utilises a] segment architecture approach rather than the traditional big bang effort. It is a divide and conquers approach to enable incremental and continuous enterprise architecture effort based on business owners need.
This approach may be in fact become nessecary for the same reasons I’m coming to which relate to people trying to do to much in the descriptive aspects of EA and not enough in the aspects relating to the enabling of collaborative decision making. But it doesn’t tell me what enterprise architecture actual is – it only narrows the scope you are applying the definition to.
So the history of how we view EA has determine that we need to break it up into segment architectures; but the fact remains that a segment architecture is not an enterprise architecture. More importantly one particular organisation I work with takes it’s segmentation strategy very seriously – having spent considerable time aligning financial treatments to segment boundaries to allow segment level reporting of financial data. This organisation would require both segement architectures to allow decision making at a segment level and also a true enterprise architecture (not simply the sum of the segments) to enable discussions around the unification of value across segments and to reduce the risk of segment based performance optimisation at the expense of enterprise performance optimisation.
In recent communications to this particular client I have tried to raise the point that the conversations about how to apply the financial rules during the transition to segmentation have created value but that unless these conversations continue via the mechanism of enterprise architecture (not segment architecture) there is a risk that value will be los through independant optimisation of performance of the type described above (at the segment level).
Where is platform architecture?
If you want to delve into the details underneath the enterprise architecture you could ask ‘where is the platform architecture’? Where have the decisions been made on which platforms will be the standardised for particular functional areas (be it business functions, integration functions, storage, etc)? This could also be called a technical reference architecture. But again, this misses the point of why I think this approach to EA is wrong.
What if you just had an enterprise architecture?
I have prepared a simple enterprise architecture for a client I’m currently working with. It is not the ‘master plan’. It is not divided into particular segments (except where they are formally seperate and independant business entities) – and may never be. It does not yet trace to a system architecture of any description. Nor does it describe any particular platforms, applications, technologies. There are a few IT related terms in the architecture but these relate to specific areas of functional groupings such as enterprise event management and shared data access which are important to the organisations operational processes.
Some people would say I have created an ‘enterprise business architecture’ and that this is just part of the enterprise architecture. But why is it only part? An application architcture doesn’t need to contain the code. The application architecture can be delivered without the code – so why can’t the enterprise architecture be delivered without the application architecture!?
Powered by WordPress & Theme by Anders Norén
