5 AI Project Foundations
Before we begin I think its worth mentioning the master Japanese swordsman Miyamoto Musashi, a Samarai from the 14 hundreds who after defeating 62 men in one on one combat wrote the book on the strategy of battle called The 5 Rings. As a Samarai he believed to be the best fighter you had to be balanced. You had to practice caligraphy, sculpture, poetry, art, teaching and philosophy. He believed you couldn’t have holes in your mental, physical or spiritual game. A popular quote from Miyamoto Musashi states:
“If you know the way broadly, you will see it in all things.”
Why am I discussing a warrior in an article about AI foundations? Because being involved in Artificial Intelligence means that you must be knowledgable in many disciplines to see the bigger picture in a way that allows you to work backwards to success, not just forwards. Client “Here is where we need to be,” You, “Here is how we get there.”
If you are not sure where to get started here are a few links to some good sources to expand the mindset to other indirect disciplines.
Top 10 Architecture Books: All of the books you can buy from Amazon are top notch and can be purchased used if your lucky - this is where your building principles came from so buy a couple and consider it an investment and a journey.
Nassim Taleb: Antifragile This was meant for the financial markets but applies to design beautifully and its a rather interesting read.
Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations (why do I need to know about blockchain? See quote please.)
You should supplement your broad reading with a decent list of technical books and I can reference @gocloudarchitects on Youtube for the top 10 list for now. My preference is more AI, SF related but these are great foundational books that you can keep and reference throughout your life. I have 3 on this list and they are excellent.
That is a start for now. (I’ll put together a top 10 book list soon)
Note: The Foundations of this article is not to be confused with the layers of AI which are different as this these are PROJECT DRIVEN foundational components. AI Layers include items like ‘Reasoning Layer’, ‘Action Layer (flows, Apex, approval processes, API automations, etc)’ ‘Feedback (Governance) Layer’, etc. That is a separate article I will work on later.
Today’s Article Topics:
Use Cases (Project clarity & ROI)
Data Management (Data Quality)
System (Tech) Infrastructure (Data Architecture & Governance)
Integration Strategy (Optimization)
Document Management & Automation (Invoice processing, Contract analysis, Insurance Claims)
Now lets dive in…
1) Use Cases: This is where we define the business clarity. Lets start with the BIG challenge - achieving ROI (or ROE Return on Energy) based on the AI Use Cases. I am leading with Use Cases for this article because it appears as the most forward challenge for a company. If the Use Case is too big, there is too much risk from funding, failure repercussions (someone has to sign off on this), loss of trust from leadership which will put more walls up for future endeavors, etc. Then, there is making the Use Case too small where there is not enough value or business benefit, defined metrics, support or visibility. The budget may not extend beyond the Pilot funding, no matter how successful. It has to hit a sweet spot so lets discuss driving this from the top down. How?
There should be a driving Company Vision or Mantra to drive success of your AI projects. The success of AI should have metrics to aim for that align with the Vision. Funding for the long term requires defined metrics of success. Make it big, bold, defined but achievable. Look to ROI framing to really address ROI in a methodical way. How to frame (map) ROI to specific hierarchies of value which we are going to get into below.
Here is the reality of choosing solid use cases. Budgets require justification. The CFO (finance) will want measurable impacts, IT Governance is prioritizes risk and return, other projects will be competing for funding. Without some type of revenue increases, efficiency gains, or risk reductions your AI initiative will move closer to the left of the desk, near the trash bin. Go back to Vision.
Why does the Vision have to be so strong? Vision will be imbedded in the culture of the company and be a driving force from leadership down. It is because AI is not an enhancement, upgrade or add on. AI is an operational model shift that will effect everyone at the company and doing business with the company. It requires dedication, grit and consistent focus with clear objectives and milestones. Value may not be achieved until foundations in people, processes or technology are fixed and this takes time and dedication.
For Enterprise Companies, AI projects tend to fall into areas that have (1) large amounts of data, (2) repetitive processes or decisions (3) expensive human labor (pulling and aggregating docs, customer support).
For my coming AI workflows I will be focusing on:
Customer Support Automation to handle support questions and case routing.
Enterprise Knowledge Search which will allow employees to search across multiple systems (KB, wikis, CRM records, emails, slack messages, etc)
Document Processing & Automation where AI will extract information from contracts, invoices, forms and pdfs and apply to digital templates.
Predictive Maintenance which predicts asset/part failures before they happen. This is a bit more complex as the workflows will be pulling from a general IoT sensor record or maintenance log.
AI Use Cases have different types so labeling will be required as different AI types require different architectures. Some TYPE examples are as follows:
Predictive: Ex. Lead Scoring
Generative: Ex. Case Summary
Optimization: Ex. Route Scheduling
Classification: Ex. Tickert Routing
Before we leave Use Cases here are the top 5 concerns blocking AI budgets in 2026: (highest concern to lowest)
# 1: Unclear ROI and Financial Discipline
Integration & Infrastructure Complexity
Governance, Risk & Security Concerns
Talent & Skills Shortage
Budget trap - Pilot to Production Funding as discussed above.
2) Data Management for AI Data Foundation (Data Integrity = quality, quantity, accessability, alignment, traceability, etc). Opening the door to the companies data will reveal projects in their own as they find out that AI is only as good as the data and the architecture supporting this data. The gap of getting to “good” data may be a tremendous effort. Consider the fact that Data is the number one hidden blocker in AI implementations.
A Data Management Plan for AI is dedicated to output which means putting data in the right Users/Systems hands at the right time per the right prompt or “need/request”. By defining a plan companies take immediate ownership and accountability. Where are we going? How do we get there? A DMP defines the following:
Data Processing Standards & Methods: How data needs to be collected, processed, secured, and governed throughout the companies AI lifecycles, from ingestion to AI model retirement which maps to technical debt covered below.
Data Definitions for clean pipelines (metadata > integrations > UI, etc) This can be considered part of governance above which “Defines” and “Ensures” data is clean (define clean), compliant (define compliant) and accessible (available when needed) , focusing on quality, ethics, and security to drive reliable, scalable AI initiatives. Note: Ethics just to be clear deals with transparency and audit processes for bias detection.
A Symantic Layer converts technical, complex data into understandable business terminology, making it easy for non-technical users to query data. This ensures consistent metrics, KPIs, and governance across all reporting and analytics tools. Think of this in terms of AI prompts. (just a note - its the layer that sits between raw data source systems like warehouses and BI tools).
AI-Ready Data Architecture: This insures that the data is in the right system for execution. You can keep data that is actionable in your ERP systems or data warehouses if you can use Integration or other methods to ensure it is available when prompted by the system or User. An example is AI document automation. For Users needing invoices, contracts, medical forms, or training documents for field users, this knowledge must be in a system that allows these documents to be relevant while at the same time immediately accessible. Ex. For Field Service Technicians to have access to product or other tool or asset knowledge documents in real time and also available to load documents before going off line in the field.
There are MORE to discuss on what makes a Data Management Plan (for AI) but this is just to get some ideas and momentum flowing for you - the reader.
A brief note to Metadata. ‘Metadata is the meaning of the data’. Without complete or comprehensive standards around your Metadata and API naming conventions what do you have? Data without meaning. I consider this technical debt (covered below).
Some of the components of an AI DMP are covered in the next items starting with data identification (where is it?), acquisition (how do we get it?) and preparation (define the gap to good).
For more readings on Data Management go to The 6 Primary Components of Asset Centric Projects.
3) System (Technical) Infrastructure: Is your architecture supporting your data AI ready? If yes, what is your readiness score on not just your data per system but your architecture?
When I arrive at a clients site one of the first things I do before addressing the requirements, integrations and other moving components is to address where the data lives. This involves an assessment of the architectural discipline of the system with the output of a visual diagram and context of the clients system infrastructure. I don’t identify only the systems they think we need to address their requirements but ALL systems and where the master data will be. I once experienced a last minute system update that contained large data sets that had not been brought to the teams attention. Is that the clients fault? Nope, I owned it because I did not address all the systems that may have down or upstream impacts to the data we needed to fulfill the lifecycle. After that misstep I have always taken a methodical and diligent process of addressing this step early. No acceptions.
Once we have identified the system of data we figure out its “state” or grade on 2 levels. One is the system in itself and another is how it fits to the AI initiative. While it may be excellent for their current needs, it may not be acceptable for the AI requirements or use cases. I usually provide Red,Yellow,Green with context so that the customer understands the assessment of the architecture system & data and gap analysis to good or Green. The System Strategy is how we as a team take actions to address this gap if it exists. Quick example, metadata may not be standardized and descriptions may be missing, there may be too much technical debt that needs to be cleaned up, the model may not work or be flexible enough for new requirements. I worked with multiple systems that alone did their job but when data needed to be moved to the target for actionable data we had transformation on 2 and the rest did not pass the data requirements.
Question on Technical Debt in systems? How does the client currently handle technical debt? To be clear, Technical debt is “a software development concept where taking shortcuts or choosing easy, temporary solutions now—often to meet tight deadlines—results in higher, compound "interest" in the form of extra development effort and maintenance later”. Tech Debt will lead to fragility (*vs antifragility), bugs, and low customer satisfaction.
There are many debts: ie.
Code Debt: (messy code) systems become harder to maintain over time resulting in slower costly development later.
Data Quality Debt: Incomplete, inaccurate, unstandardized, or unreliable data that slows actions. Think of the nightmare that is unstandardized metadata.
Architectural Debt: (poor system or modeling designs) Building inflexible models that don’t scale as data volume grows. Boxed models that have ceilings and need restructuring.
So how would you rate a company data system with 70/30% technical debt? What about 80/20%? AI will drive up the data X percent. Better to address these items early and quickly.
Next we address the question of how to position the data for execution be it client or customer. I deal with Field Technicians so I am looking for data that is immediately actionable from positioning knowledge to asset logistics be it parts, tools, skills or certifications. Do we move the data to the target or build integrations to the master systems? Can we even move the data to the target?
There is also the concept of no system of record but we will get to that later.
Let’s get to our next executional component.
4) Integration Infrastructure: After you have your data & system assessments you can progress to the ‘AI Integrations Strategy’. It is based off the Use Case Types which define the architecture needed to meet the business objectives of the Vision.
An Integration Strategy is a Roadmap that provides guidelines for integrating into existing business workflows, applications and execution points or channels (think customer service UI vs Field Service Tech - back to Use Cases).
We have already discussed data preparation and location (centralized data), now we need to get busy using APIs or middleware to connect system data to AI models in Salesforce to provide workflow automation to handle tasks autonomously (Agentforce). There is quite a bit to cover here so I will reference the article on Integrations which contains quite a few practices and rules that apply to supporting your integration infrastructure. It’s long but if you don’t have patience you probably haven’t made it this far anyway. lol.
Just for starters you can google something simple like “When to use apis vs middleware for AI integrations” and the information will provide some foundational elements on when to use which one with a set of rabbit holes to dive into. If your a techie you should fix a cup of coffee - block a couple hours, take a deep meditative breath before clicking into the matrix on this one. So good. If this is too simple then write an article on the next level and share the love for others.
Besides this article for starters, Some key concepts on this search that are important: Data Transformation (*I will do an article just on this one), Dealing with disparate systems, using standard web protocols (SF offers this in spades), Microservices Architecture, Grounding (big one for minimizing risk on accuracy like hallucinations.
5) AI Document Management & Automation: Where are my Contracts, Invoices, Warranty Forms, updated recent notes on that last call, etc for X client at X location asking about X assets or X project. If you could automate this what would it mean to your users?
Forget trying to find out the ROI - just think about the time it would save to gather all this documentation from disparate systems, people, actions, etc. This is actually a great use case. And… ask the AI system to put it into a template in X order with an introductory overview and next steps your company is taking or has taken according to the state/context of the information it received.
Also, automate a schedule request for a meeting to review these items.
I can keep going here - This is your knowledge management strategy which we will get into in future articles.
Project Documentation: As this is a foundational discussion it makes sense that documentation makes its way to the top items as it provides the foundation for the build. I have shown up to projects with little documentation or had to chase different people down to find out things that should have been well documented. It’s sloppy and risky to not have some standards for your projects. In some cases I couldn’t even get the documentation because the person had left the company and his laptop was cleaned and passed to the next employee. In other cases someone goes on vacation without passing on the knowledge needed. I’ve done this from scratch more than once so I am putting a request to manage your Clients documentation with the CoE or Product Managers who should be responsible for the sign-off and management of the Implementation documentations. It polite and thoughtful for the next teams coming in so do a good job. I have written on documentation multiple times but feel an approach from a project perspective is best here.
When I begin a project the teams are tasked with a few deliverables from the following documents:
Functional Design Document (FDD) “Outlines how a software system or application will operate from a user's perspective. It translates business requirements into specific, actionable functionalities, including user interactions, screen mockups, data workflows, and system behavior. It focuses on the "how" of the system, acting as a crucial bridge between stakeholders and developers”
Contains the following: Includes process flows, user interface (UI) mockups, data models, input/output data, and user roles.
Solutions Architectural Design Document (SADD) provides high level business alignment. “TDD is a blueprint that connects business goals with the necessary technology solutions. Provides a strategic overview of the system, ensuring it is scalable, reliable, and fits within the broader organization.” Defines how different components, data, and technologies work together to solve a specific business problem.
Contains the following: Business context & goals, logical diagrams, technology stack, data flow architecture, security strategy, and non-functional requirements that may impact scale.
Technical Design Document (TDD) addresses the ‘How’. It is a “detailed, actionable guide for developers. It translates the high-level architecture into concrete implementation steps, defining specific data structures, API contracts, and code-level components.”
Contains the following: Database schemas, API definitions (endpoints, payloads), detailed algorithms, error handling, class diagrams, and specific infrastructure configurations.
In my last project as with all large projects I delivered a FDD and SADD. I started with the System diagram with all systems defined for reference from a more detailed excel sheet master. The target system objects are provided in a table below the system section with descriptions and future state designs and systems to target mappings.
Below these two is the Integration Design model with a current and future state which goes through the versions as we updated different integrations points and concepts.
If its blocked the system boxes get a RED, The integration lines get a RED. If its in progress (no decision yet), its YELLOW, and if it is signed off - good to go - its GREEN. The document can be complex in nature but it should be very simple to understand from a high level view.
Well - This covers it for now. While you may feel I missed X items - you are probably right but these as I mentioned are based on actual projects and my experience. So best of luck with your implementations everyone and let your Miyamoto shine.