Volume 2 · Chapter 2 — Customer Discovery, Current State Assessment & Application Onboarding Framework
Discovery Before Dashboards
The structured discovery methodology Kamiti runs before a single monitoring agent is installed — business understanding, application and infrastructure inventory, dependency mapping, gap analysis, and the deliverables that earn the right to onboard.
Executive Summary
Why discovery is the most important phase
One of the biggest reasons managed service projects fail is that teams rush into implementation without understanding the customer’s environment. Installing monitoring agents is easy. Understanding the business is difficult.
Enterprise customers expect the service provider to understand their business processes, critical applications, infrastructure dependencies, integration points, production risks, existing monitoring gaps, and business priorities.
Discovery is not a technical exercise. It is a business understanding exercise.
The discovery phase should answer
- What applications are business critical?
- Which systems generate revenue?
- Which systems affect manufacturing?
- Which systems support customers?
- Which systems can tolerate downtime?
- Which systems require 24×7 support?
- Which applications are cloud-native?
- Which applications still run on legacy infrastructure?
The discovery lifecycle
- 1
Customer kickoff
Align sponsors, scope, and success criteria for the engagement.
- 2
Business understanding
Learn how the customer actually makes and moves money.
- 3
Application discovery
Build a complete, owned inventory of every application.
- 4
Infrastructure discovery
Document compute, network, storage, and databases.
- 5
Dependency mapping
Trace how applications and services depend on each other.
- 6
Monitoring assessment
Catalogue existing tools, alerts, and dashboards.
- 7
Gap analysis
Identify what is unmonitored, undocumented, or unowned.
- 8
Transition planning
Turn findings into a signed-off onboarding roadmap.
Customer Perspective
The customer discovery workshop
Before implementation begins, Kamiti runs a structured workshop with every stakeholder who owns, runs, or depends on the customer’s applications.
Customer participants
- CIO
- IT Director
- Infrastructure Manager
- Application Owner
- ERP Manager
- Database Administrator
- Network team
- Security team
- DevOps team
- Cloud team
Kamiti Labs participants
- Engagement Manager
- Solution Architect
- SRE Lead
- Observability Architect
- Cloud Engineer
- DevOps Engineer
- Database Specialist
- Service Delivery Manager
Workshop agenda
| Session | Duration | Output |
|---|---|---|
| Executive kickoff | 30 min | Business goals |
| Current environment | 60 min | Technology inventory |
| Business applications | 90 min | Application catalogue |
| Infrastructure review | 90 min | Infrastructure inventory |
| Existing monitoring | 60 min | Monitoring gap analysis |
| Security review | 45 min | Security requirements |
| SLA discussion | 45 min | Service expectations |
| Roadmap | 30 min | Transition plan |
Business Objective
Business understanding, before servers or Kubernetes
Before discussing servers or Kubernetes, understand the customer’s business. A typical FMCG enterprise spans manufacturing, warehousing, supply chain, distribution, procurement, sales, retail, dealer networks, finance, HR, marketing, customer care, and e-commerce — and every one of those functions leans on applications that must stay up.
Example business flow
- 1
Raw material procurement
- 2
Manufacturing
- 3
Quality inspection
- 4
Warehouse
- 5
Distributor
- 6
Retail store
- 7
Consumer
Architecture
Application discovery
The single most valuable artifact from discovery is a complete, owned application inventory — not a list of server names.
Application catalogue template
| Application | Owner | Criticality | Environment | Technology | Business function |
|---|---|---|---|---|---|
| Dealer portal | Sales | Critical | Production | Java | Dealer orders |
| Consumer app | Marketing | Critical | Production | React Native | Customer engagement |
| ERP | Finance | Critical | Production | SAP | Finance |
| WMS | Operations | High | Production | .NET | Warehouse |
| CRM | Sales | High | Production | Salesforce | Customer management |
Information to collect per application
- Application name & business owner
- Technical owner & vendor contact
- Environment & URL
- Technology stack & runtime
- Database & APIs
- Authentication & hosting
- Criticality & peak load
- Number of users
- Maintenance window
- Existing monitoring & SLA
Standards & Best Practices
Infrastructure discovery
Every infrastructure component the applications run on must be documented — this is what monitoring will ultimately need to cover.
Compute
- Physical servers
- Virtual machines
- Containers
- Kubernetes
- Serverless
Operating systems
- Linux
- Windows
- Unix
Cloud platforms
- AWS
- Azure
- GCP
- On-premises
Network
- Firewalls
- VPN
- Load balancers
- DNS
- CDN
- Proxy servers
Storage
- SAN
- NAS
- Object storage
- Cloud storage
Databases
- Oracle
- PostgreSQL
- SQL Server
- MySQL
- MongoDB
- Redis
Implementation Guidance
Dependency mapping
Enterprise applications rarely operate in isolation. A dealer portal, for example, may depend on half a dozen other systems — and every one of those dependencies must be documented before monitoring begins, or an outage anywhere in the chain will be invisible until a customer reports it.
- API Gateway
- Identity Provider
- ERP
- CRM
- Payment Gateway
- Warehouse System
- Redis
- PostgreSQL
KPI & SLA Examples
Current monitoring assessment
Document what the customer already has before proposing anything new — most enterprises have partial tooling, not zero tooling.
| Tool | Coverage | Gaps |
|---|---|---|
| Nagios | Infrastructure | No APM |
| Zabbix | Servers | No business metrics |
| CloudWatch | AWS | Limited application visibility |
| Grafana | Dashboards | No distributed tracing |
Questions to ask
- What tools are already deployed?
- What alerts exist?
- Who receives alerts?
- Which alerts are ignored?
- Are dashboards available?
- Are business transactions monitored?
Common Challenges
Monitoring gap analysis
Evaluate monitoring coverage across five layers — most enterprises are strong at infrastructure and weak everywhere else.
Infrastructure
- CPU
- Memory
- Disk
- Network
Applications
- Response time
- Errors
- Throughput
- Apdex
Databases
- Slow queries
- Connections
- Replication
- Locks
Kubernetes
- Nodes
- Pods
- Deployments
- HPA
- PVC
- Namespaces
Business
- Orders
- Revenue
- Payments
- User logins
- Inventory
Risk Assessment
Naming and mitigating operational risk
Every discovery engagement surfaces risks that predate Kamiti’s involvement. Naming them explicitly — rather than quietly working around them — is what earns trust with the customer’s leadership.
| Risk | Impact | Mitigation |
|---|---|---|
| No application documentation | High | Discovery workshops |
| No monitoring | High | Observability onboarding |
| Legacy systems | Medium | Phased monitoring |
| Single DBA | High | Knowledge transfer |
| No runbooks | High | SOP creation |
Deliverables
What discovery produces
By the end of discovery, Kamiti Labs delivers three tiers of output — executive, technical, and operational — so every stakeholder gets what they need to sign off.
Executive
- Executive assessment report
- Current state report
- Risk assessment
- Gap analysis
- Transformation roadmap
Technical
- Application inventory
- Infrastructure inventory
- Database inventory
- Network inventory
- Dependency map
- Cloud inventory
- Monitoring assessment
- Security assessment
- Existing dashboard catalogue
Operational
- Stakeholder matrix
- Escalation matrix
- Contact directory
- Initial SLA proposal
- Service transition plan
Kamiti Recommendations
Discovery success criteria
The discovery phase is complete — and monitoring implementation may begin — only when every one of these is true:
- Every application is inventoried.
- Every production server is identified.
- Business-critical systems are classified.
- Dependencies are documented.
- Existing monitoring is assessed.
- Risks are recorded.
- Stakeholders approve the findings.
- A transition roadmap is signed off.
Consultant Tips
Consultant’s note
Discovery is the pitch, not the paperwork
For a Singapore-based FMCG customer, discovery is often viewed as a consulting engagement in itself. The quality of your questions, documentation, and structured approach can significantly influence confidence in your delivery capability. Treat every workshop as an opportunity to demonstrate that Kamiti Labs understands not only technology, but also manufacturing operations, supply chain continuity, governance, and business outcomes.
Never begin monitoring implementation until the discovery findings have been reviewed and formally approved by the customer.