But speed has come with a side effect. 

Many organizations are discovering that while their interfaces look polished and their feature sets grow quickly, the underlying systems are becoming harder for users to understand. Navigation fragments, workflows become inconsistent, and teams spend increasing time fixing usability issues one screen at a time. 

The problem often isn’t the interface. It’s the structure underneath it. 

As AI-driven capabilities become embedded across digital products, restoring that structural layer of experience design is becoming increasingly important. 

The Layers of Modern Experience Design 

When organizations talk about digital experience, several related disciplines tend to get grouped together. 

User Experience (UX) focuses on how people interact with a system to accomplish tasks. 

Customer Experience (CX) focuses on the broader relationship between people and an organization across touchpoints and time. 

But there is another layer that often receives less attention: Experience architecture. 

Experience architecture shapes how information, workflows, and capabilities are organized so that UX and CX can function coherently across a product ecosystem. 

These disciplines operate at different levels: 

• UX designs interaction 

• CX designs relationship 

• Experience architecture structures the system 

When the architectural layer is strong, usability improvements scale across the entire product. When its weak, teams end up repeatedly redesigning individual screens while deeper problems persist. 

When Structure Disappears 

Many digital teams today operate under strong pressures: faster release cycles, data-driven decision-making, and constant feature expansion. 

These pressures bring clear advantages, but they also shift attention toward what is easiest to deliver and measure. 

The visible surface of products—the UI—often becomes the center of design work. 

Over time, deeper structural questions receive less attention: 

• How information is organized 

• How workflows connect across systems 

• Whether interaction patterns remain consistent 

• Whether the system matches how users actually think and work 

When this happens, organizations begin to see familiar symptoms: 

• fragmented navigation 

• inconsistent interaction patterns 

• growing design debt 

• increasing user confusion 

Many of these problems are not cosmetic. They are architectural. 

A Lesson from Human Factors 

UX originally emerged from disciplines such as human factors and ergonomics, which studied how people interact with tools in real-world environments. 

One well-known example comes from aviation during World War II. 

Pilots were accidentally raising landing gear instead of flaps during landing. The controls were identical in shape and located close together. 

Human-factors researcher Alphonse Chapanis redesigned the controls so they could be distinguished by touch. The errors disappeared. 

The pilots hadn’t been the problem. The interface had. 

The same lesson still applies to digital systems today: Many “user errors” are actually structural design errors. 

Why Architecture Matters Even More with AI 

The rise of AI-driven systems adds a new level of complexity to digital experiences. 

Traditional software typically presents fixed options and predictable outcomes. AI systems behave differently. They generate responses dynamically and adapt to user behavior. 

This changes the UX challenge. The central problem is no longer just interface design. It is intelligibility. 

Users need to understand: 

• what a system is capable of 

• where its boundaries lie 

• how their actions influence its behavior 

Without that clarity, AI systems can appear unpredictable or opaque. 

Experience architecture plays a critical role here because it structures: 

• how AI capabilities are presented 

• how feedback is communicated 

• how users maintain orientation and control 

In other words, architecture helps ensure that intelligent systems remain understandable to the people who rely on them. 

The Role of UX Architecture 

UX architecture refers to the structural layer of experience design that determines how a system works from the user’s perspective. 

It includes elements such as: 

• information architecture 

• navigation structures 

• task flows 

• interaction models 

• content hierarchy 

• alignment with user mental models 

This architectural perspective does not replace classic usability principles. Instead, it creates structural conditions that allow those principles to scale across complex systems. 

A simple way to think about it is: 

UI expresses usability. 

UX architecture enables usability. 

Just as software architecture precedes code, UX architecture precedes interface design. 

Designing for Long-Term Trust 

Digital systems operate within relationships of trust. When products become confusing, manipulative, or opaque, short-term metrics may improve—but long-term outcomes often decline. 

Customers abandon products. Support costs rise. Regulatory attention increases. 

Clarity and transparency are therefore not just design ideals. They are long-term business assets. 

Organizations that succeed with complex digital systems often invest in capabilities that reinforce architectural thinking, including: 

• systems mapping 

• design research 

• information architecture 

• interaction design 

• design systems and governance 

These capabilities help ensure that digital ecosystems remain coherent as they grow. 

Closing the AI Value Gap 

Many organizations today are investing heavily in AI capabilities but struggling to translate those capabilities into meaningful user outcomes. 

One reason is structural. 

AI features are often layered onto systems that were not designed to accommodate them. Without strong experience architecture, even powerful AI capabilities can feel confusing or disconnected from the workflows people actually need. 

Closing the AI value gap requires more than adding intelligence to systems. 

It requires designing systems so that people can understand, trust, and effectively use that intelligence. 

Looking Ahead 

The fragmentation of UX, CX, and product disciplines did not occur by accident. It emerged from real market pressures and technological change. 

But as digital ecosystems grow more complex—and as AI becomes embedded across products and services—many organizations are rediscovering a simple truth: 

Interfaces alone cannot sustain coherent experiences. 

What enables durable digital systems is architecture—both technical and experiential. 

When experience architecture provides that foundation: 

• UX can support effective interaction 

• CX can guide long-term relationships 

• product teams can balance business goals and user needs 

And organizations gain systems that remain understandable and resilient as they scale. 

The post Why Experience Architecture Is Critical for AI-Powered Digital Products appeared first on Perficient Blogs.

A lot has changed since then, including the introduction of Adobe’s Edge Delivery Services (EDS) and Universal Editor (UE).  Before I jump into what’s new, let’s review why some teams are looking to go headless after many years of headful experiences. 

They need content creation and management shared by multiple downstream apps.  This is often referred to as multi-channel content. 

• Traditionally this has been supported by Adobe’s Content Fragment technology. 

The engineering teams want declarative components (SPA-like experiences) rendered server-side. 

• AEM does not yet have native support for server-side rendered declarative component frameworks like Next.js.  Today, Edge Delivery Services and traditional component development both utilize imperative components.  We’ll have to wait and see if this changes in the future. 

The engineering teams do not have as much AEM development experience as with their preferred stack. 

• This can pose a risk to cost and time-to-market.  However, moving headless introduces custom implementation work such as cache refresh, authentication, content retrieval integration, and content route mapping that may lengthen the timeline regardless. 

Headful 

If you do not have any of the above headless requirements and no existing AEM components, I recommend Adobe’s latest “Headful” solution utilizing Edge Delivery Services to render static HTML + CSS + JS at the edge of the network.  The rendered pages are very fast with strong Core Web Vitals scores.  Teams typically need only light training to implement the authoring instrumentation, so I would recommend it even to teams without traditional AEM development experience. 

If you have existing AEM componentry, AEM as a Cloud Service with traditional component development is still supported.  A Hybrid AEM approach remains an excellent way to build Headless integrations on top of existing Headful implementations. 

However, for new sites or redesigns, Edge Delivery Services is a clear winner. 

Headful Recommendation: Edge Delivery Services for new implementations.

Headless / Hybrid 

In 2026, Headless is a much stronger contender than it was just a few years ago.   You no longer need a Hybrid architecture to retain WYSIWYG, in-context authoring.  Adobe has introduced the Universal Editor, a powerful tool to author AEM content directly on-top of a downstream web application. 

In a headless model, authors create Content Fragments in AEM, expose them through GraphQL APIs, and downstream applications retrieve and render that content.  Universal Editor adds the capability to open a downstream page that contains those fragments.  If the page is instrumented for authoring, authors can add, delete, and edit Content Fragments directly in-context of the rendered application.  They no longer need to swap back and forth to view the changes. 

This gives engineering teams the freedom to use their preferred technology stack, while still providing authors with the speed and familiarity of AEM’s in-context editing experience. 

Headless Recommendation: Universal Editor 

Now, what you might notice about headless requirements 2 & 3 is that these are not content-driven requirements.  These requirements are driven more by technology and team preference.  Why is that important?  Well, content fragments were primarily designed to solve a multi-channel use case.  They’re not inherently attached to any page, which creates content management challenges. 

1. How does an author track usage of those content fragments downstream from the CMS?  This often requires a custom solution like beacon analytics. 
2. Useful AEM tooling like Multi-site Management, Page moves, Metadata authoring, Page Publish Workflows are not available out of the box for Content Fragments.
3. Link checker no longer functions, as AEM does not have any inherent knowledge of the downstream routes. 
4. Downstream applications pull in fragments by name or by query.  This creates a process where CMS authors must adhere to a “mapping pattern.”  This involves either a strict content fragment naming standard or uniquely generated name field that is consumed programmatically downstream. 
5. If it’s a generated name, this creates a strict author-to-developer handoff process for new pages or content sections.
6. For example, if the downstream application wants to pull a particular component for the home page, what path or name does it look for the fragment in the CMS?  
7. Existing AEM authors are typically more experienced with creating and managing pages instead of content fragments. 
8. It creates a platform disconnect.  Authors must navigate to AEM to create Content Fragments but navigate to the downstream application or the Universal Editor to view changes in context. 

But wait, there’s good news!  We don’t have to use content fragments alone or at all.  The Universal Editor also supports writebacks to AEM page-based resources.  This solves many of the experience challenges we have with headless implementations.  We can learn from the architectural patterns of an AEM Hybrid implementation and apply them in detail next week. 

For more information on how Perficient can implement your dream digital experiences, we’d love to hear from you. We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others).  Contact Perficient to start your journey. 

The post Headful or Headless AEM: Revisited for 2026 appeared first on Perficient Blogs.

That’s where most strategies hit their limits. Not at the pilot stage, and not for lack of ambition. Because deploying AI and governing it are two different problems — and only one of them has been getting the attention it deserves.

Organizations Are Scaling AI Faster Than They’re Governing It

AI fluency is growing quickly across the enterprise. Leaders aren’t asking for basic introductions anymore. Instead, they’re asking where to apply AI, how to scale it, and whether they can trust what they’ve built.

At the same time, a gap is starting to emerge. Widespread experimentation hasn’t translated into real scale—nearly two-thirds of organizations still haven’t deployed AI across the enterprise. What works in a pilot doesn’t always hold up in production. What works in isolation often creates real complexity once teams embed it into daily operations. So, while moving fast is valuable, it only works when the right foundation is in place to support it.

Deployed Isn’t the Same as Governed

There’s a belief that shows up in many AI conversations, often without being stated directly: once AI is deployed, it’s been operationalized.

In practice, that’s where strategies can run into trouble. AI creates lasting value when organizations embed it inside systems that define its role, validate its outputs, and measure its performance over time. Without that structure, it’s difficult to scale with confidence.

That dynamic was visible at Appian World 2026. In fact, organizations made the most progress when they built AI directly into business processes—not when they ran it alongside them.

That’s what’s shaping the next phase of intelligent automation.

Governance Is What Separates Experimentation from Operational Performance

If there’s one thing many organizations are still working through, it’s not what AI can do — it’s what it takes to govern it at scale.

Governance determines where organizations use AI, what it can do, how teams validate its outputs, and how they measure performance over time. As agentic AI enters the picture, that structure becomes even more important.

The potential of agentic systems is real: taking action, coordinating across workflows, and operating with increasing autonomy. That same autonomy, without clear boundaries, introduces risk. Reliability doesn’t come from the model itself — it comes from the processes and safeguards built around it.

In practice, well-governed AI looks like this:

• Teams embed AI directly into workflows with clearly defined roles
• Inputs and expected outputs are specified upfront
• Outputs are validated within the process before action is taken
• Performance is continuously monitored and refined

“Agentic AI is exciting…but it’s still unproven and can’t fully be trusted. Governing it in a controlled set of use cases is critical to establishing trust and measuring the impacts.”- Craig Peterson, Director

The organizations seeing the strongest results aren’t trying to scale everything at once. Instead, they start with use cases they can measure, manage for risk, and prove in practice—then build from there.

At this stage, progress is less about how much AI you deploy and more about what you can run reliably and stand behind.

What Governed AI Looks Like in a Real-World Environment

Healthcare is one of the clearest examples of why governance matters — and it’s what we’ve seen in practice.

Our AI Healthcare Concierge helps patients and members navigate care, handling benefits questions, prior authorizations, referrals, and coordination across voice and chat. What makes it effective in a high-stakes environment is how it operates within a governed system:

• It handles specific, repeatable tasks rather than open-ended decisions
• Outputs feed directly into validated workflows before any action is taken
• Every interaction is measurable from the start
• Oversight is built into the process

While healthcare makes the stakes clear, the underlying principle applies broadly: AI is only as effective as the system it operates within. That’s the approach behind our AI Healthcare Concierge. Governed by design. Built to perform.

Scaling What You Can Govern Is the Competitive Advantage

That apprach is reflected in our work every day. As a result, Perficient won Appian’s Delivery Excellence Award for the third year in a row because we build solutions designed to hold up in real-world operations.

The organizations making the most progress aren’t necessarily deploying the most AI. They’re being deliberate about where they deploy it — and scaling only what they can govern.

That’s the difference between running experiments and building real advantage. The question isn’t just what’s possible. It’s what you can govern and prove is working.

Ready to move from AI experiments to AI you can stand behind? Contact us to discuss what governed AI looks like in your organization.

The post What Leading Enterprises Know About Governing AI at Scale appeared first on Perficient Blogs.

The Summit drew more than 20,000 attendees and shipped 26+ new capabilities across more than 500 sessions. CEO Sridhar Ramaswamy shared the keynote stage with Anthropic President Daniela Amodei — a pairing that, on its own, tells you where the center of gravity has moved. The headline wasn’t a faster warehouse or a cheaper query. It was a thesis: AI agents are only as useful as the governed data, semantic context, and verified identity standing behind them. 

If you couldn’t make it — or, like me, you were there and are still untangling the firehose — here are the six takeaways I keep coming back to, and what I think they mean for the teams I work with. 

1. The pitch changed: from data platform to control plane 

For years, Snowflake’s story was simple: bring your data, run your queries, pay for what you use. At Summit 2026, that story grew. The company reframed the AI Data Cloud as the operating system — the control plane — for an enterprise run by autonomous agents. 

That isn’t just marketing. The narrative arc on the keynote stage walked through three eras: the age of IT, the age of BI, and now the age of AI agents. The implication is sharp. If agents are going to act on your business — querying data, writing code, triggering workflows — then the platform that holds the data also has to govern the agents. Snowflake is making a bid to be that layer, not just the storage underneath it. 

2. Agents got names, surfaces, and a place to work 

Two rebrands anchored the agent story. Snowflake Intelligence became CoWork, a personal AI agent for knowledge workers, now reachable from an iOS app, a Slackbot, and — the one that made the room laugh — a Microsoft Excel extension. Cortex Code became CoCo, elevated from a coding assistant into a full autonomous development agent. 

CoCo is the more striking of the two. It now runs as a native desktop app for Windows and macOS, plugs into VS Code, and connects to Anthropic’s Claude Code so developers can route Snowflake-specific work from the tools they already live in. More importantly, it gained real autonomy: Automations run recurring tasks on a schedule, and Cloud Agents are serverless, event-driven workers that react to data changes — alerting a team when inventory drops below a threshold, for example — with no client left running. 

Rounding it out: a Skill Catalog for discovering and reusing proven agent skills across the enterprise. The pattern is clear — the agent should show up where the work already happens, not ask the work to move to it. 

3. Context is the new moat 

This was the takeaway I underlined twice. The biggest constraint on enterprise AI is no longer model quality it is whether the model understands your business. Snowflake leaned hard into this with a cluster of context-and-semantics announcements. 

Horizon Context (private preview) adds the ability to collect metadata from outside systems — PostgreSQL, SQL Server, Tableau, Power BI, dbt — then enrich it with column-level lineage and AI-generated documentation, and activate it through hybrid semantic search. Semantic Studio and Semantic View Autopilot let teams define and auto-maintain shared business logic without deep SQL expertise. 

The number that landed hardest came from Cortex Sense, the runtime layer that assembles data, business definitions, and operational knowledge for an agent at query time: 86% accuracy on structured business questions with full context, versus 24% for a generic model without it. Same question, same model class — the difference is context. That gap is the entire argument for why a governed semantic layer matters, and it is the slide I will be screenshotting for client conversations. 

4. Agents need identity — and now they have one 

Here is the part most of the press underplayed and most security leaders should not. Snowflake shipped AI Agent Identity (GA): every agent now gets a cryptographic identity, per-agent role-based access control (RBAC), and a complete audit trail. Pair it with the new AI Security Posture Management and you have the beginnings of a governance model built for non-human actors. 

Think about what an autonomous agent actually is — software that reads data and takes action on its own. Without identity, RBAC, and auditability, that’s an ungoverned service account with initiative. Treating agents as first-class identities is the unglamorous prerequisite that makes everything else safe to deploy. I expect this to become table stakes, and the organizations that get their identity and access model right early will move faster later. 

5. The plumbing kept advancing, too 

Underneath the agent headlines, the infrastructure announcements were substantial — and they are what make the agent story credible: 

• Snowflake Datastream — a fully managed, Kafka-compatible streaming service. Existing Kafka producers and consumers connect with a config change, and data lands as governed Snowflake or Iceberg tables. Snowflake pegs the real-time data opportunity at $128B. 

• Apache Iceberg v3 (GA) — bidirectional interoperability via the Horizon Catalog, which embeds the open-source Apache Polaris catalog. The open-table-format bet is now fully in production. 

• Cortex Training + Adaptive Compute — fine-tune open models like Qwen and Mistral on managed GPUs without moving data outside the governed perimeter. 

• Ecosystem moves — an expanded Anthropic partnership, a reported $6B AWS commitment, the Natoma acquisition, and the dbt + Fivetran merger reshaping the data tooling map. 

6. The Anthropic moment 

The expanded Anthropic partnership, and the ability to drive Snowflake work directly from Claude, signals where Snowflake believes the value is migrating: toward reasoning over governed enterprise data, not just storing and serving it. 

What I took from that fireside is a posture, not just a product. The two companies framed enterprise AI as a division of labor — the model brings reasoning, the platform brings governed context and guardrails. Neither is sufficient alone. For anyone deciding how to build, that framing is a useful corrective to the assumption that a powerful model, dropped onto messy data, will somehow figure it out. It won’t. The demo that worked was always the one with clean semantics behind it. 

What I’ll be watching next 

A recap is easy; the hard questions take longer to answer. A few I left San Francisco still chewing on. First, how much of this is GA versus preview? Several of the most exciting capabilities — Horizon Context, Datastream, Semantic Studio — shipped in private or public preview, which means the real test is the next two quarters of customer hands-on time. 

Second, does the context layer reach far enough? Cortex Sense is powerful inside Snowflake’s boundary, but most enterprises run across many systems. How well the metadata connectors and lineage stretch across a genuinely heterogeneous estate will decide whether the 86% number holds up outside a demo. 

Third, what does this do to cost? Agents that run on schedules and react to events are, by design, always working. The FinOps conversation around autonomous, event-driven compute is one almost nobody had on stage — and one every platform team will have within a year. 

The Real Takeaway 

Snowflake spent Summit 2026 making one bet out loud: that the winners in enterprise AI will be the organizations whose data is governed, whose context is engineered, and whose agents are identified and accountable. The compute was always going to get cheaper. The trustworthy foundation is the hard part — and the part worth investing in now. 

For more information on our Snowflake capabilities, visit our Snowflake Partner page.

The post Six Takeaways from Snowflake Summit 2026 appeared first on Perficient Blogs.

I felt that often last week at Salesforce Connections in Chicago — and it sharpened a question I keep coming back to: what does agentic enterprise transformation actually require of a marketing organization, before the demos, and long after the conference ends? I also had the opportunity to share my real-time reactions with a room full of marketers at Perficient’s keynote breakfast watch party. What I shared there is what I want to capture here: the announcements were impressive, but the more important conversation is what they signal — and what it will take for organizations to turn that potential into impact.

The Demos Were Good. The Subtext Was Better.

The Salesforce Connections keynote was organized around three chapters: Always-on Creativity, Self-Optimizing Campaigns, and Autonomous Pipeline Generation. The demos across all three were compelling. Agentforce Co-Worker surfaced marketing-driven pipeline insights in minutes instead of weeks. The Goals Agent compressed a campaign lifecycle from 12 to 14 weeks down to hours. Piper, the Qualified SDR Agent, accelerates lead qualification and meeting creation 24/7. And the acquisition of Contentful pointed to more dynamic control over creative assets that have historically been locked inside rigid content systems.

What stood out to me, though, was not any one announcement in isolation. It was that each of them addressed the same underlying problem: marketing operates on lag. Insights arrive after the window to act has passed. Content approvals outlast campaign relevance. Buyers move faster than the systems designed to engage them. Across all three chapters, Salesforce was presenting a coordinated attempt to shrink that latency and move marketing closer to real time.

That’s what makes the strategic case compelling. The problem is rarely that marketers lack data or ideas. It’s that turning those inputs into action still takes too many handoffs and too much time. If these tools meaningfully reduce that delay, the advantage is not just speed. It’s operating on a different wavelength than competitors still constrained by manual workflows.

That, to me, was the keynote’s real headline.

Here’s the Part I Said Out Loud in That Breakfast Room

What I also said is that none of this works by magic. My job is not just to admire what the technology can do. It’s to help clients understand what conditions must be true for it to work well. When it comes to AI agents, that means being honest about something marketers need to hear more often: agents do not remove the need for operational maturity. They make it more visible.

An agent tasked with building campaigns will only be as effective as the goals and constraints you give it. An agent generating content will only be as on-brand as the standards and approvals model you make accessible to it. A pipeline agent can scale good qualification discipline, but it can also scale confusion if marketing and sales have never aligned on what qualified means. And an intelligence dashboard can produce fast, confident-looking outputs that are only as trustworthy as the data beneath them.

That is not a criticism of Salesforce. It is the operating reality of agentic AI, and it is probably the most useful thing I can say after watching the keynote. The maturity requirement is not primarily technical. It is organizational. Can you define a good campaign brief in writing? Do you have benchmark data that can guide decisions? Have marketing and sales aligned on lead quality? Is your CRM data complete enough to trust?

Those are the questions that separate organizations that will realize meaningful value from those that will run a pilot, get mediocre output, and decide the technology is not ready. In many cases, the technology is ready. The foundation is what needs attention.

Starting Your Agentic Enterprise Transformation: Where to Focus First

If your team is still early in its AI maturity, the most valuable thing you can do right now is not deploy an agent for the sake of having one. It is to strengthen the operating conditions an agent will depend on. That means auditing data completeness in Salesforce, establishing attribution frameworks people use consistently, and documenting your brand’s voice and campaign standards in a format structured enough for a machine to follow. In practical terms, you are writing the brief an agent will eventually execute against.

If you already have a strong data foundation, the opportunity is not to treat these agents as a linear progression from one capability to the next. Marketing doesn’t work that way. The real opportunity is to connect the intelligence, campaign, and pipeline layers, so they continuously inform one another. That closed loop is the real prize: not a single agent or workflow, but a system in which each capability makes the others more effective.

What We’ve Learned at Perficient: Our Agentic Enterprise Transformation

We’re a Salesforce Agentforce implementation partner, and we’ve been building this architecture in our own go-to-market operations, so I’m not speaking hypothetically. Our internal data was sobering. Fifty-nine percent of our sellers were spending 40 percent or more of their week on non-selling activities, and they rated their tools at 3.9 out of 10. Marketing’s work was disappearing into that capacity gap, with leads untouched, intent ignored, and content missing the moment it was meant to influence.

Our answer was an Agentic Front Office: seven specialized agents deployed directly into the Salesforce and Slack workflows where our teams already work, guided by three principles. First, unlock the context agents need to be useful. Second, right-size their responsibilities with bounded roles and clear guardrails. Third, prepare the workforce to orchestrate outcomes alongside digital labor, rather than execute manual tasks.

What building this has reinforced for me is that this is an operating model change, not a feature upgrade. The organizations that get the most from this moment will pair ambition with discipline. They will invest in the data, alignment, governance, and change management required to make agents effective, while also moving quickly enough to learn by doing. Those are the organizations that will look back at Connections 2026 and recognize it as the moment their agentic enterprise transformation stopped feeling theoretical — and started becoming operational.

The post Agentic Enterprise Transformation: What Marketers Need to Hear After Connections appeared first on Perficient Blogs.

This blog was written by both Megan Mueller Jensen and Randy Roosekrans, supporters and members of PRISM, Perficient’s Employee Resource Group for our LGBTQIA2S+ colleagues and allies.

As cisgender straight people in a professional setting, we believe it’s our responsibility to do our best to support our LGBTQIA2S+ colleagues. We are longtime allies, advocates, activists, and parents of gay kiddos, and we want to share a few things we’ve learned over the years about making our workplaces safer, friendlier, more inclusive, and more supportive for our queer colleagues. (For the rest of this writing, we’ll refer to these folx as ‘queer,’ which is an umbrella term although we recognize that not all of this applies to everyone.)

1. Pronouns matter. If someone tells you their pronouns, the bare minimum we can do is respect that and use those pronouns consistently. And if you slip up in conversation, correct yourself, apologize briefly, and move on. Doing so will signal that you’re making an effort; it becomes easier with practice. If you’re not sure of someone’s pronouns, it’s ok to ask! Simply say, “I use she/her. May I ask what you use?” It’s also great to include your pronouns in your email signature, when introducing yourself, joining a meeting, or on your LinkedIn profile. It’s a positive signal that lets queer folx know that you’re a safe colleague and partner to work with, and that they’re cool being themselves around you.
2. Respect and protect the privacy of your queer colleagues. Just because someone has disclosed information to you (or within PRISM events and conversations) doesn’t mean you have permission to share that with anyone outside of that original conversation. It’s ONLY the decision of queer people themselves to whom they want to come out. That information may not be safe or smart to share anywhere else. If for some reason it’s necessary to divulge details about others, make sure you get their permission first.
3. Educate Yourself. Take the initiative to educate yourself about queer issues, terminology, and experiences. There are plenty of resources available online, such as articles, books, and documentaries that can help you understand the challenges faced by the queer community. While most queer folx are happy to answer questions, it can also be emotionally and intellectually exhausting to constantly be the sole source of information, or if there is an assumption that they “represent” all queer folx.  A few great resources include HRC (Human Rights Campaign),  GLAAD (Gay and Lesbian Alliance Against Defamation), and The Trevor Project. PRISM also hosts informational events throughout the year that are designed to help us all be better allies.
4. Speak up, even (or especially) when queer colleagues aren’t present. If someone misgenders a colleague or uses offensive terminology, intentionally or unintentionally, it’s our responsibility to correct them in a friendly but consistent way. Stand up for folx who aren’t in the room. It sets the standard for expected behavior within the team and reinforces a supportive company culture. To that end, be very mindful of “deadnaming” which is using the name a trans person had before they changed it to what they use now. It can be deeply traumatic and triggering for them to hear that name in any setting. If you happen to make that mistake, you can offer a quick, sincere apology and keep the conversation moving.  If you hear a colleague using the deadname of someone who isn’t present, it’s a good opportunity for a friendly correction.
5. Support queer-inclusive policies. The needs and challenges of our queer colleagues may be different and more impactful than ones we experience as cisgender folx. Don’t make them fight for equality and inclusivity alone. Make sure they know you are in their corner and follow that sentiment with action.
6. Remember it’s not about YOU. As allies, it’s our job to support, facilitate, and enable the efforts of our queer colleagues. Big decisions should be made by queer folx, and our role is to help make their lives easier, safer, and more equitable. Try your best to give input, ideas, and opinions regarding queer life when invited to do so or ask if you can add your perspective when it might be useful.
7. Be open to listening and open to growth. Even with the best of intentions, we won’t always get it right. We may unintentionally say something dumb or stumble over our words. If a queer colleague corrects you or gives you input, see it as a sign of trust rather than criticism.

Understand that there are many facets to queer culture, and some norms may vary. The more exposure and practice you get in these spaces, the clearer those norms will become. The most important thing is that you approach these interactions with respect — everything else falls into place!

In closing, CONGRATULATIONS TO YOU! The fact that you are reading this article and showing an interest in this topic demonstrates your allyship, and your willingness to help make positive changes within the queer community. Thank you for being who you are! Let’s help our colleagues, clients, friends, and loved ones in the queer community feel welcome to be the best versions of themselves, too!

The post 7 Ways to Be a Better LGBTQ+ Ally at Work appeared first on Perficient Blogs.

Earning the AWS Golden Jacket is a remarkable accomplishment—one that reflects deep technical expertise, persistence, and a commitment to continuous learning across the AWS ecosystem.

What Is the AWS Golden Jacket?

The AWS Golden Jacket is a recognition given to individuals who hold all active AWS certifications at the same time, demonstrating expertise across the full breadth of AWS capabilities, including cloud architecture, DevOps, security, data, and machine learning.

Because it requires maintaining every certification concurrently, this distinction signals both depth and breadth of knowledge across AWS services and domains.

What This Achievement Represents

Earning the AWS Golden Jacket reflects more than completing a set of certifications. It represents sustained focus, discipline, and the ability to operate across a rapidly evolving cloud ecosystem.

To reach this level, Gonzalo built and maintained expertise across a wide range of AWS services and domains, while continuously adapting as the platform evolves.

This includes:

• Mastering AWS services across architecture, security, data, and AI/ML
• Maintaining all certifications simultaneously as they evolve and require renewal
• Applying knowledge to real-world scenarios where design decisions impact scalability, performance, and cost
• Staying current with new services, architectural patterns, and best practices
• Balancing ongoing learning with day-to-day client delivery

That level of commitment signals expertise that stays current as AWS continues to innovate.

For our clients, that translates into real value. It means working with experts who can connect capabilities across AWS services and design solutions with a clear understanding of how to align technology decisions to business outcomes.

Powering Our AWS Practice

Gonzalo’s achievement reflects the strength of Perficient’s AWS practice and the expertise we bring to clients as an AWS Premier Consulting Partner.

Our teams deliver solutions aligned to key AWS capability areas, including:

• Cloud architecture and modernization
• Data and analytics platforms
• Security and compliance
• Artificial intelligence and machine learning

This work is backed by:

• Deep, cross-functional cloud expertise
• A strong culture of certification and continuous learning
• Proven experience delivering complex, enterprise-scale AWS solutions
• A focus on driving measurable business outcomes

A Milestone Worth Celebrating

The AWS Golden Jacket is a significant achievement that reflects both individual dedication and the collective strength of our AWS practice.

Gonzalo, congratulations on this well-earned recognition. Your expertise, curiosity, and commitment to continuous learning make a meaningful impact on our clients and our team. We’re proud to celebrate this moment and look forward to what comes next!

Read more about Perficient’s AWS practice here.

The post Celebrating Gonzalo Munoz’s AWS Golden Jacket: A Milestone That Reflects Excellence appeared first on Perficient Blogs.

Headless Page-based Authoring Tutorial Preface

This tutorial assumes that you have a basic understanding of Universal Editor’s purpose and AEM’s architecture. It is also not intended to be a comprehensive solution design for the AEM-App integration nor a complete Universal Editor tutorial. Considerations like instrumentation details, caching, app security, and which authoring options are made available are beyond the scope of this tutorial.

Step 1: Enable AEM Page Content for Export

You can certainly use the pre-configured model JSONs of AEM Core Components. However, they have several fields that are not relevant to my downstream application, like gridClassNames and allowedComponents.

So instead, I prefer custom Sling Models. This gives us a granular level of control over which fields are exposed to our downstream application.

Start by creating a Sling Model for your Page component. Configure the @Model annotation to utilize SlingHttpServletRequest.class as an adaptable so it can serve web requests to a .model.json path and match the resourceType property to the resourceType of your Page component. Configure the @Exporter annotation to use the Jackson library and support a JSON extension for export.

You’ll notice that I’ve created a getItems method that returns a list of objects. This method utilizes a custom HeadlessUtils method that looks for (almost) all children resources of the Page and adapts them to their matching model based on their sling:resourceType. This is very important, as we want each child component to export its JSON based on its own model, not relying solely on the model of the parent.

I can re-use this pattern for other container components, components like Responsive Grids or Columns that have any number, names, and types of children.

Then I can similarly configure Sling Models for all components that will appear on my page. The primary difference in how I configure these other component models is that they also need to be adaptable from a Resource in order to be exported by the getItems method or other resource-based retrieval.

Once I have done that, I can load the export of any Page that uses this model as JSON.

Step 2: Consume the Page Content Downstream

For this example, let’s create a small connector library to AEM using JavaScript. Ultimately this could be run server-side or client-side and rendered however I like. The purpose here is to show that regardless of what downstream app I have, I can use a simple REST-based GET to retrieve the data.

You may notice within the code here that I’ve abstracted out the concept of a full AEM path from the rest of my application. This is because I don’t want to force the downstream application to adhere to a specific route structure. Perhaps in my app, locale is determined by the domain and not the application route.

Further, though I want to display published content on production, I still want to edit content in the AEM author environment before I review and publish it out. If I don’t have an “author” version of my downstream app, I need a different means to instruct the app to pull from the author environment. So I use 4 key parameters:

1. The matching AEM base path – This comes statically from my route. I do not allow open-ended user-editable paths for security reasons.
2. (MSM support) Do I want to view the language-master or the rolled out live-copy?
3. (MSM support) What locale am I in?
4. Am I currently authoring?

The latter 3 act as flags which modify the base path. These flags could come from URL parameters, session storage, cookies, etc. In my case, I use URL parameters because I do not want cached AEM content while authoring.

Now, in a real implementation, to access page content in an author environment, my code needs to authenticate to AEM. This can be done via a technical account (preferred) or temporary developer token. Select one of the options linked, follow the instructions, and then come back.

Publish environment content is typically public and therefore does not require an authentication token.

Step 3: Configure AEM to Open Pages in Universal Editor

Now that I have my Page Model rendering in my downstream application, I can configure AEM to open pages of a particular path and sling:resourceType in Universal Editor. This is done by adding an OSGI configuration for the Universal Editor URL Service, which you can also read more about in Adobe’s documentation.

The mappings field has two parts: the parent path for which the Universal Editor should be opened and the target downstream application domain. [parentPath:applicationDomain]

The resourcetypes field defines the sling:resourceTypes that should be opened in Universal Editor. In our case, this is our page component.

The aemDomain field signifies that the Universal Editor should be opened on the same domain as AEM. This is critical, as being on the same domain allows sharing our user’s Adobe IMS login token with Universal Editor. This login token is later used by the Universal Editor to write back our authoring changes to the JCR.

Now authors can click the Edit button in AEM Sites Admin and have the “page” open in the context of the downstream application with Universal Editor.

This one step helps close the loop for authors. We’ve moved Universal Editor authoring as a separate domain authoring tool to integration directly with AEM. It also allows authors to continue to think about downstream app routes as “pages” in AEM even though they aren’t being rendered by AEM.

As an aside, you might notice that I’ve specified a /preview route in the downstream application; why did I do that? AEM doesn’t know which downstream app route to open for a given page. All it can do in this integration is pass details like the AEM content path.

As I said earlier, I don’t want to force my downstream application to adhere to a specific route structure. I certainly could do that; I could update the mappings field to “/content/nextDayAEM:localhost:3000/${path}”.

This would make the page /content/nextDayAEM/language-masters/en_us open like localhost:3000/content/nextDayAEM/language-masters/en_us instead. But now my app has to handle any number of route combinations.

So instead I use a common /preview path and let the downstream application figure out what route maps to the aemPath parameter and do an internal redirect, passing those 4 key parameters I identified earlier. If I’ve configured everything correctly, the downstream route + parameters should match exactly 1 AEM page.

Step 4: Write Authored Content Back to AEM

Now move on to instrument the downstream application for Universal Editor. This step involves loading the Universal Editor script, adding data-aue-* attributes to your downstream app components, and adding JSON configuration files. All of that really requires its own tutorial. So I’m going to send you over to Adobe to explain that part, but note that this example uses content fragments. The only major difference in this instrumentation for page-based resources is in the Component Definition JSON, where you should specify the plugin property as “aem” :{ “page”: {..} } instead of “aem” :{ “cf”: {..} }.

Now that all of that is complete, I should be able to log in to AEM and edit a “page.” As far as the authors are concerned, all that’s changed is a new page editor experience. This has far more ramifications than you might expect at first glance. Let’s review the headless challenges we identified from last week.

1. How does an author track content downstream from the CMS? Content is now tracked 1:1 with a “page” that matches a downstream route.
2. Useful AEM Page tooling is not available out of the box for Content Fragments. We’re now able to use Page-based tooling like link browsing, asset page references, link rewrites on moves, page launches, MSM, etc.
3. Link checker no longer functions, as AEM does not have any inherent knowledge of the downstream routes. Though AEM can’t directly check the downstream routes, it can check AEM page-to-AEM-page links.  You can have authors link them as AEM paths via the page browser and use the same route mapper you developed in Step 3 to render the links.
4. Downstream applications pull in fragments by name or by query. Whereas Content Fragments had to have unique names, Pages, due to page hierarchy, can always match the route name.
5. Existing AEM authors are typically more experienced with creating and managing pages instead of content fragments. Fixed.
6. It creates a platform disconnect. Authors must navigate to AEM to create Content Fragments but navigate to the downstream application or the Universal Editor to view changes in context. Universal Editor now exists on the same domain as AEM. It looks like part of AEM, not a separate tool.

In other words, many of the challenges we faced with a headless AEM experience are no longer relevant when we use page-based resources as the source. We’re able to leverage the strengths of traditional AEM Page Tooling because, as far as AEM and JCR are concerned, this content exists as real pages in AEM, even though all rendering can take place outside of AEM.

I hope this makes you as excited as I am, as Headless experiences just got a whole lot easier to manage!

What’s Next?

Have a tutorial you’d like to see next?  For more information on how Perficient can implement your dream digital experiences, we’d love to hear from you. We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others).

Contact Perficient to start your journey.

The post Implementing Headless Page-based Authoring in Adobe’s Universal Editor: Part 2 appeared first on Perficient Blogs.

Fewer Platforms. More Capability.  

The era of stitching together six different platforms to run a modern data environment is ending. Not because the tools got worse, but because the expectations got higher. Enterprises need data foundations that don’t just hold data. They need platforms that activate AI agents, automate management, and give information directly to the people who use it.  

These aren’t incremental feature releases; they’re a coordinated move toward a single platform that does more so you don’t have to manage more. Take native streaming, for example. Historically, if you needed real-time data pipelines, you needed separate Kafka infrastructure on top of your data warehouse. That’s overhead your team shouldn’t be carrying. Snowflake’s push toward native streaming capabilities means those separate pipelines, and the teams managing them, can consolidate into a unified stack. 

Adaptive compute extends that logic further. Instead of manually tuning and allocating compute resources across workloads, the platform adapts automatically. And the Trust Center brings AI guardrails, evaluations, and governance controls directly onto the platform, not bolted on from outside, not managed through a separate tool. Governance that lives where your data lives. 

The direction is clear: your core data platform should do more, which means you need fewer products to run your enterprise.  

CoCo for Builders. CoWork for Knowledge Workers.  

Two capabilities in particular signal where agentic AI inside the data platform is heading: CoCo and CoWork.  

CoCo is the agentic development tool, purpose-built for the people who build on the platform. It accelerates how engineers and data teams construct data products, applications, and pipelines within Snowflake’s ecosystem.  

CoWork is built for everyone else. It’s the AI agent layer for knowledge workers: the analysts, operations leads, and business users who need to act on data without waiting for a data team to build them something first.  

Instead of pulling insights out of a dashboard and manually updating Salesforce or triaging an inbox, CoWork enables agents to take that action directly. And through MCP (Model Context Protocol), those agents aren’t limited to what lives inside Snowflake. They can reach your inbox, your CRM, your operational systems, and take action, not just retrieve data.  

You can run analytics inside Snowflake and have an agent update Salesforce or open an opportunity without a manual handoff.  

Why This Matters to Your Enterprise  

Here’s the core problem we see across enterprise clients: the data stack is fragmented, governance is inconsistent, and AI initiatives stall because the foundation isn’t ready for them. Teams spend more time managing tool sprawl than actually building toward outcomes.  

The Snowflake trajectory addresses exactly that. But knowing the platform direction and operationalizing it inside a complex enterprise are two completely different things. That’s where we come in. Our connection to this shift isn’t incidental; it’s central to how we define AI-ready data modernization. 

 As the industry moves toward simplification and full-stack integration, we help enterprises move with it: reducing fragmented toolsets, embedding governance into the architecture, and building unified data foundations that AI agents can actually work with.  

How We Work With You  

We don’t drop a platform and walk away. We architect the transition.  

That means assessing where your current data estate is fractured, where separate tools are creating governance gaps, slowing pipelines, or blocking AI initiatives. It means designing a consolidation path that doesn’t break what’s working while building what comes next. And it means putting Snowflake’s native capabilities, streaming, adaptive compute, CoCo, CoWork, Trust Center, to work in ways that generate measurable outcomes.  

The Real Takeaway  

Enterprises don’t need more tools. They need a smarter platform and a partner who knows how to unlock it. We help you simplify your data foundations so you can activate agentic AI faster, and get from insight to action across the enterprise without the overhead of a fragmented stack holding you back.  

The industry is consolidating. Your data strategy should too. 

The post Here’s What Snowflake’s Announcement Means For Your Organization — and How Perficient Helps You Get There appeared first on Perficient Blogs.

But for many enterprises, the results haven’t matched the investment. The tech got faster, but the work didn’t. Most digital organizations are still trapped in a platform-centric world where the tools are working, but the teams are stuck in silos. This is where the industry is shifting, and why Optimizely Opal isn’t just an AI feature—it is an entirely new operating model.

The Platform Productivity Trap

Most enterprise digital teams are operating in a state of expensive fragmentation. You might have the best DXP in the world, but your marketers are planning campaigns in one system, your content teams are building assets in another, your developers are stuck in an endless backlog of component requests, and your analysts are providing performance reports three weeks too late.

Even when these functions live on the same platform, the human operating model remains disconnected. The tool is centralized, but the execution is not. Humans are still left to do the heavy lifting of orchestrating these disconnected pieces. They spend more time managing the tool than they do managing the customer experience.

We call this the Platform Productivity Trap. It’s the realization that owning the tools doesn’t mean you’ve solved the problems of speed, cost, and alignment.

Opal: A Shift to Intent-Driven Execution

Opal introduces a fundamental shift. Instead of humans spending hours manually moving data and context between disconnected tools, organizations can begin orchestrating AI-driven workflows that span the entire content and experience lifecycle.

This isn’t traditional automation. Automation usually means taking a manual task and making it repetitive. Intent-driven execution means the system understands the outcome you are trying to achieve and aligns the necessary resources to get there.

Teams move from asking, “Which tool do I need to use to build this page?” to asking, “What is the outcome our audience needs?”

The Rise of the Digital Experience Co-Pilot

Historically, AI in marketing has been positioned as a productivity assistant. Use it to write a headline, summarize a report, or generate an image. These are incremental gains. They save minutes, but they don’t change how the organization operates.

Opal signals a move toward something more powerful: a context-aware co-pilot embedded directly inside the execution workflow. This is a critical distinction. An AI that sits in a sidebar is a destination you have to visit; an AI that is part of the workflow is an assistant that moves with you.

This workflow embedding enables three core pillars of modern execution:

1. Content Supply Chain Acceleration: AI doesn’t just write the blog post; it understands the campaign brief, checks for legal compliance, suggests the right visual assets from the library, and prepares the content for localization—all in one stream.
2. Experimentation Planning and Prioritization: Instead of guessing which tests to run, the co-pilot analyzes your historical performance and audience data to suggest high-impact experimentation opportunities. It moves experimentation from a reactive task to a proactive strategy.
3. Operational Decision Support: The platform provides real-time signals on what is working and what isn’t, allowing teams to optimize experiences while the campaign is still running, not after it is finished.

In practice, this means AI is no longer a bolt-on to the platform. It is becoming part of how the platform thinks and acts.

Why the Operating Model is the Real Innovation

Many enterprises have already invested heavily in modern DXPs but still struggle with slow time to market and underutilized programs. These aren’t platform failures; they are delivery failures. Opal addresses these gaps not by replacing your existing capabilities, but by changing how they are coordinated.

The real value emerges when organizations begin to define repeatable AI-assisted workflows. This reduces the manual friction that kills campaign momentum. It embeds AI directly into governance, ensuring that experimentation and content quality aren’t just “nice-to-haves” but are standardized parts of the operating model.

Leaders often ask how to get more value out of their digital staff. The answer isn’t usually to hire more people; it’s to reduce the dependency on traditional, heavy delivery cycles. By operationalizing AI, you allow your teams to focus on strategy and creativity while the co-pilot handles the orchestration.

Redefining Digital Maturity

For a long time, digital maturity was measured by platform adoption. If you had a CMS and a commerce engine, you were “mature.” Then, the measure shifted toward capability: Are you personalizing? Are you experimenting?

The next phase of maturity will be measured by something else: operational orchestration. It is the ability to effectively synchronize AI across your entire digital experience lifecycle.

Optimizely Opal provides the blueprint for this transition. It isn’t about what the AI generates; it’s about what the AI enables your team to become. A mature organization in this new era is one that is more adaptive, more insight-driven, and entirely focused on outcomes rather than the mechanics of the tool.

The Strategic Question for Leaders

The most important question for senior leaders today is not, “How do we use AI in Optimizely?” That question leads to small, tactical experiments that don’t scale.

The real question is: “How should AI reshape the way our digital organization operates?”

Organizations that treat Opal as just another AI feature will see modest productivity gains. Organizations that treat it as a catalyst for operating model change will see a massive increase in experimentation velocity, lower production costs, and a more responsive digital experience.

Perficient helps organizations turn digital platforms into systems that actually improve how teams work. We focus on the outcomes, not just the implementation. Whether you are accelerating your content supply chain or optimizing your experimentation program, we help you operationalize Optimizely Opal to build a digital presence that improves continuously.

The platform is just the beginning. The operating model is where the impact happens.

The post Stop Building Platforms. Start Orchestrating Outcomes: Why Optimizely Opal is an Operating Model Change appeared first on Perficient Blogs.