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 – The Agile Architecture Revolution: How Cloud Computing, REST-Based SOA, and Mobile Computing Are Changing Enterprise IT

The Agile Architecture Revolution: How Cloud Computing, REST-Based SOA, and Mobile Computing Are Changing Enterprise IT by Jason Bloomberg

Jason Bloomberg wrote ‘Service-Orient or Be Doomed’ back in 2007 which is a book I have read. Back in 2006 I was involved in a project to improve our integration technology. We were initially looking at an Enterprise Service Bus and spent some time with our parent company as they had started the journey of service-orienting a year before. We ended-up making a choice to use BizTalk and build a ‘services framework’ based on Microsoft Windows Communication Foundation (WCF). At the time I was trying to drive the need to understand the services we needed to build using a canonical model of services to ensure non-overlapping capability that cover all the company needs – MECE, mutually exclusive and comprehensively exhaustive.

However the standard problem occurred where technical people just wanted to build the technical solutions and not worry about consistent naming or that the service was going to be designed so that it had a wider applicability than the current project, didn’t leak implementation details and our project and funding processes didn’t help either!!!

I also remember around this time I attended a Microsoft TechEd event and attended a talk on what is now REST, at the time I was aware of SOAP and using XML etc. and didn’t really get what was so special about using REST. So it was interesting to see this book, authored by someone that had written a book on Service Oriented Architecture (SOA) from that time now pitching SOA using the current buzz words of Cloud, Mobile and REST.

Just as an aside it was also around this time that I was in to written language style guides. We had an information architect join us and this guy knew how to set-up templates and styles and things like that and I was suitably impressed. I also, loosely around this time, read the Oxford University Press Style Guide. So with this new knowledge floating around my head I was interested to understand how should you use SOA in a sentence. For example was it 'a SOA' or 'an SOA'. They are both right in the sense that if SOA is preceded by 'a' it implies that SOA is pronounced as 'so-ah'. So you would say 'a so-ah'. But if SOA is preceded by 'an' is implies that your are pronouncing SOA as 'ess-ohh-ah' and in fact that is why it is preceded by 'an' because the sound of the 'ess' starts with a vowel, 'e', and so you use 'an' like you would if you wrote 'an egg', interesting eh?

This of course works for other initialisms, like SAP, so if I wrote 'an SAP system', you would know that I say 'SAP' as 'ess-ah-pee'.

Looking at my notes from this book, yes I actually made a few in this one, the first is a reference to the need to have the enterprise responsible for the IT innovation and architecture of the organisation. That is, not to outsource it, or perhaps this is just an example of confirmational bias!

Of course, the responsibility for IT innovation and architecture is where it should be the most—in the hands of the enterprise. As enterprises find an increasingly less diverse set of vendors to work with, a more economically challenging environment, and the need to innovate and manage increased complexity at an ever-increasing pace, companies will have to look inward. The solution to their IT problems is under their own control. As the vendors fight among each other for dwindling business, you should avoid those battles by focusing on developing architectural strategies that enable agility and innovation without depending on a single vendor. This is the only rational and cost-effective strategy in an increasingly unpredictable world.

The second note, and I’ve just noticed that all of the notes are from the same Chapter, so this must have been the one and only chapter that I read or had read to me whilst I was able to engage with my device (i.e. not driving), covers the topic of ‘replaceability’ of a system/platform.

If you are currently involved in an application modernization or consolidation initiative, ask yourself these two questions: How replaceable is our legacy app? And how replaceable is the app we’re now considering to replace it? If your new choice isn’t far more replaceable than the legacy you’re retiring, then all you’re doing is perpetuating inflexibility by supplanting old legacy with new legacy. On the other hand, including replaceability in your requirements for any new software will lower your long-term total cost of ownership. You’ll also be doing your part to push the vendors to offer next-generation modular software.

I must admit that I have concerns about some of our choices of new applications and also how we are using them and leveraging their capabilities.

The final note from Chapter 7 is on the topic of funding and funding is probably the single most important thing to change to improve how technology is managed and delivered. I should clarify here that it isn’t so much that a project doesn’t get the money required, but it is that the waste that is introduced by having to justify how much money the project requires based on estimates of time to deliver capability that is, at the time the estimates are generated, not, generally, well understood. And for that matter requires approval from those that are somewhat removed from the day-to-day activities of either the technology or business teams involved.

You may be scratching your head right now and wondering, “Aren’t we already doing this?” Or perhaps you are saying, “I don’t get how this is different from discrete IT project management.” If you are wondering that, then you haven’t yet experienced IT portfolio management, because IT portfolio management requires, in most cases, a fundamental change to the lines of IT control and budgeting. To attempt IT portfolio management in an environment where the funds are allocated to individual projects is a recipe for disaster.

The book promotes the use of IT Portfolio Management where the company has moved from delivering applications via projects to providing services that are consumed by the lines-of-business. This sounds similar to, or at least a good part of, the latest hotness which is platforms or ‘digital platforms’.

I remember thinking that this book had other good insights in it, but alas, I didn’t highlight them.

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.