View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Courtesy of Johnson & Johnson's Ida Dunayev, below is a transcript of his speaking session on 'Architecture in the Product-Oriented Delivery Model' to Build a Thriving Enterprise that took place at Enterprise Architecture Live Virtual Conference.
Architecture in the Product-Oriented Delivery Model
To address the demands of digital business, many organizations adopt a product-centric approach to delivering solutions. This approach is based on creating cross-functional product-centric teams which have a high degree of autonomy to experiment, innovate, and iterate to continuously deliver value for the customers.
The product-centric model requires a nimble approach to architecture, in order to balance the teams’ freedom to innovate with the risks of creating redundant, overlapping, or disconnected solutions. In this session we will discuss how Architecture can provide valuable services in the product-oriented delivery model by influencing the digital business strategy, connecting strategy to execution, shaping the product portfolio, and enabling sound technology decisions to maximize value from technology investments.
Some key takeaways include:-
From Livingstone, New Jersey, we have with us either doing they have the Senior Director of Enterprise Architecture for Johnson and Johnson, either. Hello there. Great to have you with us.
It's just a it's a pleasure to be here very well. So, for, I'll do a very short bio on Ida and that. And then let her carry on with representation either is a Senior Director of Technology at Johnson and Johnson Johnson.
She leads the architecture practice at the Corporate Business Technology Group, which supports global J&J functions, such as HR, Finance, procurement, global services, and all other functions. Either has many years of experience in various architectural disciplines, including technology, Information, application, and Enterprise Architecture.
She has background in application development and integration.
She approaches Enterprise Architecture as an art and science discipline, looking for best ways to apply to apply modern technologists to solving real business problems. Either it's a real privilege to have you with us.
On behalf of the entire audience with us, over 2000 participants globally, we very much look forward to your insights.
Thank you very much, Joza, it's a, it's a pleasure to be here to share with all of you, our learnings and our our journey, through this new operating model that we recently implemented for corporate business technologist group. So.
So what I will talk about today is a little bit of background about our technology team.
I'll talk about our journey to the product centric operating model, and what role the architecture can and should play in such a model.
We'll talk a little bit about our framework and how we made it happen, and I'll, I'll talk a little bit about the strategic portion of our services, because I believe that's where we bring the greatest value.
So, let's jump into it.
So, as I just mentioned, my team, my technology team, supports all of corporate functions of Johnson and Johnson.
We support 135,000 employees.
And their needs, an HR, Finance, procurement, global services, space, as well as health care, compliance, Privacy illegal, it's a bunch of functions.
And the challenge here is that we have to serve all these groups, while maximizing the value to the business and reducing friction in delivery. We want to be as efficient as possible, and yet, we wants to deliver the value that this functions expect from IT.
So, it took us a little bit of, of a journey to evolve the way we work internally, as well as we partner with this businesses and within the IT organization.
So in 29, 19, we identified a couple of problems, I would say, challenges in how we operated and how we support at all this 12 also, business functions.
First of all, there was a lot of complexity and overlap, and how we engaged with the business.
So, not always the business stakeholders would know who to reach out to in IT, who to go to, if they have a new initiative, or they have an existing problem. It was a bit confusing for them.
Not only was it confusing for them, it was a little bit confusing for us because there were many handoffs.
From the business requirements seem to the delivery team, to the operational team, to the problem solving team, so forth and so on.
And the roles and responsibilities were not always clear.
And the other side, the effect of that was that the resources will not necessarily align the dedicated to the core business domains and products.
So, so that lack of ownership could be felt throughout the entire end to end delivery life cycle.
And naturally caused some issues, severe that The intake process, which would be disconnected.
Again, the business would go to one person to another person, and nobody had an overall view of what the demand pipeline is like because people use different touchpoints.
And this leads to difficulties prioritizing that demand when you don't have visibility to all of it. How do you even prioritize?
And the result of that was sometimes may be missing high value opportunities or having duplicate investments in various sectors.
Another kind of problem was the lack of user centricity.
So when individual business stakeholders ask for something, they look their own, only on their own air in scope.
And more often than not, the business process spans multiple solutions that spans multiple environments.
So the Amstel user experience, sometimes it's suboptimal because the, the components of the landscape is optimized just for one task and not necessarily cross a sequence of tasks.
And finally, our organization was not necessarily up to speed on some of the new technologies and some of the advanced techniques that require us to drive next generation of digital transformation.
So, the, the solve for that was a shift to the product orientation.
So, what does it mean?
Primarily, it means that we form teams, that includes both the business side and the IT side Together. Everybody sits at the same table.
And this is where those conversations start, that unpack the business needs, and ties it to the technology, potential technology solutions, and the product technology product, that we would develop to address those needs.
The key role in that kind of a model is the business product owner.
Now, this business product owner is responsible for the entire life cycle of a life cycle of a product.
From the very inception of a product, what, this product, now, we are talking product, using product language, what this product is going to deliver to the business, how is it going to come to life, how is it going to evolve, and, if necessary, how it's going to retire from zip. So, the business product owner provides the business perspective on that.
And this business product owner, partners with the technology product owner, who is the technical lead on what technologist, I needed to come together and be integrated to actually enable the business product of that, that we have in mind?
So, this is a completely different mindset, and it requires adopting a consistent product management approach, which is a discipline in and by itself.
So, we did, in fact, train, the entire corporate business technology organization on product management discipline, had a product management, one-on-one training, Everybody took the training. And. And, we also had to train our business counterparts to be with us on this journey, because if they have to take this role of business product owner. They have to know what's expected from that role. So it was quite a journey, and we're still on this journey, but I think we've had some. early success with that.
So what does it mean to move from project to product centric model? Well, there are a bunch of things that are happening here.
So, first of all, a little bit of history. So the project centric approach was really good in in helping to increase productivity of IT teams and optimize the way we work.
And the approach to that was very much focused on delivery on the very predefined outcomes that any particular solution would deliver.
It's a very deterministic approach.
You create the schedule that spans a year, year, and a half, maybe even two years, you decide what features are going to be in scope.
You bring the team together that's assigned for this period of time.
And your funding is exactly for this set of features. That's agreed, and you have a contract for in the very, very beginning.
So it's a highly deterministic approach.
The problem with the highly deterministic approach is that we're all humans. So we kinda really foresee the future very well.
That's one. And the second thing is the environment around us is constantly changing.
And we need to adapt to that change.
And we need to provide the best experience for the users who also are very attuned to getting very intuitive and very flexible and their requirements change over time, as well.
So to solve for this uncertainty, we need a more collaborative experiment, the best, the lawn based approach, to drive this innovation, to drive this flexibility.
And that leads us to the product centric model, where that is not necessarily finite and date.
The working software, even though it may have limited set of features, is considered that product, right. So we're all familiar now with beta perpetual beta that we experienced with Google and other technology companies. It's working, it's, it's good, so let's improve it from there.
Having some sort of a vision for where this product is going, still is needed.
The team stays together after each release, so we don't disperse them, we keep them together for the duration of, for the life, time of the product, and the funding is interesting, right?
So we are located annually and we use it according to the direction of this business, product, owner, and the technical product owner to decide what features, what, what should be included in the next day lease so that we achieve the best benefits for the business in next. In the next iteration.
Quite a bit of my mindset change and the biggest changes. So when you move this deterministic approach right now, all of a sudden, you don't know exactly what's going to be delivered when.
And it requires a little bit of letting go and trusting the team and trusting that the business product owner to drive this evolution.
So that creates tremendous challenges for architecture as you can imagine. Right. So all of a sudden, we shift focus to this.
atala must self directed persistent teams who work on a bunch of products.
They prioritize a child product and platform delivery of aid, the hardness innovation.
They do quick iterative decision making there on their own.
They focus on user experience and they have deep, technical and subject matter expertise.
Now, what does it mean for architecture?
Who wants to make sure that we actually have a wholistic product portfolio that is, uh, and I'll pass some logic to itself and there's the Lines of Business and Technology strategists as a set as a portfolio, not just a bunch of individual elements.
How do we make sure that we don't have overlapping products since everybody's working on that little piece?
How do we make sure that we make the best use of existing technologists and that we actually do bring the innovation into the organization?
How do we make sure that we don't create new technical debt? Because all this teams, they might be taking some shortcuts. They might be going for some quick wins and just doing.
Yeah, now maybe some quick, quick fixes somewhere.
And how do we understand the impact of change? If something changes in one product, how do we understand how it may propagate to the rest of our environment?
So all this questions are key for architecture to address. This is why I think the role of architecture is extremely important in this product centric model.
Because we are the organization that looks across individual products, and across individual product teams.
So how is that organized?
So, it's a little bit of a busy slide, but I'm going to try and walk you through it.
So, on the left, you have this business business centric domains, where we said we want to align our delivery model to the business.
So, the functional domain is aligned with the business function.
So, we have an HR team, finance procurement, so forth, and so on.
Within each one of these functional domains, that is a school odd, this is a product centric team that is focused on delivering a particular product or for their customers. So, each domain, we have multiple squads working on multiple on-site audits and several products for that particular domain.
Now, in order to up promote the specialty that all specific expertise across Squad's, we have this concept of a chapter where product owners, business analysts. People in a specific role come together to share best practices across Squads.
But the key portion of this slide here is Architecture.
It's a group that looks across everything. We look across domains. We look across Squads, we look across Chapters.
So make sure that the portfolio of products is actually aligned to the overall strategy.
We called the functional domains, develop their technology roadmaps across products.
Regards technology solution architecture on key initiatives That's within the vendor. Squats, that's for the products. And we also look after the cross domain data and integration strategy.
We partner very closely with the strategy and an operational team, which looks after the financials of this portfolio.
So we want want want to make sure that when we do the portfolio review investment reviews, that those investments actually aligned if the domain technology strategy and we actually invest into the products in alignment with those strategists.
So, um, so, the, the portfolio file services then includes both the strategic component where we look after the set of products, as well less services for individual product, one product at a time. Solution architecture, you might call it.
So on the left-hand side in the left column here. You see our strategic content, This business capability, landscapes, roadmaps, technology strategies. These are the services we provide on the strategic level.
Moving towards the right side of the slide, discovery and innovation, product, platform, and solution guidance.
This is where we step in, and we help individual product teams to explore that problem, To identify what technologies are needed to evaluate technology options, to define what solution should look like, and then integrate everything with everything that we provide guidance on that as well.
And finally, one of our services is to educate the organization of what's happening in the industry, to provide an external point of view, so that we really take advantage of what's, what, innovation, that happens outside of Johnson Johnson: perhaps under then? Johnson and Johnson, as well.
So, I would like to spend a couple of minutes now, on this strategic aspects of our services.
We spoke a little bit, just a little bit about how we provide solution architecture services to the squad's.
But I think that discipline is, is well defined, and people usually know how to do it.
The strategic part is, I think, less appreciated than less understood, so I would like to spend a little bit of time on this.
So, our organization, Corporate Business Technology, is a technology group that supports all those corporate functions.
What questions do we want to be able to answer, And then, how architecture can help answer those questions. This is how we position ourselves as a value add organization, to corporate and business technology group.
Our organization needs to understand, how can we become trusted business partners? What is our business model? What are the business priorities?
What business capabilities our business partners see as differentiating? Where do they want to invest?
And in order to enable those business strategists, what technology should be invested? So, what should about technology roadmap, multi-year technology roadmap to the market? What are the macro trends, and industry and technologies?
Which technologies are important and relevant to enable those differentiating capabilities that the business has in mind?
And then, finally, as we talked about product centric approach to our delivery, what does our portfolio composition, product portfolio composition? Is? It really aligns to everything we said we want to do?
I've investing the money and talent at the right place.
Do we have opportunities for perhaps cost optimization, but we have too many products, perhaps, that nobody's using?
So, so the framework that we adopted to enable us answer those questions is, is actually based on that business capability model. And I think one of the presentations earlier this morning was, was dedicated to that concept.
So on the top, you see that, that same questions that we just discussed in a previous slide. Business strategy to Technology strategist, the product and platform portfolio.
And what underpins it is what ties it all together, is the business capability model, and then the product catalog and the associated roadmaps and finally, technology, platforms, and capabilities.
So let's dive into a business capability model.
And this is truly a cornerstone of connecting business and IT, and it's a proven method.
We didn't invent that, but it's a proven method that really, was, implement that successfully here.
I'm proud that we got quite a bit of traction with our business counterparts in applying this model and using it to generate the, the Technology and Business Roadmaps.
So, it does connect the business strategists to business and IT portfolio planning to product and domain roadmaps to operational use and rationalization opportunities and whitespace opportunities, all of those things.
Because we can express the business strategists by identifying which capabilities need to be developed, then we assess which of those capabilities are priority to the business.
So the maturity assessment is important here to kind of color this, this framework in the priorities color, which ones are more important, which ones are less important for the business.
And that we can look at the business portfolio through that lens, and see what the business is planning to do to advance those capabilities.
And then what does it mean to technology? Landscape of the business highlights a certain area.
Say totally what's, this is how we compensate them and engage our employees.
If the business says this is the prime priority for us, this is the primary area for us.
Then we can look at the portfolio of products, technologist's solutions that we have today that support that area and see, do we have overlaps today That we have maybe too many products that are not connected to one Another do become antiquated products.
Either rationalization opportunities or maybe that is a whitespace opportunity.
Maybe we have some products, but none of them are good enough, and maybe we should go and search for a barrel, want to develop a better 1, 2, 2, to meet the business needs that are apparently not being met today.
So, we apply this approach to develop the domain technology roadmaps. Right. So, so that we inform where, where the technology group should invest and why and how.
We adopted this five step process.
that starts with the business capability model so we develop the business capability model or we adopt the one that business have with their habit if they don't have it.
We help them develop one or adopt an industry standard one for each one of those corporate functions that we just looked at.
And then we map our existing products against that model. That's step number two, and we produce as this product landscapes.
The color coding here reflects the time disposition of this products tolerate, invest, migrate, eliminate, like, what is the status, how, how, how well are they feeling, what these products are supposed to do, and what does their technology maturity level? I be dependent on outdated platforms, and that needs to be refreshed, that needs to be eliminated. So that's that, the depiction of our as its environment.
And then we do this capability maturity assessment with the business, and we ask them, well, which of these areas are most important to you?
Right, then I use this total rewards example before the way we compensate our employees, the way we plan compensation, numbers, and things like that, right, and the business. What the, the darker color coding indicates here that, yeah, it's very important for the business.
They wants to become, perhaps industry, you lead us in this particular capability.
So what do we need to do to help them get that right? So we will now depict the to be product landscape. What should the environment look like, if we want to really advance this particular capability for the business?
So we painted it to be product landscape.
And in order to get there, now we have to divide the set of initiatives, set of activities. And some of this may be not, they want to acknowledge it through, and maybe some business process needs to.
Change, may be some organization, needs to change, but we don't really impact those areas. But we look at it from the technology perspective.
And they say, What an initiative on the technology front?
Do we need to activate?
in order to get from where we are today, As is step two, to step forward to where we want to be, in alignment with what business really wants to achieve, is alignment and this heat map.
So last year, we was successful at implementing all this five steps for most of our functions, and we are planning to refresh this views this year.
So that this, this information always becomes available and becomes up to date.
And the important piece here is that now we're starting to bring this technology roadmaps to the investment conversations.
In the portfolio reviews, this is when, really, it becomes impactful. When this, this, this deliverables, this artifacts of, although that they're being used by the business, as a, as a background for many conversations, like: where the money goes, what applications we have, how manian why, and so forth, and so on.
But now, it becomes the basis of actually discussing the investments and why certain investments need to be made in certain areas, and looping it back to where the business needs are, and the business capability heat maps.
So now, we're starting to get traction with actually making decisions, based on this work.
So another supporting asset for us, which is also very important, asset that we architecture group helps to curate, is the product catalog. So you would think, Well, what's, what's the big deal about the product catalog, It? just, you know, list all the products. It turns out that there is a lot of interpretation of what constitutes a product.
And somebody who sits outside of the product, teams meet to help with the definition so that we have a consistent degree of granularity and meaning across all areas, right?
So if somebody, if one team calls that website a product, now let's make sure that that website has enough substance behind it, and it has the roadmap.
And it has a vision, and it has a product owner, so that it qualifies as a stand alone product, rather than being just a web page, and maybe potentially a component of another product.
So this turned out not to be a trivial task, and acquired a lot of conversation with the conversations, with the, the domain leads and the product lists, product teams.
But I'm, I'm proud to say that we achieved this consistent definition and we are driving valid this consistent representation of this product information across various ICD positives.
Right, so we capture the product information then CMDB in our ....
We now capture it in our portfolio tools, the investment portfolio tools, landscape views and roadmaps, as you saw in the previous slide, so it's very important to get this data right, because the entire delivery model is dependent on it.
And similarly to business capabilities, the product catalog is the lynchpin connecting, now, the Business Strategist, Portfolio Planning, and all those things into the actual implementation.
This is where all the strategists and all this good stuff gets actually realized through the products.
So, um, so what are some of the takeaways, like, what are the lessons learned, and?
What can we offer as a as best practice to other teams?
Well, the services that we provide, how do we make sure that they create value for stakeholders?
It is important to tailor the service offerings to the stakeholder needs.
For example, our leadership team, our corporate business technology leadership team, the latest who lead the development and delivery for each one of those domains, they're our stakeholders.
So the IT leaders usually wants to see the strategic directions and the roadmaps, They say, What's, what's around the corner for my, for HR? Domain, What's around the corner for Finance? How will this environment look like in one year, one, and a half years from now?
So that, our stakeholders.
So we help them by articulating and crafting those roadmaps together in the business and address their needs. That's that way.
Now, when we shift focus to product owners and delivery teams, while they are delivering a discrete products, they are discrete solution. So they need guidance on the solution architecture.
They need help understanding what, what solutions, what products. What platforms exist in the marketplace?
Where are they industry's going? Should they buy?
Should they build if they buy, how they integrate everything to everything, if they, if they build, what should be the main components of that solution.
So the product illness and delivery teams really benefit from solution architecture services.
So what we tried to do here, with our group, is, we tried to balance the two services and provide both, and sometimes, it's not an easy balance to achieve, because everybody will have different priorities and they will have different needs, But that's the, this the Catalog of Services, includes both.
Now, we talked a little bit about the role of architecture in a product oriented flow of work.
So what does that take away here?
Well, as we discussed, if, if the product teams are left to themselves, they will be very, very successful and very efficient in producing a bunch of products.
Now, the role of packets, actually, is to make sure that, that bunch of products actually is a self contained thing.
And it's, it has its own, um, internal logic for why this products does exist, and how they're connected to one another.
So a coherent set of products, a coherent set of portfolio is, is of importance.
And this is what this is the value of pocket secretaries to look at products across different boundaries, and making sure that each individual products and it's roadmap, and why it goes, is actually aligned.
There's the overall technology strategy, and why is that important.
It's important because the products don't really exist in and by itself.
A product has to talk to other products, It has to be part of a business process that they support.
There is no one product that really supports and still, and process for everyone and everything. So, so it's still part each product is part of an ecosystem.
And what architecture does, it provides the context and the line of sight across this entire ecosystem, and guides each individual product, evolution in such a way that the portfolio is coherent.
All right, so the next thing is, OK, so we talked about all this things. Business strategists, IT strategist, product portfolio investment portfolios.
So so the value add, the fact gets, actually, is to be able to connect all this multiple perspectives, and to provide that line of sight across all this dimensions.
And the way we did it was through business capabilities, center centric approach, to developing strategies for connecting business and IT. Again, a proven approach.
Not the brand new thing, but works really, really well.
If we engage the business and make them the stewards of the smalls, right? So, it's not our model, It's their model.
We're just there to help them articulate and capture it, but it's for them.
And, and, and it's there, product. And they connect it to the outcomes that they want to achieve.
So, that's that partnership with the business on joint ownership of the capability model itself, is important.
So, how can we trust and avoid an ivory tower? Reputation? And architecture is always perceived as someone who is sitting in the corner and Ross Vedic period diagrams that nobody really needs or wants.
Well, credibility and trust is earned by solving real problems.
So, architects are not shy of jumping into the solution with solution teams, with product teams, and help them help them solve real problems, and they, that way, they gain the respect, credibility, and trust.
On the most strategic front, you know, we said IT leaders. They want the strategies. They want the roadmaps that well. They want all this stuff.
So, so we establish shared goals and objectives with them.
So, if, if a domain lead wants a roadmap for their specific domain, we say, OK, so let's make that joined goal. So, it's not the architecture doing that, but we're doing it together.
In order to get there, we're gonna try and implement those five steps that we just talked about, and now the only zone that domain leads to actually make sure that the teams, they're teams actually collaborate and work with us, to develop those artifacts that inform the strategy, right? All of a sudden, it's not the architecture problem anymore.
It's a joint problem, and it's a joint gold and joint objectives.
And now, all of a sudden, we look at common metrics and now we monitor progress together.
We asked, Where are we up from this five steps way, which domain is where we, who has completed Step torquil, completed step three. And, again, it's not just the architecture goal, we don't do it for architecture. We do it together, right?
So, this upfront agreement and the contract, if you will, on the goals and objectives of not only what will be achieved, but how it will be achieved Goes a long way.
To get an engagement from the teams to actually produce those deliverables.
Now, because we our, our services portfolio. So broad them, there are so many things that we can do.
It's very important to have explicit prioritization framework.
So regular backlog reviews, regular priority reviews with the key stakeholders at key to explicitly prioritize our work.
So what we do so architects, architects are aligned by domain.
So we have an architect who supports, let's say, HR and finance, and another gift that supports Saudi HR payroll. Another CapEx support finance and another one supports procurement.
So floats off so that that get the Act establishes a regular cadence of meeting with the head of HR domain.
And they review the backlog of this HR archetypes and they say, what are the top three priorities for for that object theft on a quarterly basis to focus on?
We tried to keep it to top three. It doesn't always happen that way.
But there is an explicit review and the main stakeholder, the domain leith.
They know at all times what the architect is working on, because they agreed on it, and they explicitly define those priorities.
So another thing is to be able to articulate the scope of our services, so we can manage expectations and be realistic about what we can and cannot deliver.
For example, when we say, we're going to provide solution architecture services, because we have so many products, it's unrealistic to expect that we're going to play in each and every product Delivery cycle, right?
So, we say, well, because we're a small team, we're gonna maybe participate in top three or top five or top, top several key initiatives, key products for the organization, and how do we define those top three or top five? Well, through those backlog reviews, if you will, through the explicit prioritization with the stakeholders, we define what the initiatives are most important. We make sure that it's an architect overseeing, or helping to design that solution.
And then finally, to stay relevant, to stay as thought leaders in the organization, and to have that credibility.
We, we have to keep up, keep up to speed with industry trends, you know, participating and contributing to confidence, as such, as this one, we bring knowledge back to the organization, and I'll continue to earn a reputation of a technology expert.
So, this concludes this presentation. I thank you very much for listening.
Hope you found that helpful, and I guess I'll invite Joseph back to to run the Q and A session.
Fantastic presentation, either what a wonderful presentation, thank you so much for, for the breadth and the depth that you have share with us.
The incredible process, I hope that everyone is paying close attention to all the amazing sites that you have shared with us today. Based on the questions that we have received. They are, they are, and so I'll just pick a few here to get us started. So, the first one comes from ... and ...
asks, How did you handle or accommodate emperor, thighs? What he calls technology, that driven changes that may be no vetted to realize maybe more foundational things versus business capability driven things that that really have value creation associated with them.
How do you strike that balance between maybe, the more strategic and intangible and the very tactical value creation things.
This is a wonderful question and it's not either or. Write that and we have to do both. So how do we do both?
So, first, it's, ah, it's increasing visibility of the technical debt. First, make it visible, will make it known and how to make it known. Well, we use the time free worked, tolerate, invest, migrate, the lemonade assignments for, for each product.
We know we defined what what category, what life cycle category of this particular product falls into.
And then, we look at our portfolio and look at this, the composition of their portfolio, to say, OK, it looks like, I don't know, I'm gonna make this up, by the way, So, that's not true numbers.
But maybe we'll say, Well, it looks like 30% of our portfolio, perhaps, in very tight state, it means we are carrying this burden.
These are the applications that we said we want to retire, that maybe they're dependent on outdated technologies or what have you.
So, how much does it cost us to cater to that tail and make it make it visible?
Make it real, and bring it in front of the investment communities, and say, so, it cost us this much.
You will have to refresh this. You'll have to upgrade this technologists. We have to run on VMs.
Current versions, it's gonna cost you this much.
So we have to make a decision. Do we keep running those things?
And keep investing Adobe, retire. Some of them invest through the pie and move into another product. Right.
So the first thing I would step, knowing what the technical debt is it that's by itself, is not a trivial question to answer. So we work with our technology services parts. So we have a technology infrastructure organization.
Who hasn't closed societies? Interdependency of what product depends on what platforms isn't the databases? And I'm operating systems That's out of date, or what have you, They create reports, and they tell us, your disproportion of your products Depends on this, outdated technologists. Then we make it visible to our organization.
And we say, well, it looks like this set of products needs to be the upgraded ..., And then, and then it's a decision where to invest. And it's that is not perfect fence sites, but the decision has to be an informed decision.
With all this data at the table, so what architecture does we make it visible?
We make a tangible, and we, we inform the decisions, right? Then, we might have an opinion.
We might say, Look, This entire portion of a of a landscape portion of a portfolio relies a lot. On five, You should really get rid of it and invest, but then it's the decision of when, and how to put this on the roadmap, and make it part of the strategy.
Excellent. Pamela Bishop has been asking a number of good questions. I'm going to pick one from her right now. And Pamela asks, product managers can view business architecture as a redundant function that does similar things that, you know, like value streams, roadmaps, and things that they may be doing within the business or function already.
So, the question is, what approach would you take to foster engagement between business architecture with your product organization?
Yeah, great, great question.
So I would say across all 12 or so business functions, the degree to which business architecture exists in some or doesn't exist in others vanish. Right?
So, we don't really have a uniform way to say, we have business architecture everywhere and it's a maturity level X, right?
So depending on the function from function to function, we may have a different degree of maturity. And even organizationally, it might look differently. Right. In one function, for example, we may have an official business architecture group sitting within the business.
And if that's the case, we are more than happy to partner with them and say, OK, show us your business capability model. Now. we are more than happy to accept yours. We don't want ours. We don't want to create new one if you already have one.
So let's work together. Let's see if it makes sense. Maybe with ..., maybe we might be with just adopted.
So in the areas where this business architecture exists, we are more than happy to partner with them and make them our extend that arm if you will.
In some areas, some of our functions are not that advanced, and they have no business architecture to speak off, and they not necessarily have a function or resources to do that.
So, we partner with them, Then we show our approach, We show a frame framework, and say, look, this other function actually did adopt this method. Then they have the business architecture and look at our successful.
So, we use some of this example, S, as best practice example, to motivate the others who may not have it to go the same route, But it's a collaborative approach, right? So, if somebody does not have it, we help them create it.
If somebody has it, we are not proud. We are more than happy to take one Bake-off portion of it down, and advanced that way, Right. So, I wouldn't say it's a novel upward dundon because we would not create something that conflicts are redundant. There's something that exists, we embrace it.
And we are more than happy actually one that exists. Right, because our group is very, very small.
And we don't really have a dedicated business architect, that dedicated application. OK, I don't have those dedicated roles.
So we have one architect who covers, say, an entire tribe, payroll domain.
Top to bottom, you'll name business technology information.
Architecture solution architecture.
And then if HR happens to have a business architecture, I'm more than happy to take what they've got.
Know, I appreciate that answer either because it's contextual, it's practical. It's insightful. A lot of times people get into this I that idealized notions on how things should operate right and and what are you providing? He is a real-world perspective that, especially if they're large businesses, that, you have to take the context into account, And, in some areas, are going to be very hands-on. Other areas. You're gonna be more of a partner support. Whatever they're doing. That's really great insight. Falling up one more question from Pamela Juju: Have specialized business architecture roles, or did you make a decision to train your existing technology architects and business architecture?
Millimeter meter. Now, great question. So, our architects and our team, they, they wear many hats, right?
So the short answer is, no, they we don't have dedicated business architects, But the other side of the question is, no, we don't have to acknowledge architects either, right? So this what we call what we call domain architects.
They, why are this multiple hats, as we just discussed.
And depending on where the corresponding domain is, they may need to, to do a little bit of business architecture. They may require a little bit of training, but most of them have the basics.
Most of them come from either enterprise architecture background, or solution architecture background, but have the understanding, the notion of how two of the different layers of architecture. They have a pretty fluent in each one of this architecture domains, if you will.
So, so, no, we don't have that separation, and yes, they wear multiple hats, and they have to be flexible in what particular, um, that's what they're working on at any given moment, but I think this five step framework that we put forward, it elevates the importance of business architecture, right? So we didn't even use this term a lot, right? We say business capabilities, look, remodel your business, we help you articulate with your business strategy is in terms of the capabilities that you want to invest into. So we kinda indirectly promoted the notion of Business Architecture. We never actually even necessarily use that term, but it's day, it's embedded in the in the model.
And Josie, I just wanted to comment on what you just said about being flexible with the business partners.
That's, that's a great observation, because last year, we did put this five step model for represent.
Everybody goes through this five steps and let's, let's just do it, and the learning from that was that, well, we cannot really force everybody to march at the same pace that those five steps, right.
So, so we were able to achieve the end of five steps, with some functions and some functions with just, they were just starting to embrace the capability model itself.
They just started drawing those diagrams that you started.
Think about that because their business isn't that in those ways.
And they are still a little bit, you know, behind on this journey, but it's, it. And the learning this, this, yeah, yeah. We have to be flexible. We have to be considered considerate of where people are and adopt.
Very, very good. one more final question here. I have time to wrap up with one from ..., who leads enterprise technology architecture in Brazil.
So, another global perspective here, and that, and his question is, How do you do, I mean, Johnson Johnson, Of course, a global company operates in Brazil, as a matter of fact.
And that, and the question becomes, how do you deal with high demand technology costs, that there exists, and then, yes, and then the constraints of budgets right that you have, and what do you think is the best approach for the, for an investment technology strategy? Especially in times of uncertainty and rapid change that we're undergoing right now? Do you have any tips on approaching investments in technology, you know, if constraints budget constraints there, and the high cost of technology implementation?
Yeah, it's, it's a great question.
We are well aware of the regional implications on the cost of what it costs in the region to roll out some global programs. So, so we take the little bit, kinda.
How should I say it, the flexible approach to that, Right?
So uncertain platforms, The way we decided we're going to have a global solution for all of Johnson and Johnson, that just goes without saying, Our HR platform is global. Workday is being rolled out everywhere.
And yes, the regents have to somehow, I guess live with that. And we try. I think the central group tries to help did.
he just actually implement the global platform, because the benefits globally outweighed any kind of complexity, is awk or cost implications in the region. So that's being sold. That investment is being sold on a global level rights, or some for big, global platforms.
For some of the smallest solutions, I think it's, it's important to be conscious of the, of the regional budget constraints on ..., Regional investment strategist. So, so, we have to wait and see what makes sense, Right? So, so, we do have, regional teams will have regional products. We'll have regional solutions.
And there is a portfolio of those ripe. And we need to make sure that the benefits of having a local solution outwards.
The benefit of having something centralized, so how to go about it while cost versus benefits analysis, I guess, those those usual techniques that help. And also, looking at, again, a product portfolio. Do we have all ready products in our portfolio that can do 90% or 80% of what you guys need in the region?
If we don't have it all tax implicate tax, tax applications in Brazil, they're going to, I think, be gonna stay forever and it's a pretty diverse portfolio. Right, because the requirements are so unique, that is, no global solution, potentially, for that, right, not yet, venues.
So, if the benefits are there, the needs of the ad and then it will be a regional solution funded Accordingly. Right?
If, if we have something global and it's, it's of benefit to the whole organization than than when we need to throw out something global. So there is no direct answer.
Again, I think the key is visibility and cost and benefit analysis and understanding the entire landscape.
Either what a terrific presentation. Grading sites are so privileged to have you with us, with over 2000 global participants learning from you, an expert in the field. It's, it's been a real honor to have you, so thank you for sharing your insights today.
My pleasure, because I've type it to be here. Thank you everyone.
Thank you, ladies and gentlemen.
Other than I have, from Johnson and Johnson, Incredible insights, go back, look at the presentation, and immerse yourself into a very, Is structured approach to Enterprise Architecture and successful Enterprise Architecture. So thank you for sharing that either, and on behalf of, of the organization. And we're gonna wrap up today's day one of Enterprise Architecture Live, with a different type of session. We're going to welcome at the top of the Hour Business Transformation Leader from UNICEF. And the end of the ***** is going to talk to us about Enterprise Architecture and the power of storytelling.
Ah, this is a bit of a unique topic on how are, can we become better communicators about the very complex items that we deal with? And communicate them simply to others? And communicated them? Communicate with persuasion. Communicate with a vote towards engagement with the audience that we have. So Enterprise Architecture and the Power of Storytelling and those same month, Business Transformation liter at UNICEF will guide us for that at the top of the hour. I'll see you back soon.
Senior Director, Enterprise Architecture,
Johnson & Johnson.
Ida Dunayev is a Senior Director of Information Technology at Johnson and Johnson. Ida leads an Architecture team for Corporate Technologies group, shaping technology strategies and designing solutions for Finance, Human Resources, Procurement, Global Services, and other corporate business functions.
Ida has been practicing the architecture discipline for over 20 years. She enjoys this field because, just like architecture for physical structures, the IT architecture requires a balance of art and science to create solutions that are practical, elegant, and can withstand changing environmental conditions.
Prior to joining JNJ, Ida worked for other Pharmaceutical companies, such as Roche, Pfizer/Zoetis and Allergan. She helped to select, design, and connect software solutions supporting the compounds ’journey from the research labs through clinical development and manufacturing to the market. Ida has background in software development, system architecture, data management, and integration.
Ida has a MS in Electrical Engineering from St. Petersburg Polytechnic University in St. Petersburg and holds Architecture Certifications from The Open Group and The British Computer Society.
Search for anything
October 28, 20211
1:00 PM - 2:00 PM ET
November 9, 2021
11:00 AM - 12:00 PM ET
January 13, 2022
1:00 PM - 2:00 PM ET
January 27, 2022
1:00 PM - 2:00 PM ET
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Watch On-Demand Recording - Access all sessions from progressive thought leaders free of charge from our industry leading virtual conferences.Watch On-Demand Recordings For Free
Courtesy of DC Government's Ernest Chrappah, below is a transcript of his speaking session on 'Going Digital To Enhance The Customer Experience' to ...
Courtesy of 's Anu Senan, below is a transcript of his speaking session on '' to Build a Thriving Enterprise that took place at Enterprise ...
Courtesy of Tasktop's Dr. Mik Kersten, below is a transcript of his speaking session on 'Project to Product: Driving Digital Transformation Insights ...
Courtesy of Nintex Pty's Paul Hsu, below is a transcript of his speaking session on 'Improve employee productivity during and post-COVID by ...
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events