Adobe Experience Manager continues to lead the enterprise content management space, combining proven enterprise-grade tooling with flexible delivery, powerful extensibility, and dependable performance. But leadership doesn’t stand still. Newer Adobe Experience Manager offerings embrace a highly flexible and scalable serverless architecture, built from the ground up and crafted from Adobe’s 20+ years of content management experience. Adobe has been working diligently on a new delivery architecture that leverages edge-based scaling and recommends serverless edge workers in place of application servers and services. This solution is called Edge Delivery Services (EDS).

“Wait, I thought EDS was document authoring?”

Not necessarily. The important thing to understand about Edge Delivery Services is that, as its name suggests, the solution is primarily a change in the content delivery tier. That in turn, once you adopt it, you’re faced with a new set of decisions to make about where you want to store the content and which UI you want to use to author it.

When you move to EDS, you always have the same Adobe-managed Delivery and Services tiers, but you can bring your own CDN to sit on top of them and the tiers that come before are flexible. When we talk about the Platform tier, there are two primary content store and management options.

1. Document Authoring
   This newer approach can use Adobe’s DA.live product, Google Docs, or SharePoint as a content store. (You may recognize DA.live by its previous names — Dark Alley, Project Franklin, or Project Helix.) Adobe heavily recommends DA.live and Document Authoring via Experience Workspace for new AEM implementations.
2. AEM as a Cloud Service (XWalk)
   When AEMaaCS is used in EDS, it’s called AEM XWalk (crosswalk). It continues to have all of the content storage and management benefits of AEM as a Cloud Service, but the content is delivered quite differently. Instead of the traditional approach where web requests come to the AEM Publish instance via Apache Sling, Adobe’s Edge Delivery Service constructs a traditional HTML hierarchy and serves it at the CDN. There’s no more Sling resource mapping and page compilation at the time of an end user’s request.

Now, to further paint this picture, I think it’s helpful to compare pieces of the classic AEM headful stack and their equivalent headful options in the Edge Delivery Services model.

As Adobe has moved to a more decoupled architecture, you may have noticed that the number of options per stack capability has also grown. This is important as selecting a platform type forces you into a set of content stores, which then forces you into a set of compatible authoring UIs.

Before you do anything else, you need to decide if you want a Headful or Headless AEM implementation. If you’re not sure how to decide, I recommend my previous blog on the topic.

One important amendment based on insights from Adobe Summit is that Adobe is making a large investment in agentic AI and tooling for the experience layer. While choosing headless will decouple the CMS from the presentation layer and have a higher degree of freedom, you’re also limiting Adobe’s ability to add value at the presentation layer. New presentation-layer features and agents will only work in a headful experience.

With user-driven web experiences on the horizon, this is an increasingly important consideration. You may ultimately find it more valuable to cater to user interests with adaptable, personalized experience rendering than stick with traditional business-driven experiences.

Once you’ve made the Headful vs Headless call, the next set of capability decisions becomes clearer.

Headful Decisions

If you decide on a headful approach, you’re implicitly picking EDS. From there you decide between XWalk or Document Authoring as the content source. While the exact pros and cons of each solution are beyond the scope of this blog post, I will offer a few light comparisons.

1. XWalk utilizes all of the existing AEM content management tooling, security, workflows, WYSIWYG authoring, and content policy controls.

2. Document Authoring focuses on author empowerment in the document-style authoring that most users already understand.

Decision – Headful with XWalk

If you decide on XWalk, the AEMaaCS Java Content Repository will be your primary content authoring store, just like in a traditional AEMaaCS implementation. The AEM Sites Admin will continue to manage your page content. What changes are the following:

• You will need to utilize AEM blocks instead of Touch UI components
• Universal Editor will be your primary component and page editor.

Decision – Headful with Document Authoring

If you decide on Document Authoring, you have several choices for a primary content authoring store. I highly recommend DA.live as the primary source as it contains CMS tooling, though you may have existing documents in Google Docs and SharePoint you want to integrate. Document Authoring implementations require AEM blocks. Then you have a choice about how your authors edit content:

1. Edit directly in the Document UI.
2. Edit in Universal Editor for a more WYSIWYG experience.

Headless Decisions

If you decide on a headless approach, you have a different series of decisions to make. Both the AEMaaCS JCR and Document Authoring can be a headless content store. As I said earlier, the exact pros and cons of each headless solution are beyond the scope of this blog post, so let’s focus on the subsequent decisions.

Decision – Headless with AEMaaCS

If you decide to use AEMaaCS, do you utilize:

1. Content fragments
2. Page-based resources
3. Both?

I covered these pros and cons in my last blog post. If you use page-based resources, you will always use the Universal Editor as the authoring UI. If you use content fragments, you will use the content fragment editor and optionally the Universal Editor if you want WYSWYG-style authoring.

Now, there’s one caveat with AEMaaCS to be aware of. If you use page-based resources, as of mid-2026, there is no OOTB schema definition available for AEM Blocks (EDS-style components).  If you want small headless payloads, you will have to utilize classic Sling Models as described in my last blog post or develop a custom solution.

Decision – Headless with Document Authoring

If you decide on a headless approach with Document Authoring, I would highly encourage you to use DA.live and not Google or SharePoint. In a headless use case, you need a schema-based JSON export. Of the previously mentioned document stores, only DA.live offers that out of the box. Document Authoring implementations require AEM blocks implementations. Then you have a choice to make about how your authors edit content. You can have them edit directly in the document view or utilize the Universal Editor for a more WYSIWYG experience.

Wrap-up

With an increasingly decoupled AEM architecture, there are more options than ever before to meet the needs of your organization. Still need help deciding? Be on the lookout for a future blog post that walks through the paradigm shift that is Document Authoring. Or reach out directly! 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 At the Speed of Content: Adobe’s Lightning Fast Product Offerings appeared first on Perficient Blogs.

JMeter is a free tool made by Apache that helps you test how well your website, app, or API performs when lots of people use it at the same time. It acts like many users hitting your system all at once to see how it handles the pressure.

It’s great for testing:

• Websites and web apps
• REST and SOAP APIs
• Databases

Other services like FTP, JMS, LDAP (though most people use it for web and API testing). JMeter runs on Java, so make sure you have Java installed — version 8 or higher (Java 17+ is even better). The latest version of JMeter is around 5.6.3.

#2. Apache JMeter Working

JMeter is a Java based application or tool that simulates a group of users and sends requests to a target server. And hence, return statistics which show the functionality and performance of the server.

Working of Apache JMeter is explained in the image below:

#3. JMeter Test Plan Structure

Everything in JMeter lives inside a Test Plan — think of it as your test notebook.

Basic tree structure looks like this (from top to bottom):

• Test Plan (the root / main folder)
  • Thread Group (your virtual users — most important!)
    • Samplers (what action each user does — e.g. HTTP Request to open google.com)
    • Logic Controllers (if/loop/while — optional for now)
    • Pre/Post Processors (prepare or clean data — optional)
    • Assertions (check if response is correct — optional)
    • Timers (add think time between clicks — very useful!)
    • Config Elements (HTTP Header Manager, Cookies, etc.)
  • Listeners (how you see results — tables, graphs, reports)

Most beginners start with just: Test Plan → Thread Group → HTTP Request → Listener.

#4. Create Your First Test Plan (Step-by-Step)

Step 1: Download and open JMeter

1. Download JMeter from the official Apache page:
   https://jmeter.apache.org/download_jmeter.cgi
2. Download the binary file (ZIP or TGZ). For example, Apache JMeter 5.6.3 has both apache-jmeter-5.6.3.zip and apache-jmeter-5.6.3.tgz.
3. Unzip / extract it anywhere on your machine.
4. Open the bin folder:
   1. Windows: double‑click jmeter.bat
   2. Mac/Linux: run jmeter.sh
      
5. JMeter GUI opens and you will see a blank Test Plan.

Step 2: Add a Thread Group (users)

1. Right‑click Test Plan → Add → Threads (Users) → Thread Group

Thread Group controls how many users run your test and how the load starts.

Step 3: Create a GET API test (List objects)

3.1 Add HTTP Request sampler

Right‑click Thread Group → Add → Sampler → HTTP Request

3.2 Fill HTTP Request fields (IMPORTANT) 

Use these values: 

• Name : HTTP Get Request 

• Protocol: https 

• Server Name or IP: api.restful-api.dev (only domain, not full URL)  

• Method: GET  

• Path: /objects  

 The real endpoint is:  https://api.restful-api.dev/objects 

Common mistake: Don’t put https://api.restful-api.dev/objects inside “Server Name”. If you add path there, JMeter can fail with host errors (UnknownHost). Use domain in Server Name and endpoint in Path.

3.3 Add Listeners

Right-click Thread Group → Add → Listener → View Results Tree (best for debugging)

• Add Summary Report or Aggregate Report (for final numbers)

3.4 Save Your Test Plan

Save your file as something like FirstGetApiTest.jmx

3.5 Run the Test

Click green Play button (or Run → Start)

3.6 Watch the Results

Watch the results in View Results Tree!

Step 4: Create a POST API test (Add an object)

4.1 Add another HTTP Request sampler

Right‑click Thread Group → Add → Sampler → HTTP Request

4.2 Configure POST sampler fields

• Name: HTTP Post Request
• Protocol: https
• Server Name or IP: api.restful-api.dev
• Method: POST
• Path: /objects

4.3 Add JSON Body (Body Data)

Inside the POST HTTP Request sampler, go to Body Data and paste this JSON:

JSON : {

“name”: “Apple MacBook Pro 16”,

“data”: { “year”: 2019,

“price”: 1849.99,

“CPU model”: “Intel Core i9”,

“Hard disk size”: “1 TB”

} }

This sample object structure matches the API style shown by restful-api.dev (objects contain name and flexible data).

4.4 Add Header (Content-Type)

For POST requests, you should send JSON with correct header.

1. Right‑click the POST HTTP Request (or Thread Group) →
   Add → Config Element → HTTP Header Manager

2. Add header:

• Content-Type = application/json

This tells the server your request body is JSON.

Step 5: Add Listeners (to see results)

For debugging (best for beginners)

• Right‑click Thread Group → Add → Listener → View Results Tree

For final numbers (report-style)

Add one of these:

• Summary Report or Aggregate Report

Listeners show your execution results in table/tree/graph formats and can save results too.

Step 6: Save your test plan

Save file: JMeter recommends saving your test plan before running.

Step 7: Run the test

Click the green Play button (or Run → Start).

Now open View Results Tree to see:

• Request details
• Response body
• Status code (200/201)
• Any error message

You now understand how to create GET and POST API tests in JMeter.
Next, let’s take your learning one step further with two practical real‑world challenges.
The first covers JWT Authentication Testing in JMeter, and the second focuses on Data‑Driven Testing at Scale with JMeter (CSV + Groovy).

Challenge A: JWT Authentication Testing in JMeter Using DummyJSON API

This section provides a simple, production-friendly approach to testing JWT authentication in Apache JMeter using the DummyJSON Auth API. It demonstrates how to build a minimal test plan that performs a complete authentication flow with only the essential JMeter components. The guide walks through sending a login request to generate a JWT accessToken, extracting the token using a JSON Extractor, and finally invoking a protected endpoint (/auth/me) using the required Authorization: Bearer <token> header. With a focus on clarity and minimalism—no timers, assertions, or extra plugins. This blog serves as an ideal starting point for understanding token-based authentication testing in JMeter.

Step 1: Create a New Test Plan

1. Open Apache JMeter 5.6.3+
2. Go to File → New
3. Rename it to: DummyJsonAuthTest

Step 2: Add HTTP Request Defaults

1. Right‑click Test Plan →
   Add → Config Element → HTTP Request Defaults
2. Enter the following values:

• Server Name or IP: dummyjson.com
• Protocol: https

This sets the base URL so you don’t repeat it everywhere.

Step 3: Add Global HTTP Header (Content-Type)

1. Right‑click Test Plan →
   Add → Config Element → HTTP Header Manager 
2. Add only one header:

• Name: Content-Type
• Value: application/json

This ensures your JSON login body is posted correctly.

Step 4: Add a Thread Group

1. Right‑click Test Plan →
   Add → Threads (Users) → Thread Group 
2. Configure the following settings:

• Number of Threads: 1
• Ramp-Up Period: 1
• Loop Count: 1

This keeps the test extremely lightweight.

Step 5: Add Login API (POST /auth/login)

1. Right‑click Thread Group →
   Add → Sampler → HTTP Request
2. Set the following:

• Name: Login – POST /auth/login
• Method: POST
• Path: /auth/login

3,  Go to Body Data tab → paste:

{

“username”: “emilys”,

“password”: “emilyspass”,

“expiresInMins”: 30

}

This request matches DummyJSON’s official documented example.

Step 6: Extract JWT accessToken

This is the most important step.

1. Right‑click Login sampler →
   Add → Post Processor → JSON Extractor
2. Configure the following:

• Variable Name: accessToken
• JSONPath Expression: $.accessToken
• Default Value: NOT_FOUND

Why $.accessToken?
Because DummyJSON returns this exact field name in the login response.

 Step 7: Add Protected API (GET /auth/me)

1. Right‑click Thread Group →
   Add → Sampler → HTTP Request
2. Configure the following:

• Name: Protected – GET /auth/me
• Method: GET
• Path: /auth/me

Step 8: Add Authorization Header (Bearer Token)

1. Right‑click Protected sampler →
   Add → Config Element → HTTP Header Manager
2. Add:

• Name: Authorization
• Value: Bearer ${accessToken}

DummyJSON explicitly states that /auth/me must receive the accessToken via the Bearer header.

Step 9: Add View Results Tree (Optional but Useful)

1. Right‑click Thread Group →
   Add → Listener → View Results Tree

This will allow you to see the response body and confirm that the token extraction works correctly.

Step 10: Run the Test

Click the green Start button ().

Expected Behavior

• Login API returns 200 with a JSON containing accessToken.
• The JSON Extractor captures the token.
• Protected API returns 200 with authenticated user details.

If you see:

401 Unauthorized

Check the View Results Tree → Request headers → Authorization must look like:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs…

Challenge B: Data‑Driven Testing at Scale with JMeter (CSV + Groovy)

This section explains an easy and practical way to run large‑scale API load tests in JMeter without errors or data conflicts. When many virtual users use the same username or repeated IDs, tests often fail because of server caching or duplicating data issues. To avoid this, the blog shows how to give each virtual user its own unique data using a CSV file, small random values, and Groovy scripts.

You’ll learn how to create a clean and simple JMeter test plan that reads login details from a CSV file, skips the header row, adds random values, and generates unique fields through a Groovy PreProcessor. The test then logs in, extracts an access token, and uses that token to call a protected endpoint. This guide helps you build reliable, scalable, and realistic API tests in JMeter.

1) Prepare Your CSV Data

Create a file named users.csv. Include a header and tab or comma as your delimiter. Two examples:

Option A — Tab‑separated

username        password

emilys emilyspass

michaelw         michaelwpass

sophiab            sophiabpass

Option B — Comma‑separated

username,password

emilys,emilyspass

michaelw,michaelwpass

sophiab,sophiabpass

We’ll configure JMeter to ignore the first line so the header is not treated as credentials.

2) Create a New JMeter Test Plan

1. Open JMeter → File → New.
2. Rename Test Plan to: DummyJsonAuthTest_data_driven

3) Add HTTP Request Defaults

• Test Plan → Add → Config Element → HTTP Request Defaults
  Set:
  • Protocol: https
  • Server Name or IP: dummyjson.com

(Prevents repeating the base URL for every request.)

4) Add Global HTTP Header Manager

• Test Plan → Add → Config Element → HTTP Header Manager
  Add: Content-Type : application/json

5) Add CSV Data Set Config (Critical)

• Test Plan → Add → Config Element → CSV Data Set Config

Configure:

• Filename: users.csv
• Variable Names: username,password
• Delimiter:
  • \t if your file uses tabs
  • , if your file uses commas
• Ignore first line: True  (ensures the header row is not treated as data)
• Recycle on EOF: False
• Stop thread on EOF: True
• Sharing mode: All threads

With Ignore first line = True, JMeter reads username,password strictly as variable names, and your data rows become proper user credentials.

Setting Recycle=False / Stop on EOF=True ensures each row is used once per thread and unused threads stop when data runs out.

6) Add a Thread Group

• Test Plan → Add → Threads (Users) → Thread Group
  Example settings (tune to your needs):
  • Number of Threads (users): 5
  • Ramp‑Up (sec): 5
  • Loop Count: 1

Each thread will pick the next row from users.csv.

7) Add the Login Request (POST /auth/login)

• Thread Group → Add → Sampler → HTTP Request
  • Name: Login – POST /auth/login
  • Method: POST
  • Path: /auth/login

Body Data:

{

“username”: “${username}”,

“password”: “${password}”,

“expiresInMins”: 30,

“note”: “rnd_${__Random(1000,9999,)}”

}

Why this helps

• ${username} / ${password} come from the CSV row for that thread.
• ${__Random(1000,9999,)} appends a small random number per request (handy when you want trivial uniqueness).

8) Generate Unique Variables (JSR223 PreProcessor, Groovy)

We’ll create values that are globally unique per sampler execution, perfect for payload fields like emails or order names.

• Right‑click Login – POST /auth/login → Add → Pre Processors → JSR223 PreProcessor
• Language: groovy
• Script:

// Unique email and order name per sample

import org.apache.commons.lang3.RandomStringUtils

String random = RandomStringUtils.randomAlphanumeric(8)

vars.put(‘uniqueEmail’, ‘test’ + random + ‘@example.com’)

vars.put(‘uniqueOrderName’, ‘Order_’ + System.currentTimeMillis())

“

You can now use ${uniqueEmail} and ${uniqueOrderName} in any downstream JSON body or header to avoid caching/collisions.

If you see a class not found error for RandomStringUtils, add Apache Commons Lang to JMeter’s /lib folder and restart JMeter. Most distributions already include it, but environments vary.

9) Extract the Token (JSON Extractor)

• Right‑click Login – POST /auth/login → Add → Post Processors → JSON Extractor
  Configure:
  • Names of created variables: accessToken
  • JSONPath expressions: $.accessToken
  • Default Values: NOT_FOUND

The login response should return accessToken. This extractor exposes it as ${accessToken} for the next step.

10) Add a Protected Request (GET /auth/me)

• Thread Group → Add → Sampler → HTTP Request
  • Name: Protected – GET /auth/me
  • Method: GET
  • Path: /auth/me

Add a Header Manager (child of this sampler):

• Authorization : Bearer ${accessToken}

11) Add One View Results Tree (for quick verification)

• Thread Group → Add → Listener → View Results Tree

Run a small test (1–5 threads) and verify:

• Login → 200 OK, response contains accessToken.
• Debug Sampler (optional) shows username, password, uniqueEmail, uniqueOrderName, and accessToken.
• /auth/me → 200 OK with user details.
• No more Invalid credentials due to the header row being treated as a login attempt.

The post JMeter Performance Testing appeared first on Perficient Blogs.

1. Why Testing Is Required

Traditional software is predictable; LLMs are probabilistic. Responses may vary depending on prompts, context, and available information. DeepEval addresses this through automated test cases, evaluation metrics, benchmarking, and continuous reporting.

2. Types of Test Cases

Single-Turn, Multi-Turn, and Arena Test Cases provide increasing levels of evaluation coverage.

3. End-to-End LLM Evaluations

Treat the application as a black box and evaluate final user outcomes.

4. Confident AI Platform Features

Confident AI extends DeepEval with Test Runs, Datasets, Arena comparisons, Experiments, Prompt Studio, Reporting, Observability, Governance, and collaborative evaluation workflows.

5. Why This Matters for Business

Objective quality measurement reduces risk and increases trust in AI systems.

Conclusion

DeepEval converts subjective AI evaluation into measurable engineering metrics.

6. Evaluation Report Screenshot

Figure 1. DeepEval / Confident AI Test Runs dashboard.

7. Python Installation

pip install deepeval

pip install –upgrade deepeval

deepeval –help

pip show deepeval – Get the version of deepeval

8. Running DeepEval Locally 

One important observation from my testing:

I successfully performed local DeepEval testing without using an OpenAI API key by executing custom Python-based evaluation logic and creating evaluation reports locally.

This demonstrates that evaluation concepts and reporting can be validated locally using Python implementations. However, DeepEval also supports advanced LLM-as-a-Judge metrics.

Arena Test Case Diagram

Model A Answer —-> Compare —-> Winner
Model B Answer —-^

End-to-End Evaluation Flow

User Query -> AI App -> Response -> DeepEval Metrics -> Report -> Improvement

LLM Evaluation Lifecycle

Datasets -> Test Cases -> Evaluation -> Metrics -> Test Runs -> Optimization

• Test Runs: Benchmark and track evaluation results over time.
• Datasets: Manage golden datasets and evaluation samples.
• Arena: Compare prompts, models, and responses side-by-side.
• Experiments: Measure quality impact before release.
• Prompt Studio: Iterate and validate prompts systematically.
• Reports & Dashboards: Centralized visibility into AI quality.
• Observability: Monitor production traces and quality signals.
• Governance: Standardize evaluation across teams.

References

https://deepeval.com/docs/evaluation-test-cases

https://deepeval.com/docs/evaluation-end-to-end-llm-evals

https://app.confident-ai.com/project

The post DeepEval Explained Simply: Why Testing AI Outputs Matters appeared first on Perficient Blogs.

From EDC systems, laboratory data, clinical trial management systems (CTMS), and safety data to operational and real-world sources, the volume of information flowing through clinical programs continues to grow.

At the same time, AI is creating new opportunities to analyze that information at a scale that wasn’t previously possible. Organizations can no longer afford to treat quality as something that gets evaluated at the end of a study. Increasingly, they need to identify risks, signals, and data issues while there is still time to act.

That’s creating a new challenge for clinical teams. The industry’s problem is no longer access to data. It’s deciding where experts should focus their attention.

More Data Hasn’t Made Review Easier

For years, life sciences organizations have invested heavily in data platforms, automation, and analytics. Yet clinical trial delays remain stubbornly persistent.

According to the Tufts Center for the Study of Drug Development, approximately 80% of clinical trials still miss their planned enrollment timelines. If the industry has more data, more technology, and more AI than ever before, why do delays remain so persistent?

A core reason is that visibility alone doesn’t create action. Data may be available, but it’s not always organized, prioritized, or presented in a way that helps teams determine what requires attention first. Clinical data managers, medical reviewers, and biostatisticians still spend significant time reconciling information across multiple systems, reviewing discrepancies, and tracking down answers before meaningful analysis can even begin.

Clinical teams are being asked to do all of this at once:

• Review growing volumes of study data
• Identify potential data issues and safety or efficacy signals earlier
• Resolve discrepancies faster
• Support increasingly complex protocols
• Deliver cleaner, submission-ready datasets

The result is a familiar pattern. Teams accumulate more information than ever before, while the people responsible for reviewing it face increasing pressure to move faster without sacrificing quality, safety, or compliance.

The Shift Toward Risk-Based Clinical Data Review

One of the most important changes happening in clinical development today is the move toward more proactive and risk-based approaches.

The goal isn’t simply reviewing data faster. It’s bringing quality, oversight, and risk identification earlier into the trial lifecycle. Instead of treating every data point equally, organizations are asking a different question: Where should we focus first?

As data volumes continue to grow, that question becomes increasingly difficult to answer. Clinical teams can’t scale review activities in direct proportion to the amount of information flowing through a study. They need better ways to prioritize attention, identify meaningful risk, collaborate, and focus effort where it can have the greatest impact.

Why AI-Driven Clinical Review Is Becoming a Competitive Advantage

When people think about clinical trial performance, they often focus on enrollment, protocol design, or study execution. But clinical data review plays an equally important role.

The faster teams can identify anomalies, review discrepancies, detect potential safety or efficacy signals, and align around a common view of study performance, the faster they can make informed decisions. Instead of spending time searching for information, teams need critical signals surfaced in the moments they matter most. That shift is already underway across the industry.

Quality is becoming part of the process from the beginning rather than something that gets evaluated after the fact.”
— Prabha Ranganathan, Associate Vice President, Life Sciences

Organizations are increasingly moving quality and oversight earlier in the trial lifecycle rather than relying on downstream review and remediation. As a result, clinical data review is becoming less about finding issues after they occur and more about identifying risks while there is still time to act.

Better Decisions Require More Than Visibility

Which discrepancies represent meaningful risk? What signals may indicate a developing safety concern? Which issues can wait, and which require action right now?

These are the questions that can’t be answered by another dashboard alone. They require a trusted view of data, clear prioritization, and the ability to connect signals to action while there is still time to influence the outcome.

That’s why clinical data review is evolving from a process focused on finding issues to one focused on identifying risk sooner.

Perficient’s Clinical Data Repository and Review solution was designed to support that shift. By combining a unified clinical data foundation with agentic AI capabilities, it helps organizations move beyond data aggregation and turn growing volumes of clinical information into faster, more informed decisions.

As data volumes continue to grow, competitive advantage increasingly comes from finding critical signals sooner—not reviewing more data.

The Next Challenge Isn’t More Data

The life sciences industry has spent years solving the problem of data collection. The next challenge is helping clinical teams keep up with what that data is trying to tell them.

Organizations that gain an advantage won’t necessarily be the ones generating more information. They’ll be the ones that help their experts find the right signals faster, make better decisions sooner, and act before risks impact study outcomes.

Interested in seeing what that could look like in practice? Reach out to schedule a demo with Perficient’s Healthcare & Life Sciences team to explore how AI-driven clinical review can help your teams focus less on administrative work and more on the decisions that move studies forward.

The post Faster Decisions Start With AI-Driven Clinical Review appeared first on Perficient Blogs.

Health plans are losing Star ratings because insights arrive too late to change outcomes. AI closes that gap by getting the right insight to the right person while there is still time to act.

At this year’s Databricks Data + AI Summit (DAIS), health plan leaders consistently pointed to the same challenge: improving outcomes in an increasingly complex data environment. I spoke with Matthew Giglia, Healthcare and Life Sciences Forward Deployed Engineer at Databricks, about how AI is helping healthcare organizations get more value from their data.

More Data Isn’t the Missing Piece

Health plans no longer have a data problem. Most already have access to claims and clinical data, social determinants, member engagement history, quality measures, and risk scores.

But more data has not automatically translated into better Star ratings, faster interventions, or clearer insight into what is working.

That signals an important shift: the bottleneck is no longer data.

The Gap Between Insight and Action

Data was never the real constraint. Decision latency is. An insight sitting in a dashboard doesn’t close a care gap. A risk score doesn’t improve a measure on its own. A report doesn’t change a member outcome unless it reaches the workflow where decisions are made — while there is still time to act.

In many plans, the distance between knowing and doing is still measured in weeks. By then, the opportunity to intervene has often passed.

The problem is not the model or the report. It’s how long it takes to respond once an opportunity is identified. That’s why a health plan can have sophisticated analytics and still struggle to move its Star ratings.

AI Should Not Mean More Noise

The organizations getting real value from AI aren’t using it to gather more information. They’re using it to shorten the distance between insight and intervention.

In practice, AI helps health plans:

• Prioritize what matters instead of surfacing every signal with the same urgency
• Surface risk earlier so care managers and quality teams can intervene before an outcome is locked in
• Reduce the noise that buries care managers in alerts they can’t work through

While the challenge shows up differently for health plans and providers, Giglia sees the same shift from the technology side:

Health systems used to treat yesterday’s data as good enough. Now, with AI in the mix, they need that data connected across every domain it touches: governed, tagged, and traceable back to its source, but usable the moment it’s needed.” — Matthew Giglia, Databricks

The technology to do this exists. The harder work is making it practical inside the workflows care managers already use every day.

Stars Performance Is a Decision Problem

Stars ratings are often treated like a measurement problem — they aren’t. The measures matter, of course. So do dashboards, scorecards, and reporting cycles. But performance changes when teams make better decisions sooner.

That means helping teams answer the questions that shape daily work:

• Which members should we prioritize this week?
• Which interventions are most likely to improve a specific measure?
• Where is staff effort going without measurable impact?
• What actions were taken, and what changed as a result?

Whether the measure involves medication adherence, preventive screenings, or member experience, the challenge is often the same: identifying the right intervention early enough to influence the outcome.

These decisions cannot be answered by visibility alone. They require trusted data, clear prioritization logic, workflow integration, and feedback loops that show whether an action worked.

This is where Stars intelligence needs to show up: in outreach planning, care management queues, quality interventions, and resource allocation. Not after the fact and not buried in another report. It needs to be available in the flow of work while the decision still matters.

How We Partner with Databricks to Close the Gap

Perficient and Databricks partner together to help health plans close the distance between data and action.

Databricks provides a governed foundation that brings claims, clinical, and social determinants of health data into a trusted environment for analytics and AI. Perficient helps health plans put that foundation to work. We define the governance, prioritization logic, and adoption strategy needed to move AI from concept to operational impact.

The goal is not another proof of concept. It is to help care managers, quality leaders, and operations teams make faster, better-informed decisions in the workflows that drive Star performance.

Our Databricks Brickbuilder Specialization for Healthcare & Life Sciences reflects that combination. It brings together technical depth on a governed platform with healthcare expertise that translates AI into measurable outcomes.

That’s exactly the kind of work we want partners to lead. We can provide the platform and accelerators, but healthcare expertise is critical to making the solutions real.” — Matthew Giglia, Databricks

The Plans That Win Won’t Be the Ones with the Most Data

Health plans need to prioritize getting trusted information to the people who know what to do with it — while there is still time to change the outcome. That is the practical promise of AI in Stars performance.

Data, models, and platforms all matter. But they are infrastructure. The real advantage is the ability to decide and act faster than the plan next to you.

That’s what will move a Star rating next cycle: not another layer of data, but whether the member who needed the call got it in time.

Curious what else came up in health plan conversations at DAIS this year? See Why AI Stalls for Health Plans: Turning Data Into Action to see how this same issue is playing out across the industry.

Connect with our Healthcare & Life Sciences team to see what closing the distance between data and action could look like for your plan.

The post Why More Data Won’t Fix Your Star Ratings appeared first on Perficient Blogs.

With tools like Figma Make, Copilot, and increasingly capable design assistants, teams can generate layouts, components, flows, and interactive prototypes in a fraction of the time it once took. Work that previously required days can now be accomplished in hours—or even minutes. 

As a result, a question is becoming increasingly common: 

If AI can generate high-fidelity designs almost instantly, why bother with low-fidelity wireframes at all? 

It’s a reasonable question. It’s also the wrong one. 

The assumption behind that question is that UX activities are simply increasingly polished versions of the same thing—that discovery becomes wireframes, wireframes become mockups, mockups become prototypes, and prototypes become products. 

If that were true, skipping straight to polished designs would be an obvious efficiency. But that isn’t how UX works. 

UX Is Not a Screen Production Process 

One of the most persistent misconceptions about UX is that its primary purpose is producing screens. 

It isn’t. The purpose of UX is reducing uncertainty. 

Every activity in the UX process exists because there is a specific question the team needs answered before investing additional time, money, and effort. As those questions are answered, uncertainty decreases and confidence increases. 

Viewed through that lens, the purpose of each activity becomes much clearer. 

These are not interchangeable deliverables. They reduce different types of risk. A team that skips an activity is not simply skipping work. It’s choosing not to answer a particular question. 

Sometimes that’s fine. Sometimes it’s expensive. 

Why Low-Fidelity Wireframes Still Matter 

Consider the debate around skipping low-fidelity wireframes. 

There are certainly situations where moving directly to high-fidelity designs makes sense. If a product already has a mature design system, well-defined requirements, established user workflows, and a library of proven components, much of the structural uncertainty has already been resolved. In those situations, jumping directly into polished designs can be entirely appropriate. 

Those situations exist. They’re just not the norm. 

Most projects begin with incomplete requirements, evolving stakeholder expectations, competing priorities, and unanswered questions about user behavior. In those environments, low-fidelity wireframes provide value for a reason that has nothing to do with artistic skill or speed. 

They make change inexpensive. 

Moving a box on a wireframe takes seconds. Changing a workflow takes minutes. Reworking a polished interface with dozens of components, interaction states, accessibility requirements, and responsive behaviors can take days. 

More importantly, low-fidelity artifacts change the conversation. When stakeholders see sketches and wireframes, they tend to discuss structure, content, priorities, and workflow. When stakeholders see polished interfaces, they often discuss colors, typography, spacing, and visual details. The more finished something looks, the less willing people become to question whether the underlying solution is correct. 

Wireframes help teams evaluate the foundation before decorating the house. 

AI Changes the Speed—Not the Purpose 

This distinction is at the heart of AI’s impact on UX. 

AI can generate ten dashboard concepts in minutes. It can create navigation models, interface variations, onboarding flows, prototypes, and even production-ready code with remarkable speed. 

What it cannot determine is whether users need a dashboard in the first place. 

Before any design should be evaluated, teams still need answers to questions such as: 

• Are we solving the right problem? 
• What is creating friction today? 
• What do users actually need? 
• Which assumptions have been validated? 
• What outcome are we optimizing for? 

Those aren’t design questions. They’re uncertainty questions. And uncertainty is what UX exists to reduce. 

AI is transforming how quickly teams create artifacts. It can generate concepts, suggest layouts, summarize research, automate documentation, produce code, and eliminate countless hours of repetitive work. What it has not changed is the purpose of the UX process. 

The goal was never simply to create screens. The goal was to learn enough about users, problems, and business needs to make informed decisions. AI accelerates execution. It does not eliminate uncertainty. 

The Two Jobs of UX 

One mental model helps explain where AI creates value—and where it doesn’t. Every UX project contains two fundamentally different jobs. 

Job #1: Creating Artifacts 

• Sketches 
• Wireframes 
• Mockups 
• Prototypes 
• Specifications 

Job #2: Reducing Uncertainty 

• Understanding users 
• Identifying problems 
• Aligning stakeholders 
• Evaluating tradeoffs 
• Validating assumptions 
• Testing solutions 

AI dramatically accelerates the first job. The second job remains where UX creates most of its strategic value. In fact, the faster artifact creation becomes, the more important the second job becomes. Producing the wrong thing quickly is still producing the wrong thing. 

A More Useful Question 

The most valuable question organizations can ask is not: 

Can we skip wireframes now that we have AI? 

Instead, ask: 

What uncertainty was this activity intended to reduce, and has that uncertainty already been resolved? 

That question applies to wireframes, discovery research, usability testing, competitive analysis, stakeholder workshops, and every other UX activity. If the answer is yes, eliminating or compressing a step may be entirely reasonable. If the answer is no, the uncertainty hasn’t disappeared. It has simply been deferred to a later—and usually more expensive—point in the project. 

The Real Impact of AI on UX 

AI is reshaping UX processes. Some activities are becoming faster. Some are being combined. Some traditional deliverables are becoming less important than they once were. 

A designer who once sketched on paper may now generate concepts directly in a design tool. A team that previously created dedicated wireframes may move directly into editable prototypes. 

The artifacts may change. The questions do not. And those questions are the reason UX exists. Because the real value of UX has never been creating screens. It has always been reducing uncertainty before uncertainty becomes expensive. 

AI helps us produce answers faster. UX helps us make sure we’re answering the right questions. 

The post AI Can Generate Your Designs Faster—But It Can’t Tell You Which Questions to Skip appeared first on Perficient Blogs.

This achievement reflects our continued investment in industry expertise, technical excellence, and innovative solutions that help manufacturers, transportation providers, and energy organizations modernize operations, improve decision-making, and unlock new business value from their data.

Our combined expertise in Manufacturing, Transportation & Energy and the Databricks platform enables us to help organizations accelerate digital transformation initiatives, optimize operations, and scale AI-driven innovation. Earning this specialization reinforces our commitment to delivering measurable business outcomes for clients across these critical industries.  – Nick Passero, Databricks Practice Lead, Director Data and Analytics

How We Earned the Specialization

Proven Industry Impact

Databricks evaluates partners on their ability to deliver measurable value for organizations across manufacturing, transportation, and energy. Perficient has helped clients improve and improve important business operations. For example, a leading Midwest energy provider had a hard time getting accurate screen-scraping reports for field operations. This caused safety concerns for field teams.

We used Databricks and Microsoft Power BI to centralize and display location data to understand if supervisors were providing proper oversight of their teams in the field, resulting in a more consistent measurement of team movement to give management better and more reliable insight into field operations. 

When a leading global mobility solutions provider had an abundance of inefficient, outdated, and individual platforms for its data management, we implemented Databricks Delta Tables and Workflows to stream unorganized customer data into one unified platform. Our solution increased data accessibility, visibility and accuracy.

Solutions like these empower organizations to improve product quality, reduce costs, increase asset reliability, and make faster, data-driven decisions across their operations.

Commitment To Thought Leadership

Another component of the specialization is a demonstrated commitment to advancing industry knowledge through thought leadership. Databricks requires partners to continually contribute insights that help organizations navigate emerging opportunities in data, analytics, and artificial intelligence.

The post Perficient Earns Databricks Brickbuilder Specialization for Manufacturing, Transportation & Energy appeared first on Perficient Blogs.

What I Built 

The agent creates Journeys and Journey Tasks through a conversation. You start by defining the Journey itself, then walk through the tasks that make it up, including task type, performer, initiator, expiration, and due date. If you already have a Journey Template ID, you can also use the agent to modify an existing journey rather than starting from scratch. The goal was to make something approachable for someone who does not live in Oracle every day. 

What Surprised Me 

The current out-of-the-box options for AI agent creation are more limited than I expected. Most pre-built tools are designed for fetching data, not making changes. If you want the agent to actually do something in your system, you are building custom tools and explicitly defining every field it can access. The bigger the scope, the more complex that gets. Each element added is an opportunity for the agent to break, and I learned that the hard way. 

The context awareness was a pleasant surprise. Asking for five onboarding tasks returned results that felt like they came from someone who understands HR. It picked up on implied differences, like new hire versus manager onboarding, without me needing to spell that out. That was genuinely useful. 

Consistency was a different story. The agent’s delivery shifted from session to session. Functionally, it was performing the same tasks, but the way it was asking me questions was always different. That required more tuning than I thought. 

The last thing that caught me off guard was how useful AI was in the building process itself, not just the end product. Writing the agent’s instructions, handling API calls, and making sense of error logs. Things that would have slowed me down significantly before became much more manageable with AI involved. 

What This Means for HR Teams 

This does not replace HR judgment. It removes the part that slows everything else down. A lot of time spent building a journey goes toward figuring out where to start. This skips that part. You describe what you need, get back something usable, and edit from there.  

Closing Thought 

Building this opened my eyes to what an AI agent is capable of. It made me wonder how far this could realistically go. Is there a future where entire Oracle modules are configured through a chat window? Maybe. The technology is closer to that than I would have guessed before starting this project. The harder question is where the sweet spot is between AI assisted configuration and professional implementation. Some things benefit from the speed and accessibility AI brings. Others need the judgment and accountability that comes with a real implementation. Finding that line is going to be one of the more interesting conversations in this space over the next few years. 

The post Building an AI Agent for Oracle HCM Journeys: What I Learned Along the Way appeared first on Perficient Blogs.

This is where Battery Passports come into play. 

At Perficient, we’ve built a Battery Passport offer that enables manufacturers to transform complex battery data into meaningful customer experiences, operational insights, and regulatory compliance capabilities. 

The Databricks Data Intelligence Platform is the foundation of the Battery Passport solution we built. Databricks provides the scalable data and AI platform necessary to manage battery information throughout the entire lifecycle. 

Why Battery Passports Matter 

A Battery Passport serves as a digital record of an electric vehicle battery’s lifecycle, health, origin, and performance. It brings together critical information such as battery state of health, charge history, degradation rates, and more. 

These insights create value across the EV ecosystem: 

• Consumers gain confidence in battery condition and vehicle value. 

• OEMs improve transparency, strengthen loyalty, and create opportunities for subscription-based services. 

• Dealers and insurers benefit from trusted battery health information. 

• Manufacturers can support emerging regulatory requirements and sustainability initiatives.  

The Consumer Demand for Transparency Is Already Here 

Perficient research reveals a significant gap between EV interest and EV adoption. While 46% of consumers would consider purchasing an EV, only 14% currently own one.

What’s driving that hesitation? 

The leading concerns revolve around battery information transparency, such as life and charging capacity, charging downtime, and servicing complexity. 

Our research also found that approximately 61% of EV owners and EV-curious consumers would be more likely to participate in an ownership experience program if it provided insights into their vehicle’s value. Similarly, more than 60% of surveyed consumers expressed interest in loyalty experiences that provide visibility into EV value. 

These findings highlight a growing opportunity: consumers want more transparency about battery health and vehicle value. Battery Passports provide the mechanism to deliver it. 

Building the Battery Passport on Databricks 

Databricks provides the centralized foundation necessary to support a modern Battery Passport ecosystem. Powered by Databricks Lakehouse, battery telemetry is streamed via Lakeflow into Delta Lake, governed through Unity Catalog, and enriched with Agent Bricks AI agents for real-time health scoring. 

Using our Battery Passport solution built on Databricks, manufacturers can deliver a unified battery data + AI platform that brings together: 

1. Lifecycle Traceability

Databricks enables organizations to ingest and unify data from manufacturing, assembly, logistics, vehicle operations, and recycling systems. Such lineage creates an end-to-end digital history for every battery, which supports both customer transparency and compliance requirements. 

2. Scalable Data Management

Battery telemetry generates enormous volumes of data. Databricks enables manufacturers to store, process, and analyze structured and unstructured data at scale, creating a centralized repository for battery lifecycle information.  

3. Regulatory Readiness

Global regulations increasingly require visibility into battery sourcing, sustainability, and lifecycle tracking. Databricks provides the governance, lineage, and reporting capabilities needed to support evolving Battery Passport compliance initiatives.  

Turning Battery Data Into Customer Confidence 

The future of mobility depends on trust. Consumers need confidence that their battery will perform as expected, retain value, and remain transparent throughout its lifecycle. 

A Battery Passport bridges that gap by transforming complex battery data into actionable insights for consumers, manufacturers, dealers, insurers, and regulators. 

With the Databricks Data Intelligence Platform serving as the underlying data + AI platform, manufacturers can move beyond fragmented systems to create a connected Battery Passport ecosystem that delivers traceability, intelligence, and business value at scale. 

As regulations like the EU Battery Passport mandate take effect, OEMs that fail to operationalize battery data will face both compliance risk and competitive disadvantage. 

The post From Data to Trust: Powering Battery Passports through Databricks AI appeared first on Perficient Blogs.

Each year, the Databricks Data + AI Summit sets the agenda for enterprise data and AI. With more than 30,000 attendees at Moscone Center, this year felt different. Not because of any single announcement, but because of what the announcements collectively signal: we’ve crossed a threshold. The conversation is no longer about whether AI is capable. It’s about whether your organization is ready.

Here are my five most important takeaways from DAIS 2026:

1. AGI Is Already Here, But Your Organization Isn’t Ready for It

The most provocative moment of the entire summit came in the opening minutes of CEO Ali Ghodsi’s keynote. His message was unambiguous: AGI is here, and the problem is no longer about intelligence.

This wasn’t entirely surprising. Those of us who follow Ghodsi’s interviews and public commentary have heard him building toward this framing for a while. But hearing it as the opening thesis of a 30,000-person summit, backed by a full product portfolio organized around it, made it land differently.

Databricks organized its entire 2026 product portfolio around four enterprise pain points: context, control, cost, and choice. If AI is already smart enough, the bottleneck is whether your organization can give AI systems the grounding they need to act appropriately on your behalf, within your business, using your data, and according to your rules.

We’ve watched this shift happen live in client engagements. The question stopped being, “Can we build this?” It’s now entirely about trust, grounding, and governance. That reframing should inform every AI investment decision you’re making today.

2. Genie Ontology: The Most Important Foundation Play at DAIS

Genie Ontology is a continuous-learning semantic layer that automatically extracts business meaning from your data estate: tables, queries, dashboards, and pipelines. Rather than forcing analysts and engineers to manually annotate data assets with business definitions, Genie Ontology learns the language of your organization, including your metrics, processes, KPIs, and organizational hierarchy, and makes that knowledge available to every AI agent operating in your environment.

The capability is genuinely compelling. A general-purpose model doesn’t know what “net revenue” means in your organization, which pipeline feeds your forecasting dashboard, or what your data governance team considers a reliable source. Genie Ontology builds that knowledge automatically, and that changes what AI agents can do inside your environment.

But it raises a question worth sitting with. The traditional practice of building an ontology is a human activity. It requires deliberate decisions about what concepts matter, how they relate, and what to leave out. An automated system that learns from how your organization already queries its data is powerful, but it is only as good as the patterns it learns from. If your data estate has inconsistencies or inherited assumptions baked into years of query history, those will come along for the ride.

We lean toward believing the strongest outcomes will come from pairing Genie Ontology’s automated extraction with targeted human curation of the concepts that matter most. That said, we are actively exploring how far the automation can take you before curation becomes necessary, and for which use cases the automated layer may be sufficient on its own. This is one of the more interesting questions coming out of DAIS 2026.

3. Genie One Signals the Arrival of the True AI Coworker, Not Just a Chatbot

Building directly on the context foundation of Genie Ontology, Databricks launched Genie One, and it represents a meaningful evolution beyond what most enterprises have deployed as AI assistants to date.

Genie One is available across web, iOS, Android, Slack, and Microsoft Teams. It goes well beyond question-and-answer interactions: it creates documents, runs scheduled tasks, and takes external actions via Model Context Protocol tools. Think of a business analyst asking a question in Slack, getting a governed answer drawn from the lakehouse, and scheduling a follow-up report, all without opening a BI tool. Alongside Genie One, Databricks also launched Genie Agents, the evolution of Genie Spaces, which can now be shared externally through a new OpenSharing capability.

The broader point for enterprise leaders is this: the distinction between an AI tool and an AI coworker is moving from marketing language to a real architectural distinction. Genie One is not a chatbot bolted onto a data platform. It is a context-aware agent that understands your business data, takes action on your behalf, and operates across the communication channels your employees already use every day.

4. Unity AI Gateway Is the Answer to Agent Sprawl

One of the most underappreciated risks of the agentic AI era is what analysts are already calling agent sprawl: the uncontrolled proliferation of AI models, agents, tools, and workflows independently deployed across an organization without centralized oversight.

Most organizations we are talking to right now have multiple AI initiatives running in parallel with no shared cost visibility, no unified audit trail, and no way to enforce policy across them. Each team did the right thing locally. The problem is organizational, not technical. Nobody planned for the inventory.

Databricks’ answer is Unity AI Gateway, which extends the proven Unity Catalog governance model into the runtime layer of AI workloads. It provides centralized controls for governance, observability, budgeting, model routing, and security across an organization’s entire AI estate, including tools, MCP services, skills, traces, cost, and runtime behavior.

For technology and risk leaders, the message is clear: start building your AI governance architecture now, before the agent inventory becomes too large to manage.

5. The Lakehouse Gets Real-Time: LTAP, Lakehouse//RT, and Agentic Data Engineering

Every enterprise running real-time use cases today is paying a tax: a separate serving layer, a synchronization pipeline, a second governance model. The promise of collapsing all of that into a single platform is not a new idea. Many technologies have tried it. Most have not gotten it right.

Databricks is taking a serious run at it. The centerpiece announcement was LTAP (Lake Transactional/Analytical Processing), a new architecture that unifies OLTP and OLAP on a single copy of data using open formats. The practical foundation is Lakebase, Databricks’ new serverless Postgres offering, which puts operational data inside the lakehouse boundary rather than alongside it. Paired with this is Lakehouse//RT, powered by Reyden, a ground-up compute engine rewrite built for the concurrency and latency demands of real-time analytics.

We have been testing Reyden already. In our own work with a healthcare client running FHIR data at scale, we saw sub-100 millisecond patient-specific lookups across billions of records on a small cluster, without a separate serving layer or a second copy of PHI. The results were compelling enough that we wrote about it in depth. If you want the technical detail, you can read more here.

Of all the announcements at DAIS 2026, this is consistently the one our clients are most excited about. The question is not whether the architecture is interesting. It is whether Databricks can deliver on it at enterprise scale across diverse workload types. We are in the field testing it, and we are excited to see where it goes.

What This Means for Your Organization

DAIS 2026 painted a coherent and compelling picture of where enterprise data and AI are heading. Databricks is positioning itself as the open foundation for the agentic enterprise: context through Genie Ontology, governance through Unity AI Gateway, real-time infrastructure through Lakehouse//RT and Reyden, and an AI coworker layer through Genie One.

At Perficient, our Databricks practice is already working with clients to translate these announcements into actionable roadmaps. Whether you are in the early stages of evaluating the Databricks platform or are a mature Databricks customer looking to accelerate your agentic AI capabilities, the conversation to have right now is where these investments fit within your data and AI strategy.

The post 5 Takeaways from DAIS 2026 You Need To Know appeared first on Perficient Blogs.