Foundational Architecture to Support Your Content Supply Chain

Transcript

Hello, good morning, good afternoon, or good evening.

Thank you for joining today’s session.

As people walk in just want to introduce that today’s session will be focused on foundational architecture needed to support your content supply chain, and it will be led by Will Brisbane.

So yeah, just want to do a quick introduction of myself. My name is Letty McClure. I’m a senior business strategist here at Adobe with the Ultimate Success Team. I’m going to be your host and moderator for today’s session.

I do want to note that this session is being recorded and a link to the recording along with this presentation will be sent out to everyone after the session.

This live webinar is a listen only format, but do please feel free to share any questions in the Q&A pod. Our team will answer as many questions as possible during the presentation. And if there are, if there is time remaining at the end of the session, we can discuss any remaining questions that may not have been answered.

Okay.

While we wait for the attendees, more attendees to filter in, I do want to let you know that today’s session will be followed by four additional sessions that break down the value realization framework, followed by additional sessions, framework pillar by pillar, sorry, focused on content supply chain use cases.

Links to the sessions will be pasted into the meeting chat here shortly, but I did want to just highlight for the February 4th, we will be up, we’ll be on an operating model design session covered by Bernice Plunk. The February 6th session will then be covered by Kaylee Turnwald, who will cover how to establish executive sponsorship. And then we’ll finally wrap up the series with the Dev Tatik, who will discuss change management.

And let me go ahead and copy and paste those links so that you can have a chance to review them.

Again, these are pasted in the chat.

Let me just check the attendance.

Looks like we have a good size. Again, thank you again for joining today’s session. I will be your moderator, Letty McClure. And again, today’s session will be focused on foundational architecture needed to support your content supply chain.

Will, who will be presenting the session is our principal customer success architect out of Ohio and has been with us for four years.

Will, I will turn this over to you and hand you the microphone.

Welcome Will, take it away.

Hey, Letty. So we’re here to talk about the foundational architecture needed to enable the content supply chain vision.

But before we dive into that, I’m going to go off camera so you can focus on the content instead of my face. I do want to set some context as to why we’re having this session in the first place and why we’re doing this series of webinars.

A few years ago, we here at Adobe interviewed 100 executives with the goal of identifying the most common barriers to realizing value, particularly with AEP, Adobe Experience Platform. Then we took those insights and they became the foundation for the value realization framework we use today.

That framework is a cross-functional programmatic approach to guide customers onto the path to value and ensuring that strategic planning occurs, is activated upon and is measured across all these pillars.

The five pillars of this framework are roadmap to value, technology, resource investment, sponsorship and org readiness.

And each pillar in the framework represents a critical theme tied to delivering value. And we found that the absence of strategic planning within any one of them is often the root cause of failure. Each session in this mini-series will highlight one pillar from that framework and share key artifacts to support strategic planning and accelerate value realization within your organizations.

For today’s session, we will be focusing on the technology pillar and the key artifact related to this pillar is the North Star architecture.

This artifact, we found, is the best way to ensure that strategic planning occurs, it can be activated on and is measured within the technology pillar. So we’ll be talking about the foundational architecture needed to support your content supply chain, but we’re going to be doing that through the lens of the value realization framework and talking about the North Star architecture artifact as a tool for ensuring that we realize value from our technology through this strategic planning.

So with that context in mind, our agenda today will start with some discussion around what I even mean when I say foundational architecture. From there, we’ll talk about the key artifact from that technology pillar, the North Star architecture, what it is, why it’s valuable, how do we create one, how do we use it, and we’ll do all this through the lens of content supply chain.

So let’s talk foundational architecture for content supply chain.

What does that even mean? If you’re coming from an AEM perspective, you may immediately think of the traditional instance-based architecture with the relationship between an author, a publish, a dispatcher, and a CDN. But foundational architecture often goes beyond just the infrastructure. It often includes how content is modeled and delivered and governed and how that all evolves over time.

That means decisions around content hierarchy in sites and assets or headless versus headful delivery models and how those underlying building blocks of templates and components and metadata schemas and workflows and governance models all kind of shape how the teams actually work as part of a foundational architecture.

From a work front architecture perspective, you might immediately think about workflow automation or data structures and layouts and statuses. But foundational architecture and work front can also be about how work is modeled and how it’s routed and measured and also governed. So that includes decisions around things like custom forms and fields and how all that data rolls up into reporting and how request queues are designed and how groups and teams and portfolios are structured and ultimately how all that is governed at scale. Again, foundational architecture.

This is before you even account for integrations, not just between work front and creative cloud or AEM, but with the broader enterprise systems.

Then there’s the fact that foundational architecture can also mean very different things depending on your vertical or your organizational structure.

Retail has very different needs from medical or financial.

Your organizational structure, whether work is handled all in-house or through agencies or some combination of both, elements like governance and data retention and data flow and even which systems are involved and how they can connect can differ pretty dramatically based on those realities and the use cases they support. So when we talk about the foundational architecture required to enable and optimize content supply chain, the real challenge isn’t defining a universal checklist. It’s answering a different set of questions. How does content actually flow through your organization from a technology perspective? How is that flow documented and planned for and then executed against and then measured? And how do you know whether it’s working? What’s foundational for one organization isn’t necessarily foundational for another.

And that’s why when Adobe talks about the technology pillar of the value framework in the context of strategic planning and execution and measurement, the answer to those questions is the North Star architecture.

So that brings us to the question, what is a North Star architecture? I’m going to sidestep that question for another second and first look at a few examples of what this can look like. This is a generic example, obviously, but we have the content supply chain piece up at the top with some AI image generation starting in Firefly and falling into both Express and Creative Cloud with content and data moving into AEM and Workfront as well and some connectivity between the two. And then it kind of all feeds down into the personalization and activation layer. And then we have some web data coming in from the left, getting populated into analytics and moving into platform and getting pushed into Marketo and HEO and Target as well. So that’s one example.

Here’s an example of one that’s a little more content supply chain focused.

And realistically, if you look, it’s not too much different from just zooming in on this section, which is an important part of the North Star architecture. But we’ll get to that in a moment. But here in this one, we have up here in Workfront, work is being requested and scoped and prioritized and creative production happens in the Creative Cloud with those assets getting pushed into Workfront. And there we have reviews, approvals and workflow orchestration all managed in Workfront.

Workfront integrations with AEM via Fusion and with the Native Connector, with the Native Connector pushing these assets into AEM assets.

There, those approved assets are stored and versioned and governed and the integration with Express and Firefly expressed in a little different way.

Again, we’ll talk about how North Star architectures can have differences.

But then those assets are curated and shared through Content Hub for agency use. And then content is also assembled down in sites and delivered via web and mobile experiences.

So, in another example, this one is much less generic. You’ll see some explicit call outs to non-Adobe systems and real integrations, including connections outside the Adobe Stack. And while this example doesn’t emphasize or even strongly feature content supply chain, as AEM is all by itself over there on the right, I think this really illustrates my next point nicely, which is the North Star architecture depends on you. It depends on your organization, your audiences, your vertical, your use cases, your maturity, and in a really big way, your goals.

So, what is a North Star architecture? We are not talking about a static diagram or a one-time design exercise. We’re talking about a way to answer a few core questions. What’s foundational for us? Where do we need to start? And where are we trying to go? At a basic level, a North Star architecture represents an ideal future state view of your marketing technology solutions and how they are all intended to connect to support your current and planned use cases.

So, when Adobe talks about North Star architecture, we’re talking about it in the context of a technology pillar of the value framework, and it’s intentionally strategic and high-level, and it’s intended to be driven by use cases.

The goal isn’t to document every implementation detail, but more create alignment between the business and the technical teams around where your platform is headed. So, we think of the North Star architecture as a way to translate those business goals and those KBOs and those priority use cases into a more clear technical direction using a format that both business and technical stakeholders can actually understand and work from.

Because at the end of the day, the goal of a North Star architecture is shared clarity. It gives teams a common reference point for planning and execution and measurement while still allowing all those underlying systems and implementations to evolve over time.

Looking at those North Star architecture examples, you didn’t see any port numbers or IPs or even full system architecture. It’s intended to be a high-level view of data and process flow between solutions and systems that allow us to zoom in on key sections that would enable use cases, like we did earlier with the content supply chain, part of a broader system. But we can zoom in on those use cases, and then we can prioritize those use cases. And then use that to kind of guide our plans.

Speaking of use cases, if you didn’t attend my colleague Yuen’s session on use case roadmaps for content supply chain, I highly recommend you check out the video. That link will be shared in the chat as well.

And a few things we do like to think about when we’re helping our customers with their use cases and strategic planning around their technology.

Some of the key points are North Star architectures are about the future state. Where are we going? What are we trying to accomplish? And this doesn’t mean it’s not worthwhile to also draw up an architecture based on your current state. You absolutely have to. You have to know where you are to know how to get to where you’re going. So that is the only way you’ll be able to identify the gaps you might have. But this also doesn’t mean that you have to design your North Star architecture with every possible future use case in mind. I’ve seen many customers try to do so and design every possible use case in future product enhancements and it paralyzes them. So North Star architectures should be limited in scope. So don’t try to architect design every possible use case that you might want to implement.

But focus on the highest value. What’s most urgent? What are the high priority pressing use cases? Because North Star architectures are intended to be living, breathing documents.

Several times I’ve walked into clients that haven’t updated their architecture since they initially bought their tools or if they even have an architecture at all.

They are intended to be updated regularly so we recommend reevaluating every time you reprioritize your use cases. Reassess where you’re at technology wise to support those. Think about your priority use cases. Think about your business goals, your emerging challenges, what new opportunities or product features and the progress you’ve made towards your milestones and your goals. Having that kind of flexibility ensures that the North Star architecture remains relevant and actionable throughout your life cycle. So whatever cadence you’re using, whatever process you use, make sure you’re reviewing the architecture as part of that. And this prevents your implementation from going stale but it also sets you up for success for being ready to pivot to new features.

With that in mind, when I think about a North Star architecture, this is generally the level of detail I picture.

It’s not overly technical but it clearly shows what systems are involved and the general flow of data between them with some not very super specific or detailed labels.

In some cases there’s a lot happening with one arrow that doesn’t even have a label between Workfront and Gen Studio that there could be a lot going on there.

But when using this as more of a strategic framework to align and prioritize across business and technical teams, sometimes that one single arrow is enough. So the development of a North Star architecture isn’t purely a technical exercise. We hear the term architecture and automatically think architect.

But business strategy and planned use cases play a major role in shaping it. So the technical teams will almost always end up with a more detailed implementation specific view of this and that is expected but the purpose of the North Star architecture is to create that shared understanding and direction. So a high level view like this allows you to zoom in on and prioritize a specific view or the connectivity between multiple solutions to help to activate a goal use case.

But keeping our context in mind, strategic planning and value realization, this is the right level to kind of get to and begin with.

So what is the value of a North Star architecture? We’ve alluded to this a bit but let’s talk about it more directly.

First let’s take a step back to the survey we did in the first place that led to the value realization framework and the North Star architecture specifically.

What were we hearing from the executives that we talked to that were blockers for them realizing value? They spoke about misalignments, technical teams and business teams working at cross purposes. I’ve seen business teams creating use cases that weren’t technically viable. So wasting time designing a process in their content supply chain that either isn’t feasible or doesn’t scale. I’ve seen tech teams create burdensome limitations and arbitrary restrictions on what we can or what kind of content authoring experiences we support.

And in the survey we heard about teams prioritizing the wrong things. So I can’t count the number of times I’ve heard a variation of we need to implement this or this feature or integration.

And when we ask why, there’s more about because we can’t.

So you have to have plans and use cases in order to make the technical work not wasted.

So the big refrain we heard was my implementation is stale and outdated. So it’s really easy to get comfortable with what you have and to just keep running new campaigns and new content based on the features and capabilities that you’re used to. But if you really want to move the needle, sometimes we have to keep moving forward. And there’s a reason Adobe keeps releasing new features and it’s not always just to keep our engineers busy.

If you’re not keeping up, you have the potential to fall behind and that is where you start to lose edge over your competition. So it’s all about value.

So how does a Northstar architecture specifically help with this? First, it gives us a holistic view of the technology and implementation.

For the business team, this can clearly show what data is being ingested, what content flows are happening, what integrations are in place.

And it can either implicitly or explicitly answer questions about timing of use cases and integrations that will help to expedite your content supply chain usage. And for technical teams, it can help identify gaps in the implementation.

Prioritization is a big help. It’s one of the main focuses of strategic planning because it can help you answer quickly and accurately the most important question, can we do this today? And if not, what’s the level of effort to get there? So what value are we going to get by implementing this feature or this integration or changing this process? And you get that by telling which use cases are unlocked. It can also help you to group specific use cases to solution capabilities that you need to unlock in order to execute. So in other words, you can kind of get two birds with one stone in some cases. And all of that helps point to our focus on value and what value have we unlocked so far. What value remains to be unlocked and what do we want to focus on unlocking next? And outside of the strategic planning aspect, a Northstar architecture could also help with alignment between teams.

Since it’s use case driven, we really want you to ask the question, why are we doing this? How does implementing this piece of technology tie to our use cases and our KBOs and our value? Avoid implementing something just because. So when everyone understands the why behind this strategy, it becomes, it creates confidence and a clearly defined Northstar architecture shows that we’re in it for the long haul with a stable approach that builds trust. So you should have a clear value driven reason for committing to the hours of committing to a new feature.

How else does it align the teams? Well, it shows clearly what the company is working towards and what use cases are going to be unlocked. Are assets syncing from work projects to AEM? Are content fragments accessible in the AJO? You can check the architecture. As long as you’re keeping that updated, it can be a visualization of your capabilities.

And finally, it promotes transparency because you can host your current and future state architectures for the entire company to see if you wanted. It’s not just about quick wins. The Northstar architecture lays the foundation for long term strategic partnerships, aligning on shared goals so everyone is able to support the growth focused implementations.

All right, so now we know what the problem is and what the solution is.

And now we understand the value of the NSA. How do we actually create a Northstar architecture? And like many things, it’s always discovery. We have to know what we have and where we’re going in order to create the Northstar architecture. So asking a lot of questions.

Business questions, technical questions. We have to understand the use cases as well.

I like to kick this off by asking if you have anything at all already. Is there a current state or a more future state? When was the last time it was updated? And if anything has been implemented since then.

How does the current architecture support your current use cases? And again, one reason we let the series off with the use case session is because your Northstar architecture should always be use case driven. So start off by ensuring what use cases you are trying to architect for, understand what products and capabilities are needed for those use cases, what integrations, etc. And try to capture an appropriate amount of depth from the NSA just to understand where the company is at.

As it relates to content supply chain, when we were talking earlier about foundation architecture, we were asking the broad questions from different angles to establish context.

As part of discovery and building Northstar architecture for content supply chain, you revisit those questions in a more concrete way. So discovery is less about what data you have and more about how work and content actually move through your organization today and where things break down, where are the pain points and the silos and the bottlenecks. You want to understand how content is planned and created and reviewed and managed and distributed and activated, what systems are involved at each step, where do handoffs occur, where is manual effort or duplication creeping in. You also need to understand what information travels with the content, what metadata is captured, where is it captured, when it’s applied and is it actually used downstream for governance or reuse or activation.

These are all things that would be part of the discovery for creating that content supply chain specific architecture.

Finally, you also have to look at the integrations, not just what’s technically possible but what integrations are actually required to support the priority use cases and operating model that you have.

And those are the answers that will really shape the Northstar architecture for your content supply chain.

So once you have the discovery and you need to actually make a diagram, how do you do that? There are lots of tools online to help. I tend to use Lucidchart the most and that’s the only one I have a whole lot of experience with but there are quite a few others. I know some love Marrow and Vizio. I’ve never tried to draw.io. We also have a set of blueprints available online for various Adobe products which can help you to get a good jumping off point.

When this call is over, we’ll share this deck out and a couple of leave behinds and that will be emailed to you. That link to the Digital Experience blueprints has a lot of good starting off points. And then finally you can work with Adobe. There’s a number of different groups here that can help. If you have ultimate success, you can work with your account team and just reach out to your account team if this is something that you need support with.

So once you have a Northstar architecture, how do you actually use it? We’ve talked about it for strategic planning and alignment across teams.

We’ve talked about prioritization, identifying gaps and understanding what we can execute today. But it doesn’t stop there. From discovery we should now have a clear understanding of what capabilities we need to enable to support our priority content supply chain use cases.

Once we have that, the NSA becomes a way to translate the gaps into the concrete technical requirements to move forward.

If you remember we were looking at the Northstar architecture diagram example, there were some arrows that had a whole lot happening on them. This is where we break those down into actual next steps for the technical teams. The project plans, the sequencing, the priorities, the timelines.

We always want to try to tie that back to the value we expect to unlock through those efforts.

We can also go deeper on individual use cases for specific content supply scenarios. We can detail the flows required to support them and use that to further align business and technical teams.

For example, what needs to happen after content is approved? How does it get governed and distributed and activated across channels? Here’s another example of a full state Northstar architecture.

It’s generic, but you can imagine customizing this with your specific partners and vendors to make it your own. We can use this to identify gaps like we don’t yet have experience fragments exporting to target. Or, oh look, we need RT CDP to activate our audiences, but we haven’t stood that up yet. Understanding the technical requirements and implementation work necessary for specific use cases gives us a better understanding of which use cases can be activated immediately or which ones require some additional efforts.

So today we’ve largely focused on content supply chain, but I did want to loop back to this diagram from the beginning.

More just as a reminder that your Northstar architecture can include all of your marketing technology. It doesn’t have to just be your content supply chain or what you’re focusing on. Here we have a more Adobe-centric view and even with the content supply chain focus, you can see how ultimately content flows back into systems like Target and AJO to support personalization and activation.

Looking at it more end to end, I feel like it gives you a more complete picture of how your marketing technologies work together. And it gives you a practical way to identify and prioritize and align around the use cases and what it is that is needed to accomplish them.

If I leave you with one takeaway from this whole session, I hope it’s that a Northstar architecture is a tool for strategic planning.

It helps you to understand what you have today. It tells you what you need to implement to support your priority use cases and where the bigger gaps in your technology stack may exist.

It’s also a tool for alignment, so it creates a shared reference point for productive discussions across teams and gives transparency on the current objectives and priorities that are being worked on.

And finally, a Northstar architecture should be treated as a living document. It should be revisited and updated regularly as part of your planning and prioritization process. As new implementation work is completed, the architecture should evolve to reflect that progress. So it’s your current state architecture and your desired future state. Keeping those in kind of step is critical in always knowing what’s next and what the next priorities are.

And as we wrap up, I did want to emphasize that having a plan is only the beginning.

Consistent follow through is essential to success.

Having the Northstar architecture as a tool is only worthwhile if you use it. As next steps, we recommend the following. First, identify a list of initial use cases for prioritization. Keep it limited.

It’s an initial list of priority use cases. And then two, design and execute the tactical action plan. Build and leverage the Northstar architecture to identify what’s needed to enable those use cases.

And then finally, contact your Adobe account team for support if you need it during your use case planning, your development, or your execution journey.

As I said, we’ll be sending out this deck to you included in those links where that visual experience blueprints has all those examples and starting off points for Northstar architectures.

There’s a good resource about building a seamless content supply chain. And then there’s also a link to the cross solution architecture design webinar, which was really good. In addition to the link that was shared in the chat, I’ll add that one to this as well.

So that is the extent of the content I have available for you today. I do think we have some time left for Q&A. Ledi? Yes, thank you, Will. That was great information. We do have a question in the chat and I wanted to get your perspective on it. But as we get into this Q&A portion of our event, I’m going to launch this really quick two question poll. And we’d love to get your feedback. So please help us shape future sessions with your feedback here. But yes, let’s go ahead and review that question from Shavon. He’s curious and he’s wondering who is maintaining the NSA and does that reflect the most up to date, including references to content advisor for content reuse? That’s a good question. And it’s actually one I love to answer because while we are talking about who creates the Northstar architecture. I made sure to point out that it’s not just a technical task, right? Like the business users, the decision makers need to be involved as well because the use cases drive the Northstar architecture.

What you want to do with the solutions drives the future of the connectivity and the usage of the data, the flow of the data, the flow of the content. So I think that the maintaining of an NSA should be part of any sort of development or business planning exercise. Once those strategic business planning exercises take place and there are use cases that come out of those, that is the next step should be taking a look at the Northstar architecture. What updates need to happen? What have we updated since this was last updated and then use it again as a strategic tool? As far as reflecting the most up to date and references to content advisor and so forth, the level of detail is really up to you. There were some of those that we saw in the examples that had a lot of outside systems and data points and data lakes and pins and authentication systems. So the level of detail that makes sense to you is really the best recommendation I could make, which sounds like a non-answer but it’s the best I’ve got.

Great. Thank you for addressing that. Any other questions? Feel free to post them in the Q&A pod or the chat.

Well, I do have one question personally.

Where would dynamic media fit into this content supply chain flow? Is that considered AM assets or just under the AM umbrella? Yeah, that’s a good call. I don’t think any of the diagram examples that I showed today had dynamic media called out or at least not in a prominent way that I remember.

But regardless, dynamic media would be more downstream of the content creation and the management. So probably right after AM, essentially right at the point of delivery to web and mobile and apps. So right before it gets to the end users. This is probably where I’d see it most.

Got it.

Oh, we got one. Hi, Jennifer. Thank you. How do you define a use case? It seems as if that is the core to the NSA. It has been a very active debate in our org. I missed the first session in this series, so perhaps this was covered there.

Yeah, the previous session was all about use cases, so I would definitely recommend checking it out. But the way I define a use case is more a business objective or goal.

A use case could be a creative agency that we work with is creating content associated with a work front task.

And after the task is marked, goes through approval and is approved, it should go directly to AM into a folder associated with the project ID. And so that could be a use case that you would want to happen. And it’s part of and then the North Star architecture aspect would be identifying where the technical gaps are that would enable that flow to happen. That’s how I roughly think about use cases or essentially things that you would want to do within your work streams.

We have another one from Thaxton. Is Gen Studio Adobe’s foundational content supply chain app? Good question. And Gen Studio is a very broad term, right? So Gen Studio makes up the whole content supply chain stack from work front and AM, creative cloud and so forth to also Gen Studio for performance marketers. I would say that it is definitely a fully featured kind of all in one sort of if we’re talking about Gen Studio for performance marketers as a foundational content supply chain app. I think that’s a way you could definitely think about it for sure because it covers all the bases.

Outside of the Gen Studio for performance marketing space, creative cloud and work front and AM have that at Firefly and you have that same flow. So yeah, I think it’s probably a good way of describing it.

I don’t see any other questions. Thank you, Jennifer, for responding. I believe you’ll get a lot of information around use cases if you have time to watch that other session.

All right. Oh, question in the Q&A.

I’m sorry, I didn’t see you, Greg. Are you seeing more native integrations versus Fusion slash custom with clients? I see a whole lot more native than Fusion, but more and more lately I’ve been seeing a lot of Fusion providing additional support to the native. So thinking about things like the content lifecycle and workflow orchestration, doing things like auto creation of folders when work is approved or moving assets when reviews are complete and doing more complex or advanced metadata stuff or content fragment creation.

So a lot of that kind of stuff is not all part of the native connection. And that’s where some people more and more I’m seeing using Fusion to support.

Or provide more features rather.

Okay. Okay, I don’t see any other questions coming in.

All right, well, we’ll go ahead and close out. Thank you all for attending and taking the time today to join the session. We hope to have your company again on future webinars. And if you do have additional questions, you may ask, reach out to your account team and they will relay them to us.

Hope you have a great day and great rest of your evening or day.

Thanks, everyone. Thank you all.