AI Mastery for Technical Business Analysts
AI Architectural Strategy
Beyond the Buzzwords: Architecting AI
As a technical business analyst, you've moved past defining what AI is. The real challenge is architecting how AI systems work within your enterprise. This isn't just a technical puzzle for engineers; it's a strategic decision that balances cost, performance, and long-term flexibility. Your role is to guide these decisions by understanding the critical trade-offs at the heart of AI architecture.
Choosing Your Engine: LLMs vs. SLMs
The first major architectural choice often involves the model itself. While Large Language Models (LLMs) like GPT-4 get most of the attention, their smaller counterparts, Small Language Models (SLMs), are often a more practical choice. Think of it like choosing a vehicle. An LLM is like a massive lorry: it has immense power and can carry almost anything (handle a wide range of tasks), but it's expensive to run, slow to manoeuvre (high latency), and overkill for delivering a small parcel.
An SLM is like a delivery scooter: it’s nimble, cheap to operate, and incredibly efficient for a specific task, like navigating a dense city (a niche business domain). It can't haul furniture, but it will get that document across town faster and cheaper than the lorry ever could.
| Feature | Large Language Model (LLM) | Small Language Model (SLM) |
|---|---|---|
| Cost | High (training, inference, licensing) | Low (cheaper to run and fine-tune) |
| Latency | High (slower response times) | Low (faster, near real-time responses) |
| Specificity | General-purpose, broad knowledge | Specialised, high accuracy on narrow tasks |
| Data Needs | Requires massive, diverse datasets | Can be fine-tuned on smaller, domain-specific data |
| Best For | General chatbots, content creation | Document classification, sentiment analysis, specific data extraction |
For example, a company-wide, public-facing chatbot might benefit from an LLM's broad conversational ability. However, for an internal tool that analyses financial reports to extract specific metrics, a fine-tuned SLM would deliver faster, more accurate, and cheaper results.
Build vs. Buy: The Core Dilemma
Once you have a sense of the model size you need, the next question is how to source it. This is the classic 'build vs. buy' dilemma, adapted for the AI era.
Deploying AI at scale is as much an architectural and operational challenge as it is a data science one.
'Buying' an AI Model
This usually means using a managed, proprietary service from a major cloud provider, like AWS Bedrock, Google's Vertex AI, or Azure OpenAI Service. You pay for access to state-of-the-art models via an API. The primary advantage is speed and simplicity. You don't manage infrastructure, and you get access to powerful models immediately.
The trade-off is control and cost. You are tied to the provider's ecosystem, and their roadmap is not your own. Costs can become unpredictable at scale, and you have limited ability to customise the model's core behaviour beyond what the service allows.
'Building' an AI Model
This doesn't mean creating a new LLM from scratch. For most organisations, 'building' means taking a powerful open-source model, such as Meta's Llama 3 or Mistral's Mixtral, and fine-tuning it on your company's private data. This gives you a specialised model tailored to your specific domain.
The benefit is control and specialisation. The model is yours, it runs on your infrastructure (or private cloud), and it can be highly optimised for your tasks. The downside is the required expertise. You need a team that can manage the fine-tuning process, handle the infrastructure, and maintain the model over time.
| Approach | Pros | Cons |
|---|---|---|
| Buy (Managed Service) | Fast to implement, low initial effort, access to cutting-edge models | Vendor lock-in, less customisation, potentially high long-term cost |
| Build (Fine-tune Open-Source) | Full control, deep customisation, potential for lower cost at scale | Requires significant in-house expertise, higher initial effort |
Orchestrating the System
An AI model is rarely a standalone product. It must connect to your existing enterprise systems to be useful. This process is called Model Orchestration: defining a workflow that integrates the AI model with data sources, legacy applications, and user interfaces through APIs.
As a BA, your job is to define the business logic for this orchestration. For instance, if a customer asks, "What was my last order and do you have similar products?", the orchestration layer might:
- Make an API call to the CRM to fetch the user's order history.
- Send the product information from that order to an AI model with the prompt, "Find products similar to these."
- Receive the AI's recommendations.
- Format the complete answer and send it back to the user.
This API-led approach is crucial. It treats the AI model as just another service in your architecture. This makes the system modular. If you later decide to switch from a proprietary LLM to a fine-tuned open-source SLM, you only need to change the API call in the orchestration layer, not re-engineer the entire application.
This is the core of modern AI architecture: making strategic, informed decisions about model types and sourcing, and then connecting them intelligently into your existing business processes. It's about building systems that are not only powerful but also practical, sustainable, and aligned with your organisation's goals.
A financial services company wants to deploy an internal AI tool to quickly analyse thousands of daily transaction reports and flag specific anomalies based on a well-defined set of internal rules. Which model type represents the most practical and efficient choice for this task?
What is the primary advantage of the 'buy' approach to sourcing an AI model, such as using Azure OpenAI Service?