Embark on a transformative journey with the masterminds, Dr. Phil Tetlow, Paul Homan, Neal Fishman, and Rahul, as we dissect the intricacies of IT ecosystems. Their groundbreaking book "Ecosystems Architecture: New Thinking for Practitioners in the Age of AI" serves as our compass, guiding us through the labyrinth of system architecture and its symbiotic relationship with artificial intelligence. This episode promises a thorough exploration of their collaborative vision, shedding light on how they address the monumental task of scaling complexity to meet the demands of an increasingly connected world.
As we navigate the domain of Ecosystems Architecture, our conversation reveals a landscape where adaptability and innovation reign supreme. The authors champion the power of community and open dialogue in sculpting the future of architectural practice, making it clear that no one person or organization can tackle these evolving challenges alone. They make a compelling case for governance models that encourage both control and cooperation, all while ensuring the customer remains the centerpiece of their human-centered approach. This episode is a testament to the collective expertise that has birthed a new framework poised to revolutionize how we conceptualize and navigate complex IT systems.
The episode concludes with a dual reflection; first, on the harmonious collaboration that birthed the book despite its complex subject matter, and second, on the alignment of the authors' vision with The Open Group's philosophy. This alignment promises a potential shift in the Standards of Architecture practices, igniting a spark that could transform the way we perceive our roles within vast technological Ecosystems. As we close, we invite listeners to not just witness but actively participate in the evolution of ecosystem architecture, shaping a future where Enterprises are not isolated islands but integral components of an interconnected world.
Copyright © The Open Group 2023-2024. All rights reserved.
Embark on a transformative journey with the masterminds, Dr. Phil Tetlow, Paul Homan, Neal Fishman, and Rahul, as we dissect the intricacies of IT ecosystems. Their groundbreaking book "Ecosystems Architecture: New Thinking for Practitioners in the Age of AI" serves as our compass, guiding us through the labyrinth of system architecture and its symbiotic relationship with artificial intelligence. This episode promises a thorough exploration of their collaborative vision, shedding light on how they address the monumental task of scaling complexity to meet the demands of an increasingly connected world.
As we navigate the domain of Ecosystems Architecture, our conversation reveals a landscape where adaptability and innovation reign supreme. The authors champion the power of community and open dialogue in sculpting the future of architectural practice, making it clear that no one person or organization can tackle these evolving challenges alone. They make a compelling case for governance models that encourage both control and cooperation, all while ensuring the customer remains the centerpiece of their human-centered approach. This episode is a testament to the collective expertise that has birthed a new framework poised to revolutionize how we conceptualize and navigate complex IT systems.
The episode concludes with a dual reflection; first, on the harmonious collaboration that birthed the book despite its complex subject matter, and second, on the alignment of the authors' vision with The Open Group's philosophy. This alignment promises a potential shift in the Standards of Architecture practices, igniting a spark that could transform the way we perceive our roles within vast technological Ecosystems. As we close, we invite listeners to not just witness but actively participate in the evolution of ecosystem architecture, shaping a future where Enterprises are not isolated islands but integral components of an interconnected world.
Copyright © The Open Group 2023-2024. All rights reserved.
Welcome to Open Comments with myself, Ash and me, Oliver.
Speaker 2:And me Irene.
Speaker 1:Today we will be bringing you a special episode with the four authors of Ecosystems Architecture New Thinking for Practitioners in the Age of AI. Thank you all for joining us today.
Speaker 3:Okay, so with us today. I'll give you a brief summary. We have Dr Phil Tetlow, Paul Homan, neil Fishman, and Rahul Gentlemen, in whatever order you please, would you please give us a brief introduction to yourselves and who you are and what you do?
Speaker 4:We go according to the order that you gave us already. Why not? So? Good morning, good afternoon, good evening everybody. I'm Phil Tetlow. I'm an architect, chief architect. I work for IBM. I've been in the industry for well over 30 years now. My specialty or my area of specialism is data, data science, analytics and, more recently, ai. But if anybody asks, I just make the coffee, that's my cue, I guess I like coffee.
Speaker 5:Paul Homan. I'm an IBM Distinguished Engineer, a long time enterprise architect and, I would say, a long time open group contributor, having looked after the architecture forum for a few years and being involved with quite a few things along the way.
Speaker 6:Neil Fishman. Like Paul, I'm also an IBM Distinguished Engineer and I've been doing this work for now more longer than I care to remember. I've written, like Phil also, a number of books around enterprise architecture around, since semantic modeling, artificial intelligence versus vis-a-vis data science, and that's that.
Speaker 7:Hi, my name is Rahul. I'm a senior research engineer at Emergy Technology Lab for HONDA Research and Development in Europe, based in the UK. My primary focus in research is around data privacy and decentralized architecture, and as part of my job, I'm also responsible for deep tech strategy around products and services.
Speaker 2:Thank you, Thank you for your introductions, gentlemen. We will also be hearing from Chris Ford, general Manager Asia Pacific Region and Vice President Enterprise Architecture, who will be asking the authors some questions.
Speaker 1:To start things off, how did the conception of the book come about, and maybe we could go from the same order from the previous question. Thank you, yeah.
Speaker 4:So I think we should cover ancient history first. So all the authors on the call today share a similar heritage. We've all worked in the field of IT architecture before as we've progressed through our career. I've got no doubt whatsoever that we've all been faced with building bigger, better, faster, stronger IT systems, and I think I'm speaking for all of us in that as we started to progress up that ladder, we became increasingly frustrated with the idea of scaling, or the ideas of scaling complexity. What I mean by that is, as a jobbing IT architect, it doesn't matter how hard you concentrate or focus on a particular problem area or solution If that problem area is large enough for the solution is big and complex enough. Eventually you reach a point where it doesn't matter what schematics you have, it doesn't matter what requirements you have in front of you. If you're not careful, all that carefully narrated knowledge will eventually turn into gloop and it'll just drip through your fingers. So and that was the first challenge that I think attracted all of us as authors here For me also, and to a lesser extent Neil and I'm sure he'll fill in the gaps here I spent about a decade, had a bit of a detour in my career, where I went off voluntarily to help build the semantic web, which is part of the worldwide web, and I became fascinated about how we can accurately describe and portray the assets that we need to in our everyday life and how we can create linkages between them.
Speaker 4:And that detour eventually ended in an argument with one of the leaders of the worldwide web around the notion of connectivity, scale and complexity, and essentially I put forward the point that it doesn't matter how much technology you throw at the worldwide web. The true essence is actually a combination of the social interaction of the users with that technology, and out of that came an extension to the field we now know as socio-technical science. So if you bring those two things together, the germ of the idea here was if you look at current state of the art in IT architecture, you'll probably use labels like enterprise architecture. The problem with enterprise architecture is that it assumes we know where an enterprise starts and where an enterprise ends. We're now working in an age of increased connectivity, predominantly provided by the internet and the worldwide web, to the point where enterprises and organisations have a plethora of connections beyond what we would consider to be their traditional borders. If you roll all of those things together.
Speaker 4:There was an aspiration to think differently about how we might architect above the enterprise level in totally open problem spaces. We call that ecosystem's architecture, simply because if you go out to speak to anybody from the natural sciences and you ask them about connectivity in open environments, they'll talk about ideas like evolution and emergence and complexity and scale and roll all of those things into one ball and you get this idea of ecosystems. So probably about 10 years ago maybe 15, a group of us inside IBM and then very slowly, experts from other organizations started to pull together a collection of ideas about how we might think beyond the enterprise, above the enterprise, in a hyper-enterprise space, what the challenges of doing that were and what the conclusions might be drawn. I'm going to pass over to my colleagues, my other authors on the book, just to see if they've got any complimentary words or if anybody would like to disagree with that summation.
Speaker 6:I will just follow in on that. For me there's a couple of things that one being science and two being specialization and the science part. Just to jump off from one of the parts that Phil was discussing, when we look at science, you kind of think that science is a disciplined thing and therefore reasonably static. And we can certainly look at the natural sciences let's say biology, chemistry, physics that these tend to work in predictable paradigms that can be anticipated and predicted in terms of behaviors or manifestations that will occur, and certainly there can be evolutionary changes that occur, but they occur within the bounds of the natural sciences themselves. When we look at other sciences, especially around civics and certainly organizational behavior would fall into civics one of the distinctions we see between that type of science and the natural sciences is around mutability, that in general, the natural sciences are generally immutable, but the evolution part is distinguished. It's happening within the immutable boundaries that are set aside, set about, that allow things to exist. When we look at civics and the sciences that humans create, we find that they're highly mutable, such that things can change in an instance or at the whim of somebody, and so there is this sense then that because organizations are based on organizational science and civics that there is a high degree of mutability to that that is subjective and subjective and does not have to necessarily obey discrete things. This means that an organization could be focused on manufacturing hardware one day and the next day they decide to go into services, a whole new thing they can create. That it doesn't matter if they how much experience or what resources they have. They can choose to make that change. You can have an operational system, let's say, from an IT system that has been running for a long time, stable and everything. Somebody can come to work one morning and say we're going to get something new because it's perceived there might be some advantages, whether justified or not, that there's a high degree of variability around this mutable side of things and it tended to then get into as an architect, what we're laying down, how easy is something to morph change and what is an overall speed of response. So that started to get into the ecosystems aspect of things in terms of looking at discrete things that are trying to do something.
Speaker 6:Because within that change, the other aspect I mentioned in addition to science was the area of specialization. We can see ever since the time of Henry Ford with creating the production line for Ford cars, people started to specialize in their job and their roles. What will potentially then happen is that if a company requires an instant change because of the mutable, that they are doing something new, something different, they're changing something. That change is going to likely to require a certain specialization In the modern organization.
Speaker 6:Often, if that specialization is not purely embedded within the organization, they will go outside the natural boundaries of that enterprise and seek to procure it, seek that specialization, whether it's a manufacturing arm, a distribution arm, a services arm, whatever it might be a company to facilitate in a supply chain, to provide something. But they will start to seek to go outside the natural boundaries. And what we see through specialization and the complexity of that is that many organizations have set up an environment that they have farmed out areas of specialization as a necessity to survival, for speed, to market and other advantages in scale and otherwise. And I think between the aspects of the science, the immutability, the immutability and civics, coupled with the specialization, kind of have really come about to where they've opened up, where a discussion on ecosystems architecture is meaningful and then pragmatic to pursue.
Speaker 3:Thank you, Neil. Rahul Paul, do you have anything to add to this?
Speaker 5:I like the way when I hear people answer a question, I realized I was thinking about a completely different question. So if I just say one thing, for me the history was quite short in the. Actually a long time ago and it did seem like a very long time ago, I dread to think now I heard somebody talk about ecosystems in the business world were going to be the next big thing and everybody was talking about it. It was in all the academic, it was in the professional world. Everyone was saying ecosystems this, ecosystems that, and it didn't take much research. But actually we did quite a lot that everybody was saying they were really important, but nobody was actually saying how to create one right, how to architect one, what to do about it. And that actually was the genesis for me.
Speaker 5:That was the spark that kind of went. There's a void here. Everyone says these things are important, yet nobody's actually working out how to do it. And that's where the journey started, of the whole kind of the thinking that's led to the book. So I think that's an interesting little piece. You know, it was a void we spotted.
Speaker 7:I'll add on to what Paul just said, mainly as a researcher focused upon applying a lot of technologies, especially emerging technologies, into customer focused services. We are quite keen to understand what's a better way to architect, given the complexity, given the change or rate of change which is requiring the systems today, and one of the primary challenges that everything is changing over space and time for the system that we're designing today. Regulations are changing all the time, customer expectations are changing all the time and the main challenge for us is how do we create a system which is multi-domain, multi-region and even multi-party as well, to create the services which the customer expects from the company today? And these are the kind of questions which led us to investigate newer approaches which can be applied into the future system designs and, of course, ecosystem stood out to be a very clear direction to move forward now.
Speaker 4:So, rahul, just as a minor aside, why don't you just pass a couple of comments about the first time you and I met? And there was an awful lot of no, don't do that, do this, and oh, you've been thinking about that as well, haven't you?
Speaker 7:Yes, I think a lot of work, a lot of discussions have happened in the background around what's a better way to design systems, given all the stuff which is existing today already in terms of complexity and change, and I think we have converged from two different directions into the same answer. Same direction now in terms of what we should do in not just architecture, but even thinking about systems from design phase to deployment, etc.
Speaker 8:So, gentlemen, my first question is how would each of you, from your own perspectives, define ecosystems, architecture?
Speaker 4:It's an interesting question. My guess is that we probably all have different opinions on what ecosystems architecture is, but we all are completely agreed about the thought processes that we articulate in the book, the approaches that we have come together on and the tools that we believe to be relevant moving forward as the industry evolves, and actually that's the beauty of co-authoring a work like this. So there's an old saying that his argument is the finest form of debate, and we've had many years worth of fine argument over could we, should we have, we did, we will, we Okay, we might have just, and whatever came out the other end, I hope. Hopefully it reads well and it provokes provokes more discussion and more thought. So one thing that we regularly commented on when we met in the meetings prior to writing this book, and certainly writing the book, was the fact that this was just the start of a journey. We're not trying to overtake or overrun any prior thinking. This is genuinely about the shoulders of giants and inching forward as the arc of innovation accelerates away from humanity.
Speaker 6:probably I don't know any of you other guys think- I don't think it is necessary for us to all have directly the same definition, and I think this is what we invite the reader to take as well is that we're not asking them overtly to buy into a definition, but rather to allow them to seek to add how they view things. I would say that there's an underlying tenet, that within this, that from the historical side of things, it has been traditional to try to put some boundary around a scope of work and within ecosystems it's an approach to where to say you can't necessarily meaningfully or naturally define that boundary and so whatever you want to put inside or outside of those things amongst the four of us we will have probably some nuance, and we invite our readers and other practitioners that want to look into this to allow them to develop their own things. And but I would say that the aspect of the ecosystem is to come at creating a solution for a complex problem for which there is no inherent or necessity to define a boundary.
Speaker 5:I would say, if you asked us all to describe, let alone define, what an ecosystem's architecture was, we would no more come up with the same set of words. And if we were asked to describe a banana. But the point was, what we've created is sufficient for us to have a dialogue around the same concept, so we all understand what the other persons and we're not talking across purposes. So the fitness for purpose of it, I think, is what we've set out and defined. To the same extent. I went through the whole enterprise architecture definition, wars, you know, and kind of like okay, what does that mean within the open group, and so I don't think it's necessary to have the perfect definition, because that's not what we're trying to do. We're trying to define it fit for a purpose, and the purpose was to have a conversation around the concept.
Speaker 7:Hence the practitioner piece and I think the more important point is that this is not the final definition. This is not even focused about finding the standardization around words you look at. This is more about asking questions and this is more about encouraging everybody else to ask these questions, which are discussed in the book as well. And the last point I would like to make is we release this book with the hope that people recognize that they are not the only one facing the kind of problems that we are describing the books or asking questions which are being discussed in the book, and we are hoping that this book brings out people from different parts of inter-procure architecture world together and ask clarifying questions even further than what we are in the books today.
Speaker 4:Yeah, there's a very clear invite in all of that, so come and join us. The strength is in the crowd. If you've got an idea and you want to add it, by all means do. That's. That's the.
Speaker 7:That's the nature of advancement and innovation yeah, and we're happy to be told that we are wrong. If we are wrong, we'll be wrong.
Speaker 3:So it's to encourage a new way of thinking rather than telling people this is how it is.
Speaker 4:I would say it's two things. One, it's a recognizer. It's a recognition that the world is changing and the practice needs to change in step, and secondly, it is an invite to contribute alongside.
Speaker 6:I would just add on that it's not that it's just new work or new thinking for the sake of creating new work and new thinking. It's a recognition that we are reaching levels of complexity that nobody has had to address before and that, along with that especially when we look at the artificial intelligence componentry especially what generative AI will bring to this or general AI will bring to this in the future is that we want to try to be ahead of the game as much as possible in developing meaningful solutions for organizations, as opposed to always putting our organizations in a position where they constantly have to play catch up.
Speaker 4:Yeah, well said, well said.
Speaker 3:Thank you, gentlemen. I think that's a great summary into the the concept of the book and the thinking for it.
Speaker 8:Gentlemen, can each of you share, from your own perspectives, some sneak peek insight into the book with our listeners, something perhaps that you've been thinking about that's not explicitly contained in the book, but there's a perspective that you would like to bring to our listeners here in the podcast?
Speaker 4:So I think there's a conclusion that we draw out specifically in one of the chapters so Neil has kind of alluded to it already which is we're getting very close, if we haven't gone past the point where the scale and complexity of the IT systems that we aspire to build is beyond the capability of even the brightest souls within our community.
Speaker 4:The question is how can we achieve what we cannot humanly achieve? And the conclusion is that we're going to need help. Recently, with the arrival of generative AI, there's been a bit of a sea change in the industry, so no longer do we need to converse with them, with the digital machines around us, using languages that they can understand. Rather, now the machines can communicate with us in languages that we can understand and, as a result of that, we can use the capabilities of generative AI to augment the naturally given skills that we have as intelligent human beings. That's awesomely interesting, while at the same time being immensely frightening, and there is a significant element of professional practice that's involved in making a huge statement like that. One of the side effects of the ecosystem's architecture book surely has to be some heavyweight thinking, hopefully at the global level, with regards to the creation and adoption of new professional practice, specifically in the area of IT architecture, when, where and how IT architects do indeed seek and use the synthetic help of AI agents. I think that's my killer. That's my key point.
Speaker 5:I think, yeah, I think, if I was going to reflect I don't know if it's a sneak peek or just a kind of piece of the book that I kind of really enjoy, aside from chickens and waffles, and I'll leave that just hanging but the the bit that to me I didn't even realise. I said it and I think it was Phil first reflected it back. But one of my stock expressions when I'm thinking about any of these things or anything architectural is that's all well and good and beautifully. That got mirrored back in the book and is part of it, and the reason why that's important and I think a little kind of gem in the middle of it is it's quite relatively, you know, it's interesting but relatively not that valuable if all you're doing is thinking about something.
Speaker 5:But actually I think this book goes beyond that. Not only is it set up these are things to think about it teases us with a few areas that we can start to do something about. So that's all well and good, fine, but actually let's draw a line behind the thinking part and let's mean what does that mean we've got to do and what can we do? And there's plenty more to explore in that area and I think that's the next sort of you know chapter of the journey, but actually there's a reasonable amount of and these, this is what it means and this is what I think we can do about it, and that's the. That's the bit that I enjoy seeing coming to life.
Speaker 6:I think for me it's kind of opening up some other areas and avenues to explore in a meaningful way and subsequent work. So, for example, an element of TOGAP in the architectural development method is an aspect of implementation governance. If we focus on the word governance, to have a meaningful governing thing in terms of governance you have to have the ability to assert influence or assert control. If you don't have control or influence, you really don't have governance. And so then what does governance mean in terms of an ecosystem where all of the participating nodes of that ecosystem can you actually govern? So can you force decisions or influence them to make certain decisions? In some ecosystems that may be possible, In others it may be impractical.
Speaker 6:Just having saying we will connect things through an API doesn't automatically make everything exchangeable. Saying further, we'll do that with XML or JSON. Again, it doesn't force it to be always exchangeable because there are two standards there alone. Further on into schema design, HL7 or various things within NIEM, that doesn't give you the ability to always conform.
Speaker 6:And then when you look across the ecosystem and potentially see the literal hundreds or thousands of nodes that could participate in an ecosystem, can everybody change at exactly the same time? Do they have the person power? Do they have the budget to do so? Do they have control of the systems, that they have the code, or are they using, you know, procured services where they don't have over control of how something is set up? So I think it's really. I think an exciting thing is that it's opening up to re-explore what governance means in an ecosystem. So how do you assert control and influence where you can't necessarily mandate across every node of that ecosystem? So it requires a lot of cooperation and synchronicity within that. But when you backdrop it against one of the things that ecosystems is trying to do, which is improve speed, the governance has got to complement that and not hold up the speed of progress.
Speaker 7:For me, there are a few things which are currently alluded in the book, but we would definitely like to expand it further and there is a set of questions implied within the text. Currently, One of the things is about how to design humane systems, how to design systems which keep customer at the center of everything. We usually keep. Any organization like to think they own and they control the system. So by default, in their own mental model, they are at the center of their own universe. But ecosystem architecture is a way of thinking about things while keeping the real human at the center, someone who will benefit, use, utilize the service over there.
Speaker 7:Second thing is it also brings in question what is the value. What is the value for business? What is the value for customers? What is the value for the whole chain which is required to bring to life the service from a particular ecosystem? And last would be about the question of viability. Would our ecosystem survive, even if it is formed by a group of companies and markets and stuff? Why should it survive? What is the way to make sure that ecosystem is viable during this lifetime and serves the purpose for which it was designed for? A lot of theoretical and practical questions which are really interesting for us, which we hope to tackle later on as well.
Speaker 4:Yeah. So if I could just briefly add to Rahul's comments there, we spent a lot of time talking about the idea of ego and centricity. If you're viewing the world from the point of view of a particular asset or atom inside a think space, is it right, is it proper to think about that as being the center of the universe around, with everything else evolves? And one of the key tenants of ecosystems architecture is that, rather than thinking about reductionist ideas, ecosystems architecture is much more Taoist. It's much more about believing that every atom in the universe has equal presence and equal importance and then working out what that means in terms of all the connections and relevances across that universe. It's quite harmonious, or it should be harmonious, in the way that it's understood, accepted and applied.
Speaker 7:Yeah, absolutely Thank you.
Speaker 1:And moving on to the next question, what are some of the challenges that you'll face in writing the book, and also can you describe any of the roadblocks? And maybe we could start with Rahul for this question. Please, thank you, not to put you in the spot.
Speaker 7:I say, very interesting question. I think so. So what were the roadblocks and challenges in writing this book?
Speaker 7:I think, as a reflection of the topic itself, there's a huge complexity in the thinking which has brought us the current version of the book. It's kind of a multifaceted crystal. We could pick up any particular facet and write a book about it, and we wanted to convey in some logical, understandable way what the whole crystal is about. What are the problems that we are looking to solve? What are the values that can come out from this particular approach, and not just from the perspective of technology or innovation, but from the perspective of business and customer value and how it would be pushing the envelope by combining different technologies together under the umbrella of ecosystem architecture. So Gen AI was definitely something which added a lot of value, a lot of surprising twists in the story on the way. It wasn't there at the start when we were thinking about ecosystem architecture, but it just came through. The authors at the right time I would say, I believe Phil or Paul, to add to that probably.
Speaker 5:I was going to actually I'm going to nudge the question slightly, if I can. So to me, I think, the biggest challenge in where we've gotten to through the working group efforts that got to producing the book and is still there to carry on the work I think the biggest challenge is actually genuinely having the permission to stay in the discovery stage and allow yourselves to explore it, because there's so much needs to be considered and everybody likes to bring in the whole. We all, by osmosis, adopt the whole idea that you have to deliver something in order to prove value, when in fact, there's massive, massive value in just the exploration part and the kind of kicking it around piece, and I think the biggest challenge was actually keeping us in the kicking it around and then being able to convert it, and that's a sort of a testament to the way that we work together and that we had a lot of fun along the way doing it.
Speaker 6:I think there were elements that it was a topic that everybody had been seriously thinking about for some long period of time.
Speaker 6:We may not have always been on the same page every time, we brought up every topic, but in general the backdrop was something that we were coming in, recognizing, as Paul said earlier, that there was a gap avoid in the literature about how to deal with this particular topic, and so it had been something we had been mulling over, and by the time that we had come together as a working group, it was surprisingly organic and efficient within how it all came together, that everybody was on the same page about trying to get something out there so that these ideas could be shared, so that they could be enhanced and grow and the discipline could be put out there. So we were driven to do that, and to me it was almost frictionless. In a way it felt very organic the way it happened. When you look at the time frame in which the book was put out, it was incredible how quickly the material came together, so it was very pleasing and satisfying from that standpoint.
Speaker 4:If I may, I'm going to drop the mic and introduce a bit of a tease. So I think that one of the biggest challenges we faced actually became one of the biggest triumphs of the book. So we got involved relatively quickly and some very deep, very philosophical discussions and we needed to describe many ideas that were very, very deep and abstract, and I can remember, if not one meeting, there was a series of meetings where we just went damn it, let's just talk about chicken and waffles, and that's what we did. But if you want to find out why that's such a triumph, unfortunately you're going to have to buy the book and read the chapter.
Speaker 7:That's a very good sales bit, trill.
Speaker 7:I will add one more point picking up on what Neil had said, actually about the journey itself. So I think all of four of us have been thinking about this topic in our own professional life for a long time, before we met each other, I think, and a lot of thinking on all four authors' part had matured by trying to explain the story and try to explore the problem within our own professional circles as well. And I think it was quite the right time when we started discussing together as a working group around this topic. So we already had some preliminary analysis, investigation done as part of our own personal professional life when we came together and that was one of the reasons, I think we kind of hit it off quickly once we realized all of us are looking at the same problem and we have already gone through several iterations trying to find an answer and approach, which failed miserably when we were working individually but putting our heads together, we were able to at least understand the direction we should be able to go as a working group.
Speaker 1:And continuing on to this, how would you define ecosystem architecture in terms of the book fitting in with the open group? I think that leads on quite nicely with what you were just saying, Rahul, as well.
Speaker 7:Oh, that's interesting. I'm telling you a question now.
Speaker 5:I mean, I'm happy to kind of say why. So I had the pleasure of taking the concept of the working group to the open group, originally as a proposition. Now I've also had the pleasure of being engaged with the open group for a very long time over 25 years so one of the things that I saw was a lovely bit of serendipity in that. For me and this is just a personal opinion, but I don't think it's controversial the open group is a foster of ecosystems. It brings disparate people together to work on common things and collaborate and itself therefore sort of not unwittingly, but not from a pure architectural mechanism actually is a great place to kind of have the same exercise conferred within it. So for me, the open group was just a lovely backdrop place to have it, because the open group is all about ecosystems.
Speaker 7:And in a way we landed on a planet which was not hostile to the idea of ecosystem architecture, because that was inbuilt into the functioning of Open Group as a body itself. So we were quite easily acceptable and we found quite a strong support and facilitation of the working group focus area as well.
Speaker 3:I love that shameless promotion of the open group from Yibab Boran Raul.
Speaker 7:I'm grateful for the support. Of course we would be happy.
Speaker 4:Yeah, so you're going to get some more from me, unfortunately. So I was pretty clear about the open group being the destination for this work and, interestingly, the hints in the title. So the open group is about, firstly, being open. Secondly, the emphasis on group. So this isn't about he, him, she or it, it's about lots of people coming together. Thirdly, it's a group or a receptacle, a place to meet, discuss and debate, specifically for IT architects. And then the killer thing is that it is the and I'll repeat that it is the only open global forum for architectural discussion which is free of influence from any commercial outside organization, be that civil, be that public, be that private. It is a coming together, it is a dojo for architects to do their training and fighting. And there was no other place. The open group was the temple.
Speaker 7:And one more motivation for me personally was that this is when me and Paul were discussing about how to take forward our internal ecosystem architecture activity outside of our internal project. The emission is that ecosystem architecture work, the body of work which we're doing right now, would hopefully evolve into some standard, some form of standard, and I think the open group was a natural fit for that kind of thinking, for that kind of working, for that kind of approach.
Speaker 2:Hey, Rahul, you may have just answered this question, but how do you all see this book impacting this technical field?
Speaker 5:For me, I think the slightly more initial, humble part ambition, I should say was the practitioner, so it is key with a lot of the things that I worry about in terms of architecture.
Speaker 5:So it was great to see that in the title of the book, because the idea is that we created something that an individual who is working in an organization is able to actually then go and do something with, so they can kind of apply it out in the wild or start to address some problems. And I think what it does from a technical point of view and I'm going to use it with a small T is really talk about OK, how do I address this problem? How do I unwrap it? What are the tools and techniques and things I need to do? What are the things I need to do, differently from what I currently do, in order to be able to address some of this problem, where that goes and how that will influence the thinking. I think everyone on this authorship call is of the same mind that it will have wide reading ratifications going forward. It might take a while, it might not, but there is certainly something that it will impact and I can see updates to standards, if not unique things in their own rights in the future.
Speaker 6:I think one of the ways it potentially could influence some work is that, as architects, we're very used to dealing with things in an as is and a 2B state and they are distinct, and that there will be a transition that occurs between the as is to the 2B. From an ecosystem standpoint, the as is and the 2B can just simply be nodes within the ecosystem's architecture, so they don't have to then be distinct and, as such, I think it opens up a new way to think about work, because it's you're getting back to the boundary standpoint is. It opens up additional opportunities about how to do things and, ultimately, I think it allows architects to truly approach the work of architecture in terms of the long term and not just the shorter term of what an organization needs. But you can now start to plan what the organization may need in 40, 50, 100 years from now, because you can represent that as a node within the ecosystem's architecture.
Speaker 4:Yeah, so I'm minded to provide an answer by way of a story and I really really didn't want to name drop on this call, but I think on this occasion it's worthwhile. Over 20 years ago I can remember being in a cab, in a taxi, on a long ride to a client location with a very, very eminent software engineer, grady Booch, and that was very, very early in the ideas that we've now managed to bring together. And I can remember empty in my head in front of him and talking about a whole lot of gibberish. And Grady stopped me relatively quickly and he said look, young man, they're all great ideas, they're great words, but you need to understand the following.
Speaker 4:He said if you look back at the history of humankind, it's essentially been a story of progress. We aspire to build bigger, better, faster, stronger. But as we do that, we really only learn how to master two things better. And he said the first thing that we learn to master is scale. Generally, as we move forward, we build bigger things, we build bigger cars, we build bigger bridges, we build bigger ships. But with scale, the downside is that you increase the complexity.
Speaker 4:And he said the human mind is built to essentially chase prey on the plains of Africa. It's not designed to build mega bridges and mega structures. So, he said, we can't slurp up all the complexity that we're creating, so we create defense mechanisms, and the primary defense mechanism that we have come to terms with is the idea of abstraction. So the more complex a thing becomes, the further away from it we stand to understand the nature of that thing, and the one thing that I truly love about the book that we've managed to bring to you is the fact that it handles the ideas of scale and abstraction really well.
Speaker 7:I'll add on to the point that Phil made. One of the key influence or a change which we hope to emphasize and accelerate is a new generation of tooling which can be built for this future ecosystem architectures and approach. We have demonstrated the use of JNAI already as part of this book, but there is a whole set of things which we have not mentioned in the book at all. But the hope is to trigger that discussion, trigger the questions of what else can be the use as enhancement of the current toolkit which is as part of the enterprise architecture used today.
Speaker 2:And I'm sure, by having this call here today, this discussion, that all our listeners are triggering those questions and are starting to think about ecosystems, architecture and how it applies to them. So this might be the hardest question of the day. So if you could all describe the book in three words, what would they be?
Speaker 7:Meaningfully point your book Controlling complexity and change, paul.
Speaker 5:I can't think of three words, to be honest, because I'm stuck with, actually, what I want to say, so I'm going to cheat entirely and just ignore the question. What I will say, though, is no enterprise is an island, and I think that's what this book is about. It's basically saying ecosystems is where any self-respecting enterprise architect needs to look next, to serve and provide value into its own organisation.
Speaker 4:Yes, so I'm going to end on a high with this question. I think the three words that I would choose to use are made of paper. Of course, the book's made of paper.
Speaker 3:I think that's a challenging question, asking the authors of a book to summarise it in three words.
Speaker 7:We can write another book about it. To be honest, we could.
Speaker 3:So I guess where do you see this book evolve? Do you see it evolving? I know you've only just published it and you've mentioned it's got a lot of scope for scale, but how do you see this book evolving, the areas that you're talking about?
Speaker 4:Do you want to do with this one, Paul, or should I?
Speaker 5:Well, I'll start with a non-book angle, if you like, so that maybe leaves enough wiggle room. But I think if I look at the thinking and where that's going and the work around it and whether it manifests as a book or something similar is a separate conversation I think what we've got is a whole bunch of stuff which sets out a stool, sets out some ideas, puts out some hypothesis and is a call to action. I think the next bunch of thinking is a playback on the results of that action that the community picks up, so there's almost like an ecosystem's architecture. Thinking in action is the next piece.
Speaker 7:And it should be built with the participation of the wider ecosystem of enterprise architect. Honestly, it won't be the work of just four of us. I believe 100%.
Speaker 4:Yeah. So Paul's nailed it. So I've written a word down in front of me here and that word is clarion. So the book is actually just the thought of a journey. We've kind of committed as a team already to write a follow on book, which Paul said is ecosystem's architecture in action or in practice. What we're genuinely hoping will happen as a result of the open group conferences, meetings, calls over the next couple of years is that use, cases and experience can be harvested and we'll collect that together to understand what's good, what's not so good about this and ultimately inch towards some type of standard and professional acceptance.
Speaker 6:I think this is going to get really quirky If it grows and starts to manifest. It potentially paves the way to be able to explain why there's no such thing as data and then to really get a handle on that, so that this ecosystem's is about a new way of generally thinking in terms of how architects piece together systems for businesses and organizations to use, and I think that the next segment of that, in addition to embalishing the work, is to rethink what data means to organizations.
Speaker 3:Thank you, guys. I think there's a great summary into the book and the work in the future that we hope to have, and I'm sure that a lot will come of this. But it may take some years, as you say. It could be a very long process, but we're all looking forward to seeing what happens.
Speaker 1:And, on that note, we'd like to say thank you to all of you for joining this special episode today. It's been great talking to all of you on the book and we hope our listeners have enjoyed this episode as much as we have, and we really enjoy bringing different topics into the fold for our listeners and I think this episode was definitely a very special one. So thank you so much all. Please stay tuned for the next episode coming soon. Thank you, stay safe. Thank you so much, guys.
Speaker 7:Thank you. Thank you, please buy the book, read the book and send us lots of questions.