 So, our next video this morning is from Peter Haveland, who is the Chief Technology Officer at Latitude Financial Services. Peter has nearly three decades of experience spanning financial services, management consulting, technology and energy. He's currently working as CTO of Neobank Latitude Financial Services, focused upon leading the digital agile transformation of the company. He served as the Vice-Chair of the Open Group Architecture Forum and a member of the Open Group Governing Board. Peter will look at the issues faced when protecting against digital disruption, how organizations can innovate to accelerate digital transformation, the capabilities required to realise a digital business and how you architect the digital business. So please, let's hear from Peter Haveland. My name is Peter Haveland and I'm here to talk to you a little bit about the next section here around what capabilities are required to realise a digital business, how do we architect a digital enterprise and what makes it different from others. I'm sure capability modelling is nothing new to a lot of you guys. I'll tell you what though, getting a good capability model is pretty hard, isn't it? Anyone that seems to be able to put out a capability model these days with 200 boxes on it but I think the aim of the game for us is to actually choose the ones which are going to be really valuable for us in our daily existences. And I think the asset test or maybe the thing that's interesting to mention or talk about is that these capabilities in a digital agile business basically have to be as autonomous as possible in order to give us the maximum speed and this I think is where the real rub is where the real rub is. I've tried to very quickly here put down a couple of capabilities I think might be worthy of examination in this context, starting with things around strategic marketing, personalisation, digital distribution, things like that, moving quite quickly into the experience layer. What I've tried to do in some cases is show a progression so most companies for example would start with a consistent experience across product or channel, move then into a responsive situation where that experience is in fact capable of responding to various inputs and then lastly the achievement of an evolutionary experience where it is almost always changing and indeed the experience is in itself a major value driver for customer acquisition and retention. Decisioning is a huge component for us and I imagine a huge component for a lot of other companies. What's interesting for me at least if I think about how we used to do architectures or indeed how I've done a lot of architectures, the idea of a decision based architecture I guess is not something that's been at the forefront. So the idea now that you would model decisions as first-class citizens and then you would seek to understand how to manage those and automate those and then provide a degree of traceability and transparency to your customers as well as regulators I think is something a little bit new and something that's probably going to grow as well in the future. Partner interaction, ecosystem enablement and indeed the interaction of sorry the integration of customers with the product development life cycle is also something I think is worthy of attention. The idea that you would externalize some APIs or some features from your own platform it's not really a new one but I think it continues to be a major value driver of some of our more successful digital agile businesses out there. Data isn't itself a huge aspect and indeed has its own capability model but again I think for a business that has these aspirations the idea of capturing all data all the time especially for interactions from customers and partners being able to understand that being able to source that analyze it and then get insight from that that then influences your product strategy or your experience strategy is fairly critical to your ability to get this flywheel type effect up and running where you can constantly understand customer needs and respond quickly. The call is core one of my favorite sayings the idea that your core transaction systems don't really resemble a traditional core system anymore they're hyper scalable they're hyper distributed they're quite isolated in their context they have little independent microservices being called from all over the place there's data sharding there's polyglot persistence there's data gravity at play so that you really try to reduce as many bottlenecks as possible it's not really about our single point of failure anymore it's about a single point of speed and we want a lot of scalability we want a lot of performance and we want a lot of reliability all the time so that's really those sorts of characteristics I think in that space. From an operating model perspective I think it's interesting to go into these in a bit more detail is the idea that we have certain operating model characteristics that are needed in order to make this happen we also have certain design philosophies and certain engineering practices which are needed to make this happen and finally we have certain architectures certain solutions certain patterns which are also needed I don't know that you can actually do this without these others in concert so I think going forward maybe we'll see capability models actually also talk about the company's operating model or its execution capability as importantly as it does some of these others we'll put the rest there for now we can come back to those so firstly just quickly the idea of a biz dev sec ops operating model it's written a little differently you see it written dev ops dev sec ops biz dev sec ops biz arc ops the idea though that we have these capabilities that are relatively isolated from others it means there's less interdependency it means there's less bureaucracy it means they can respond faster they can move quicker and we actually have better ecosystem resiliency because even a small failure in one component doesn't hit a failure in another component and remember in this case where the most ambitious companies are actually trying to replicate that in their business operating model as well as their technology architecture from an operating model point of view things like inverse conway maneuvers in the org structure continuous control environments to handle regulatory compliance and cyber security things like that as well as techniques like outcome based contracting which seek to look at the value delivered through partnerships rather than maybe a traditional perspective which was more about costs under management from a design technique point of view is quite a bit on this out there right now personally I find it's quite important to stay on top of it and to always be experimenting to see what's going to work for you what doesn't techniques like design thinking are great for putting the customer first putting them in the middle and also putting in a bit more of a continuous improvement continuously evaluating sense and respond type footing set base concurrent engineering wonderful technique for keeping engineering teams in that problem space for as long as possible really minimizing those type one decisions really maximizing the type two decisions and lastly domain driven design a wonderful architecture pattern an enterprise architecture approach if you will that helps to define these independent domains in isolated context which again means we can run technology stacks independently of another we can use them in different contexts we can drive reuse and we can improve resiliency from an engineering point of view a couple of things also to throw into mix things like solution train engineering fitness functions and release on demand capability are fairly fairly aspirational for many companies but they also represent some pretty serious engineering capability if you if you're able to have these characteristics fitness functions great for dealing with finance functions who need continuous justification for improvement of capability and release on demand is really the pinnacle of what we want to get to to decouple the deployment from the actual release so we can do things like canary testing and a B testing blue green deployments things like that last but not least couple of things around architecture the event driven reactive independent service model it's kind of micro services but I think it's a bit more mature than micro services really what we're looking for is independent services that's key streams of record that really underpins and drives your eventual consistency having streams of record is great for reducing your dependence on on databases of record yet databases are hard databases are hard to upgrade they're hard to deploy they're hard to drop they're hard to restore you don't want to change schemas there's plenty not to like about them streams of record is an interesting concept that really can help if you've experiencing challenges like that and lastly eventual consistent data architecture you know there's there's strongly consistent data architectures which rely heavily on relational databases as eventually consistent data architectures that allow you to use different more scalable databases particularly NoSQL databases they're good for different contexts you certainly need both in your landscape I think the idea though that we would instead default to an eventually consistent data architecture as opposed to a strongly typed one which is probably what we did in the past is really what we're trying to call out here again if you can maximize your use of eventual consistency you can you can maximize your use of self healing systems you get better scalability you have better ecosystem resiliency and you know those deployments don't have to be so fraught with danger so that's just a little quick whistle stop tour of some of those I hope you enjoyed that I can't wait to talk a little more to you about these I've got a few examples in the pack let me know please and yeah have a great day all righty bye-bye