This shows our novel approach at using generative AI and large language models to assist both novice and experienced integration developers identify and define the requirements, create a design, and finally begin construction of integration code using Apache Camel to be run on Guidewire Cloud Platform's Integration Gateway.
Recording is here: https://youtu.be/qtsP3uflbMk
The Ultimate Test Automation Guide_ Best Practices and Tips.pdf
Guidewire Connections 2023 DE-4 Using AI to Accelerate Application Integration
1.
2. Connections brings together P&C's largest community of
esteemed insurers, industry-leaders, and valued partners
for three powerful days of education, networking, and fun.
3. We appreciate your feedback on
Connections sessions.
Please submit your evaluation on our
Guidewire Connections event app.
Your Opinion
Matters to Us!
4. Using AI to Accelerate
Application Integration
Video: https://youtu.be/qtsP3uflbMk
Presentation:
https://www.slideshare.net/brianmpetrini/
presentations
5. Safe Harbor
This presentation contains “forward-looking statements” within the meaning of the “safe harbor” provisions of the Private Securities Litigation Reform Act of 1995, including
but not limited to, statements regarding our financial outlook and our future business momentum related to our cloud vision and strategy. These forward-looking statements
are made as of the date they were first issued and were based on current expectations, estimates, forecasts and projections as well as the beliefs and assumptions of
management. Words such as “expect,” “anticipate,” “should,” “believe,” “hope,” “target,” “project,” “goals,” “estimate,” “potential,” “predict,” “may,” “will,” “might,” “could,”
“intend,” variations of these terms or the negative of these terms and similar expressions are intended to identify these forward-looking statements. Forward-looking
statements are subject to a number of risks and uncertainties, many of which involve factors or circumstances that are beyond Guidewire’s control. Guidewire’s actual
results could differ materially from those stated or implied in forward-looking statements due to a number of factors, including but not limited to, risks detailed in Guidewire’s
most recent Forms 10-K and 10-Q filed with the Securities and Exchange Commission as well as other documents that may be filed by the Company from time to time with
the Securities and Exchange Commission.
In particular, the following factors, among others, could cause results to differ materially from those expressed or implied by such forward-looking statements: quarterly and
annual operating results may fluctuate more than expected; the impact of the COVID-19 pandemic on our employees and our business and the businesses of our
customers, system integrator (“SI”) partners, and vendors; seasonal and other variations related to our customer agreements and related revenue recognition may cause
significant fluctuations in our results of operations and cash flows; our reliance on sales to and renewals from a relatively small number of large customers for a substantial
portion of our revenue; our ability to successfully manage any changes to our business model, including the transition of our products to cloud offerings and the costs
related to cloud operations; our products or cloud-based services may experience data security breaches; we face intense competition in our market; our services revenue
produces lower gross margins than our license, subscription and support revenue; our product development and sales cycles are lengthy and may be affected by factors
outside of our control; changes in accounting guidance, such as revenue recognition, which have and may cause us to experience greater volatility in our quarterly and
annual results; assertions by third parties that we violate their intellectual property rights could substantially harm our business; weakened global economic conditions may
adversely affect the P&C insurance industry including the rate of information technology spending; general political or destabilizing events, including war, conflict or acts of
terrorism; our ability to sell our products is highly dependent on the quality of our professional services and SI partners; the risk of losing key employees; the challenges of
international operations, including changes in foreign exchange rates; and other risks and uncertainties. Past performance is not necessarily indicative of future results.
The forward-looking statements included in this presentation represent Guidewire’s views as of the date of this presentation. The Company anticipates that subsequent
events and developments will cause its views to change. Guidewire undertakes no intention or obligation to update or revise any forward-looking statements, whether as a
result of new information, future events or otherwise. These forward-looking statements should not be relied upon as representing Guidewire’s views as of any date
subsequent to the date of this presentation.
6. Brian M. Petrini
Product Manager
Guidewire
Wander Salomao
Guidewire
Senior Software Engineer
Using AI to Accelerate Application Integration
7. Using AI to Accelerate
Application Integration
Enterprise Integration is Hard
How Can AI Help?
Fundamental Integration Breakdown
01
02
03
04
Agenda
AI Program and Demo
9. Enterprise Integration
is hard!
Developing integrations is a
complex topic that requires knowledge
of the functional and nonfunctional
business requirements.
Due to the complexity and time to
learn all these aspects, an integration
developer may miss key aspects and
not deliver an integration that meets
all the requirements.
At worst the integrations could cause data
inconsistency, unavailability, or be open
to security attacks.
Protocols Data formats Database
Objects HTTP Messaging
Integration
patterns
Security Integrity
Reliability Error Handling Apache Camel
Data corruption Unavailability
Security
Attacks
10. How would an ideal integration work?
Make it so!
“I want to integrate X (consumer)
with Y (provider) on platform P (middleware).”
11. What is needed for “Make it so” to work?
End
Start
Make it so
12. Need to break it down into stages
End
Start
Requirements Design Construction Testing Maintenance
IEEE/CS - Software Engineering Book of Knowledge v3 [ISO/IEC TR 19759:2005]
13. Understand what is the output at each stage
IEEE/CS - Software Engineering Book of Knowledge v3 [ISO/IEC TR 19759:2005]
End
Start
Requirements Design Construction Testing Maintenance
Business
Analyst
Integration
Architect
Integration
Developer
Integration
Developer
Quality
Assurance
23. We tried few-shot
“Prompt engineering” …
An example of generated code
Forget all previous instructions.
You are an Integration Architect familiar with Enterprise Integration Patterns, you're here to help me
with any questions or challenges I might have related to system integration, communication
patterns, and best practices. You will follow the following script to gather information about the
integration. You will ask one question at a time. Only after collecting information for each question
will you ask the next one. If the user enters a response that does not make sense or is invalid, help
them enter a valid response.
Collect information about the primary data object (PDO) and what fields it has.
Ask the user to provide a schema for the producer API. You support OpenAPI and WSDL.
Ask the user to provide a schema for the consumer API. You support OpenAPI and WSDL.
Summarize how each one produces or consumes the object (PDO)
Ask if the user would like you to generate an Apache Camel Java DSL which transfers the object
(PDO) from the producer service to the consumer service.
If the user agrees, generate an Apache Camel Java DSL route for the integration, which extends
RouteBuilder. The route should
expose a rest endpoint which initiates the transfer. It should call the producer to get the the primary
data object and then call the
consumer with the primary data object. After generating the code, summarize it and ask if they'd like
you to modify it in any way.
Here's an example chat:
"Collect information about the the user's favorite food
Ask the user what they enjoy to cook
Ask the user if they have any food allergies
AI: What are your favorite foods?
User: I love pineapple and bacon
AI: What types of food do you enjoy cooking?
User: Roasted pineapple dishes. Especially if they also have bacon
AI: Do you have any food allergies?
User: I'm allergic to sesame"
An example of generated code
24. The more specific the prompt, the better results
Role
LLM
Example
Output
Context / history
End
Start
Requirements Design Construction Testing Maintenance
25. What are the challenges to using AI to build an integration?
*some may not be knowable a priori
Challenge: How we overcame it:
Definition of “done.”
What is needed to accomplish the task
needs to be well defined.
Need a verification that the
task is completed correctly.
Need to have a pathway or at least
prerequisites mapped out so that
the task can be accomplished.
Knowledge to accomplish the task may
not be known at the time of the request.
User may not have skills nor
education of the domain
Define a list of interface characteristics that should
be filled in by the user and work until complete.*
Use the LLM to validate the requirements against
interface characteristics to ensure nothing is missed.
Break down the process of discovery, analysis, selection, and onboarding
integration systems, as well as functional and non-functional requirements
into layers that can be stepped through as sub-tasks.
LLMs can be augmented with contextual information or at least
places to search to help a user complete a task.
Foundational models (LLMs) can provide specific explanations of
technologies and summarize educational materials.
26. Lets drill down into the requirements stage
End
Start
Requirements Design Construction Testing Maintenance
29. Functional Definition
Principal data objects
Operation/function
Read or change
Request/response objects
Technical Interface
Transport
Protocol
Data format
Interaction Type
Request-response or fire-forget
Thread-blocking or asynchronous
Batch or individual
Performance
Response times
Throughput
Volumes
Concurrency
Message size
Integrity
Validation
Transactionality
Statefulness
Event Sequence
Idempotence
Security
Identity/Authentication
Authorisation
Data Ownership
Privacy
Reliability
Availability
Delivery assurance
Error Handling
Error Management capabilities
Known exception conditions
Source: https://www.slideshare.net/kimjclark/interface-characteristics-kim-clark-and-brian-petrini
Describe integrations with Interface Characteristics
31. User conversation patterns
Start End
User provided everything we needed to know
Start End
Users input was missing some requirements detail
Question Response
32. User conversation patterns
Start End
User provided everything we needed to know
Start End
Users input was missing some requirements detail
Question Response
Start End
Users input was missing some requirements detail in an area they are inexperienced
Question Response Education Re-question Response
38. If the Consumer can’t consume directly, and the
Provider can’t or won’t change their capabilities,
then we need Ivan the Integrator
Ivan (Developer of Integration logic) - if the Consumer can’t consume the Provider’s
data, actions, or notifications directly, then Ivan develops integration logic to resolve
the differences between the interface characteristics.
Ivan
<Integrator>
Application
Integration
Data
Action
Notification
<Consumer>
Application
Domain
<Provider/Producer>
Application
Domain
Data
Action
Notification
39. Get Data
Discover
Analyze
Select
Onboard
Always Request-Response
Always Read
What are the subtleties of Get Data?
● Do we enough query information to get precisely the
data we want?
● Are we allowed to access the data?
● Granularity – single retrieve or is a composition required?
● If composition, do we know the linking fields
(e.g. foreign keys)?
● Does the existing data model suit our purpose?
● Is the data current?
● Is the data of sufficient quality?
● Is there too much data (e.g. multiple records
vs. single record)?
● Is the payload large (e.g. images, blobs, etc)?
Discover
Analyze
Select
Onboard
40. Request Action
Discover
Analyze
Select
Onboard
Request-Response or One-way
Read or Change
What are the subtleties of Request Action?
● Which action? Create, Update, Delete, Open,
Close Submit, etc?
● Granularity – is the action available as a single action
or is it multiple?
● Understanding the function – under fulfilling
or over fulfilling?
● What is the state model that this action is related to?
● In which states can the consumer participate?
● What does the end state look like in success and failure?
● Do we fully understand the valid paths through
the state model?
● Are we dealing with data distributed across
multiple systems?
● Are data integrity rules inherently enforced, implicitly
enforced, or does the consumer need to implement them?
Discover
Analyze
Select
Onboard
41. Receive Notification
Discover
Analyze
Select
Onboard
Always One-way
Always Read
What are the subtleties of Receive Notification?
● We do we receive the notification? Push, Pull, Poll?
● Does the notification contain all the data we need,
or just the keys?
● If data is provided, is it complete notifications or deltas?
● Do we need all of the notifications we are receiving?
● Are the notifications timely?
● Can notifications be lost or duplicated?
● Do notifications arrive in order?
Discover
Analyze
Select
Onboard
42. Provider Selection Process
If more than one possible provider
Discover Analyze Select
Does the provider offer
the service or data
model needed?
Review detailed functional
and nonfunctional
characteristics
Filter based on mandatory
characteristics and
sort on prioritized non-
mandatory characteristics
Onboard
Set up a formal
relationship and
secure access
47. Where we might go next:
Provide assistance to other stages
e.g.
Construction of Camel routes
…
e.g.
Create Test cases based on
requirements
…
e.g.
Modify existing integrations based on
new requirements
…
48. Where we might go next: Incorporate private IP
DB Vector
DB
Orchestrator Output
Validator
Prompt
Constructor
Input
Validator
LLM
DB Vector
DB
Orchestrator Output
Validator
Prompt
Constructor
Input
Validator
LLM
Add Guidewire APIs, docs, data models to a local index and private LLM
49. Software Engineering Design Assistant (SWEDA)
Requirements Design Construction Testing Maintenance
DB Vector
DB
Orchestrator Output
Validator
Prompt
Constructor
Input
Validator
LLM
50. Where we might go next:
Reverse engineer requirements?
Requirements Design Construction Testing Maintenance
DB Vector
DB
Orchestrator Output
Validator
Prompt
Constructor
Input
Validator
LLM
e.g.. Gosu Analysis for Migration
52. Connect with the Guidewire Developer Community
Subscribe to the
Developer Newsletter
Receive our monthly email with links to new
resources, events, blog posts and more.
Learn and grow with the largest network of developers in the P&C industry
Visit developer.guidewire.com
Find curated pages, code samples, one-click
access to API references, certification paths,
and technical deep dives, that help level up
your skills as a Guidewire developer.
Join the discussion
on Stack Overflow
Participate in a peer-to-peer forum with other
Guidewire developers. Find questions and
post answers to share your expertise!
53. Thank you!
Brian M. Petrini
bpetrini@guidewire.com
Wander Salomao
wsalomao@guidewire.com
54. We appreciate your feedback on
Connections sessions.
Please submit your evaluation on our
Guidewire Connections event app.
Your Opinion
Matters to Us!
55. 56
Further reading
•Enterprise Integration Patterns (2004) [Hohpe, Woolf]– Book -
https://www.enterpriseintegrationpatterns.com/
•Interface Characteristics (2008-2011) [Clark, Petrini] – Presentation, Paper
•Integration Design Course (2008-2014) [Clark, Petrini] – Description, Materials (Dropbox)
•Fundamental integration and service patterns (2013) [Petrini, Clark] – Presentation
•Patterns for API Design (2022) [Zimmerman et al.] – Book - https://microservice-api-
patterns.org/