 Thanks, Ekta. Let's get this started. My title slide. I appreciate you all coming tonight. I'm a little intimidated to hear that I'm sandwiched in between Keith Morris and Neil Ford. I've written no books, so I'm just a lowly consultant. But hopefully you'll get something out of this tonight. This is a topic that I and my colleagues have been discussing a lot over the last couple of years. And I'll explain all about that. So who am I and why am I qualified to talk to you about this? I'm the head of technology for ThoughtWorks in Australia. So I'm kind of like the regional CTO in Australia. I've done a lot of different jobs in ThoughtWorks over the years. General management and back and forth with consulting. And this is kind of where I've landed. I do a lot of my time as spent consulting with customers. And so I kind of split my time between internal leadership and running the business and being a consultant. And most of the consulting that I've been doing for the last two years at least has been with big enterprises mostly, helping them adapt their enterprise architecture practices to technology delivery organizations where teams are much more empowered to work autonomously, where they work in short iterations, get fast feedback, where teams build, own and operate their own solutions and dev ops and continuous delivery and all those good things. Oftentimes technical leaders don't know where they fit in that sort of an organization. So I've done a lot of work, I guess, with those technical leaders trying to shape what that looks like in those organizations. And I'll have something to say about that in the course of this talk. So I guess I'm kind of a reluctant enterprise architect. I don't really want to take that title on, but it is where when you get enough gray hair and experience, that's kind of where you get stuck a lot of the time. But I'm an inveterate geek, so I really stay in ThoughtWorks and I stay in this job because I love technology, I love playing with technology and programming and everything still. And one of the really great privileges that I have in my role at ThoughtWorks is participating in this thing we call the technology radar. So I and 16 to 20 of my colleagues get together every six months and we go into a room and argue about what goes on this publication, what goes into this publication called the technology radar. I could spend a lot of, I could spend this entire hour talking about the tech radar. So I'm not sure how much to tell you about it. The last one, about six weeks ago, we were in Barcelona that we tried to rotate around and it's some toll of what we observe ThoughtWorks teams doing all over the world. So one of the features, I guess one of the things that distinguishes the tech radar from other publications like certain analyst organizations might publish is that it's grounded in experience. So we're very particular about putting things up there that are of interest to us and that are of interest to people on ThoughtWorks teams all over the world. And we're very particular about only advancing things into the trial ring that have been used and used successfully on ThoughtWorks projects and actually gone into production and been successful enough with them that we would recommend them for other people that we would use them again. It's not intended to be comprehensive in any way, it's the stuff that we do. Obviously, it's not all of technology, we do kind of business software, custom software development, that's our business. So it's focused on that, but as an opportunity, I'm really lucky that I get to get together with these people every six months and connect with them and I've been doing it for a number of years now and I really enjoy it. So if you have any questions about the tech radar and there are some things in there this issue and a lot of what I'm going to tell you today comes out of the conversations that I have with my colleagues at those meetings. But if you have any questions, I'm happy to take them offline or whatever. If there's anything in there, I will try my best. There's about 100 items on there. I'm not an expert in all of them, I have to admit. Anyway, so we're going to talk about platforms. Just roughly I want to talk about what is successful businesses have in common. It's surprise, it's platforms. And what do I mean by a platform? It's a very commonly used and overused term. And what qualities do they have to have to be successful? And then I really want to drill down into this idea of the platform, looking at the platform as an internal product and managing it as you would a product. Because I think this has much wider implications for how we behave as technology organizations. Okay, my animation's got away from me. So this comes out, I guess Star Wars tends to work in two different places. We work with smaller businesses, medium-sized businesses or purely digital businesses. And in Melbourne, I'm from Melbourne, Australia by the way. I know I have an American accent, I'm sorry to disappoint you. But I've lived in Melbourne for many years and Australia is my home. Melbourne, you may not know it, but it's quite a center for technical innovation. And right now there are a number of global technology digital companies, successful digital companies, headquartered in Melbourne. So it's a very tight technical community. So places like realestate.com.au, Envato, A-Connex, M-Y-O-B. These are people in Melbourne tend to move around. It's a very incestuous city that people move around a lot. And we see what those... So we kind of take what we learn and we provide scale to those businesses. We do a lot of the offshore work we do is for those businesses. But the other place we work is in big enterprises, big banks, the big banks in Australia, the big insurance companies, fast food, retail outlets all over the world. These are the kinds of customers that we tend to work for. And a lot of them what we're engaged in is this idea of digital transformation. This is kind of where our business has taken us in 2017 is a lot of the work we do is towards digital transformation because those big enterprises want to be... They want to operate much more like those smaller businesses, like the pure play digital businesses. And the banks, insurance companies, retailers are struggling to deliver at the pace. They're struggling to innovate and to experiment. Because they really... We know that in order to be successful in a digital business, you have to continually roll out new features to your customers and try those out in the marketplace and make decisions based on the success of those features. And you have to do it cheaply and quickly enough that it's not... It doesn't cost you a lot to throw them away when they're unsuccessful. And of course, big companies struggle with this if they're not purely digital start with. But that's not how we usually get engaged. That's how these things... That's the trajectory of how these engagements go and how companies... But we get engaged in different ways. A lot of times people need a continuous delivery. But we go and we try to do continuous delivery. We try to apply continuous delivery and we're happy to do that. But oftentimes what we find is the architecture or the organizational structure doesn't really support continuous delivery. So we struggle to get the full benefits of continuous delivery. Another thing is this A word. We're often asked, as thought works, we're associated closely with this word that I've tried to excise from my vocabulary entirely. But it's because it's misconstrued and abused a lot. So people decide they want to have fast feedback with teams that work closely with the business and have joint ownership of code and those kind of things. But in the end they get maybe 10% of the benefits of Agile that they could potentially get because they don't have the architecture. They don't have the culture. They don't have the operating model within their business to be able to take advantage of Agile methodologies. This is one that we're seeing a lot lately is that businesses want to participate as a platform business. They want to create a platform that sustains an ecosystem externally. They want to participate in external business ecosystems by exposing APIs as part of their business. And it's been interesting to me over the last couple of years that this is coming from the boardrooms. It's not coming from technology. It's coming from the business. They want, they see APIs as the next big thing and we need to participate in this. But they jump into this long before they are able to actually harness the power of APIs internally. So companies that are far from being able to implement APIs, get them used and have a thriving developer culture internally are trying to create that externally. And that's really putting the cart before the horse. So occasionally, very occasionally, we'll encounter a customer that's willing to address these things holistically though, that's willing to address the entire problem. And that's really what's necessary to be successful in this digital transformation. And it's really, it's this idea of digital platforms. Where is my definition slide? How about that? I was playing with my presentation. I have a definition that I will tell you verbally. So because there's a slide in here someplace, we'll come to it later. So I use this idea of digital platform in a very specific way. And it's platforms, we talk about SAP as a platform, or there's all kinds of things that we call platforms and it's a really overused term. We have not enough words in this IT business. So to me, a platform is a set of APIs, tools, knowledge, support, plus an organizational structure and an operating model that enable autonomous teams to deliver digital solutions and digital features quickly and at scale. And it's this idea of supporting autonomous teams because in order to be successful and roll out these digital features, you need to have teams, so a two pizza team. We talk a lot about the two pizza size team, a team that can be fed by two pizzas that is working to deliver digital features closely with the business directly to the customer without having to interact a lot with the rest of the business, without the friction that slows them down and having to coordinate at work. And I'll have a lot more to say about that in a minute. So this idea of digital platform is not just us that's talking about it. This is the blue line is Google Trends for the search term digital platforms over the last two years. And the red line is the Google Trends for the search term enterprise architecture over the last two years because I love to beat up on enterprise architecture. You can see that there was something happen a year ago. I don't know what it was, but something happened about a year ago to really accelerate interest in this idea of digital platforms. There's a lot of people, and almost everybody I talk to in this business either has a digital platform that they're trying to improve or they believe they have one. They are in the process of building out a digital platform or they know that they need a digital platform and they want to build one. I don't think all of those people are necessarily talking about what my definition of digital platform is. They're not all talking about the same thing for sure. But I think there's enough commonality that we can make some generalities about what it is that they need and what it is that... what are the good qualities that one of those things needs to have. Just as an example, like I said, I was just in Spain a few weeks ago and there's the Spanish Bank BBVA. They're a customer of ours. We don't take credit... They have transformed themselves over the last 10 years to be a digital company. They have some very... This is all available on the web, you can go Google it, but they've had some very enviable numbers in terms of converting their brick-and-mortar customers to purely digital customers. The thing that they're able to do is roll out very specific products to very narrow customer segments and do that cheaply enough that it's worthwhile for them to do that. And that's a tremendous benefit to them. They can do, like in Chile, you can apply for a credit card in a few minutes and receive that card in less than 24 hours, which is days faster than it was before that, unheard of. And they credit, at least for part of that success, with having a digital platform, with taking their spaghetti, their spaghetti architecture and transforming that into a digital platform. And there's a lot that's written about this and you can go and read about it yourself or we could maybe make some introductions if you're in the financial services business. Oh, there's my definition. I've got those slides mixed up. How well did I do? Yeah, so the important thing to remember from that definition is it's APIs, it's a big part of it. It's tools, but it's also an organizational structure in an operating model. So why do they work? What is it about digital platforms? This is the picture. This is just trying to describe what goes on. If you work in a big enterprise, you know that your IT systems are interconnected spaghetti that's compute and storage and batch files flying around and mainframes connected together with ESBs and various other things. It's very complicated and it's hard to pull apart and it's very slow to deliver things there. So what we do as IT organizations, we come in and we try to classify those things and architects try and apply layering or categorization or some kind of taxonomy to those. And we put these layers and I've tried to... It's significant. You don't need to understand this necessarily for this talk, but we have very business specific... This is one of the problems that people have, very business specific, line of business or brand specific things facing the customer, transitioning to more generic commodity kinds of systems and the systems of record. And the problem is that those concerns are spread throughout the entire... So things that ought to be very business specific get stored in your core banking system or your core insurance system. And things that are commodities, it's very difficult to break off and manage those commodities as separate systems. We also usually have some kind of underlying operational infrastructure as well. And this is fine except that these boundaries are very blurry. And so when we try to deliver, we're still... Next slide. Whenever we try to deliver a change that's customer facing, it ends up being a slice across this whole thing. And because that, even though we have... Oops, I went too far. You're not supposed to see that yet. Because we have underneath this nice, neat categorization reflected by our organizational structure, our teams in IT, underneath that is that spaghetti still exists. And all that coupling still exists. So we have to deliver in slices, in big enterprises, that are very slow. So all these changes have to be planned out really far in advance and they have to be coordinated very carefully in large programs of work. So even the smallest digital change tends to ripple through the entire organization. It's very slow and it certainly inhibits autonomy. So what we need to do instead is pull... So this is the beginnings of this platform idea is pulling apart specific business capabilities into separate organizational units. So you can think of each of the cubes here as being both an organizational unit and a collection of technology assets, systems assets. So we pull them apart into autonomous units. Sometimes I call them domains. You can call them platforms unto themselves. We've had various names and I've seen various businesses go through this evolution. It's a process and we can talk about how you get there. But this is the ideal. So each of these cubes, whether it's very business specific stuff that faces a customer or if it's commodity things that could potentially be outsourced entirely, each of these has a set of teams that build, own and operate their own technology. And inside is encapsulated a lot of complexity. But between these units, they communicate via APIs. And APIs being very... We'll talk a lot about self-service, but they need to be self-service APIs that are available to anyone who wants to build a solution. So we break up RIT. This is in the ideal case. Nobody gets there overnight. But if you look at these digital businesses, this describes how they're structured in many cases. You break it up into separate autonomous units, each of which exposes some APIs to the rest of the business that they're responsible for certain business capabilities. They own the data in those business capabilities and they are responsible for their software. There may be also some technology foundations that are provided and are shared across the organization, but those also have to be provided via self-service APIs. So this is kind of the idea of the organizational structure and it's this idea of business capability mapping, breaking up the organization, giving people specific business capabilities to be responsible for, and then requiring that they only communicate with each other through APIs. But there is some platform... There is some technology that underlies this that we find to be common across all these businesses. So when people want to become platform-enabled, when they want a digital platform, inevitably they end up building out these digital, these technology foundations. And I'll just go through these quickly, each one of them. We have the customer touchpoint technology. This isn't the channels themselves, but it's common services and technology that's made available to support the customer touchpoints. It's things like frameworks, AB testing frameworks, and the telemetry necessary to be able to collect the metrics to do that AB testing. Content delivery, edge networks, identity management, content management, those kinds of things can be made available via self-service APIs to support these digital delivery teams. APIs are kind of the glue that holds the whole thing together. So when we talk about platforms, APIs are very important because we're creating an internal ecosystem that thrives, that based on interaction through these APIs. So we need to have the right kind of technology to support these APIs. I find that most people embark on an API program. They buy an API gateway, and that's it, they're done. When really the API gateway is secondary or tertiary, it's how you design those APIs. It's how do you describe them? How do you define your contracts in these separate parts of the organization? And how do you test the APIs? How do you deploy those APIs and build out the microservices to back them up? Data is, I think of data as the currency of exchange within the platform. So people come to use the platform because they want to consume other people's data. And in turn, they contribute data back to the ecosystem. And it's that exchange of data encourages a thriving ecosystem internally within your business. And so you need to have certain... I'm up here to attend the Stratoconference, so I've been hearing about this stuff a lot. So having metadata... This is going to become particularly important with privacy laws that are coming into play, right? The metadata standards and reference data knowing where the data is, having catalogs that allow you to find where the data is and who the custodian of that data is within your organization. So everybody's pretty worried about right now, I think. And finally, the delivery... what we call delivery infrastructure. So this is what helps teams build, own and operate their own software. So instead of teams doing programming software, creating a jar, throwing it over the wall for somebody else to deploy and host somewhere else, we're talking about teams actually doing the infrastructure coding, determining where that software is going to run and operating it, maintaining it, answering the pager at night when it goes off. But we can provide help for that. And the platform needs to provide the right kind of help. Environments on demand, cloud-native environments, container orchestration. This is closely related to a lot of the stuff that's on the radar, this issue. So Kubernetes is about to eat the world if you're not Kubernetes. Knowledgeable yet you will be soon. Container orchestration is a generic name but kind of mezos and the others have kind of fallen by the wayside. You need to have the monitoring and alerting capabilities and other ways to support the service mesh. So that's another thing that's in the radar, this issue, that people are going to more decentralized means for managing microservices and APIs. You don't need to host all of your microservices or your APIs in one central place in order to have visibility, transparency and manageability over those APIs. Code repositories, build pipelines, those kinds of things. So everybody ends up building out some of these common elements and embarking on a platform implementation means you're going to have to have some platform teams that help harvest these components and it's all held together though by an operating model and an organizational structure. So it takes, it's not just having those, so many businesses try to put into place those technology foundations but they fail when it comes to the operating model and the organizational structure and the culture that allows autonomy. Having transparency and accountability but also having trust. So trusting people that people will do the right thing but holding them accountable for that and through transparency being able to ensure that they are accountable to those things. So that's a bit of an overview of what we're talking about when I talk about a digital platform at least and how they, and maybe I haven't made that clear I'm happy to go into it some more if people have questions but how they accelerate delivery and how they make it possible to deliver features through small teams working autonomously but they need to have some quality so what is it about platforms that platforms need to be to be successful and I want to, I'm going to be drilling down into one of these in particular but the platform needs to be addressed needs to be treated as an internal product and I have a lot more to say about that we mean it's customer focused and it's compelling people want to use it as opposed to some other external service. Platforms are, let me go back, platforms that they're self-service so all of these APIs, all of this knowledge all of the support needs to be available in a self-service way. You should not have to file a ticket and service now to be able to use somebody else's API you should be able to easily find those APIs they should be easy to use and you can consume this business capability and that business capability to build out a new feature. They enable ecosystems and most importantly it's not something, there are plenty of places that would purport to sell you one of these it's not something you can buy off the shelf this is when a successfully executed digital platform is your crown jewels it is the IP that enables the business and differentiates your business that enables it to leapfrog your competitors and stave off disruption but I really want to drill into this idea of platforms as products I've seen a lot of I'm old as you can see I've worked on a lot of service oriented architecture projects I was around when that term first came into being and I've certainly implemented a lot of based on ESBs and a lot of other things and very few of them I'm sorry to say have been successful I've seen a lot of really unsuccessful service oriented architecture projects and the reason for that is they failed to deliver services as a product they failed to deliver services that were things that people actually could consume and could find and consume instead they just exposed the cobalt copy books as XML and that's never going to be successful so I want to talk about how we can be much more successful with those kinds of engagements this is just talking about what so when I started talking about this idea of platform as a product we think of the products that you see I'll explain this slide in a second think of the products out there things that we consider products they're consumer oriented we know that products are consumer oriented so incorporating the voice of the customer is important they're delivered with a certain level of quality that they have you expect a certain certain kind of quality from a product you expect it to be supported if you have a problem with a product you want to be able to return it you want to be able to file a support request and have it responded to and the products have some kind of brand identity they have you know the providers of products need to reach out and they need to identify their product and give it a brand a shape that you can remember and they need to engage with the customers through that and this is a t-shirt so we just last week we have a big conference every year in Australia the out conference it's kind of like go to conference or some of those others and this is realestate.com.au they're good friends of ours in Australia and they've been they've embarked on this platform journey for some time they've been evolving their digital platform and the architect for the digital platform actually created this brand so Colab this tech building blocks this was the t-shirt that all the REA people wore at the conference last week so it has a logo so this is their platform right it has a logo it has a catchy name and the purpose of this is to get everybody in the organization to realize that the platform is something that they need to support the platform is there for them to use and the platform is something that they need to contribute back to so when you're building a new solution they don't just think about building whatever my stakeholders ask for they also think about does this advance the platform can I use the platform what other features could the platform provide me that's going to make it easier to build this out and it's been really they have it written into their business strategy and everything so it's been they've embraced this and I was I asked them if I could use these graphics for a long time then they had these t-shirt they gave me a t-shirt so I figured it's okay to take a picture of the t-shirt and show to people in the stock this the idea of the platform goes back I think to to this famous you you guys know about Jeff Bezos and the API decree that Bezos made back in that was a 2007 so if you don't if you haven't heard the story you know Jeff Bezos said he was tired of the friction created by coupling between databases between different teams databases and he said from from now on nobody accesses anybody else's data directly anytime you are going to access somebody else's data you need to do it through a service they each team needs to create services that expose their data and if you're going to use another data's services you need to that's the only way to access the data the data there and the interesting thing about this is this quote here I think he said all services interfaces without exception must be designed from the ground up to be externalizable the team must plan and design to be able to expose the interface to developers in the outside world no exceptions and the last thing was anybody who doesn't do this is going to be sacked and this had a tremendous like transformative effect on Amazon that we can see today right so that the services that supported that supported amazon.com we now have available as external services and it's a bigger business for Amazon than there then the bookstore was so this I think this has this is subtle and nuanced but I think it has tremendous implications that when you make something to be externalizable what you're doing is you're giving people a choice when you say I'm going to create an API of the same quality the offer to my colleagues as I would offer to the external world what you're saying is my colleagues could I need to create something that's compelling for my colleagues to use even if they don't have to use it so we're going from this with the platform idea we're going from this idea of mandated usage you have to you know the enterprise architect says you have to use the ESB therefore use the ESB to freedom of choice you can go external embrace shadow IT go find something better we're going to provide you a product an internal product to your colleagues that is so compelling that they're going to want to use that instead of going external and using something else and we're going from a world of top-down governance to principles that create alignment and from centralized control to having you being able expecting everybody to deliver quality so I think this has a big this creates this mindset is very different and it's really scary for some people and this is what inhibits a lot of businesses from going down this platform route next slide so how do we do this how do we make a really compelling offering to our colleagues we're thinking of our colleagues as customers now so how do we do that how do we create something that they're going to want to use instead of going externally well we actually know designers, user experience people, product managers have known how to do this for a long time actually and it's applying the techniques of design thinking can be used and I give this talk to architects a lot and I ask architects how many here take have done a course in design thinking like the Stanford crash course in design thinking almost no hands go up when I ask that of a group of architects and they they say they design things that's their jobs right for architects to design things and yet none of them have ever taken design thinking is a methodical way of challenging your preconceptions of what you think people want and helping you gain empathy and understand what they really want so how many architects actually go to we're talking about colleagues we're talking about developers people you can consume an API you're a developer how many times do we go and actually try to gain empathy with the developers position and satisfy that demand I don't think it happens very often I'll show you this is Marty Kagan talking about what makes working closely and directly with customers that's what makes a product successful this is just an example of doing that survey that I ran trying to understand what benefits a platform could provide to developers and there's about 50 questions and these are the top 10 pain points so this is a technique from user experience right you don't ask people what they want you ask them you try to understand what their pain points are what they're experiencing and it's actually challenged my preconceptions because we wanted to build stuff we wanted to build some DevOps stuff you know some environments on demand build pipelines and so on and that's on there but it's not the worst thing what needs to be addressed in order to really satisfy the developers demand is making it easier to negotiate and interact with other teams so it's addressing this idea of couple backlogs that I talked about before so negotiating with other teams waiting for those changes to be made having those changes break the stuff that you were writing because the communication was wrong somehow whatever the platform does it has to address those things and your design problem creating the right APIs creating your service oriented architecture needs to start there the next steps in the design thinking defining ideating so product managers talk a lot about this problem demand solution trio so I think as as architects we think about the problem a lot you know we want to have this is a particular example but it could be we have a business problem we're good with that we have a solution we're good at thinking up feasible solutions to those problems but we often leave out the middle part to demand so in this case we have a problem we want to create some customized this document management is an area that we often this often arises right you've got a loan origination system for example and you need to send out loan documents to the customers and you need to go through the document system to get those templates created so that your emails go out with the right sort of look and feel to the customer so but there's a demand from the developers to be able to reduce the delay in creating those custom templates so there's a big pain point that's preventing the business from doing from rolling out digital solutions there so the next step in this design thinking problem is to come up with different solutions put it in front of the developers say is this what you were trying is this would this help try to gain some more empathy and understand and refine take that feedback so that's there's one solution you could have a source code repository where everyone is like an open source project where you can contribute templates where the team that's building the origination system could contribute the templates maybe you could expose some forms maybe the document management team could expose some forms that the origination team could use to design their own templates and that self service solution reduces the friction and allows them to roll these things out without so much dependency in coupling between teams or maybe you just build your own maybe you it's not always the right thing to concentrate and have a single solution for everything maybe it makes sense for the origination team to just have their own document management system maybe they manage it themselves maybe they send out emails themselves in a lot of cases that's actually simpler than simply removing duplication within the enterprise so that's just another here's another example of building an API with this idea of building a product that you're offering to your colleagues as customers this is just using the lean business model canvas to approach the API problem the API development problem as if it were a business so understanding the stakeholders understanding the flow of data the flow of revenue through the API who are your partners in building that all those kinds of things really trying to understand the problem and defining some hypotheses that you can test as you build it out and then it needs to be done in an evolutionary way so I'm running out of time so I think I might skip over this next section but just a couple of highlights one of the authors of building evolutionary architectures you can't build this all out at once if you're embarking on this platform journey you build that one little piece at a time take one business problem build out the platform elements you need start shaping the organization do your business capability mapping understand start assigning ownership of these systems probably you're going to have to start migrating these capabilities from usually forward so it's going to take time it's going to take time to migrate some of these capabilities into away from the commodity systems and into the business into the probably your commodity systems of record will get smaller and I'm working with a bank in Australia that's trying to do this right now and put more of that logic into the business facing systems the last thing I want to wrap up with is this idea of a product needs a product manager so the platform needs a product manager it needs somebody that's going to look at the future what is the roadmap for the platform and what is where are our priorities how much is it going to cost which parts are we going to build out first and this idea there's been a lot written about the idea of a product manager Martin Erickson is one of the gurus in the area and this is a really quite if you're a product manager you will recognize this diagram it's a very famous diagram from his blog that says what does a product manager do there's a lot of people who ask this question so it's the intersection of user experience technology and business so you need to be a little bit in all three of those things deep in at least one of them but across all three of them and it's that intersection where product management takes place and I've taken this and talked to a few product managers and thought about how does this apply to the idea of a platform and we take user experience it's really developer experience and there's quite a bit of interest in this idea of developer experience with the rise of APIs but this is actually something we talk about now developer experience when we talk about technology it's really APIs, microservices data, these are the technology building blocks that the platform needs to be successful and then creating business organizational alignment so understanding not just the end customer's business but understanding the operating model and the organization the strategic goals of your business is when we talk about the business idea so I look at this and you know this looks a lot to me like any IT leader this looks a lot to me actually like what an enterprise architect is supposed to do I don't think a lot of them do I think a lot of CTOs or enterprise architects or CIOs they worry a lot about the business so if you ask them what they do they say I understand the business I understand technology, I align technology with the business but they don't always take they don't always look at this developer experience they don't really, so many architects worry about these two and then they just throw solutions out there and they say they don't track it through and they don't understand what the practitioners on the ground actually need the same is true with CTOs and CIOs as well sometimes you have people that are they understand the technology, they understand the developer they're less business savvy so it's really, I guess I want to put to you just to wrap this up that the role of a technology leader in an agile organization an organization where teams are autonomous where they build on and operate their own software people are able to make their own decisions about technology you're not in where you trust people to deliver and do the right thing and trying to control them in that kind of an organization this is the role of the technology leader to be the steward of this technical asset that we call the platform and that's really the way that the CTO or the CIO can best serve and participate in the business is in doing the best is in incrementally, evolutionarily looking after the platform and making sure that it's always suited as best it can be to satisfy the business and to be a tool of creating value in the business and moving away from IT simply being a control mechanism and a cost center so just to summarize it's about autonomy what's that? I was too hurried with the slides I think today so platforms enable autonomy they're about building smaller, faster and cheaper solutions I can do this I'm a developer so I can actually fix this in real time what was I going to say? Yes ok so platforms enable autonomy they are about building faster, cheaper solutions and being able to experiment to be able to do tests and learn in your digital solutions but it has to be a holistic approach it can't just be something that consists of just point solutions you can't just do continuous delivery or just do agile it needs to be an entire holistic approach and moreover what I want to leave you with here is that your colleagues are your customers when you were building a platform it's the customer that serves the customer that you need to be there for you need to treat your colleagues with the same level of respect and a level of quality service to them as you would to one of your external customers and I think this is what this is the trend this is the direction that technology leaders are going in today thanks that's all I had to say happy questions do we have time for questions? ok they talk about the autonomous groups and they just communicate through APIs if you need to communicate through like it pop your subscribe