Last week, infrastructure generalist vendors TIBCO and Progress Software, both of which sell BPM technology alongside complementary technology (event processing, ESB, data integration, analytics, and so on) announced their Q3 financial results.

TIBCO announced that it had achieved 23% growth year-on-year in both license revenue and overall; Progress announced that it had achieved 8% growth overall (but 14% from software licenses). For the year-to-date, TIBCO hit revenue of $512.8m; Progress hit revenue of $384m.

Interestingly, both companies share a figure: both companies source around 35% of their revenue from new license sales, with 65% coming from services and maintenance – both companies are mature. Also interestingly, both companies have been using similar campaigns to attempt to reinvigorate their fortunes, and engage customers in business conversations rather than deep-tech conversations (“my ESB’s faster than your ESB,” etc).

For TIBCO, it’s all about helping customers capitalise on a “two-second advantage“; for Progress it’s all about building companies that exhibit Operational Responsiveness. For both, it’s about tying together technology that helps organisations sense changes, opportunities and challenges quickly (event processing) with technology that can make sense of those events and drive the right response into the organisation or the market (BPM, integration technologies, and so on).

Both companies have played up the roles that their “responsiveness” technologies are playing in their growth. It’s certainly good to see veteran players like TIBCO and Progress rediscovering a bit of mojo; let’s see whether they can parlay this upward swing into longer-term growth plays. For me, the health of a handful of  “independent” infrastructure software players is a good sign for industry at large, because it maintains a level of industry choice that just wouldn’t be there if the market collapsed down to the usual behemoths.

At TIBCO’s TUCON user conference a couple of weeks back, CEO Vivek Ranadivé unveiled the themes that his company plans to use to anchor its marketing over the next year at least: Enterprise 3.0 and the “two-second advantage”. Unsurprisingly given his predilection for publishing books that provide the backstories for his company’s direction (see The Power of Now and The Power to Predict), the “two second advantage” is also the title a forthcoming book from the CEO.

So – does this idea make sense? In my view, yes – with qualifications.

It’s important to say that Ranadivé is quick to point out that the advantage he’s talking about doesn’t have to be two seconds; it could be two minutes, two hours or two days. What’s important is the challenge: imagine what you could do if you could understand enough of what’s going on just a little bit before your competitors. TIBCO is taking this idea and using it to illustrate the value of event-driven IT infrastructure: it’s using the idea to highlight examples in industries like mobile telecoms, financial services, healthcare, and travel & transport.

Basically, TIBCO’s approach, at a high level, boils down to the company saying “we understand what it takes to build event-driven IT infrastructure that delivers information quickly around large and complex organisations, and we understand what that can mean to a company – because we’ve been helping companies do it for decades.” [As an aside, part of me wonders why this doesn't form the core of its campaign, but there you go].

So far so good, then. But here’s the qualification: TIBCO has to be very honest with its market, because it would be very tempting – but very dangerous – to tell this story simplistically, trying to convince potential customers that everything they do has to be event-driven, real-time and so on.

At TUCON, we heard two assertions repeated together: first, that the volume of enterprise data is inflating rapidly; and second, that the ‘half life’ of enterprise data’s value is decreasing at an ever faster rate. Now I can buy both these statements: what I have trouble with is whether the same necessarily holds true for the *same* data. Most of the inflation in enterprise data volumes can be attributed to email, email attachments and rich media. Most of the data with a ‘half life’ issue lives elsewhere. Yes there are information management problems here: but I think the “two second advantage” has to be more nuanced than this.

The truth is that there are some parts of many enterprises’ activities which would definitely benefit from being event-driven – but the thing to watch out for is that pesky old consideration of ROI. The value of some kinds of enterprise data may decrease rapidly over time; but this is a statement about its *relative* value. Is the *absolute* value of that data high enough, when it’s fresh, to deliver a return on the investment that would be required to make the necessary infrastructure change?

If TIBCO can be smart and honest about the scope and applicability of the two-second advantage, I think we’re on safe ground. The concept parlays directly from TIBCO’s experience on trading floors into other industries – taking TIBCO’s core original competency (event bus) and playing it out in other scenarios. In this way it’s a little like IBM’s Smarter Planet theme.

Now, though – don’t get me started on Enterprise 3.0. All I’ll say here is that (much as I’m generally against the idea of versioning concepts) the term Enterprise 2.0 has become pretty widely understood already, and it has nothing at all to do with client-server technology infrastructure.

For TIBCO, “Enterprise 3.0″ is just shorthand for a combination of BPM, SOA and business analytics. It’s almost as if TIBCO has been panicked into Enterprise 3.0 by the recent rhetoric of Johnny-come-lately Progress (which, following its acquisition of BPM specialist Savvion and the combination of this with its 2005 acquisition of Apama, has started positioning itself as helping customers with “Responsive Process Management”).

The two-second advantage has the potential to play strongly for TIBCO; Enterprise 3.0, to me, is the sound of a company trying too hard.

When MWD started in 2005, the first topic we sunk our teeth into was SOA (it was 2005′s Cloud Computing, pretty much).We researched the technology and the practice pretty thoroughly, I think (along the way tackling “SOA 2.0” among other things), but in mid-2007 we drifted away from the topic a little. At the time it seemed that we’d said pretty much all we could about the subject – we’d done a lot of technology and architecture research (looking at the need for governance, the need to consider consumer as well as producer service lifecycles, and so on), and there were still relatively few opportunities to dig into actual case studies to start to determine real-world best practice experiences.

Over the past few months, though, I’ve started to pick away at SOA once again – it feels to me like we’re at the stage where there are some interesting real-world stories to dig into, and at the same time there’s still a lot of people looking for answers to some straightforward questions about the nature of SOA and how to deliver value from a SOA investment.

With this in mind, I was excited to see the launch of a “SOA Manifesto“, styled after the Agile Manifesto – which has had a significant impact on expanding awareness and understanding of Agile development techniques. I was intrigued to see that Anne Thomas Manes of Burton Group, of “SOA is Dead” fame, was one of the signatories – so I decided to ask her about her involvement in the drawing up of the manifesto. I know that Anne and her team do a lot of case study and best practice research on SOA, so I was interested to hear why she wanted to get involved. Below are my notes from our conversation.

NWD: What kinds of issues have you seen that made you want to get involved in the SOA manifesto?

ATM: Fundamentally, the amount of people I’ve seen who still think SOA is about technology rather than design/architecture. Though we are further along now because we have better books (like Thomas Erl’s books), I just felt that there’s still a need to show people that SOA is about designing systems differently. When I wrote the “SOA obit” blog entry, it was really a reflection of the fact that only around 15% of the projects we saw were delivering significant value; and maybe another 25% were just about breaking even. The majority of projects we’ve seen just haven’t delivered a decent return. My goal in being part of the SOA Manifesto group was really about trying to get people thinking about SOA in a different way, so they could use SOA to enable much more business-aligned portfolios of applications.

NWD: What’s the precise purpose of the manifesto, do you think? What does the group want its value to be, and to whom?

ATM: We very much admired the Agile Manifesto, and followed that path. When it was published a lot of people didn’t know what Agile meant; it really helped crystallise the role and value of Agile development. The value of the SOA Manifesto is hopefully similar – it’s in the way it establishes a set of core principles and value statements to help people think about what we think are the right things and getting SOA back on the right track.

NWD: What kind of feedback have you had on the SOA Manifesto so far?

ATM: Well, there have been a number of accusations that the content is too general-purpose – that there’s nothing that’s inherently Service-Oriented about it, and that you could apply it to many other things. You know, I think that’s true – but I don’t think that it invalidates the principles at all in the context of SOA. This kind of reflects the whole point of doing the Manifesto: the challenge we’ve had with SOA implementations is that too often, people have ignored the stuff we know works in the rush to try out a shiny new set of technologies.

NWD: Is the SOA Manifesto “group” planning to build on this initial statement? If so how?

ATM: We currently have over 300 signatories to the Manifesto [Now around 475], and all the group members are blogging/tweeting about it. We’re trying hard to make sure that we get as many signatories as possible, in other words. But, just as was the case with the Agile manifesto, there’s no group intention to directly commercialise this [in delivery of a body of knowledge, training, etc].

I’ve looked at a lot of the commentary and criticism of the SOA Manifesto out there, and a lot of it seems to be about saying “so what?”. But as Anne rightly points out above, the fact that the principles in the Manifesto are quite applicable to many types of business-technology change initiative doesn’t make them worthless. The fact is, SOA implementation *is* a business-technology change initiative.

I think the other thing to bear in mind, when looking at the SOA Manifesto and SOA analysis and commentary generally, is that no-one in their right mind is saying that SOA is always the right answer when it comes to application implementation (though in my view there’s an abstract business analysis/architecture part of SOA, reflected in OASIS’ SOA Reference Model specification work, which has general applicability across all domains). There are many technology implementation domains where SOA principles aren’t the right ones. As the Manifesto points out, SOA should be all about a set of architecture decisions that promote flexibility and agility (through things like loose coupling). In some situations, there are other factors (like extreme performance) which might trump a general desire for flexibility – or at least create interesting tensions for architects.

So – to sum up: personally I’m a fan of the SOA Manifesto. It’s not perfect, but nothing designed by committee ever is. It *is*, I think, “good enough” for what it needs to do – which is to add more weight to the argument that if you want to deliver value from SOA work, you have to continually remember to focus on  a set of IT architecture principles and avoid getting too distracted by shiny products.

A couple of months back I had a brief Twitter exchange with David Bressler of Progress Software (@djbressler), following a comment I’d seen from Judith Hurwitz (@jhurwitz) at Progress’ analyst day regarding the lack of brand awareness that the company has out there in industry. What I said was: “Progress is a bit like Unilever – top-level brand is vanilla, sub-brands have chops”. What I meant is that these days, there’s little knowledge of what Progress does (a typical response is either “Who?” or possibly “oh, they used to sell a 4GL and a database in the 1990s, didn’t they”) – whereas there’s much more recognition of brands like Sonic (SOA infrastructure), Actional (SOA management / governance), IONA (middleware, SOA infrastructure), Apama (event processing), DataXtend (data integration) and DataDirect (data connectivity, legacy application integration).

David replied that Progress is a technology company’s company – which is absolutely correct: Progress has a long and successful history of providing a platform for other software vendors to embed in their application offerings. And he followed up with this blog entry, saying “We’d love for the Progress brand to have some chops, and we’re trying but it’s not trivial.”

Well, for a few weeks I’d been meaning to write a blog post of my own exploring this – but in the general headlong rush that we’ve been experiencing so far this year, I’d forgotten to write that post. When I saw today’s news that there’s been a change at the top at Progress, though, I was finally prompted to write some thoughts down. (Thanks for the pointer Miko).

The main thought in my head all those weeks ago was that it’s all very well for Progress to be a bit like Unilever – with the sub-brands (Sonic, Actional, Apama, DataDirect, and so on) having much more visibility in industry than the parent brand – as long as the company doesn’t want to start pulling together broader IT and business infrastructure propositions that tie together pieces from the different brands. Unilever is well-known for owning a vast portfolio of products, many of which actually compete with others in the portfolio (Dove v Lux; or Persil v Surf, for example. The invisibility of the parent brand is fine for Unilever, but it’s bad news for Progress if it wants to really make the most of its potential within enterprises (by cross-selling or bundling its products to help customers with broader opportunities, for example).

So this is the point where the company has to undergo a pretty radical shift. As reported in PCWorld, the new Progress Software CEO (formerly the COO) has established a target of doubling the company’s annual revenue to around $1bn, by “reorienting sales towards multi-product suites, as well as aiming marketing messages more at business executives than IT workers” – that is, precisely what it’s not currently suited to doing.

This goal makes absolute sense, and in fact it has made sense for ages. The majority of the markets where Progress’ brands play are growth markets where there’s real opportunity, right now; and what’s more, the combination of the offerings could have real power, too.

The required shift will be no picnic, but there are worse times for Progress to be trying to make it happen. There’s a new man at the top with a new broom, no doubt; and what’s more, there’s still a small window of opportunity open for another medium-to-large-sized specialist infrastructure software vendor to pick up business, following BEA’s acquisition by Oracle a few months back. TIBCO and Software AG have recently been making much of BEA’s disappearance as an “independent” infrastructure software vendor, and it’s surely no coincidence that both these companies also have aspirations to reach $1bn in annual revenues (Software AG has been particularly vocal about this of late). Progress has long had the potential to join Software AG and TIBCO as a serious contender for enterprises wanting to avoid getting into bed with the MISO pack (Microsoft, IBM, SAP or Oracle) for whatever reason, but until now it just never seemed to be able to be bothered to do what was necessary.

With a new CEO at the top, it’ll be fascinating to see whether Progress can move up a gear. If it succeeds, then enterprises wanting to avoid giving too much technology supplier power to the MISO pack may well have a new choice – and in a market where consolidation has recently been rampant, more choice would be refreshing for everyone.

Something that’s been sloshing gently around in my head for a little while came into focus the other day on reading a post by Brenda Michelson: Unintentional Cloud Watching >> Cloud Computing for Enterprise Architects. Namely, that the link between cloud computing and SOA has multiple angles.

It’s becoming clearer that, true to Tim O’Reilly’s initial Web 2.0 noodling, by providing open infrastructure services and APIs, the poster children of the Web 2.0 era – Amazon, Salesforce, Zoho, and so on – are now treading the path that companies like StrikeIron started out on in 2002.

As a result, as other commentators have noted, it looks like the bulk of the service-oriented IT that many organisations will interact with will be “stuff from outside” (commercially provided services) rather than “stuff from inside” (internally developed services). And it’s not just hosted SaaS providers who are playing here of course: there’s the issue of newer versions of on-premise commercial packaged application software products and integrations between them – SOA is coming in by the back door there, too (see SAP’s ESOA, Oracle’s Fusion Architecture). In fact, perhaps unsurprisingly, there are strong parallels here with the component-based development (CBD) hype-wave of the 1990s – a lot of the initial hype was around tools and development for enterprise IT groups, but ultimately the vast bulk of development was actually carried out by commercial software vendors, for consumption by enterprise IT teams. What we’re seeing here is a repeat of “componentware” market development, with a 21st Century twist.

Regardless of where services come from (and indeed because they will come from multiple places, creating cross-enterprise service networks), it’s increasingly the case that in order to deliver effective IT capabilities in the 21st Century, you need to understand SOA principles and build technology and management structures that really support the principles of service orientation. Much has been written about the “consumerisation of IT” and how new generations of people entering the workplace are asking difficult questions about why enterprise IT applications are so unintuitive to use. But what happens when business teams that are using SaaS-based offerings learn about the infrastructure side of the story – how easy they can be to customise, extend, and integrate with – and ask why internally-developed systems don’t exhibit the same qualities? Another slab of SOA pressure, that’s what.

Back in 2006 I was doing some research for an event that we were considering running on “IT Sourcing in the 21st Century”. As part of trying to work out what might be in scope and what might be out of scope, I drew this picture:

As the picture attempts to show, from a technology architecture point of view, the software-as-a-service (SaaS) model relates to the prior Application Service Provider (ASP) model in much the same way as SOA relates to monolithic on-premise applications – to deliver value, both SaaS and SOA need to “crack the box open” and enable IT capabilities to be customised, composed and remixed while also being shareable/reusable. There’s much I disagreed with about Anne Thomas Manes’ recent “SOA is dead” post (see Schrodinger’s SOA), but she nailed this parallel between SaaS and SOA pretty well I think.

With the increasing visibility of cloud-based infrastructure and application services in mind, anyone seriously pursuing SOA should be looking to the world of SaaS for insight, or at least inspiration. In the IT industry’s rush to SOA, many of the nuances and implications of SOA have often been condensed into simplistic advice targeted at software developers (something that’s been written about a great deal, not least by us). One of the themes we’ve returned to again and again in our SOA advice is that the concept of a “service” isn’t primarily about something you build – it’s about something you experience. If you’re going to deliver business value from your SOA efforts, you have to grasp the implications of this and make the necessary changes – not only in terms of tools and technologies, but also (crucially) in terms of your governance approach. One of the most popular posts from arch-architect Todd Biske, on ITIL and SOA, digs nicely into how it’s crucial to consider the full service lifecycle when you do SOA, and drive governance to ensure that you can deliver “real service” – not just code wrapped in XML-based interfaces.

The providers of cloud-based services should have this idea etched on their brains – and there are plenty of examples of this principle in action for any eager student of SOA. Witness the grumbles that echo when Twitter barfs, for example, or see the grumpy users trying to get to grips with Zoho’s CRM API in the face of almost non-existent documentation. These are great examples of situations where the provider’s idea of service doesn’t match the consumer’s expectation.

The rise of cloud computing and SaaS should entice us to revisit our development-centred assumptions about SOA and search for a “bigger picture” that focuses on consumer expectation and value first. The pressure to deliver business value from IT capabilities, and the increasingly diverse mix of IT capability sources, demands that we do so.

I’ve spent a couple of days wavering over whether to jump into an ongoing blogosphere debate over the “Death of SOA”. For those who haven’t yet read any of the debate online, here’s the catalyst: SOA is Dead; Long Live Services – a fictional obituary of SOA by Anne Thomas Manes of the Burton Group. On one hand I wanted to avoid adding another voice to a growing crescendo of opinion and counter-opinion and the risk of not really shedding any extra light: but on the other hand I thought that some people might expect MWD to have something to say! Particularly given past blog posts like SOA 2.0? Stop the madness, Little SOA vs Big SOA, More big vs small thinking: SOA vs BPM, The pointless search for SOA ROI, and On SOA governance: for SOA, read CPOA?.

In the end, I couldn’t help myself. Call it New Year exuberance. So what’s our take? Is SOA dead or alive? Should anyone care?

I think there are a couple of key points to consider. First, what’s wrong with SOA today? And second, what should we do about it? I agree with Anne on the first; but I think I really disagree on the second.

When I look at Anne’s post in detail I believe she’s making 4 basic points:

1. The majority of SOA projects have failed to deliver what they promised.
2. Business people are disillusioned with SOA.
3. “SOA projects” will be killed by today’s difficult economic conditions.
4. Despite all this, the requirement for SOA is greater than ever.

I’ll happily back two of those points up – the first (UPDATE: to a degree – I have anecdotal evidence that suggests many organisations struggle with SOA, but that’s not quite the same)and the fourth. There’s one section towards the end of Anne’s post I’m particularly in agreement with:

SOA is not simply a matter of deploying new technology and building service interfaces to existing applications…it requires a massive shift in the way IT operates. … The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change.

This is pretty much what we’ve been saying about SOA for some time (see Little SOA vs Big SOA from April 2007). In short: SOA won’t succeed if you take an overly technical, product-based view of it (and indeed we’re far from alone in this – ZapThink bangs this drum a lot, too, for example).

So we agree that not all is well in the State of SOA: but where I diverge with Anne’s post is in the prognosis for SOA and the treatment for the illness.

Anne’s prognosis/suggested treatment is that SOA (or at least the term) is (or will soon be) dead. Her view appears to be that because its death is inevitable, we should accept it and move on – stopping talking about SOA and starting talking about other things instead. This appears to be bound up with her observations that “business people are disillusioned with SOA” and “SOA projects will be killed by the economic downturn”.

Before I move on – I don’t know about you, but I think that if any IT group has been trying to sell SOA directly to business people, they deserve everything they get. Regardless of economic conditions. No, no, no! You don’t sell methodologies and architectural patterns: you sell outcomes. Argh! And here’s a hint: if you work for an IT group that used to try to sell SOA to business people, and is thinking about now trying to sell “mashups”, “cloud computing”, or similar things – don’t bother, you’ll get the same result. Sell the outcome and the benefits, not the mechanism or the technology. Double Argh!

There’s another risk with changing the way we speak about what Miko Matsumura jokingly now calls “The Artist Formerly Known as SOA”: by doing so, we continue to spread the perception that the IT industry is a fashion industry unable to kick its habit of (re)inventing terms to reinvigorate markets when earlier promises go unfulfilled. Whether she knew it or not when she wrote the post, by referring to a change in terminology (away from SOA and towards “services”, “mashups”, “cloud computing”, etc) as an active and influential commentator, Anne is contributing to the fall from grace of the term.

Well, as I said here when I railed against SOA 2.0,

I sincerely believe that analysts should be good stewards of the influence they have – educating, clarifying, abstracting, comparing, acting independently, being measured, etc. It’s about filtering out hype and trying to provide practical, independent advice and insight.

Just because SOA is difficult to do, we shouldn’t start calling it something else in the hope that we can start over without anyone noticing. And it’s no surprise that SOA is tough to sell to business people – I don’t believe that was ever up for debate, and it shouldn’t be seen as any kind of broader indicator.

Let’s acknowledge that we all have more work and education to do – but let’s not jump the shark on this. “SOA is Dead” is a headline that no-one needs.

A couple of weeks ago I was the happy recipient of a review copy of the excellent Todd Biske’s SOA Governance book. Todd’s “Outside the Box” blog is one of those rarities where every post is worth reading twice – so I was very interested to see whether his writing ability might stretch to something the length of a book! Todd’s clearly established himself as someone who has a lot of insight on the topic of SOA Governance, so I was pretty sure I wouldn’t be disappointed.

A number of other bloggers have posted detailed reviews of Todd’s book, so I’m not going to do exactly the same here. Take a look at the Amazon comments if you’d like to see what they said.

For me, I’ll be brief: SOA Governance is a very good book indeed, in that it does something that so many technology and business management books fail to do: it breaks a complex and hype-laden subject down into very manageable chunks, and walks through the topic clearly and at a steady pace – but it still manages to move quickly enough to prevent the reader getting bored. It’s not a perfect(*) book, but then nothing is – and if it had been, I would have been too jealous to write this. We need more technology/business management books like this, and we needed just such a book on SOA Governance. Well done Todd!

I knew this was a good book because it made me revisit some conclusions I’d already had washing around in my own head for a couple of years.

One of the things that I still find as I travel around is that when I get into discussions about SOA, there’s way too much focus on the “S” and not enough focus on the “A”. It’s almost as if we’ve been blinded by technologies and standards which have “service” somewhere in their names, and aren’t able to look at the bigger picture.

What Todd’s book reminded me is that if you want to get real value out of service orientation, then it’s the “A”rchitecture that really makes things happen. Todd’s narrative keeps coming back to his definition of Governance, which revolves around People, Policies and Processes. And it also talks a lot about the concept of “contracts” in the context of analysing how service providers and consumers should work together in order to interact. Without People, Policies and Processes in place to guide your organisation down the right path, and without the concept of “Contract” to focus on the responsibilities that need to be described and assigned when service consumers and providers interact, such an architecture effort will likely lead nowhere. You’ll end up with “just a bunch of services”.

So – and this was the thought that occurred to me after reading Todd’s book – perhaps we shouldn’t really be thinking about “service” oriented “architecture” at all. It seems to me that what architects might find more productive to focus on is policies and contracts, not “services”. Maybe “service” is better thought of as a concept that describes the outcome of this kind of architecture approach. And so maybe it’s the case that there are two things in play here, and we’re getting them mixed up: contract- and policy-oriented architecture (CPOA ;-) and service-oriented IT delivery?

What do you think?

(*) one thing I found rather strange was that despite a word at the front to reassure readers that they didn’t need to know any technology detail in order to read the book, at a number of points you’re suddenly confronted, out of nowhere, by XML fragments which (as far as I could tell) didn’t really add any value. That’s a tiny niggle though.

Following the first Software Delivery InFocus podcast which we published in September, October sees Bola Rotibi’s second podcast episode, in which she discusses a series of questions focused on the topic of Application Lifecycle Management (ALM). Her guests are John Leegte (ICT Architect at the Dutch Tax and Customs department, Belastingdienst) and Steve Jones (Head of SOA and SaaS for Capgemini’s global outsourcing business).

Application Lifecycle Management (ALM) is a topical subject that has garnered significant column inches in recent months, as many of the leading players in the market have launched new versions of their ALM solutions, and make strategic announcements concerning future directions and customer services and support. Over the last few months we have either heard about or seen previews of products from the likes of Borland, Compuware, HP, IBM, Microsoft, MKS, Polarion and Serena, to name but a few. Software is seen by many organisations as a key enabler of business value – whether that be through improving operational efficiency, competitive differentiation or business/ product innovation. With this in mind, an ad hoc approach to software application lifecycle management cannot provide the predictability, visibility and traceability that organisations require of a process that has such a significant impact on the balance sheet. So – how relevant and applicable is ALM now and in the future, particularly in light of today’s technology and business environments, when issues such as agility are so much to the fore?

The episode is slightly longer than normal (clocking in at 41’55″). There was so much good material in the conversation, we didn’t want to cut anything! Thanks very much to both John and Steve for such a great conversation.

You can download the audio here or alternatively you can subscribe to the podcast feed to make sure you catch this and all future podcasts!

As with all the episodes in this podcast series, we’ve also published a companion report which summarises the discussion and “key takeaways”. You can find it here, and it’s free to download for all MWD’s Guest Pass research subscribers (joining is free).