ºÚÁÏÃÅ

Podcast Transcript

Alexey Boas:

Hello and welcome to the ºÚÁÏÃÅ Technology Podcast. My name is Alexey. I'm the head of technology for ºÚÁÏÃÅ Brazil, and I'll be one of your hosts this time together with Zhamak. Hello 

Zhamak. How are you?

Zhamak Dehghani:

I'm good, Alexey. Hello everyone. I'm Zhamak. I'm your cohost today and connecting to you from San Francisco.

Alexey Boas:

Great, and we are here with Sriram Narayan this time. Hello Sriram. Would you mind introducing yourself?

Sriram Narayan:

Sure, and yeah, I'm happy to be on this podcast. Thanks for having me. I work as an advisory consultant for ºÚÁÏÃÅ. I've been with ºÚÁÏÃÅ for a long time, 15 years plus, and in the industry for over 21 years. About four years ago I wrote this book called Agile IT Organization Design, which is really about organizational agility, and for the last few years I've been helping client organizations improve the performance of their IT departments, product departments, digital departments and so on. More from a point of view of the overall operating model, not so much with individual skills and team level things, but more as to how they are organized, how they govern, the metrics they use, and the funding models and so on, and as part of that technology strategy, also enters the picture sometimes, and so yeah, that's pretty much what I've been doing in the recent past.

Alexey Boas:

Wow. Quite a lot. Quite a lot. It's going to be a very interesting conversation, I guess, and we're here today to talk about the price of reuse, and I guess we're talking about reuse across the enterprise, and enterprise architects have that challenge and those trade offs. Should we push the lessons learned and the things that we've been doing across the enterprise to many levels? And how does that limit innovation and different solutions or different places of the enterprise? So there's a tension and a trade off there when we talk about reuse across the enterprise. So Sriram, what's your experience with that? Any thoughts on that? Any stories to share about that?

Sriram Narayan:

Yeah. Yeah, it's a very interesting topic and I think something very relevant now as more and more organizations are trying to modernize their existing legacy systems, trying to be more digitally savvy, digitalization and so on, and I want to talk about this with an example from the auto industry, because as you know, most automators operate globally across all major markets, US, Europe, China, Asia, Pacific, and so on, and they offer variations of their product line in different markets, but there are also variations in customer buying patterns, variations in business processes, and variations in the regulations that the local businesses are subject to. So on one hand, you have a lot of local regional variation. On the other hand, you have this aspiration from an enterprise architecture point of view to have some degree of centralization and some degree of reuse of software solutions across markets, and that leads to certain ... like you mentioned, certain potential trade offs to be made. There are certain inherent tensions in making some of those decisions, and I think that provides a good frame to get into the details of this particular topic today.

Zhamak Dehghani:

I just want to pause there for a minute and ask the really obvious question. Just maybe somebody else has the same question. Why reuse? Why would architects or enterprise architects have the aspiration of reusing the capabilities that they build? I know it's a very obvious question, but maybe it's worth just touching on the root cause here.

Sriram Narayan:

Sure, and Zhamak, I'm smiling as I respond to your question because usually the way I hear it is the other way around. The people in charge of IT spend ask the question the other way. Why not reuse? Why would you reinvent the wheel every time in every business region? But it's a very interesting answer to this question. Yes, because on one hand it can get really expensive to create roughly the same software solution for every market region, but on the other hand, as you get into the details, you often find that there are very interesting variations and it's not so easy to get agreement among business stakeholders, across market regions to then plan for reuse. So yeah, why reuse? It's more from a cost angle, and why not reuse? It's more from a business flexibility angle.

Alexey Boas:

Yeah. I guess there's also the capability trap. So I have a group of people who think that through once and then we don't have to do that again, which is not true when we talk about software at all, because you can't just do the designs and do a basic framework once and then reuse that with slight variation. So the devil is in the details, as they say, and that's very true for software as well. That flexibility that you mentioned, Suidem, sometimes is what makes or breaks a market in a specific region, for example, but I guess there are also legitimate reasons for doing that. So whenever you need standards, for example, or a uniform user experience across regions, for instances, or even processes that need to integrate across those regions, those are also valid and legitimate uses or cases for reuse.

Sriram Narayan:

Right. I mean to that extent the idea is ... I mean if business processes need to be integrated across regions, then surely yes, but even sometimes the nature of the business is such, like in the auto industry for example, every region can function fairly independently as a business. You have a potentially a centralized product line of cars that you're selling in the market, and you would have some regional variations, but once that is there, every region is kind of its own market. They have their own marketing strategies, they have their own dealership network connections, and they have their own customer buying patterns. So for example, in Europe, it's common for customers to configure a car and then order it. Every car is in some ways custom configured, whereas in the US it's largely stock inventory. You go to our dealership and you pick something from the stock. So depending on the nature of the business, sometimes there is not much need for integration across markets, and the aspiration to standardize is more of a cost aspiration.

Zhamak Dehghani:

So tell us about your auto industry story. I think you have some good stories and maybe kind of war stories to share.

Sriram Narayan:

Sure. Yeah, thanks. So this particular case, there was this ... of course I can't take any client names here, but there is this auto major who has a market in the UK and a new CIO was appointed in the UK market, and when he came on board he realized that perhaps the ways of working needed to be updated to be in tune with the times, and so he brought us in to help them migrate to a more product and customer centric way of working, and so we came in and we started talking to the teams to understand their current ways of working and opportunities and challenges and so on, and as we started speaking, we realized from a cross section of teams that they were telling us that there wasn't much that they could build by themselves in terms of software solutions. They basically told us that they used to understand the changes required from business stakeholders, but basically really those changes to headquarters, because the systems were all fairly centralized and there was a global backlog managed by headquarters in Germany who would then rationalize the requirements across regions and then prioritize it and so on.

Sriram Narayan:

And so the teams in the UK were telling us that we don't have much autonomy, and on the other hand, the business stakeholders in UK, they were telling us that things are too slow. Anything we ask takes three years to get done, and we can't really compete effectively in this market with a three year kind of lead time for the features that we are asking, and in a way, these two comments made sense, because if requirements are a sort of ... if there is a global backlog at headquarters, then it stands to reason that there will be a delay between a particular region asking for something and then headquarters coming around to rationalizing that requirement across regions, doing it in a generic enough manner, and then prioritizing it into the backlog and then shipping it back.

Sriram Narayan:

So our initial diagnosis, based on this, was that on one hand the CIO is saying that you want to move to a more product and customer centric way of working. On the other hand, we clearly observed a lack of autonomy over here, and that was our initial thinking that yes, if you want to operate in a product and customer centric way, you do need empowered autonomous teams who can move fast, but then we started talking to some local technical architects in the UK and they told us that the things are the way they are because of a deliberate strategy on the part of enterprise architecture in headquarters, which was basically a strategy of centralized application development, and this was their way of ensuring reuse of software solutions. Apparently the global CIO was a keen on maximizing reuse to keep costs under control.

Sriram Narayan:

His logic was something like ... it went something like this. He agreed that there needs to be some sort of a balance between say local spend on software solutions versus global spend on software solutions, and in his mind, it ideally it should be 70 global, 30 local, because if you think about it, if you operate, let's say in four regions, and as a cost basis, if it is 70 global and 30 local, then your cost basis is 30 multiplied by four regions. So 120 plus 70. So 190 is your cost base. On the other hand, if the ratio is flipped around to say 70 regional and 30 global, then your cost basis is 70 multiplied by four, 280, plus 30. 310. So your cost basis is 190 on one end of the spectrum and 310 on the other end of the spectrum.

Sriram Narayan:

So from that logic point of view, they were operating under this strategy of maximizing reuse, trying to keep it as 70/30, global versus regional, and that made sense if you just looked at it from an enterprise architecture point of view, but the business stakeholders did not see it that way. From their point of view, they wanted to move fast and they did not care so much about how much reuse was being achieved across markets. They wanted to customize their offerings to their market. They did not want to rationalize their feature requirements with other markets. The way they saw it, reuse was being thrust upon them as some sort of greater good when all they could see was an ever increasing wait for the things that they wanted done.

Alexey Boas:

Yeah, of course. Yeah, I was just going to say that from ... if you do a purely cost analysis, and cost analysis is tricky because they're very concrete. When you talk about how much money you're going to save, it's something very concrete, but they don't take into analysis the cost of opportunity, for example, of running the business in a suboptimal way. So you really have to have a connection to that strategy of reuse to the business model that you have and the operating model that you have and how much you want to run the business differently across different regions and the benefits that can bring.

Zhamak Dehghani:

And I think it's the same as if you just consider suffer architecture in isolation and do a global optimization, not try to locally optimize, that's how you design your architecture. It's a pattern that we also see. I think what you described with the auto industry and different distribution markets, it's very similar to, let's say retail companies that have multiple brands, and they have a central IT to build infrastructure, supply chain, e-commerce, and so on for a variety of brands and business units that represent those brands, and it's a very common pattern that we see, the frustration of the brands, the frustration of customer facing businesses. At the same time, frustration of IT, because they have to cater for such diverse set of needs, but with an approach that is expected to rationalize all those needs into one solution.

Sriram Narayan:

Exactly, exactly, and the business guys are almost like ... they're saying we're paying a big price for all this so-called reuse, and the price as they saw it was a decline in their ability to be responsive to the market, whereas the benefit was some nebulous notion of cost savings achieved by enterprise in headquarters, and it wasn't really our ... we were never going to get to the bottom of this. We were never really going to be able to say, was it the business that is overreacting or was it headquarters who is overstating the benefits of reuse? But as far as we could see, one thing was clear. There was clearly a lack of alignment between the business operating model and the enterprise architecture strategy, because ideally enterprise architecture strategy should align itself with the business operating model, but here it's like the global CIO thought that it would be too expensive to align with the decentralized business operating model, but then he should have ideally brought everybody together and made them realize this, but instead what we felt like, he had probably made the mistake of unilaterally deciding on a reuse driven approach that wasn't really very compatible with the existing business operating model.

Alexey Boas:

Yeah, exactly, and what happened? So did they achieve a reasonable tradeoff? So we started the conversation saying that there are tensions and trade offs, and I guess the trick is to look at that tension in a powerful and creative way so you can find the best balance. So were there any lessons learned on finding that balance for that particular story?

Zhamak Dehghani:

I've been sitting on the edge of my seat waiting for this story to unpack, so I'm all ears.

Sriram Narayan:

I'll come to that in a minute, but I think before we can agree on what's a reasonable trade off. I think it's useful to also understand what reuse really implies, because people think of it only in terms of software reuse, because of course ... and in this case there was a misalignment. The two parties didn't agree. Business and enterprise architecture, they weren't really on the same page, but even if they were on the same page, even in that case, I would like to offer the reuse as a price, because the reuse of software solutions across markets really in some sense implies the reuse of the underlying software requirements document across markets. To use an outdated term, nobody uses the term software requirements document anymore, but I'm using it in a way like if you're used to an agile software delivery, it's the sum total of what is described in your epics and features and user stories that comprise the totality of your software requirements that represent that solution.

Sriram Narayan:

If you're talking about reuse, businesses should first all sign off on that single software requirements document, but that never happens, because you develop it for one region and then the other is expected to tweak it a little bit and then start using it. So reuse really represents an agreement among business stakeholders, and it is not a one time agreement, because nowadays software is not like you build it once and then run it forever. We don't do it that way. Software solutions are constantly evolving. So in this type of situation, when you're talking about reuse across markets, in turn, it demands a constant ongoing agreement on feature shapes and designs and requirements between business stakeholders across regions. It's not a one time workshop where people get together in one location for a couple of weeks and agree this is the way to go. So in today's world of constantly evolving software, what reuse really demands is the constant agreement among business stakeholders, and that's clearly easier said than done.

Alexey Boas:

Yeah, that's interesting. When you are leveraging a software platform, you inherit the business process that's derived from that platform. I guess we see that in some rewrite projects, when you have to revise a software system and then you have these old weird requirements and processes of requirement because the business process has adapted to work the way the software forces that to work, and then you force all that standardization in business process across all regions, and they have to evolve in the same ways as well, if I get what you're saying.

Sriram Narayan:

Yeah, and that's a good point that you're making, that it is in some cases it is possible to make the business process adapt to the software solution that's in place or that is being put in place, but that is what we will distinguish between what we refer to as utility software versus strategic software capabilities. If it is utility or if you're building for corporate IT, then by all means reuse can be a primary driver or an important driver, because that is not going to give you differentiated capabilities in the market, but when you're talking about building solutions for market tracing capabilities or solutions that are very closely supporting the market facing capabilities, in those cases it's important to design for business success first and reuse later.

Alexey Boas:

Yeah, and adaptability is also much more important in that case.

Zhamak Dehghani:

And I think maybe there is a piece around kind of how the technology's evolved and how the shape of reuse has changed, because traditionally when we think about reuse, it's you build a monolithic system and it encapsulates all your business, a lot of different workflows, a lot of different data sets and it provides a kind of a big set of capabilities, but organizations kind of have moved away that model to decompose their capabilities into kind of smaller services. Because of building something new with the existing pieces has gone down because with microservices or with APIs, the way you can compose solutions has less cost than encapsulating all the possible variations into one system and use that system. You can encapsulate variations through composition of services and pick the pieces that fits your business model and replace the pieces with new services.

Zhamak Dehghani:

So I think companies have moved probably the technology. The reuse aspirations is already there, but companies have moved from a very different model. The centralized services, those systems that you talk about, to this marketplace of capabilities that you can choose to choose or not, and then thinking about your enterprise architecture as a marketplace, it changes the behavior completely, from a CIO commanding that everything shall be implemented in one system and in one way, to product owners of those capabilities trying to convince people that this capability that they've built is the best. Hence, come to my market and use my capabilities. I wonder, based on your story and observations, is technology also changing the way we're creating that trade off between reuse and diversity?

Sriram Narayan:

Yeah, I mean certainly technology has the potential, like you said, if we can get to that state of a marketplace where there is enough flexibility to do reuse as appropriate, but also to build not too expensive variations on top of existing components. In some ways, depending on the nature of the solution, in other contexts, this has been referred to as a pluginable architecture, where there is a common goal and then you can plug in different variations to that, and to some extent, yes. Microservices provide a building block for creating these sort of pluginable ecosystems of components within an enterprise, but it is also a journey, I guess, for companies who are some way away from this. It's hard for them to make a leap to this new world.

Sriram Narayan:

And so in the meantime, I guess it's useful to recognize that depending on the times that you are existing as a business ... I mean today it's time of rapid change and a lot of previous generation businesses are doing all they can to just protect market share and to grow it to whatever extent, and in and in those cases, probably all you can do to help the local business regions to just achieve those goals is probably going to have a more important influence on business outcomes than indirect cost savings achieved by the sort of reuse that looks good on paper but might come in the way of achieving those business outcomes in those local regions, especially in times of change like this. So I guess if it all will reach a stage where the pace of change slows down ... I doubt it, but if it is that stage, then that's probably a good time to consolidate.

Sriram Narayan:

But right now, when you're just trying to fend off competitors coming in from different ... France and so on, at that time, everything that you can do to help the local regions adopt a speedy approach, adopt a customized approach ... and then yes, not to throw all caution to the wind, but if you can use that approach of classifying, okay, these are my strategic capabilities and I'm going to prioritize a little more for responsiveness over here and these are my utility capabilities, and here I'm going to maybe plan more for reuse, or even I'll plan more for buy over build when it comes to utility. That is already a well known pattern. So I guess there are no quick fix or easy solutions, but it's just to recognize the times that we are in and to play that balancing act using some of these principles that we've just talked about.

Zhamak Dehghani:

I'm smiling when you talk about local optimization for the market fit when you're starting up. I live in Silicon Valley and we consult a lot of scale-ups, companies that started as startups and all they wanted to do is grabbing markets. So you end up with these hyperspecialized systems, or hyper diversified. So you have all these ... some main features for your offering and then lots of little tweaks that are just to satisfy a single customer. You build a different solution. For a different customer, you build a different solution. So you just lost your common base and when you get to scale ... and as you mentioned, now you change your strategy. Your strategy changes when you start up versus when you're going through that hyper growth, and then once you are a scaled organization, all those phases of your journey are different, then your strategy and your technology strategy changes.

Zhamak Dehghani:

But it's an interesting phase when you have gone ... now you've got your market share, but you've got all these little switches and little changes and hyper diversification of your product, and you come to scale and you have to support now so many snowflakes in your market, and that's actually a difficult shift as well, now to say I'm going to classify my market size segment and apply a more rational approach in terms of what capabilities I build to satisfy this segment and not support a snowflake of customers. So I guess what's interesting from what you say is that it's a journey and your strategy might change as your organization goes through different phases of growth or maturity, in a way.

Alexey Boas:

Yeah. I guess it goes back to what we were talking about balancing as well, and balancing the trade off and finding the right spot to be at the right moment. So do you have any final thoughts to share with our listeners about the price of reuse?

Sriram Narayan:

Yeah, I mean I was just thinking about a word Zhamak pointed out, and that's again a very big problem, that when you're in startup mode, you can afford to have really customized solutions for your various customer segments and so on, but then as you grow and grow and that no longer becomes viable, then yes, you are faced with a different challenge of now how do I rationalize across all of this? But my only takeaway from that is at all times ... because on one hand if you see while startups are doing that and they are funded by investor money and they're able to do that and you know that the market, the buyers are not going to worry so much about your strategy, that they are going to buy the thing that best suits their needs. So they are always probably going to buy the thing that's most tailored to their needs, and so startups are going to win.

Sriram Narayan:

They're going to be able to acquire a lot of market share by pursuing this strategy in the beginning and the incumbents cannot just stay in their existing strategy of oh, I can't mimic the startups at all because I have a large footprint, and so I cannot offer those kinds of tailored solutions. They can't do that. They lose market share if they do that. So to some extent you are reacting to conditions in the market. If you see that the startups are burning up investor money but offering highly tailored solutions, then you've got to do some of that for quite awhile. You've got to come down two notches from your highly efficient and standardized global operating way, and then when things catch up a little, that's when you can go back and forth. That's the nature of the business, and I guess the underlying principle here is at all times we let the business drivers determine these things rather than any or technical drivers. They are important but they come second and priority.

Zhamak Dehghani:

Yeah, that's right. That's a good way of summarizing it.

Alexey Boas:

Yeah, it makes a lot of sense. Well, and that brings us to the end of the episode. Thank you so much Sriram. It was a great conversation and great to have you with us. Thank you so much for joining.

Sriram Narayan:

I enjoyed it very much as well. Thank you for having me and thanks for sharing your insights as well.

Zhamak Dehghani:

Thanks Sriram. I'll make sure we put in link to your book in the show notes. Any other books coming up?

Sriram Narayan:

No, I mean right now I'm more focused on helping out clients on various things. There is probably lots of stuff to write about, but then writing a book is quite a time consuming and intensive process. So I think in the last couple of years I switched to writing articles. So if you visit a Martin Fowler's website, you might find a couple of articles that I've written. Project Over Product is a recent one that got quite a bit of attention. So I think I'll stay in that mode for a while now.

Zhamak Dehghani:

Perfect. Thank you very much. It was nice having you.

Alexey Boas:

Thank you so much. And on the next episode we will talk to Alexandre Goedert, head of technology for ºÚÁÏÃÅ Chile about evolving from cloud adoption to building a digital platform. Hope you will join us for this conversation too.