Pablo Bermejo, Author of Building Software Platforms: A guide to SaaS transition with AWS

Len:Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Pablo Bermejo.

Based in Asturias, Spain, Pablo is a Principal Software Architect and Distinguished Technologist at independent IT services provider DXC Technology. A popular conference speaker, he is also a writer, who has published numberous articles and whitepapers on a wide variety of topics in a number of fields.

You can follow him on Twitter peibolsang and check out his website at dev.to/peibolsang.

Pablo is the author of the Leanpub book Building Software Platforms: A guide to SaaS transition with AWS. In the book, Pablo provides a guide to a new architectural style that can be used to help companies build internal platforms that empower their developers to build services and provide solutions to problems in alignment with the organization's own needs and tempo.

In this interview, we’re going to talk about Pablo's background and career, professional interests, his book, and at the end we'll talk about his experience as a self-published book author.

So, thank you Pablo for being on the Leanpub Frontmatter Podcast.

Pablo: Thanks for having me, Len. I'm excited to be here with you today.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you first became interested in things like computers and technology?

Pablo: Right. Okay, I consider myself a privileged person. Because I was born, raised and I went to college and I work - everything within twenty square kilometers, in Asturias. I was born in Asturias, I grew up in Asturias, went to college to Asturias - and I work in Asturias. And for those who know that part of the region in Spain - it's small, it's very rural. I had great opportunities to grow here - yeah. I first became interested in computing when I was a teenager, so that is the early 90s. I'm 40 years old now. So that is in the early 90s, when a friend of the family - back then it was very rare, especially in this region, to have a computer. I remember it was a fellow teacher of my parents - my parents are teachers, and one of their fellow teachers, he had a spare computer. I mean, it was rare to have one. But this person had a spare computer - and that spare computer, he gave it to us.

That's how I started to get familiar with computing, and that's where I started to learn some BASIC programming back then. On my own, with a hard book copy of BASIC - that's where I started to discover the infinite possibilities of programming a computer.

And of course, I also - as I said, I'm very privileged - because since I was very young, I knew what I wanted to do for a living: anything related to computers. And it just happened that - again - in Asturias, you can go to the college and study computer sciences, and I became a computer - well, a software engineer. So that's a little bit of my background.

Len: You mentioned the college there, it was the University of Oviedo. Is that correct?

Pablo: That is correct, yes.

Len: For people who might not know, you said - you sort of modestly said "college," but this is a university going back to, I think the 16th or 17th century?

Pablo: Oh, yeah. This is one of the things that happened over here, is that you can even visit the buildings back then. There's a historic building of the 15th century. It's one of the oldest universities around in Spain.

Len: And so you mentioned, you were fortunate enough to have this computer, and you had an actual like hard copy book that you learned BASIC from.

Pablo: Yes.

Len: I'm curious - this podcast has over the years become a little bit of a sort of time capsule of time capsules, of people from different eras and places around the world, learning - getting to know programming and things like that, because so many of our Leanpub authors are into that.

I'm just curious, to dig into that a little bit deeper. Were you a tinkerer, even before you got the computer?

Pablo: A what, sorry

Len: A tinkerer, someone who takes things apart and puts them back together and things like that?

Pablo: No, not much. No, I wasn't that kind of person.

Len: Okay.

Pablo: No, I was very - all my life, I've been very focused on getting my school subjects passed and that's all - and some sports. I'm a sportsman, and in my free time, even since I was a kid, I always try to do sports.

Len: And did you begin by making games? Were those your first programs? Or was it something else?

Pablo: Well, I remember I tried. Even back then, I don't even remember. It was GBASIC or QBasic, the language where you could do some drawings. I don't even remember now. But yeah - of course, I was trying to do shapes. I remember perfectly, trying to do shapes, and human shapes and buildings, with programming, back then.

I got very frustrated, because even with the manuals, I couldn't do it. I thought that made me a bad programmer. But later, I tried to fix that by going to college, and then I became officially a bad programmer. But yeah - I got a very first experience in my early years, teenager's years. But then I very, very quickly recognized that that was my future.

Len: It's really interesting - I love thinking about the history of computing and things like that, and people's first encounters with them. And I remember, one of the things that might be sort of - it's difficult to convey to people, is - how exciting it was to be able to have an impact on what you were seeing on the screen, yourself. Even the most rudimentary thing.

I remember someone I knew had got a computer - this was in the early 80s. And he typed out, pixel by pixel, an ice hockey team's logo, and then printed it out, and said, "Look what I made." And it was just like these crude blocks.

Pablo: Blocks, exactly.

Len: He kind of made an approximation. But the idea that you yourself could type something into a computer, and then make it happen on a screen, was just magical.

Pablo: It's magical. I'll be honest with you, it's one of the best feelings you - I mean, personally, there's a lot of self-realization when you try to solve a problem, and you try to attack the problem, and then fight it and design a solution. Build it as you want to build it. And then it works, or it doesn't work - but it's yours.

I use this a lot with the team I work with - all these kind of systems that we build, software pieces that we build, are like our babies. It's like we design them, we take care of them, we make them grow - and sometimes there is this feeling of ownership, that what you're building is yours. And it's, as I said - it's a lot of self-realization when you are coding and when you are programming, for sure.

Len: And what was your first job in software engineering?

Pablo: My first job was as an IBM Lotus Domino developer in 2003. I think - and this is something that usually happens over here - that I even graduated after I got the job. So I got the job, and then one year later, I graduated.

And yeah, I was an IBM Lotus Domino developer for the first couple of years. It's a technology that's no longer - well, I'm sure it exists. Actually, I didn't check. Back then, it was very popular. And the creator of Lotus Notes, it's Ray Ozzie - who to me, is one of the greatest software minds of all time. And only because that person invented that, I was happy working with IBM Lotus.

The technology itself was interesting. If you think about it now, it's a NoSQL database. Back then it was like, well - everything was 09:02 AutoCOL/article [?], and everything like that. Back then, Lotus was like, "Okay, I'm a documents database." And then I'm like, "Okay, you were the MongoBD and the DocDB of the early 2000s."

It was interesting. It allowed me to learn cool stuff. I learned Ajax, and web development with Ajax with Lotus Domino, because the Domino servers that you could have a JSON representation of a view. And that was sent by the server, and I used that to start playing with JavaScript Ajax and Prototype back in 2006. So that was actually was kind of my escape valve for Lotus Domino. And because the technology itself, as I said - it's not very interesting or compelling, but that part of it, where you could build web applications and use Domino as a backend with JSON - that was pretty interesting.

Len: It's interesting to talk to people about their careers. A lot of people - their way into their first jobs, is through start-ups and stuff like that. And some other people - the other side of the sort of coin there, is big companies. I gather you've been with big companies for much of your career?

Pablo: Yes, very much. I think it's just circumstantial, because of the local market in - I wouldn't say in Spain. Spain in general is fine. It's true that it's a market which is dominated by the big corps, and especially the big consultancy corps - the Accentures, the DXCs, the Deloittes, and other local players. But it has been always dominated by large corporations, and the opportunities that you get back then - not now - Now it's very different, it's a lot of small start-ups and product companies.

But back in 2000's, basically that was the only choice, nd especially where I lived - again - in Asturias, the opportunities were very reduced. You could only work for Capgemini, DXC - but it was CSC, HP, and that's it. For smaller companies, yes - but they were struggling.

Now, the situation is totally different. There's a lot of cool start-ups that are doing cool things, that are going well with organic growth and everything. But back then, the market was dominated by the big corporations, yeah.

Len: That's actually a good segue into the next question, which is something that comes up relatively frequently on the podcast, which is - if you were starting out now, let's say you were 18 years old and you were just out of school - and you were intending to have a career just like the one that you've had, would you formally study Computer Science at university, or would you choose a different path?

Pablo: No, I would go to university. This is very, very clear. University gives you something that some other ways of learning can't give you, which is fundamentals.

Don't get me wrong, I'm all for programming bootcamps and things like that. I love them, they are very good. I think - and this is something that I talk about a lot in my work, is - the bootcamps help you hack the learning curve. You can learn how to build an application very quickly - which is very, very helpful for entry-level people who want to see something working in two weeks.

There's a lot of people who cannot spend mentally, or financially, five years learning something - and at the very end of the career, they build an application, right? Many people leave, burn out on the way. They want to see something, and say, "Why am I learning calculus? Why am I learning maths and algebra? Why am I learning all that? I want to build an effing application, right?" That's fine.

For those kind of people, bootcamps is a very good solution. You can learn something. You can have quick satisfaction. Because in two weeks, or even one month, six months - you get a good learning path, and you are kind of hacking the learning curve.

But the important thing is that you are not done. Now you need to learn all the fundamentals. So, at the end of the day, the path you take through the university, and the path you take through the bootcamps, is the same. The goal, the point where you want to reach, is the same. Which is, full understanding of the technology, full understanding of the fundamentals, building applications and solving real problems.

Which way do you want to take? Either the long way with the university, and at very end of the university, learn how to build an application. Or, hack the learning curve. It's a shortcut. Then you get the satisfaction - but don't forget, you need to learn the fundamentals too. Again, different curves, different paths for different people. Personally, I would choose the university way. Well, it's my mentality - and well, I think it fits well with my way of thinking.

Len: And just to sort of go into a little bit of detail there, for anyone listening who might be facing this choice, wherever they are in their career - maybe they've got another career, and now they're choosing maybe to become a software developer or something like that. What do you mean by the fundamentals?

Pablo: The fundamentals of computer sciences. This is how computers - from the physical level - how computers work inside, what is the von Neumann architecture, to binary programming and logic. All these kinds of things. From how programming languages work, how databases work - all these kind of things. All those fundamentals - you don't need that if you are trying to build an application with React or Turbolinks. You don't need that. But in the long term, you kind of need it. As you start solving larger and larger challenges and problems, you realize that you need the fundamentals. To be able to think with an open mind, and actually be able to resolve larger problems. So, the fundamentals are fundamental.

Len: That's really interesting. And when it comes to - I mean, I imagine you know the difference between big companies and start-ups and things like that. Is it typical for the big companies, when it comes to entry-level positions - to require someone to have a Computer Science degree? I mean, in 2021 - nowadays?

Pablo: No, the gatekeeping days are over. Those gatekeeping days are over.

My position is the following: I hire people to my team. I'm an architect, who happens to be a manager as well. Basically, if I find somebody from the university who lacks real hands-on experience, and they've got a strong base, in - again - the fundamentals and the foundations, but they lack real-hands on experience in building applications, I would give them a training course, or I would give them like a six-month period for them to catch up, right?

On the other hand, if I find somebody from the market - well, "from the market" is a very horrible name, I hate it to say that. But you know what I mean, right?

Len: I know what you mean, I do that sometimes too.

Pablo: I hate it. Sometimes I - these kind of words, I try to eliminate them from my vocabulary sometimes - but you know what I mean, right?

Len: Yeah.

Pablo: If I find somebody, who - again - coming from a coding bootcamp and without a college, university title - I don't care, I hire them. And in the interim?, I consider whether it makes sense or not, to pay them for university. Like if I realize this is a potentially good candidate or good people, that is productive and they've got a future and a glittering, promising career - maybe I consider to say, "Maybe we need to give these people the fundamentals, so why not we, the company, funds their training?" That's my approach to hiring.

Again, two different paths, for very different people. It's driven by context, financial situation, life background, so - and again, I'm not a gatekeeper, the gatekeeping days are over. I consider that gatekeeping is very dangerous for our industry. Our industry needs more, I don't know - writers. They need more, better communicators - actors, and people from science.

We need to nurture our industry with different points of view. Because if everything we've got is engineers from the university, then it's going to be very self-enthusiastic between ourselves - and I don't think it's doing any good to the industry.

We need more people with external eyes, that can help say, "Hey guys, you engineers with the title, you are not doing this right." This industry needs some push with some other things that we engineers can't see - because it's not our background, and we need those kind of people in the industry.

Len: That's really fascinating, actually. One of the big questions of the day right now - in late 2021, when it comes to gatekeeping and finding new people and sort of widening the prospects and bringing diversity onto teams - what do you think about remote work?

Pablo: Right, remote work for - I mean, I've got mixed feelings. So as a worker, yeah - I think, kind of. I'm one of those people who want to see other people. I'm a social animal, I need to be with people. So could I accept a job which is 100% remote? Oh my God, yeah - it depends on the conditions. I would ask 100 questions about, "When can I see my team, when I can reconvene with them? Are there any events where the team can go together? Is there any office I can go?" I need to see people.

But on the other hand, I'm very, very comfortable working remotely. So I'm kind one of those people who like a hybrid, right?

For my hiring self, totally - I don't care where the people are, as long as they do their job. So, the pandemic was good to spot micromanagers. All those people who got nervous during the pandemic because, "No, no, I want my people, in the office." And, "I need to chat with my people every day, because I need to know what they are doing."

Well, that was a very good micromanager trap. So all of them appear, and show from the caves and I'm - of course, I'm not one of those. As long as the team is doing a good job, even if it is a schedule where they say, "Hey, Pablo, I work four hours in the morning and then five hours in the night," that's fine. We've got situations like that in my team now, where even people say, "Well, Pablo. I need to go - and my family is from Canary Islands, so would you mind if I go and I redo my life in with my family in Canary Islands?" And I said, "Go, now."

Len: Thanks for sharing that. It's really interesting, and this is a subject I think we can probably talk about for a very long time.

Pablo: Yeah.

Len: Particularly when you bring up the idea of someone whose job was contingent on the sort of artificial environment that people were working in - that was maybe a legacy of past requirements, but wasn't really necessary anymore. It's even baked into - these conventions can become baked into language. For example, even now, people will say, "It's time to get back to work."

Pablo: Yes.

Len: And what they mean is, "Back to the office."

Pablo: Exactly.

Len: But it is conflated in people's minds, right? You see it in the discourse. Particularly in the United States, there's been this whole thing about sweatpants. I don't know if you've noticed that articles are always like -

Pablo: Yes.

Len: "It's time to get out -" And what is with this obsession with sweatpants?

But I mean, you can ask it sort of in a funny way - but when you try to take it actually seriously, what are these people concerned about? And it's likem without the kind of uniform and the ornamentation, they don't see work really happening. And it's just interesting for people - I have a sort of very straightforward mindset when it comes to stuff like that. Like, is it work or isn't it? I don't need a watercooler to prove I'm working -

Pablo: Exactly.

Len: And I definitely don't need a commute to prove that I'm working.

Pablo: Show me the outcomes, show me what you're doing.

Len: Yeah, exactly.

Pablo: Deliver me the milestones and all that kind of things, but yeah--

Len: Exactly, but as you said at the beginning - that's your hiring self, that knows all these things. But you also have to know that people have certain personalities, and that's an important thing to take into account. Some people need to be around other people, just every once in a while, or even every day, to get their juices flowing. Other people, you fly them out like a kite and tie a rock to the bottom, and come back a while later, and reel them back in - and they're like, "Here's the best output you've ever seen."

Pablo: Exactly.

Len: You just need to take that into account. Actually, just on one last question on this broad area, though. You mentioned the pandemic, and I was just wondering if you could talk a little bit about - I mean, it's been almost two years now - but how that affected you where you live?

Pablo: Well, at the beginning, you know that Spain was hit hard - well, like any other country. And I'm lucky, again. Because the region where I live is not very crowded, as I said - it's kind of rural. I mean, it's not 100% rural, there's a lot of rural space. But it has been always probably at the tip of the spear, in terms of good situations. It's like Asturias has been always good at the lowest levels of the virus spreading in Europe. I'm not even talking about Spain, I'm even talking about Europe.

And now - well, it hit hard. To my family as well. My grandparents passed because of the pandemic, but they were 97 and 98 years old. So well - of course, they couldn't do it. But apart from that, well, now the situation is probably is the best in Europe, in Spain. I mean, if you look the news and you - if you read what's going on North of Europe, it's like, "Oh my God, what's this? Are we back again to 2020? What is this?" Spain is, I think we have reached a level of 95% of vaccinations.

Len: Oh, wow.

Pablo: That's impressive. And, well, historically, we've been - I guess, there's some historical reasons why Spain always has been responding well to these kind of situations. Demand social cohesion. And Spain is a very social, cohesive country. We are demonstrating that with these vaccination rates, which is putting our country in the lowest level of risk in Europe. So now, the situation is quite good, of course.

Now, you can't think in terms of countries right now, because I mean, Spain is good, but what happens if Portugal is not good or France? It's like they are there, it's 400km away from Spain. Now, you can't think in terms of frontiers. It's like well, what happens in Africa? I mean, I don't care if the Spain is 95% vaccinated, if Africa and Morocco is - again - is 14km away from Spain.

I mean, I would stop looking at these numbers from a country perspective. It's on a species perspective. What happens if there's free movement of people around the world? What happens when we open our frontiers, and people from all over the world come to our country - which they should. And it's like, where's your numbers, Spain? That's why I think when I look at those numbers, it's like, so what? I mean, if Spain is 95% vaccinated and then South Africa is only 20%, it's like, "Well, what's the point?" So it's very difficult. But, again, I'm kind of lucky that in the current situation and circumstances, where there's still a little bit of country lockdowns - you can't travel much, although it's opening - we are good, we are good.

Len: Thank you very much for sharing all of that. It's always so kind of - as you nicely captured the fact that it's, the issue with the pandemic is simultaneously hyperlocal and global.

Pablo: Totally, it's a very good of putting it, Len.

Len: There's just no escaping either of those features of it. I'm glad to hear things are going so well, at least now locally. And when you said things were going well, it's like I was like, "Huh," I just realized I hadn't seen anything about Spain and COVID for a long time in the news, which is the best, in a way you could -

And so, now moving onto the next part of the interview, we're getting closer to talking about your actual book. I wanted to ask you a little bit about, I'm just looking at your LinkedIn profile here - if you could just talk a little bit about the work you do day to day, and that you've been doing for a while now for - I think it's DXC Assure?

Pablo: That's right, yes. So DXC Technology - again, is a large company - is a global IT services company. I think now, we are about 140,000 people - around that. We are very well known, because we are a services company that - we are a little bit less known, because we are also a software company. And there's a software group within DXC, that means a group of probably 4,000 people - that we build software, like a product, right? We've been doing that for 25 years already. I mean, they have been doing it. I've been doing it only for about eight, nine now with this team. I think it's eight years, seven years with this team.

But as a company, DXC has been building intellectual property for 25 years. We are specialized in insurance software, so basically large policy admin systems and reinsurance and broking, quotation, identification systems - all these kind of things that we sell to our customers as products.

About five years ago, we started that transition, and we started to move from a product-based economy to a services-based economy. We realized that there is nothing magic in our code that makes it irresistible to our customers to own it. They don't want to own our product because it's fantastic - no, they like our service. And we realized that the future was deliver our service - sorry, our software as a service. So five years ago, we started a transition to - software to service. And that's the name of the product, the solutions - DXC Assure.

At the core of DXC Assure, at the core of the SaaS solution, there is a component - is the platform, it's a digital platform. So you can start already linking the dots. There's a platform, it's a SaaS, it's transition, building software platforms, a SaaS transition - a guide to SaaS transition with AWS. Which is exactly what I tried to capture in the book, is my experience during the last five years - from a technology point of view, how to start to decompose and migrate large monoliths into more cohesive and decoupled services.

Doing it using now what we call "a platform approach" at the core. Doing everything on AWS, because as I said, when you are doing software as a service, you own all the costs - the cost of the assets in their totality - you own, you have the TCO. So we decided to go full with AWS.

It's like - okay, well we don't have a multi-cloud requirement, we don't have a portability requirement. We deliver to our customers all that they care about, we give them the best insurance functionality through the internet. Whether we deploy that on AWS or Google Cloud, it's like you and me when we watch Netflix - we don't care, just give me a good service.

Len: Thank you very much for that, there's actually a lot of really interesting stuff to unpack there. I like the way you're linking the actual work that you're doing to the book, and how it came out of that.

And so just to start at the sort of very - we'll get to the really interesting stuff, but just to start at the basic level. So you make these insurance products, and you provide these insurance services - are those to insurance companies, is that who your customers are?

Pablo: Yes.

Len: Right.

Pablo: That's right, our customers are large and small insurance carriers. So yeah, insurance companies - that's right.

Len: Okay, so hopefully that will let me now build an analogy, to make sense of what you're - to fill out the sort of picture of what you're saying.

So - in the past, if you wanted to say run a web company, you had a room in the back with servers in it. And you had to actually buy them, you had racks. You had a person to put them in the racks, and make sure they all talked to each other, and then talked to the internet appropriately - and you had to have this physical thing that you were maintaining in your business. But then eventually that went away, and you could have this sort of up in the cloud.

And also in the olden days, if you, let's say wanted a web browser - you went to the store and you bought the product and you took it home, and you installed it on your computer - and then you had that product.

Nowadays, of course. what you would do is you would download the browser application from the web, and then and not only would you have it, it would update all the time as well.

I'm trying to build up the idea that so, if you're,let's say I'm CEO of an insurance company, and I want some software to do something. In the past, what you would do is you would probably build it - you would maybe hire a team of programmers to build it yourself, which is the analogy to having the servers in the back of the room. But eventually what people maybe transitioned towards, was actually having a company provide them with the software in a less in-house way.

But then there's been this shift towards actually providing the - realizing that you don't need to provide them with this product, you could provide them with a service. Am I kind of getting it?

Pablo: Totally, yes.

Len: And one of the really interesting things that happened too, particularly with things like AWS, is that instead of having to have like - I've got ten servers or whatever it is, right? I can actually only use exactly what's being used by my customers. So it's only when people are hitting my website that I'm using these servers in the cloud, and that's all that I'm paying for.

And I gather one of the things that's really driven the kind of work that you've been doing, is realizing that like you can build services that are only paid for when they're used.

Pablo: That is correct, Len. So there is nothing in the principles of software as a service that says that you have to do it on the cloud. Or let me put it another way - there is nothing on the principles of the software as a service and the service economy, that says that you couldn't do it on on-prem, with very little under your desk. There is nothing.

It just happens that it doesn't make sense, it doesn't scale, right? I mean, if you are providing a service to your customers, yes - it could make sense that you own everything, you own the hardware where your software is installed. But why do you want to cosplay as a cloud provider these days? You don't want to cosplay as a cloud provider, that's their job - managing hardware services is their job now in 2021.

So if I use those services as a utility, then for me, it's even easier to translate those costs into software as a service. What I mean is - if I am paying for what I consume in terms of infrastructure for my internal calculations, it's easier to transform that into a price per use of the software as well, right? Because there's a closer connection between what I pay and what I sell as a subscription, right?

Of course in the middle - there is labor, there is a lot of things. But now the relationship is kind of closer.

And of course, when you are doing software as a service, you are - again - you are hitting the long tail. It's like well, anybody can subscribe to it. I don't have even a business model approximation? How many users are going to use it, so I want it to scale. I don't want to be going downstairs every day to rack up more servers, because I just suddenly I got 2,000 more clients. No, if I got 2,000 more clients, AWS is going to scale it for me.

So that's why - again - there is nothing in the principles of SaaS that says that you cannot do it on-prem with very little. But it doesn't make sense, it doesn't scale. And that's, also - I talk about this in the book a lot,I talk about build versus buy patterns - which is something that I'm not sure if you wanted to cover that as well?

Len: Oh, that was my very next question. If you could talk a little bit about this distinction? What's the difference between a build pattern, versus a buy pattern - and from whose perspective are we thinking? Who's got the pattern?

Pablo: Exactly. Well, the pattern's everywhere - when you are a builder, and when you are a consumer. So, for example, Jeff Lawson, who's the CEO of Twilio and he speaks - well, he wrote a lot about this in his book Ask Your Developer, which is a book that I absolutely love - and is actually one of my inspirations to my own work. He says, "Well, it's not actually build versus buy, it's build and buy. Because there are some situations where you need to build, and some situations where you need to buy - and they are not mutually exclusive."

I mean, it depends. For some components, you need to buy the components. But for others, you build them. And again, I talk about this a lot in the book.

So, when do you build? Well, you build when you've got something that is core to your business, and when you need full control. When it is so critical to make your company different from the competition, that you need to build it.

And typically in a post-pandemic world, this is user experience, or customer experience. Everything that is exposed to my customers, where I offer them ways of acquiring my services. In this case - an insurance company is buying an insurance policy, "I want full control of that, I want to build it." So my customers who are insurers, I would recommend them, "Go and build your customer-facing portals."

Of course here, there are nuances that - again - I talk about them in the book, I don't want to leave my customers alone. It's like, "Oh, go and build it." No, it's, "Go and build it, but I'm going to offer you components. I'm going to offer you a framework. I'm going to offer you a design system. I'm going to offer you a small component so you can build your product."

There are even customers who say, "Yeah, thank you, DXC, you are giving me all these tools, but I don't have the manpower." It's like, "Okay, then we can partner, and we can do it together."

When do you buy? Well, you buy when there is something that is not important, it's just cost of doing business. For example in my company, DXC - internally, we've got SAP to manage the finances, and Workday to manage HR. Do you mind DXC building our own HR system for 140,000 people? No, like okay, buy it. It's core? No, because we are not an HR company, we are an IT services company, so we buy it.

So today, those are the kind of things that you buy when it's not core to your business, it's not going to make you different. I mean - do you think that DXC is different from our competitors, because we've got Workday? No. It's cost of doing business. So that's when you buy.

And this is very interesting, because - again - I talk about this in the book a lot, is, some people and some companies, for them it's so important that they recognize what is core to them. And that's the key question. It's like, "When do I build, when do I buy?" Well, the answer is very easy. If it is core to you, build it. If it is not core and it's just cost of doing business, it's not giving you any competitive advantage - then buy it. They don't know how to answer that question.

It's like, "Well, I don't know if this is core to me. Well, yes, I can buy Workday of course. But Workday out of the box or a service out of the box, is not giving me what I need for my unique HR process." It's like, "Your HR process is not unique, it's just cost of doing business. It's just a natural process. Adapt - you must adapt your process to the tool, not the other way around." So you can focus on your core business - and your core business, in the case of DXC - is selling IT services. In an insurance company, it's selling more policies. In a car manufacturer, it's just selling more cars.

Len: It's so fascinating actually. One of the things I really liked about the explanation you gave there - which was very good, was you captured the fact - I mean, particularly at the end there - when you were talking about like, "How do I know what's core, though?" It's actually not necessarily straightforward. Especially before you've actually gone down the path, the technological path that you're going to have to go down, right? The decisions that you're going to make along the way, are determined by the decisions about what you make is core. But you kind of might find out at the end that what's core, is not what you thought.

Pablo: Exactly.

Len: And that actually gives us the opportunity to bring up something a little bit fun. Because your book is Building Software PlatformsA guide to SaaS transition with AWS, and it's for companies who might want to build internal software platforms with the architectural style that you set out to make this work. You talk a lot about how this is empowering - learning how to empower the developers within your company to create the kind of tools that your company needs.

But not just for the specific thing - there's a higher-level principle that this book is one instance of. I think that you start the book by showing that that's true, by talking about a restaurant.

And so I was wondering if you could talk - and you have a good joke, "So you thought this was a software book, but now we're learning about gastronomy." I was wondering if you could actually talk a little bit about that example that you give at the beginning?

Pablo: Right, yes. It's a very funny example - I don't even remember how it came about, but it has been always kind of in the back of my mind.

So, there's a restaurant in Spain called "El Bulli," which is actually probably the best restaurant of all time. And the main chef of El Bulli is Ferran Adrià. Ferran was known because in the late 90s, when El Bulli was already enjoying a leading position - two Michelin stars, among the best places in the world - he was like, "So what?" He went conference to conference, and he watched how other chefs - they express what they were doing, presenting what they were doing. But they were keeping their secrets and the recipes to them - they were not sharing that with him, to the world. So Adrià, that triggered Adrià's creativity - and said, "It's over. I'm going to open source my recipes and my techniques." And that's what he did.

Of course, he didn't use the word, "open source." Now we know that, even in 2021, probably if you ask him, he doesn't know what the "open source" word means. Well, maybe he does? He's very smart guy.

But what he did was, "I'm going to open source my recipes." Because he thought that the best way of protecting an idea, was actually making it public. So by doing that, this was a smart move - because what happened after that was that El Bulli and all the competitors, started to compete in equal conditions of practices, of techniques.

Everybody knew what Adrià and El Bulli were doing, and the techniques and the products - everything. So all the restaurants around the world, they started to use molecular gastronomy, and they started to acquire all the tools - and they started to compete in equal conditions. By doing that, actually what happened was that maybe without knowing, Adrià and El Bulli - they created a standard, an industry standard. And they created a standard just by making it public. It's like everybody using it, it's a standard. So that's how a standard appeared. It's like if everybody use it, that's a standard. And they created a standard by open sourcing recipes and tools and techniques.

So - again - other restaurants had started to compete in equal conditions. But El Bulli, what happened was that they differentiated from the rest by how they cooked the dishes they made. It's like the dishes they made with equal conditions, with equal practices, with equal raw materials. They were still the best - because they differentiated themselves in service, in operations, in customer experience.

So you could get exactly the same dish in El Bulli or in your local restaurant, because the techniques were exactly the same, the raw materials were exactly the same. But why weren't they? Why El Bulli, why is your local restaurant - couldn't do what El Bulli was doing? Because El Bulli was differentiating in service, customer experience, and operations.

And that is a lesson to the industry today, I mean to the tech industry - in that when you are enjoying a leading position as a product, and you've got a very competitive landscape - it could be a very good move to open source your product, to stop competing on the product, and to start competing on the service.

And you know who's the master of doing that, is AWS. AWS, they are the masters of industrialization. Of course there are always some challenges and situations, like what happened with Elastic as well. But at the end of the day, they are masters of industrialization. And the net of it is - companies that are moving today in the product economy, if they want to preserve their competitive advantage and still lead in the coming years, they need to move to a services economy. Because that's where, at the end - the evolution and the industrialization goes.

Len: It's really fascinating, the lesson to be drawn from that. And like, I mean - the courage and the, I mean - the balls of what they did, is really incredible.

But it makes me think - when we were talking before about, "How do I know what's core, or what I want to be core to my business?"

We'll do an exercise, right? If you've got any proprietary technology or secrets - imagine everyone knew them and imagine everyone had them, right? Then what would you be doing to compete? And this is a really good exercise for thinking about how - that I learned from your book about how to really come to grips with what it is you are doing - and what you want to be doing, and what you can do, and where you can compete.

Pablo: Exactly. In the book, I use a technique which is called Wardley Maps, that - again, the creator - I quote Simon Wardley, who is the creator of the technique - a lot in the book, because he's got brilliant quotes and he - I mean, he also envisioned where the tech industry was going in 2008.

In 2008, he was already talking about serverless. I mean not with the word "serverless." He called that something like "runtime utilities," or something like that. But he envisioned already - he was the CEO of a company, where they did something like what AWS Lambda is doing today. They did JavaScript runtime as a service. Again, in a small company, and he envisioned where the industry was going.

And then he developed this technique, which is called, "Wardley Maps," which is giving you movement and position. You place the different elements of your business, or even your architecture in a map - and you can easily see the dynamics of what is custom built, where the things are evolving, where the competition is happening, where do I get the market push, where my next move should be - here or here? "Should I buy or build it?" Well, if it is core - you build it. If it is not core, you externalize. Because, well - it's a very industrialized utility. So Wardley Maps is an excellent tool to build and develop strategies.

Len: That's really fascinating, and that was on my list to talk to you about. I was also introduced to this idea, the idea of Wardley Maps, from your book.

Let me see if I can grasp it quickly for people. Imagine you've got an X-axis and a Y-axis, and the X-axis starts on the left with a technology that's completely unique to you. And then on the - as you go further right, the more universal and - as it were - commodified it becomes.

And then the vertical axis, the Y-axis is - starting at the bottom is totally not user facing, completely internal to your system, and then at the top is exactly what the user sees.

I think a lot of people listening to this, who come from the nerdy kind of business background like I do - to some extent would immediately start thinking of a quadrant. But that would be the wrong way to think of it, it's not - you can imagine there's the drawing a line through this grid, that whether the movement is through time, right?

Is that kind of right? Is that one way you could use a Wardley Map to plot my movement through this table?

Pablo: Exactly. And Simon Wardley, there's a lot of material. Simon is very kind, because he - I mean, all his work is Creative Commons. It's a lot of videos of Simon Wardley talking about this in YouTube, and he continuously talks about, what is the difference between a graph and a map.

A graph is typically an architectural diagram - website, users, servers. When you put that on white paper, you got a graph. The difference between a graph and a map, is that the map gives you position and movement. It tells you where you are comparing yourself to the climate, to the competition, to your context. And this term that he uses - it gives you situational awareness with regards to your elements.

Again, it's very important. Because typically what we use in business, to draw our strategies, are short analysis, graphs, road maps. That is giving you position, if you like, right? But it doesn't give you movement. You don't know what, you can't - it's very difficult to understand where the competition is happening, what elements are more industrialized than the others.

I should never compete with things that are already industrialized, compete with a product - I should never build a product where a utility already exists. Because the utility's going to win the market. But if there isn't a product for something, maybe I need to custom build it?

All these kind of things is what Wardley Maps gives you, and allows you to identify what are the market pressures. And see, "Okay, my next move would be industrializing my lifecycle operation, or industrializing the way I build frontends," for example. "I should partner with someone who is building it for me, so I can focus on something else. If the market of insurance application is already commoditized and there are utilities, I should go for that and focus myself on other stuff." That's movement.

Len: And it lets you account for timing.

Pablo: Very much.

Len: Which is something you talk about really well, about AWS in particular. That it's not, as it were - only building the products that people need, but it's building the products that people need and releasing them at the right time - is crucial.

Pablo: Yes, AWS is very, very good at meeting their customers where they are. They don't push you to use technology that you don't want to use. And this is a name that I learned, it's a German name, "zeitgeist." It's a word that I think you English native speakers use as well, but that's new to me.

It means the - literally I think it means, "the ghost of time," zeitgeist, I think? Which is, well - understanding, and being empathic with - having some empathy with the time you are living in, right? And understanding what are the contexts of the society. And in this case - your users, your customers. Understanding what are their problems, and giving them a solution - exactly where they are, exactly the solutions they need.

That solution may not be exactly where you want to be in five years. But take them by the hand, show them the way - and gradually, with them, walk the journey, while you show them how to evolve the journey you want to do.

AWS is very good at that. Because when they started AWS Lambda in 2014, it was a very - well, that's a different case. Because actually the problem with that, was that it was very aggressive, nobody used it, and they needed to revert it - to make it less aggressive.

But for example, if EFS - EFS is a very good example, because they serve state functions. Another good example. They started very simple with a very, very basic, pretty basic state machine functionalities, giving customers low code ability to write state machines.

Gradually, they started to add more and more and more functionality. So they master MVPs. They give you an MVP - and you know when you use that MBP - that in two years' time, they're going to invest. In two years’ time, they're going to give you another 1,000 functionalities out of the box, and it will cost you nothing.

Len: I think since we've been talking for about an hour now, we should probably move on to the last part of your interview where we talk about - it's been a great conversation, we could talk about this forever. But I mean, that's one of the reasons people should go and buy the book.

Pablo: Exactly.

Len: So speaking about the book, we save this for the last part of the interview. We talk about your experience writing and as an author. I was just wondering, what was the moment -? Do you remember the moment or the period of time, when you realized you kind of had a book in you?

Pablo: Yeah.

Len: About this kind of thing?

Pablo: Totally.

Len: And when you made the decision? Okay.

Pablo: Totally. The hardest part of building software platforms is adoption. Because it's a new architectural style, it's a new way of building tools for empowering developers. And adoption at the beginning, for us, it was kind of hard. My customers - in this case, as a platform architect and product manager - are developers. The 1,000+ developers are my customers. And adoption was hard, and even - I'm very happy with DXC. Because full support and sponsorship, they really understood that it was the way to go. But in any case, adoption is hard.

I remember I started to write notes in preparation for meetings. Meetings with other directors, meeting with customers, meeting with peers. To explain to them, what is a platform, what are the benefits for them, what is the platform all about? Technically, from that point of view, what is a platform? Why is going serverless and embracing the technology important? I started to write notes to support some presentations, decks.

After a few months, even a couple of years - I realized, "Oh my God, how many notes do I have?" And it's like, "I have a book. So look at this. If I write story about this and -" I remember at the time, I was learning also about Wardley Maps. I said, "Oh my God, if I glue up all these notes with some Wardley Maps concepts and all the things I'm learning about AWS, I think I've got a compelling." So that's what I did, I started to glue up all these notes with some wording, and trying to make a smooth story and a guide to SaaS transition - and this is how the book was born.

Len: Did you have a schedule for writing? Where you were like, "I'm going to get up five in the morning and get in two hours before I go to work?" Or did you work on the weekends, or -?

Pablo: No, I - this is the first time that I say this, but I wrote my book walking. There's a lot of meaning in what I'm saying.

So Saturday morning, Sunday morning even, weekdays in the morning - I go out and do some one hour, one hour and a half walking. I don't know what happens to your brain, but I remember like 1,000 ideas came to my mind. And I made another 1000 voice notes about this and this and this. And then, I say, "Oh, yeah. I'm going to write this down."

I would say that the most compelling ideas, if there are compelling ideas - I mean, readers should tell me that - that came to me while walking. It's incredible, and I'm very avid Twitter user, and I heard that from a couple of Twitter users as well. For example, Sarah Drasner, who is now Engineering Director for Android and Google - and Sasha Rosenbaum, who is in - well, a leading position in DevOps in Red Hat. They say this a lot - that they like to walk, they like walking. Because a lot of ideas come, and something happens to your brain in those moments - and it happened to me.

Len: That's really fascinating. I think you're the first person to talk about writing their book while walking, that we've had on the podcast.

There is an ancient kind of heritage for that. There was - I think it might have been Plato's Academy, where they called "The Peripatetics." Because they would walk around while lecturing, rather than standing - someone standing somewhere, and then speaking to people sitting before them - you would go on a walk. And a lot of people think, "Oh, that's just a way of keeping the students occupied or something," but it's also for the person speaking, because it kind of gets the juices flowing.

I gather too that the Romans, back in the Roman days - were notorious for walking around, at times and places when people didn't just go for walks, and the people thought they were crazy, right?

Pablo: Crazy, yeah.

Len: Because they'd go for walks. But I've always thought, I bet a big part of that - and I'm not talking about peasants, I'm talking about the generals and aristocrats and stuff - they would have ambulatoriums. Like they would build things for you to walk around in.

Pablo: Oh, I see.

Len: I always used to think it was partly for that to get thoughts and conversation going.

Pablo: Those things fascinate me. I mean, these are fascinating things - how the human brain works, and this is fascinating.

Len: Yeah. And by the way, I totally sympathize. I mean, I have to keep myself from talking to myself with all the ideas that come when I'm walking around. Probably at least having something - I could pretend I'm making voice notes or something, which would make me look less crazy, yeah.

And so, you wrote the book in a very interesting way. And then eventually you decided to publish it, and you decided to publish it, it's in print on Amazon - but it's also available on Leanpub. I was wondering if you could talk a little bit about why you chose Leanpub as the platform?

Pablo: Well, I was a user of Leanpub before I wrote my book, so I purchased a couple of books here. For example, well - I can say there's a very good book on cloud strategy by Gregor Hohpe, which is I think one of the best-selling books in Leanpub. I own a copy of that.

And also being an agilist, the first time I heard about Leanpub - the first thing that came to my mind was the "lean" word. Like "lean," okay. And even without looking in Google what Leanpub was about, I got it. It's lean publication, it's Leanpub.

It's like, "Okay, this seems to be some a way of where you are publishing an MVP of your book, and then you iterate." It's like, "Oh yeah, that's it." So it literally clicked to me, "Right - if one day I write a book, I think I'm going to use this."

And also, because I think it's a very good platform, full of choices. Being on Leanpub already is an honor for me. It's like even you can publish it, fine. But my book is amongst other brilliant books on the platform - and to me, already that is an honor.

Len: Oh, thanks very much for those kind words. It's funny you say Leanpub clicked with you right away, because there are people for whom that happens. But we also get the occasional kind of snarky Brit who's like, "I thought it was a bar that only sold diet beer," or something like that.

Pablo: Well, yeah. That too.

Len: In another universe or another timeline, that's what we did.

Pablo: Exactly.

Len: So, your book is available in print on Amazon, and I was wondering if you could talk a little bit about how you did that? How did you get your book in print?

Pablo: Oh, it was very easy with Leanpub. It was very, very easy. I think I'm a - I subscribe to the standard plan, or even the professional plan - I don't recall now. I think it's the standard? And with the standard - you can have a free print ready copy of your book, that you can go and upload to Amazon. It was very, very easy.

Len: Thanks very much for sharing that. Yes, we have a Print-Ready PDF option, where you if you write your book in one of our writing modes, you can click a button, and then - I mean, you do some settings - but you can basically click a button and get the file you need to use print on-demand services like Amazon KDP, and Lulu, and things like that.

I'm glad to hear it was easy. We hear that from some people. But since we've, I mean - since I've been there for the whole development of it, it always surprises me that it works. It's only because of working closely and talking to people like you over the years, that it does work now.

The last question I actually always save for a guest who's a Leanpub author, is - if there was one magical feature we could build for you, or one terribly annoying thing about Leanpub that we could fix for you, can you think of anything you would ask us?

Pablo: There's one. It's resources management. It's how pictures are managed in the writing mode.

Len: Okay.

Pablo: It was kind of a - well, not a pain - but for example I find it - I think my book has about fifty figures, pictures - and it was hard to manage those fifty. I think I got a very flat view of them. Whenever I wanted to replace one picture with another, I found it a little bit difficult. Because replacing, there is no good way of replacing a picture with another one. You need to delete the previous one and upload it. At least, maybe that's me? I didn't find a way. But if I didn't find a way, that also means that there is some UX part of it which needs to be fine-tuned. But for the rest, I I found it very usable, very straightforward. It's like, go write your book. There's a "Write" tab up there, you click on "Write," and you start writing. And that's it.

Len: Thanks very much for that actually. That's really helpful for us to know. I'm actuall - I feel guilty, I didn't actually look to see what writing mode you'd used before the interview, but I'm looking at it right now. Yeah, you used the browser/web writing mode. Where, yeah - we give you a "Write" tab in the browser, and you just write there. And although in some ways, when it comes to just writing words, it's super straightforward - you can click a plus button and create a new chapter, adn then you type a pound sign--

Pablo: Oh that - Very easy. And the Markua language - is it Markua, the name, right?

Len: Markua is how we pronounce it.

Pablo: Oh, Markua, right - is pretty easy to follow, very well documented as well, I found. Very comprehensive documents on the internet, so yeah.

Len: Oh, that's good to hear. It's our vision of Markdown for books - basically for anyone listening, who knows what that means.

But when it comes to images, so we have a - on the "Write" tab in the browser, we have a "manuscript" section - which is where you type your words out, and stuff like that. And then we have a "resources" section, where you upload images. And then you can click a little link, and then that gives you the Markua text that you need, that you can just paste into your manuscript. But, yes - the way that looks and the way that is managed, is in need of improvement.

Pablo: Yeah.

Len: And it's actually interesting, I'd never particularly thought of the situation of needing to replace an image before. Basically what you would have to do, is you would have to make sure to copy the file name, you would delete the image that's on there - and then you would add a new one. But then, where the new image has been added, would be at the bottom of the list basically -

Pablo: Exactly.

Len: And that would be confusing and kind of nerve-wracking.

Pablo: Yeah.

Len: You'd want to do a new preview right away, to make sure it was working and stuff like that. And that's definitely -

Pablo: After a few months, I found my way to do it. But at the beginning, it was a little bit confusing. But yeah, I think that's my - off the top of my head, that's what I have.

Len: Thanks very much for that. Another limitation of the "resources" tab there, is that if you have - I mean, you've got about - you said you've got about fifty images or so, that's kind of manageable.

Pablo: Yeah.

Len: Some people have up to hundreds of images, and if you have hundreds of images, you would actually want something a little bit more robust than what we have.

Pablo: Like a file manager or something, whatever.

Len: Yeah, we'll definitely think about how to do that better.

Well, Pablo, thank you very much for taking the time out of what I'm sure is a beautiful evening in Spain, up in the north there, to be on the podcast - and thank you very much for being a Leanpub author.

Pablo: Thanks to you, Len.

Len: Thanks.

And as always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.