Session Information:

One lasting learning from the past year is that businesses that were able to pivot quickly could accelerate investment and strengthened their resiliency. Pivoting quickly is made possible by having a composable business made from interchangeable building blocks.

Imagine being able to take apart a spaceship and rebuild it as a castle using the same building blocks, or more relevantly, take apart a dishwasher and rebuild it as a ventilator. Enterprise architects are the ideal people to lead this effort given the knowledge already derived from architecting the enterprise. In this session you’ll learn how enterprise architects can be key contributors to composable thinking using modular thinking and applying it to business and technology capabilities.

Session Transcript:

Now, I'm super excited for our next guest joining us. We have them coming from Boston, Massachusetts today, leaders from Mega International with us. Hello there we have Rashid Bhatnagar and Yannick ... Ross, she serves as pre sales engineer for Maggie International. She's specializing helping organizations meet their digital transformation goals with maggots Hope X platform.

Previously she has worked with Juliet Sciences, Ford Motor Company and I a financial group helping them use mega Overholt backs platforms in optimized fashions.

She started Technology Information Management at Jack ... School of Engineering and is currently working towards her PHD in organizational psychology from Harvard Extension.

Now, yanick is with us, he has worked for Mega International in various roles for 12 years and currently serves as the VP and Managing Director of North America markets.

He has worked with hundreds of companies in EMA and North America, helping them use the Hope  platform to realize measurable success in digital transformations.

Yannick holds master's degrees from ... Paris Sorbonne Business School in IT Methods, apply to Enterprise management, and information systems and knowledge management yannick. What a pleasure to have you with us. We're very much looking forward to our presentation today.

Thank you very much for this introduction this. This very good introduction introduction I must say. Thank you to beto's for hosting our webinar today.

So today, the topic that we would like to share with you is about composability and how Composite BT will help drive speed, flexibility and resilience.

And of course, the main topic that we would like to address today with you is how enterprise architects can help on that topic. And whole enterprise architects will be, will be used, I would say, in the fashion, to really help drive these, These composite B, T this speed flexibility in, resilience during the set transformation.

So, just, I'm not going to introduce ourselves again. See that very, very well here. You have our pictures, but you're gonna see us and a camera 2 by 3. Can they be indirectly to throughout the pic today?

So, before going within the business, the peak of the of the of the day, little above mega, one slide, so, some of you may know us already. So, Omega is a well established and fast growing even software vendor. We have approximately the more than 2000 customers worldwide. More than 52 countries. We have, analytics, experience which were quite young or so in the in the spirit that we'd say you for for what we do. So quite an interesting place to work and to to to to work with also if you are our customers.

The bottom part of the slide is even more interesting MSC because we've been Gartner or Forrester leaders for many, many years now forgotten or it's been more than 12 years now that we've been in the leaders quadrant.

That's what we are, I would say, the most proud of right now is ready to be seen as the customer choice for partner, forgotten, or peer insight. Because this is our customers talking about us. And saying that they really like our tooling that we liked the way we help them solve their problems. This is really what we're very proud of when our customers say witching hour there. So I hope for you will see today that we have a lot of things to share with you and that you will, you will contact us for more information.

OK, so the topic of today so today we want to talk about architecting for business Composite.

So within the next 30 minutes, I would say we would like to share with you a couple of things.

So we'd like to share with you a definition.

Maybe not everybody is familiar with the pitch of composite BT. It's quite recent. It has been promoted many, many times the right now.

And, and, even though we're not super familiar with it, you will see that Enterprise Architect will be familiar with that. Because it's usually the concept of Enterprise Architecture, that I've been at this for a long time.

We want also to share with you, how E will be able to help, to help. That's too big, to become a reality, because you're going to see it's a business. An ..., at the intersection, you have the Enterprise Architect that will be able to help.

And we also want to share with you some guidelines, a methodology that we have built within mega to help drive this Composite BT from the business perspective, go and going down to the to the H.

And when I start this kind of presentation, I always like to, to use this quote. Because I think it's, it's very, very true to what you're going to say today. But nobody in the, in the world of enterprise architecture, whenever you have a primary in front of you.

And I really think that it's super important to take the time to think about how you're going to approach the problem and then executes on that problem for greatly, less time.

And we'd say then the time you have spent thinking about that might be French, probably the sort of thinking, but it's very true to see two to see something like that.

So as Composite BT comes in, we wanted really to think about why companies are, are trying, and I'm going to two, I would say, compatibility right now. What is the, the key mention right now?

So globally right now, in the wake of GAVI 19 bits that you can think about many disruption that will happen in your market in much better markets. We've seen that's somehow, we will be new reality things have been shaken down somehow with new ways of doing business.

Of course between no in the interdisciplinary team with experience of what's happening in 20 20.

So, we, we all understood that the change is basically the new normal. Right now, we need to quickly adapt to, what the customer wants, the customer needs. We see behavioral changes, we see that the customer, they want much experience.

The change, the speed of the change there has been very, very big.

So, in previous webinars at mega, maybe you followed that. Also, we talked about how we could be more prepared, being more proactive, instead of being reactive to market change, this is really what we would like to talk about today. This preparedness, this productivity to be prepared, will really lead us to be more resilient, to have a more clear competitive advantage there. It's really important to try to see that. And we'll see how Composite BT will help to drive the preparedness of architecture.

For us, I've talked to many customers, and sometimes, we have customers coming to us and say, OK. You may, CEO, my CIO wants me to say, OK, OK, the Architects Architects Group, I want you to add a new AI function and that application, and your voice function, and that that, that application.

How do we react? How do we do that? How do we create this piece? And you will see that we composite BT.

Which the way of thinking of composite iti.

It's going to be clear how you will be able to shift, and to be able to, to create more, more more time, to market fashion, and beat them to market application that you believe that you'll be able to use.

So, first of all, I would like to find that it's a bit what we here, know what I mean by this composite.

So, by business composite, Beaty, first thing first is that composite B T compatible thinking, it's a way of thinking into which we think that everything is decomposable first thing.

But, moreover, it's that things are composable that you'll be able to just assemble things, but reassemble them in another fashion so that they can serve maybe another purpose. So when you think about business and IT, we're going to come to that in a minute. But the thinking is about that. Everything is incompatible, and you can compose them.

So, I applied to the business, this means that the business can be broken down into smaller pieces, that can be better managed, and that can be more resilient, because you know which pieces you have to, to to to, to manage, if you have an impact on your customer base, and it really helps you understand better, how are you going to support the business with technology? So, this famous business, NHC alignment.

And so, when the elements of the business composite, because we're gonna talk about today, is the capability, amongst others. So we're gonna have a piece on that.

This piece, of course, the capability, that's something that the yeas are very familiar with, that you can see that we can break down these capabilities and multiple pieces, and intent intent, disabled building blocks that we can, that will be able to say.

So, that's the piece that's going to be applied to the business, and I played you to do the technology. That means that our obligations can be broken down into set pieces, that you can recomposed decompose them, and that's what we will share with you today also in the presentation.

So, rachi, can you walk us through the first piece of this business compatible side with the business capabilities?

Let's go ahead and actually start by taking an analogy. So we're going to actually talk a little bit about lego's quite quickly. And let's say you actually want to buy a Star Wars Lego set, because you're expecting to make Darth Vader's helmet. Now, halfway through this experience of trying to compose this helmet, you decide you're going through and finding all the right pieces. and you're following all of the instructions. And you realize that what you really want to do is create an airplane.

So you do just that.

You use the same pieces that you would have to create that helmet. But instead, you go ahead and create a little Lego plane.

Composable architecture is a lot like that.

You have a common set of components and in the Lego world, we normally think of that as blocks in the enterprise world. We think about them as assets.

And by using a finite set of enterprise parts, which include people, technologies, capabilities, applications, et cetera, you can construct an arbitrary number of artifacts. And we're going to be walking through a few of those examples today.

But, really, the point that I wanted to run home is, when we shift our approach towards composability, we start to embed adaptability into our design, and we enable the enterprise to plan for many futures. So, when you actually buy, you know, Darth Vader's, Lego set, but you desire to create an airplane, you are now equipped to be able to do that.

Let's go ahead and actually take a look at the four steps for architecting for business, composability. The first is going to be understanding the ecosystem.

Now, here, you are really focused on creating a baseline of your inventory, basically, understanding, What do you have?

The second is assessing your need for composability.

In this step, you want to become more intentional.

What is what is it exactly that you want to focus on? What parts of your business do you anticipate change in?

Where do you want to increase efficiency?

In the lego example, this is really where you begin to create your associations and linkages.

Our third step is architecting which is understanding the underlying architecture or how do things actually grouped together?

And the fourth is build and repeat. At this stage, you're really thinking about how do you want to begin planning for your future.

So let's go ahead and dive a little bit deeper into our first step, which is understanding.

And here, when we're talking about creating a baseline, really, we're turning towards our enterprise architects and the inventory of capabilities and technologies and processes that we've built up over time to understand what do we currently do, and how are we currently addressing the needs of our customers.

To do this, we're going to take a look at a few different artifacts, including capability maps and customer journeys, And I'm going to look at what we can leverage to make. To actually take it further, be able to decompose, and like Yannick was saying, we compose in the future.

At this stage, it's also important for me to mention to you that composable architecture is an enhancement to your current business architecture and not a replacement, We're not interested in selecting and removing all the aspects of work and the different silos, or different, or parts of your organization that exist.

Really, what we want to do is select the parts of your business that are going to benefit the most from composability and enhance them to become more resilient.

So, let's look a little bit into our first artifact today, which is, Understanding Business Capabilities. Now, a business capabilities maps focus is to break down your business capabilities into smaller, more manageable elements so that you can begin to identify the varying rates of change and needs for agility.

So, all capability maps might not be equal. You're going to have some capabilities where it stands out that this capability is very essential for your business. And that's really what we're trying to draw out anyways. We want to understand, Where do we need to prioritize our work for composability.

Then, we begin to compare the assessments to discern how critical is this particular capability to metrics like efficiency, cost, and technological stability.

Lastly, we are then, trying to understand the technologies, processes, and people that support this capability.

Because we want to gain a full perspective of what's going to be, not only the effort that's required to convert this particular capability, but what's also the entire scope, different touchpoints and places of impact. So, again, we can begin to prioritize those aspects better.

For our second artifact today, we're going to actually be diving into Customer journeys.

Now, customer journeys, they really help us identify a very important perspective, because they are your lens into how your customer is experiencing and interacting with your, with your company.

So, when we create a customer journey map, we're really trying to assess, where can we provide a better and more personalized service to our customers?

And by understanding this relationship between your customer journeys and the different resources involved, like technologies, processes, applications, et cetera, again, you're able to get that fuller scope of impact that you're looking for.

Then, this information also helps you understand where you are today, and, again, create that prioritization or that need of urgency for, where do we want to actually start pivoting our mindset towards composability.

Now, these are just two examples of inventories we talked about, and in terms of capability maps and customer journeys, you could have other inventory's today that your enterprise architects are helping to maintain.

Popular ones include applications, processes, technologies, et cetera.

Really, essentially, the inventories that you want to look at are the ones that you feel are part of your core business and necessary for transformation, and even perhaps need composability to be part of their design.

So, that wraps up our first stage for a second sage, scoping the need for composability. Here, we want to focus on identifying that specific scope we were talking about. So, everything that we took, in our first step, creating that baseline, understanding our inventories, now it's actually coming down to think about questions like, where do we need a faster time to market?

In this stage, you're really going to be taking all of those inventories that you cultivated and begin to assess them, too, again, to understand what needs to be prioritized when, and why, specifically.

So, here, I do want to take a quick moment to just pivot right back to that business capability map we started with, but actually take a look at the assessment portion of it.

So, here, you're able to see that, the assets within your capabilities, your assets, which include application, people, processes, et cetera, And all these assets, again, these are the ones that are required to make this capability work. They have an assessment that's actually been attached to them, using color co-ordination, or perhaps in the ... world, symbols.

But really, what these assessments are helping you understand is they are answering questions like, have we identified the right kind of asset to support what we need from this capability? And then is that asset actually performing up to speed, or is it creating certain bottlenecks?

You're basically trying to answer questions like, are we avoiding redundant work? Where do we need to increase our efficiency and our resiliency.

And these are the kinds of questions that your assessments can really help you answer.

Additionally, assessments can also help, if they can also help you understand the health of your particular assets, when it comes to efficiency, costs, and impact of those particular assets to your capability at large.

And again, this kind of dual layard assessment enables you to really understand what needs to be, not only with the capability that you prioritize first, but that specific application or process that you start to prioritize first within that capability itself.

For our next use case, we're going to take a look at the world of processes. And, really, just start to understand that once you have your inventory of processes, if you're able to then add another layer of assessment onto them, and start to analyze for efficiency, performance, business value, risk execution. Again, the assessment metrics are based off of factors that are important for your company or your industry, to be able to better understand the health of your assets.

When you are able to perform these kinds of assessments, you not only better understand how the process supports the business, but, again, what are those critical pain points are areas that can be enhanced for resiliency.

Now, for example, in this process that you're seeing here, you can have processes in the heat map that you're seeing of, at the very top, You can have processes that, you know, rank very high efficiency and performance. And they indicate processes that are actually pretty well taken care of by your company at the moment. And perhaps they're already resilient in nature.

So really, you might want to start focusing and shifting your focus down into the lower rank of the spectrum, where you have processes that are not as efficient, that are not performing as well, and might actually be creating bottlenecks for your company, but are definitely very necessary for you guys to be able to adapt and pivot a little bit quicker.

So, in the end, really, we leverage these kinds of assessments to ask better questions on what is happening within our enterprise. And, by doing so, we begin to peel back the layers getting to the core of the business and the Prime use case for composability.

With that, I'm gonna turn it back to Ganic or love.

Thank you very much trashy for these first two steps.

So we understand clearly now that compose the B T has to be scoped based on business assets based on the assessment that you have been making in the company. That's that's you will not make the whole company complies about this is very clear.

So definitely that choice to be made based on suspicion of needs based on markets.

But it's very critical that these these choices are dictated by.

I would say, to market and that's really each customer who, who are telling you where you need to be more flexible and so on.

So the idea that I would like to do no is when we have scoped one piece of the enterprise that we need to have more flexibility, more time to market, better time to market it.

How do we do that? How do we take an application, and how do we represent this?

This new architecture that we're going to build very into, in the IT architecture, since So we're going to talk about PVC is you wanna see what it is. We're gonna talk about API. That's a bit more common. And we're going to talk about data architecture right now.

So the idea that we have here is, when we're going into the application, the IT landscape.

The goal here is to create a situation where the right IT architect can define a set of disease, that are independent, and that deliver a clear business value. That's very important, delivering business value.

So these pieces that are defined like that are cold and in the business composability world, They are called packaged business capabilities, or PVC them, not talk about PVC, that the bits in that section.

Quite an interesting thing, right? Because you think about, that's the 90 component called the Business Capability Package business capability, it's interesting to see here the connection that, we're going to have the business components to the business capabilities.

In, in the pure definition, as you can see here on the screen, under package presents capability is encapsulated software components that represents a well defined business capability and very important that are recognizable, but, as such by a business user. This is this is very important So the architects may start to break down PC. So we take an application, you start to break down PCs and now though comes a very good question, right? What is inside my application, what is outside my application to? The PC will be broken down like that.

And it's not an easy topic, this is really at the peak where architects will will it will put in their their own I would say ideas and their own knowledge and and and kind of know-how in breaking down the things regarding before Arctic in principle that may be very familiar to you because Enterprise Architect is really about that. Modularity, autonomy, orchestration, and discovery. We're going to talk about these four pieces in my next slide. The global idea here is also about APIs. It's one of the key point, because, as, as much as, well, you will be breaking down PCs. You need to reassemble them, and their way to reassemble them, to be able to, to glue them together, with the APIs. And we're going to see within, Hope, X, within. We say our design here that you can see on the left side, the small, but you can see it, you're going to see how we will be able to decompose, or the, or species, and how they would be able to, to, to fit together.

So, here on the left side, you have one example of a business capability that then gets you dates APIs. On the left side, you have events request that comes into that that software piece, and it encapsulates many things such as services, inside microservices services. We can, we use different terms. And, and here you will be able to define data that are encapsulated within that particular package. That's the show definition, you will be able to, to, to, to figure out which pieces you put within your package.

Do you like that?

Then, comes the recompose the decomposing of this, of this of this IT landscape, right? So, you have broken down many things.

You have decided how which services are going into which package presents capability And now it's time to create your global system that is going to answer to one of your customer, to your ... request.

And for that, you know, modularity will be actually point of your composite beats. Yeah that's that's of use when we see that.

But the key point is that modularity has to be derived from from the business in that case.

That means that at some point, if you have, for instance, the example of that, right there, I have a customer package business capability and the airport package and capability, another package, basically, agents capability.

That's an example for an airport company, for instance.

So here, you can see directly that, if ever you have something to change something that that's going to be impacting specific package Mississippians capability, you're gonna be able to do that within this order of governance within this this governance package without impacting the rest of your system. And because you are, well, well, I was connected with your APIs on the other end. So very important to understand that.

These species, the modularity that you're going to have to be business oriented for sure. And that's when you will be when you will be able to reassemble them. They have to be autonomous enough so that you can make the changes as you want to add, and the function, voice function in one piece without impacting the other pieces of the software. And this is really where you're going to find the, the agility that you need to be able to change your architecture without making too many changes within An impacting the changes on the other ... out there.

And we have here on the left side and mutation that we had that we have in our platform. That really helps drive that.

Composability on many layers and helps drive the API connection that you're going to have between your multiple packaged business community.

Then, finally, we talked about composability, right, so we decompose, we create the object, business capabilities in many layers. We do them together. We talked a bit about APIs for sure.

But these APIs are very important, right? So, these APIs that you can see right there, you have to talk about the orchestration.

How will it happen when you have another component of your IT that's going to be coding that API? What is going to happen? What are the data that are going to be exchange in which order? How are you going to do that?

This is all that we call the API design, ... orchestration and that is going to be very, very important for for for this, for this. I would say kind of choreography that you're going to have between your multiple pieces of the a T So this means here that, for instance, if somebody call an API like that, you want to be able to have a pattern based view like this that explain, How do we start? In which case, we send this data, that data. And, of course, this is all connected batch as the enterprise architecture, which finger to the data models, and so on and so forth. So that would be able to connect all the pieces together, it goes with that.

But the main idea is that here you really want to have a pattern that is designed offshore APIs to be able to understand how all of these pieces will be fitting together and what's going to happen when you call of the ....

And then, at the end of the day, we teach designers to batch and the solution that we have been created all along.

We'll be, sorry, but that will be no connected to our ecosystem.

So, we started by designing this piece right there, that is our package business capability.

And that this piece right now is part of a global system that is used right there. And that we can identify know, which kind of partners are going to interact for system, which kind of customers are going to do which kind of requests to our system.

And now we can see that whenever we have our requests in our system we can identify key which part of the stem is going to be impacted and you know have the agility, the decompose EBT, you are competent enough right now to identify which pieces you need to change or add and so on and two, gluey with an API to be able to to go fast in the time to market.

And so, here, it is really important to understand that going up up and up, you will be able to decompose.

You will be able to have as catalog of package business capability that you will be able to re-use, and and puts within your solutions to ready to be able to compose a distribution as you see fit, all along, to follow the needs of your customers.

So, we've been talking about the architecture piece, I'm just looking at the time, I still have a couple of minutes to talk about the builds added to be state. So, how do we tie that to the projects, The programs through the agile providence, of course, because many companies are going to working on Agile, Agile project management, and. So for that, we have also a framework to help.

Are our customers 2 to two, I would say, go from the Enterprise Architect vision. We do capabilities, the value streams, the business processes that are actually presented to us, To go down to the traditional architecture that they're presented, and to go down to the look at the esteem.

who will be able to develop the, the right pieces of software that the architects have defined.

So, of course, here we see the Enterprise Architect role is there too, Define the guardrails, The business objectives.

Where do we need composability?

To do what, what do we need to achieve?

We will defend the venue streams, the capabilities, the customer journeys, and all of that will influence, which are the pieces of the solution architecture that's ragging, too, modifying that frogging to, to, to have as an impact for this composite T So, here, for instance, you're going to be able to see that this will influence our program increments where we will be able to deliver multiple version of our architecture for one application from the start where it's quite monolithic to the end, where it's quite decomposed with multiple PCs and providing the flexibility that we need to know do the big pieces. To understand, how do we really connect with the local dev team to make sure that their architecture runway, it's actually aligned with that.

And so on that, we've created, I would say, a framework in which the Architects' assertion architects will provide every time the N plus one program increments. So when the architects will work and employment employment, when it's going to be on the next iteration for the FEMA, and then at some point, when the developments are being done, will reconcile the next version of decision architect. So that at any point will be able to have an alignment between the architecture and the local dev team. And that is going to be a work that will work in workshops tuning. The to propose of course, helps on that methodology that. We have ways to, to to to work with that and to to to help our customers building these kinds of models.

So, to summarize, to summarize, we've seen that we have four steps to help our company become more compatible to drive. resiliency, IGT tend to market.

That is based on creating a baseline of business assets.

Scope didn't need for composability, by assessment. Where do we need to be Agile? Where do we need to be more flexible? Whether we need the faster time to market being able to help on architecting it to be states. How do we break down the, the, the company? eight components. How do we do them with APIs? How do we build the patterns for them to be connected and glued together? And finally, a method to actually build A to B state, in which we will be able to, through agile method rates to align and the local dev team, and what the architects have been building all along for that.

Some tips and tricks that we've been gathering on and on, the project that we do with our customers is, first of all, do not do it all at once. Right, For sure, it's something that you need to scope.

Probably, there is a specific area of your business that needs more flexibility, so we have to understand that says, architects and builds. We have to think about combination, what goes together from a business point of view.

How do we encapsulate and glue the Dia de competence through the integration patterns APIs?

And of course, that can be said enough, the IT decomposition that has to be business oriented, so that the business can recognize the PCs, and they can actually work with ... architects in the same language. So that's the connection goes way way was mostly over there. We talk sometimes about fusion Teams and into that today, but this is really what well it switched to develop.

So the key takeaways, if I can summarize that into, into, into this slide, so at mega we have our first admitted, the rho G that you can leverage to drive composite beats shrieking. Moreover, we have a lot of playbooks.

I would say, knowledge to share on that the peak.

That's, honestly, we started to cover today, but we were very high level because of the time or so. But, you know, it's easy to come to us, ask questions. We're more than happy to share more knowledge on this topic as we are researching on that.

Second piece is that the composable architecture is not that is an enhancement to your current business architecture and that the replacement, what you have done today, if you have started to do business architecture, will be re-used for that way of thinking. So, continue on that. And we made me to plug in the ...

architecture in this compatible thinking into that, assess whether the company can benefit from composability.

And that's based on KPIs that you're going to have APIs like them to market, like that like like a transformation of customer satisfaction and so on.

And of course, architecting it in reasonable building blocks that we know and you will, of course, played a key role into business compatible project. And I have to say that when I, when I started to work on that, that's composable project. I was thinking that every architect that meets right now in my customer base, they already have a composite.

But it's it's really a way right now to to to to go to the business to connect to business BC to the HCPCS. And it really starts to close a gap and talk the same language at the end of the day.

So, to finish with that, so, if ever you're interested in that topic, notice it to contact us. You have your e-mail address there. You can start a free trial with our tool that I took some snapshot from Dave, New, you're interested Intranet and the United States to contact us. I'm more than happy to share more knowledge on.

And so, with that, this concludes our presentation. Thank you, everybody, for attending it. I hope you find it interesting. And, and let us see if we have some questions from the audience.

Fantastic, Yannick Thank you, Yannick, Thank you, Rush, you want to go, What a great presentation on on this concept of composability, of which we had a lot of people early on asking, you know, before you got into composability, Worth talking about, what is composite ability. You know, is it going to define what it is? Like? Come down, people. You've gotta get it. And you've got to it. And you did a fantastic job of showing how composability fits onto the entire process.

And in the enterprise architecture, as you said, it's not a replacement is an enhancement.

two to Dance enterprise architecture, strategists that most are familiar with. There was a quick question on definition.

On the sum of some of the audience, ask, What, if you could repeat the definition of PBC? What is a PVC?

Correct, let me just grab my notes to say exactly the same thing.

PBC is an encapsulated software components, so it sets up the components that encapsulates multiple, smaller pieces.

We can talk about micro services, but I know that multiple ways of defining that too, but it's it encapsulates multiple smaller pieces and it has to be business oriented. It has to be talking to a business user.

So, we talked about order, PBC, invoice, PBC, and nuts. You know, at that granular definition, as we always, as we often see, I would say, in the Agile world when we define too many granular microservices, that sometimes the business doesn't really understand.

Very good. Very good. Thank you. Thank you for that clarification there and the and the anionic 1 on 1 of the questions, this is a multi-layer question here so you can take it piece by piece.

But know, if I go back even my own, you know, some of the audience may have mentioned this, but in my own experience as an executive for an engineering and construction and energy company. There was, there was always a bit of a struggle a few years back with the concept of interoperability, which is this idea that software can, can folk can work in modules and we cannot, we don't integrate them but we can actually make them interoperable. And the, and this is not a new concept. There's an old concept. However, it was really hard to do because when you get into corporations, all they want to do is to integrate stuff. They want to, you know, create this, you know, almost customized solutions to what they do. And they start integrating here and there and then to kind of untangle that is really hard to make it interoperable.

Now, does the concept of composability, Builds are differing from the concept of interoperability, if you will.

And then, there's a lot of, you know, a lot of changes have happened, I think, with APIs and other things that allow interoperability to be fast easier today than they used to be, but I assume there's still a challenge as you work of organizations, that they had things are pretty integrated. And, it's hard to make them, you know, into pieces that you can connect in, in, in the, you know, throughout the enterprise, Curious about how you deal with that challenge. It is, it is a challenge for sure. It's rigorous discipline, that's the main idea. I mean, when you define your PCs of IT can be PBC, it can be a microservice, can be an application in Kenya, Mozambique application even. It's not important in that case. You have to integrate them. The integration, I see many times that we create APIs.

You know a lot of APIs, and sometimes way too much weight, the way the architects will be able to help is to define the patterns of API and to respect them.

And what I always say to my customer is before developing anything as a new API, come and see the architect, they have the catalog API. They have the catalog of what you need. Ask the question?

Hey, mister Enterprise Architect! What if I needed the order number four for my product?

What kind of APIs you have to do that? Oh, yeah, sure. We have that standard API. We can use it to a pattern based thing. Here is the thinking gages and find that you need to use for that.

It's perfect, it is perfect, but it's really, I would say, a discipline to see, come and see the enterprise architect.

They have to be the guard rails of the developments, and sometimes they see, people are like, yeah, it's too difficult, It takes too long, it slows down the process of development, it's not true.

At the end of the day, EA will always help too fast in the development process, because you will be able to re-use the PCs, We use the connection.

So, Composite Beaty builds on that concept of interpret interoperability from a technical point of view, but prescribes the way of re-using these APIs for multiple purposes.

That That's very, very, very helpful, really great insights. And as you mention, enterprise or Go to enterprise architecture, requires a level of discipline that that people try to push back against. Because you know, who wants to be disciplined, right? We want to just quick solutions to our problems. Fast rise, and so, But, but the idea that you point out something that's incredibly important. So with respect to that, what do you see as effective governance structures and organizations? There's so much ownership to be taking here at the process level. At the application level, At the data level. How, how do you, when you, from a practical standpoint, what do you see out there that's, like, you know, that looks like good governance. that's working for making all of these pieces come together.

It's interesting. I had a pure blog, just based on that, under Governance and .... It's super interesting to people.

And I see both ways, right? I see companies that have been going to EA alerts and then suddenly you find yourself in the e-gain and every Tower building kind of diagrams. And that's very useful because they are not applicable for the Development Team. I see companies also going towards the fuel development team and there is no architecture, and then you find yourself, we wish that thousands of microservices that you can then be used, because you don't know whether you do. It's actually in the middle. It's always the same. It's somewhere in the middle is the right answer. For me, the good governance that they see is, you provide guardrails provides and what we call the dense neural architecture. I'm showing, I would like that right now, but, again, we have blogs instead of that. Intention and architecture are from the social architecture point of view.

And then you will have the developer who will be able to build their own solution creativity, build the way through, build that in digital architecture.

That, that the architect I've been doing, judge, that should not be in charge of building the technical solution That still the development in and didn't need to do technique and architects.

Decision architects have to be prescribing the way it's connected. The patterns of technologies.

The global picture that can be then re-used as a gas or oil for the dev team. And when you find that kind of alignment, then you have a successful Enterprise architecture practice.

They're good. And, as you mentioned, the requires vision, requires the right thinking, and the quite a bit of discipline to coupon on that journey and stay within the right boundaries. Arizona Sabet, who, if I recall correctly, is based in Boston, Massachusetts, right there. So, Arizona, you probably can just walk over there and say, Hello .... She says, great presentation, and thank you for sharing your knowledge and insights with us today.

And she is curious about your thoughts on the similarities or differences between this concept of composability that you have and systems thinking.

How do they no, are analogous or different from each other?

Know, at mega it's, it's, it's very funny to you as I could not funny, but very interesting. Is that question because that mega, we have been having a system of system approach from the beginning? It's a little way of thinking where ingrained into that.

It's, if you use our software, you will see that perfectly.

And the concept of compressibility I can build completely on that. creating systems of systems and we use S O S system of systems thinking to build on the composability thinking. The system of systems thinking is way broader, I have to say because it's thinking that everything can be in something as basic here. And in that case, it's exactly the same kind of mindset.

Composability, for me, the way I see it, the way I see that apply to the Enterprise Architect, I would say, and that's saying that the global definition there.

But I sit more, going towards, apply that to the business architecture.

This is really where I see the difference. It's kind of a systems approach applied to the business architecture world.

That that, That's a great way. That's a great analogy. A great way of explaining that, yannick, we are out of time. It clearly could talk about this all day, because there's so much depth to this topic. We really appreciate you, and Russia did a fantastic job in showing the big picture, and showing the pieces that are required to, to drive greatness in the enterprise architecture. So thank you so much for sharing your wisdom and expertise with our global audience today.

Thank you very much, Josie. And speak to you soon. Bye, Bye.

Bye, Bye, Ladies and gentlemen, that is mega international sharing. Their expertise concepts of composability concepts of there are so critical for robust Enterprise Architecture systems. Very, very good presentation. And insights now, we're going to be taking a break now and when we come back at the top of the hour, we're going to switch gears to what industry practitioner that you do not want to miss. I'm talking about Bill Wong, who is a Leader for artificial intelligence, and Data Analytics abdel, Bill is gonna come to us directly from Toronto. And he's going to discuss how to architect an artificial intelligence ecosystem. You do not want to Miss Bill session. He always provides a wealth of information about market research. And what they're seeing. For a very practical standpoint, he's very good at separating hype from artificial intelligence applications.

There are creating value to date and that you're going to have access to all of that Plus.

When we meet bill at the top of the hour and we, and we reveal architecting an artificial intelligence ecosystem, thank you for now.