The Direct-to-Customer Phenomenon

podcasts.apple.com/nz/podcast/what-it-means/id1207507774

Forrester analyst Ryan Skinner’s keynote from Consumer Marketing 2019.

Platforms

Platforms, another word that the IT industry has overloaded with multiple meanings. It perhaps hasn’t got to the dizzying heights of the term ‘Service’, but it is on its way. Back in the day platforms meant software for building software, for example Java or .NET are platforms. Or going further up the classic software architecture stack, we would have things like Microsoft SharePoint as a platform for developing business functionality on. These could be considered ‘Technical Platforms’

Now with the move to Platforms-as-a-Service the term platform is taking on a new meaning. Companies like Apple, Uber and Airbnb understand this new use of the word platform. Platforms in this context don’t allow companies to build business software, but to build a ‘business’.

Thoughtworks discuss their Digital Platform Strategy offering which looks to help enterprises modernise their IT and improve value delivery by removing friction from engineering teams, exposing core business capabilities and intelligence and supporting efficient experimentation. Essentially building platforms within the enterprise so that the organisation can innovate their business models.

I will look to investigate this new view of platforms over the next few posts.

Software Companies that…

During the last months of 2017 I listened to a couple of Forrester “What it Means” podcasts that I think summarise the challenges that “Companies that use software” are facing. The first podcast was on Continuous Delivery, Continuous delivery: moving fast with today’s market covered the concept of continuously delivering value. The podcast, as is often the way for these Forrester “What it Means” podcasts, pitches the conversation at the CxO level and so ‘introduces’ the concept of Agile and then describes the way companies deliver value (products or services) to customers and using feed-back loops, iterating the product or service.

For me the key part of this podcast was when they touched on the challenge regarding funding. This is where the ‘Companies that use Software’ are still, or often, locked into the annual planning cycle and the requirement to develop ROI figures and understand how they will capitalise the asset that they are building. The focus for agile is that the software development is an operational expense not a capitalisable expense. However the change for the ‘Companies that use Software’, from ‘Capex’-ing their software development of large projects to opex-ing their iterative delivery of capability through software may impact their bottom-line which their shareholder won’t like, in the short-term. Of course the issue for these shareholders is that there might not be a bottom-line to worry about if the ‘ Companies that use Software’ don’t change the way they deliver software to provide value or capability.

Form is Liberating

The blog is called Breadth, Depth and Form and as I state in my ‘About’ page a phrase I say a lot to my team is ‘Form is Liberating’. I thought I would go and check out what the phrase meant and who said it first. So off I went to Google’s Ngram viewer to check for that phrase, and was very surprised to not finding any references. So Googling the phase got me a few hits and the top hit being a post from Hacker News:

However doing an Ngram search for ‘form liberates’ gets some hits:

I also had a quick look at the Critical Path video ‘Form is Liberating’, which features Warren Robinett talking about the phrase ‘Form is Liberating’ in relation to his development of the Atari 2600 Adventure game.

My view of the phrase/aphorism ‘Form is Liberating’ is that is you don’t have to focus on the process of doing something, you can focus on the something. I see the issue so often, and I catch myself doing it too, where we focus on ‘how’ we are going to do something rather that ‘what’ we are going to do. This may be okay if there isn’t a clear way or ‘how’ to approach something. But often or not there is a clear way, or process, that could be followed to complete or deliver the ‘what’. Also, focusing on the ‘how’ is also a good form (excuse the pun) of procrastination.

Another related pattern I see is that people spend so long attempting to negotiate themselves out of using a process or following a particular ‘form’ defined by someone else, that they could just have followed that process and they would have been done long before their negotiations are complete.

You could almost suggest that not following the ‘Form is liberating’ aphorism is a form (sorry again!) of lean waste (DOWNTIME). It could be considered ‘Non-utilised talent’, ‘Inventory’, or ‘Extra processing’. I realise ‘Non-utilised talent’ is related to people, but you could stretch the ‘form’ as including people that are there to support the process that aren’t being engaged when someone is flouting the process. I appreciate agile-ists might argue that having to engage others is a hand-off that should be avoided. You could argue that it is inventory waste, in the sense that I have the defined process that isn’t being used! Or Extra processing, as I may have to follow the standardised process anyway…

So, in summary, I feel that ‘Form is Liberating’ gets you focusing on the problem at hand and that you are liberated from some level of toil by using your existing reference material and standard approaches, the ‘form’. I appreciate that this doesn’t work in all fields but could be re-stated as ‘don’t reinvent the wheel’.

 

Books of 2017 – MDA Explained: The Model Driven Architecture: Practice and Promise

MDA Explained: The Model Drive Architecture: Practice and Promise by Anneke G. Kleppe

This is going to be an interesting post for me to write, not so much about the book but the fact that this is the last book that I’m going to include in my review of the Books of 2017 that I’ve read. So it means tomorrow, when I do my daily blog post, I will have to think of a topic to write about. I will no longer have the safety net of my book reviews. There are a few topics that I’ve raised during the book reviews that I would like to explore in more detail. So perhaps I will look at one of those.

Now to the book. This is one of the older technical books that I’ve read during 2017 and it felt like it as I was reading (or, okay, having it read to me!) it. My career took a turn about 10 years or so ago when I started to look after a modelling tool called ARIS. The vision within the Architecture team, that I worked in, at the time was to have a Model-Driven Architecture. We could manage and develop higher-quality solutions and leverage work done before by using MDA and have these models stored in a repository.

Fast forward a few years and whilst we had a good level of up take in the tooling and a common notation for depicting diagrams, we didn’t ‘model’. So it was interesting to have the book paint so positive a view of MDA. Lots of talk of PIM and PSM and transformations. PIMs being Platform Independent Models and PSM being Platform Specific Models and transformations being the mapping to convert a PIM into a PSM. Ultimately of course, a PSM is transformed into code. The book talks about the future of being able to round-trip from code to model and back again. Looking to what happens today, this vision hasn’t really been achieved.

The book was written as the Agile Development movement was growing apace and refers to Extreme Programming (XP) but points out that having co-location and multiple engineers working together on a solution mitigates the need for documentation, but once the solution is delivered and then run by an ops team and a different team is responsible for fixing bugs you need that documentation. Of course this book was written a good few years before DevOps became a ‘thing’.

However, the book does make a good point about documentation. Whilst a lot of engineers or maybe specifically developers (I believe there is a distinction) will point to code being the ultimate documentation (or as others have stated, the ultimate specification). The code doesn’t easily show the overall structure of the ‘system’ that the software might be part of. Hence the need for some ‘architectural documentation’, and so MDA to the rescue.

I read this book to get a better understanding of the Unified Modelling Language (UML). Whilst I’ve managed a modelling tool for over 10 years, UML is only one modelling method or notation that the tooling supports and we’ve used the richer, if to some less semantically correct or rigorous, ARIS notation. We’ve supported users of UML but can’t give the appropriate level of methodologically guidance that we can to users of the ARIS notation. However, over my ten year journey I’ve seen the benefit of standards and have stated a vision that would use a combination of the following standards to replace how we model in ARIS today; ArchiMate, BPMN (Business Process Modelling Notation) and UML. Whilst the three notations./methods don’t cover everything the ARIS notation can cover, there is standardisation and a broader understanding of these than there is of ARIS, or so I’m assuming!

 

Books of 2017 – 37 Things One Architect Knows by Gregor Hohpe

37 Things One Architect Knows by Gregor Hohpe

I was directed to read this book by my boss, who had come across it in discussions with his peers at our company’s parent, but interestingly almost at the same time Gregor Hohpe was interviewed on Software Engineering Radio about the topic of IT Architecture and IT Transformation, where he referred to his book.

Now, it is tempting to quickly review the tables of content and list out all of those 37 things. However, what I’m going to try and do is see how much of the 37 I remember – which won’t be many give the short amount of time I allocate myself to do these posts and what my recall is like!

The first idea from the book that comes to mind is the ‘elevator’. Architect should be able to ride the organisational ‘elevator’ from the ‘production floor’ talking to developers/engineers all the way up to the ‘C-suite’ floor and the Architect should be able to communicate so that each level that the Architect gets off on will be able to understand them.

And that is the first and it appears the only key idea of the book that I can recall without looking at the content… so let’s look at the content!

Ah yes, Zombies! Gregor points out a obvious point, to those that are in large corporates that is, is that corporate IT has its large share of zombie systems, undead systems – systems that might be complex legacy systems that is doing something that no one in the organisation now understands and no one wants to touch the running system because of the mantra ‘never touch a running system’. But these systems ultimately slow the organisation down if they aren’t changed.

However, looking at the other topics there is a whole group of ‘things’ that are related to Communication which I kind of touch on in the Elevator ‘thing’. So maybe I can give myself a score of 2 out of 37…

The book deserves a second read – as do most of the books that I’ve, I should call it what I really do with the books, skimmed! So perhaps I should say the book deserves a first ‘read’ after a first ‘skim’… And to think I’ve actually read a book called ‘How to read a book’, I should know better.

Books of 2017 – The Theory That Would Not Die: How Bayes’ Rule Cracked the Enigma Code, Hunted Down Russian Submarines, and Emerged Triumphant from Two Centuries of Controversy

The Theory That Would Not Die: How Bayes’ Rule Cracked the Enigma Code, Hunted Down Russian Submarines, and Emerged Triumphant from Two Centuries of Controversy by Sharon Bertsch McGrayne

I can’t remember exactly how I got to know about this book, but it was through some other podcast or article that I’d read. This is an interesting book in that it kind of spans my two major interest areas, mathematics and information technology, if you consider Data Science as IT rather that mathematics…

The book starts by outlining Bayes’s initial development of his idea and that it wasn’t really considered by anyone during Bayes’s life, as it often the way with mathematically discoveries. Was then taken, or rediscovered, by Laplace.

The rule can be described as using existing prior knowledge related to an event which can be then used to predict the probability of a future event. The term ‘priors’ is used a lot in the book as it the term ‘frequentists’ which refers to the group of statisticians that looked at the Bayesians, those that followed Bayes Rule, as being not mathematical, or just plan wrong.

The book then goes to tell the story of how the Bayes Rule started to solve problems that the frequentists, which uses frequency of measurement approaches couldn’t. For example, Alan Turing’s team helping to break the German Enigma codes during World War II and using Bayes rule to finding possible locations of a lost submarine based on its last location and direction.

Of course Bayes Rule and things derived from it are now used to build machine learning algorithms to give machines the ability to solve specific types of complex problems in novel ways. And where will Bayes Rule take us next…

Books of 2017 – Nudge: Improving Decisions About Health, Wealth, and Happiness

Nudge: Improving Decisions About Health, Wealth, and Happiness by Richard H. Thaler

This isn’t the standard type of non-fiction book that I read as they tend to be either mathematics or IT-related. I started to read this book based on an article on the BBC World Service Global News podcast that covered the Nobel prize for economics that Richard Thaler had just won for his contributions to Behavioural Economics. In the article the reporter referred to Richard Thaler’s seminal book, which at the time I thought sounded interesting.

Now that I’ve read the book, how can I link this book into a blog that covers the topic of Enterprise Architecture? Easy. Thaler describes those that make these ‘nudges’ that alter people’s behaviour ‘Choice Architects’. See what I did there…

Now interestingly, if you’ve read these blog posts in order, you would see that the book that I read before this one was ‘Playing to Win’ which uses the concepts of choices and possibilities when talking about ‘How to Win’. So in this situation you could call the person developing the strategic choices a ‘Choice Architect’ too.

The book’s premise is that my making small changes to things, like defaulting employee’s retirement saving scheme to some sensible starting value guides the employee to a better economic outcome rather than assuming that the employee is motivated to set this up even if they are aware of the benefits. The small change to the choices available is the ‘nudge’ that is referred to in the title of the book.

Making choices too hard or too complex, or having too many choices can, in many cases, mean that people are loosing out. The book ends with a section, I think the version I read (listened to) was a second or later edition, that contains examples from readers of the book of ‘nudges’ that companies or government agencies have implemented for the benefit of people.

Books of 2017 – Playing to Win: How Strategy Really Works

Playing to Win: How Strategy Really Works by A.G. Lafley

This is the first book of my 2017 books that I’d actually already ‘read’. In fact it holds the title of being the first book that I listened to using Audible back in the day when I had an Android phone, a nice Samsung Galaxy S2. The reason for listening to this book in the first place was that my work had adopted the Playing to Win approach to strategy development and people were talking about their P2W packs and their Strategic Cascade. So I wanted to find out more.

So why read it again? In part because I had just installed Audible on my iPhone and it was available and secondly, in my new-ish role, understanding stuff about a Strategy development framework that we had at least notional used at work was, I perceived, a benefit.

The process essentially covers answering the following questions:

• What is your winning aspiration?
• Where to play and where not to play?
• How to win?
• What capabilities are required?
• What management systems are required to achieve success?

When reviewing “where to play” and “how to win”, an organisation needs to consider options and the various possibilities that the options present. The focus then is asking the question for each possibility “What would we need to believe to be true?”. There is some specific guidance in the book recommending that the most skeptical member of the team is given the job to test the things that have to be true and to start with the item that has the lowest confidence level. If the test fails then the possibility can be dismissed and this reduces the tests required.

Classic research for strategy focuses on breadth over depth, but what is actually required is depth of a specific area or possibility or barrier. The concept of focusing on the item with the lowest confidence level has strong alignment with the Lean Startup approach of validating your riskiest ‘leap-of-faith’ assumption.

Regarding the selection of choices and possibilities the book recommends the following steps:

1. Frame a choice
2. Explore possibilities to broaden the set of mutually exclusive possibilities
3. For each possibility ask “What would have to be true for this to be a great idea?” using the logic flow map to structure the thinking.
4. What conditions is least likely to hold true?
5. Design test against those crucial barriers to success
6. Run tests
7. Select the best choice

The logic flow map sounds like a key tool to identifying what capabilities are needed or what combination of capabilities would be unique for the organisation that then would create a strategic differentiation.

The book then recommends some ‘do’s and don’ts’

• Don’t over analyse
• Explore a wide range of possibilities
• Do stay focused on the key question of “What would need to be true?”
• Do get skeptics to raise barriers
• Do start with testing the biggest barrier

The book also identifies some classic strategy traps:

• The ‘do it all’ strategy
• Attacking the walled gardens – Don Quixote
• Waterloo – fight on every front
• Something for everyone strategy
• Dreams that will never come true
• Programme of the month strategy

And once you’ve avoid the traps, here are some signs of a good strategy:

• Activity system (combination of capabilities) that is different to competitors
• Customers that adore you – and now customers that hate you
• More resources to spend than competitors
• Competitors go after one another
• Customers look to you first for innovation

So there you go, just follow the simple steps and you’ll have a world beating strategy.

Books of 2017 – Business Relationship Manager: Careers in IT service management

Business Relationship Manager: Careers in IT service management by Ernest Brewster

I work with a team that are the ‘relationship’ people between the Business and IT divisions within my organisation. As I suspect is the case in many organisations they have found that role very challenging. Especially as many of their internal stakeholders (I don’t like to use the term ‘customer’ as I like to reserve that for the true ‘paying’ customers) see them as a way of either getting their pet project completed or to complain about the response they got from the very latest IT fault or issue.

However, my colleagues are wanting to have a more strategic conversation with the business and have a plan to follow the discipline of Business Relationship Management. Now I also manage a team of strategically-focused IT people. So I wanted to better understand what Business Relationship Management was all about. To understand the potential overlap the the Business Relationship Management disciple had with my own team.

I ended up reading (or I think in this case, both reading and listening to) this book in a single day. My overview of the Business Relationship Manager (BRM) is that they should be wearing a blue skin tight full-length suit with some red underpants worn over the top of this suit and a large red ‘S’ logo displayed prominently on the chest, and oh yes, a large cape too.

The BRM needs to be both a trusted advisor to the business division and a trusted proponent of the issues and challenges faced by the IT division. The BRM can provide solution recommendations to the business based on the business’s need and the technology available or supported by IT. They should be able to co-ordinate resources to achieve this success. Understand the regulatory environment that the divison operates in, the products and services that the division provides, understand the processes the division runs and the vulnerabilities and risks that the division has to be aware of.