Technology companies frequently build websites according to the way they organize themselves internally.
The result is predictable:
- Services
- Technologies
- Products
- Industries
- Solutions
- About
- Resources
- Contact
Under these headings may be hundreds of technologies, frameworks, certifications, products, platforms and technical capabilities.
The problem is not that the information is wrong.
The problem is that the information architecture is often optimized for the organization rather than for the customer.
A business owner does not normally wake up thinking:
"I need an Nginx-PHP-FPM-Redis-Varnish architecture."
The business owner thinks:
"My website was hacked. Can you fix it and prevent it from happening again?"
A CTO does not normally begin with:
"I need Docker, Kubernetes, RAG, Neo4j and an LLM."
The CTO thinks:
"How can we deploy AI into our engineering workflow without creating another uncontrolled technology experiment?"
An engineering manager does not begin with:
"I need SystemC-TLM and MATLAB."
The manager thinks:
"How can we validate this architecture before committing expensive hardware and software resources?"
This distinction is the foundation of this paper.
The central proposition is:
KeenComputer, IAS-Research and KeenDirect should build their digital presence around customer problems, desired outcomes, evidence and decision journeys, while positioning technology as an enabling capability underneath those outcomes.
This creates a three-layer strategic ecosystem:
IAS-Research → Think, Research, Architect and De-risk
KeenComputer → Build, Deploy, Secure and Operate
KeenDirect → Supply, Equip and Enable
The three organizations can therefore function as different layers of a single technology value chain without appearing to be three disconnected websites.
The strategic architecture becomes:
Problem → Diagnosis → Strategy → Architecture → Engineering → Implementation → Technology → Operations → Evidence → Continuous Improvement
From Technology Catalogue to Decision Architecture
A First-Principles Information Architecture, Digital Strategy and Business Positioning Framework for KeenComputer, IAS-Research and KeenDirect
Research White Paper
KeenComputer.com
IAS-Research.com
KeenDirect.com
Winnipeg, Manitoba, Canada
Executive Summary
Technology companies frequently build websites according to the way they organize themselves internally.
The result is predictable:
- Services
- Technologies
- Products
- Industries
- Solutions
- About
- Resources
- Contact
Under these headings may be hundreds of technologies, frameworks, certifications, products, platforms and technical capabilities.
The problem is not that the information is wrong.
The problem is that the information architecture is often optimized for the organization rather than for the customer.
A business owner does not normally wake up thinking:
"I need an Nginx-PHP-FPM-Redis-Varnish architecture."
The business owner thinks:
"My website was hacked. Can you fix it and prevent it from happening again?"
A CTO does not normally begin with:
"I need Docker, Kubernetes, RAG, Neo4j and an LLM."
The CTO thinks:
"How can we deploy AI into our engineering workflow without creating another uncontrolled technology experiment?"
An engineering manager does not begin with:
"I need SystemC-TLM and MATLAB."
The manager thinks:
"How can we validate this architecture before committing expensive hardware and software resources?"
This distinction is the foundation of this paper.
The central proposition is:
KeenComputer, IAS-Research and KeenDirect should build their digital presence around customer problems, desired outcomes, evidence and decision journeys, while positioning technology as an enabling capability underneath those outcomes.
This creates a three-layer strategic ecosystem:
IAS-Research → Think, Research, Architect and De-risk
KeenComputer → Build, Deploy, Secure and Operate
KeenDirect → Supply, Equip and Enable
The three organizations can therefore function as different layers of a single technology value chain without appearing to be three disconnected websites.
The strategic architecture becomes:
Problem → Diagnosis → Strategy → Architecture → Engineering → Implementation → Technology → Operations → Evidence → Continuous Improvement
This paper proposes a comprehensive information architecture, content strategy, positioning model, conversion architecture, technology taxonomy and implementation roadmap for the three digital properties.
1. The First-Principles Problem
1.1 The traditional technology-company website
A conventional technology company often begins its website architecture with:
- IT Services
- Cloud
- Cybersecurity
- Software
- AI
- Networking
- Hardware
- Web Development
- Mobile Development
- Consulting
- Products
This seems logical from an internal organizational perspective.
But it forces the visitor to answer an important question:
Which of these services do I need?
That is precisely the question many visitors are not yet qualified to answer.
A business owner may know that something is wrong but not know whether the underlying problem is:
- cybersecurity,
- infrastructure,
- software,
- networking,
- hosting,
- configuration,
- application security,
- data protection,
- backup,
- performance,
- architecture,
- process,
- or organizational capability.
The website should therefore help the visitor diagnose the category of problem before asking them to select a technology.
2. The First-Principles Question
The fundamental question should be:
What information does a visitor actually need to make a decision?
For most professional technology purchases, the visitor needs answers to eight questions.
1. Who are you?
Identity, experience, specialization and purpose.
2. What problems do you solve?
The business, engineering and operational problems you address.
3. Who do you serve?
The types of organizations, decision-makers and technical teams you work with.
4. What outcomes do you produce?
Security, modernization, cost reduction, engineering acceleration, reliability, innovation, automation, revenue enablement or operational improvement.
5. How do you solve the problem?
Your methodology, architecture, engineering process and delivery model.
6. What technologies support the solution?
Platforms, frameworks, tools, infrastructure and engineering technologies.
7. What evidence demonstrates capability?
Projects, case studies, demonstrations, publications, prototypes, architectures, technical articles and measurable results.
8. What should I do next?
Assessment, consultation, technical review, research collaboration, project discovery, quotation or procurement.
This creates a fundamental rule:
Technology should support the decision rather than become the decision.
3. The Customer Decision Architecture
The website should guide visitors through a sequence:
Problem
"What is wrong?"
↓
Outcome
"What do I want to achieve?"
↓
Capability
"Can these people solve it?"
↓
Method
"How will they solve it?"
↓
Technology
"What technologies will they use?"
↓
Evidence
"Have they done something similar?"
↓
Trust
"Why should I engage them?"
↓
Action
"What should I do next?"
This can be represented as the Decision Architecture Model:
CUSTOMER │ ▼ PROBLEM │ ▼ OUTCOME │ ▼ DIAGNOSIS │ ▼ CAPABILITY │ ▼ METHOD │ ▼ TECHNOLOGY │ ▼ EVIDENCE │ ▼ TRUST │ ▼ ACTION
The website therefore becomes more than a brochure.
It becomes a decision-support system.
4. Why Problem-First Architecture Matters
User-centred design principles strongly support beginning with the user's needs and problems rather than prematurely committing to a solution. User needs should be based on evidence and should describe what the user is trying to accomplish, rather than prescribing a particular technology or implementation. (GOV.UK)
This principle is particularly important for technology consulting because buyers often cannot independently determine the best technical solution.
For example:
Customer statement
"We need to move our website to the cloud."
The underlying requirement might actually be:
- reduce downtime;
- improve backup;
- increase security;
- reduce infrastructure costs;
- support growth;
- improve disaster recovery;
- modernize an obsolete server;
- improve deployment automation.
"Move to the cloud" may therefore be a proposed solution rather than the actual requirement.
A first-principles consultancy should ask:
Why?
Repeatedly asking "why?" can expose the actual business requirement.
5. The Strategic Role of the Three Websites
The three properties should not compete with each other.
They should form a strategic continuum.
5.1 IAS-Research
Strategic role
Research, Strategy, Architecture and Innovation
IAS-Research should answer:
What should we build, why should we build it, and what architecture gives us the best path forward?
Its positioning should emphasize:
- research;
- strategic thinking;
- engineering architecture;
- innovation;
- advanced technology;
- technical feasibility;
- prototyping;
- systems engineering;
- AI/ML;
- embedded systems;
- power engineering;
- VLSI;
- digital engineering;
- simulation;
- engineering research;
- technical advisory.
IAS-Research becomes the thinking and architecture layer.
6. KeenComputer
Strategic role
Implementation, Modernization, Security and Operations
KeenComputer should answer:
How do we turn the strategy and architecture into a working, secure and maintainable system?
Its positioning should emphasize:
- IT modernization;
- cybersecurity;
- infrastructure;
- web applications;
- ecommerce;
- cloud/VPS;
- Linux;
- Windows;
- networking;
- application engineering;
- DevOps;
- monitoring;
- backup;
- managed/professional services;
- system integration;
- implementation.
KeenComputer becomes the execution and operational layer.
7. KeenDirect
Strategic role
Technology Supply and Procurement
KeenDirect should answer:
What technology products, components and infrastructure do we need to implement the solution?
Its role can include:
- computers;
- components;
- networking equipment;
- servers;
- storage;
- peripherals;
- engineering hardware;
- infrastructure products;
- technology procurement;
- project-specific equipment.
KeenDirect becomes the technology supply layer.
8. The Three-Layer Business Model
The combined ecosystem can therefore be represented as:
CUSTOMER PROBLEM │ ▼ ┌────────────────────┐ │ IAS-RESEARCH │ │ Research / Strategy│ │ Architecture │ │ Innovation │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ KEENCOMPUTER │ │ Engineering │ │ Implementation │ │ Security │ │ Operations │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ KEENDIRECT │ │ Technology Supply │ │ Hardware │ │ Components │ │ Procurement │ └────────────────────┘
This creates a coherent lifecycle:
Think → Design → Build → Deploy → Equip → Operate → Improve
9. Information Architecture for IAS-Research.com
The primary navigation should be organized around strategic decisions.
Recommended IAS-Research top navigation
1. Problems
- Engineering Complexity
- Digital Transformation
- AI Adoption
- System Architecture
- Embedded Systems Challenges
- Power-System Challenges
- Simulation and Validation
- Technology Feasibility
- Research-to-Product Challenges
2. Solutions
- AI & Intelligent Systems
- Systems Engineering
- Embedded & Edge Computing
- VLSI & Semiconductor Engineering
- Electrical Power Engineering
- Simulation & Digital Engineering
- Digital Transformation
- Technical Research & Advisory
3. Capabilities
This is where the technology catalogue belongs.
For example:
- AI/ML
- RAG/LLM
- Embedded Linux
- ARM
- RISC-V
- RTOS
- Yocto
- SystemC/TLM
- MATLAB/Simulink
- PSCAD
- FPGA
- VLSI
- IoT
- Digital Twins
- MBSE
- UML/SysML
- Cloud
- DevOps
The critical distinction is:
Capabilities support solutions; solutions address problems.
10. IAS-Research Evidence Architecture
A research organization needs stronger evidence than a conventional service company.
Recommended:
Research
- Research Papers
- White Papers
- Technical Notes
- Engineering Studies
- Literature Reviews
- Research Projects
Engineering
- Architecture Studies
- Simulation Models
- Prototypes
- Reference Architectures
- Proofs of Concept
Insights
- AI Engineering
- Systems Engineering
- Embedded Computing
- Power Engineering
- Cybersecurity
- Digital Transformation
Projects
Each project should answer:
- What was the problem?
- What constraints existed?
- What architecture was considered?
- What methodology was used?
- What technologies were selected?
- What was built?
- What was learned?
- What could be done next?
11. Information Architecture for KeenComputer.com
KeenComputer should be more commercially direct.
Primary navigation
1. Problems
- Hacked Website
- Outdated IT Infrastructure
- Windows Modernization
- Poor Backup & Recovery
- VPS Security
- Cloud Migration
- Ecommerce Problems
- Website Performance
- Network Problems
- Cybersecurity Risk
- Software Development Capacity
- AI Automation Opportunities
2. Solutions
Secure
- Website Security
- VPS Security
- Firewall
- WAF
- Malware Detection
- Backup
- Monitoring
- Incident Recovery
Modernize
- Windows 11
- Linux
- Cloud/VPS
- Infrastructure
- Network Modernization
- Application Modernization
Build
- Web Applications
- Ecommerce
- WordPress
- Joomla
- Magento
- PHP
- Java
- Spring Boot
- APIs
- Database Applications
Automate
- AI
- RAG
- Workflow Automation
- CRM Automation
- Business Process Automation
- Agentic AI
Operate
- Monitoring
- Backup
- Patch Management
- Security
- Performance
- Managed IT
12. The Technology Catalogue Should Be Secondary
KeenComputer may have a very large technology footprint.
That is valuable.
But it should not dominate the homepage.
A better structure is:
CUSTOMER PROBLEM │ ▼ BUSINESS OUTCOME │ ▼ KEENCOMPUTER SOLUTION │ ▼ ENGINEERING METHOD │ ▼ TECHNOLOGY STACK │ ▼ CASE STUDY │ ▼ CALL TO ACTION
For example:
"My Joomla website has been hacked."
The page could explain:
Problem
Japanese SEO spam, redirects, unauthorized users, modified files, malicious database records or compromised extensions.
Outcome
Restore a trustworthy website and establish a stronger security baseline.
Approach
- Preserve evidence.
- Isolate the affected environment.
- Assess the filesystem.
- Examine database content.
- Inspect administrator accounts.
- Review extensions.
- Analyze logs.
- Identify persistence mechanisms.
- Rebuild or restore from a trusted baseline.
- Harden the infrastructure.
- Implement monitoring and backup.
Technology
- Joomla
- Linux
- Nginx
- PHP
- MariaDB
- UFW
- WAF
- ClamAV
- monitoring
- logging
- Docker where appropriate
Technology is now evidence of capability rather than the headline.
13. The Homepage Architecture
The homepage should not attempt to explain everything.
Its job is to answer:
Who are we, what problems do we solve, and where should you go next?
A recommended homepage sequence:
Hero
Headline
Engineering, IT and Technology Solutions Built Around Your Business Problem
Supporting statement
Research, architecture, implementation and technology services for organizations that need to modernize, secure, automate and engineer complex systems.
Primary calls to action
Discuss a Problem
Request an Assessment
Section 2 — What Problem Are You Solving?
Present problem-oriented pathways.
Secure my business
Cybersecurity, websites, infrastructure and recovery.
Modernize my IT
Cloud, VPS, Windows, Linux, networking and infrastructure.
Build or modernize software
Web, ecommerce, APIs, Java, PHP and application engineering.
Introduce AI
RAG, LLM, automation and intelligent workflows.
Solve an engineering problem
Systems engineering, embedded systems, simulation, VLSI and power engineering.
14. Outcome-Based Messaging
The site should increasingly use outcome language.
Instead of:
"We provide Linux administration."
Use:
Secure and modernize your Linux infrastructure.
Instead of:
"We provide Magento development."
Use:
Build and modernize ecommerce platforms that can be operated, secured and scaled.
Instead of:
"We provide AI consulting."
Use:
Turn organizational knowledge into usable AI-assisted workflows.
Instead of:
"We provide SystemC modeling."
Use:
Validate hardware/software architectures before expensive implementation decisions.
This converts technical capability into business meaning.
15. Audience Architecture
The same solution should be presented differently depending upon the visitor.
Business Owner
Needs:
- risk;
- cost;
- business continuity;
- security;
- ROI;
- simplicity;
- accountability.
CTO / IT Manager
Needs:
- architecture;
- integration;
- security;
- scalability;
- lifecycle;
- operational risk;
- technology selection.
Engineering Manager
Needs:
- technical feasibility;
- resources;
- architecture;
- validation;
- simulation;
- development capacity;
- delivery risk.
Developer
Needs:
- APIs;
- frameworks;
- deployment;
- source control;
- architecture;
- implementation details.
Researcher
Needs:
- methodology;
- references;
- models;
- simulations;
- reproducibility;
- technical evidence.
The website should therefore provide progressive technical depth.
16. Progressive Disclosure
A useful three-level structure is:
Level 1 — Executive
"What does this do for my organization?"
Level 2 — Professional
"How does the solution work?"
Level 3 — Engineering
"What exactly is the architecture and technology?"
This prevents a CFO from being overwhelmed by technical detail while still allowing an engineer to reach deep technical documentation.
17. Evidence as a Core Architectural Element
Technology buyers increasingly need evidence.
Therefore:
Evidence should not be buried under an About page.
It should be integrated into solution pages.
Every important service should contain:
Problem
What happens if the problem is ignored?
Diagnosis
How do we identify the real cause?
Approach
How do we solve it?
Evidence
What demonstrates competence?
Technology
What tools support the solution?
Deliverables
What does the customer actually receive?
Next Step
How does the engagement begin?
18. Case Studies Should Be Structured Around Problems
A weak case study says:
"We used Docker, Ubuntu and Magento."
A stronger case study says:
"An ecommerce environment required a reproducible development environment and a controlled migration path to production."
Then:
Situation
What existed?
Problem
What was failing?
Constraints
What could not be changed?
Investigation
What was discovered?
Architecture
What was proposed?
Implementation
What was built?
Result
What improved?
Lessons
What was learned?
This structure demonstrates engineering thinking.
19. The "Proof Pyramid"
The websites should build evidence at multiple levels.
CUSTOMER RESULTS ▲ │ CASE STUDIES ▲ │ PROJECT EXAMPLES ▲ │ TECHNICAL ARTICLES ▲ │ WHITE PAPERS ▲ │ ENGINEERING NOTES ▲ │ TECHNOLOGY
Technology is therefore the lowest-level evidence, not the highest-level proposition.
20. Research as a Commercial Asset
IAS-Research can create intellectual assets that strengthen KeenComputer.
For example:
IAS Research Paper
Web Application Security for SMB Ecommerce
↓
KeenComputer Service
Ecommerce Security Assessment
↓
KeenComputer Case Study
Magento/Joomla/WordPress Security Modernization
↓
KeenDirect
Security and infrastructure products
This creates a powerful content-to-commercialization pipeline.
21. The Research-to-Revenue Flywheel
The ecosystem can operate as:
Research ↓ White Paper ↓ Educational Content ↓ Business Problem ↓ Assessment ↓ Consulting ↓ Engineering ↓ Implementation ↓ Technology Procurement ↓ Operations ↓ Case Study ↓ New Research
This is substantially stronger than treating content marketing as simply "writing blog posts."
22. Strategic Content Pillars
IAS-Research
Pillar 1
AI and intelligent engineering
Pillar 2
Systems engineering and MBSE
Pillar 3
Embedded and edge computing
Pillar 4
Electrical power and grid-edge engineering
Pillar 5
VLSI and semiconductor engineering
Pillar 6
Simulation and digital engineering
Pillar 7
Digital transformation
KeenComputer
Pillar 1
Cybersecurity
Pillar 2
IT modernization
Pillar 3
Web and ecommerce security
Pillar 4
Cloud/VPS
Pillar 5
Software engineering
Pillar 6
AI automation
Pillar 7
Managed IT and operations
KeenDirect
Pillar 1
Computing hardware
Pillar 2
Networking
Pillar 3
Storage
Pillar 4
Servers
Pillar 5
Engineering hardware
Pillar 6
Components
Pillar 7
Technology procurement
23. Search Strategy
Search-engine optimization should follow the same problem-first architecture.
Instead of creating hundreds of pages targeting isolated technologies, build topic clusters around problems.
For example:
Security cluster
Pillar page
Website Security for SMBs
Supporting pages:
- Joomla security
- WordPress security
- Magento security
- VPS security
- Linux hardening
- firewall strategy
- WAF
- malware detection
- backup
- incident recovery
- website compromise assessment
The pages should interconnect.
This creates topical authority while maintaining a coherent user journey.
24. Internal Linking Architecture
Every article should answer:
"What should the visitor read next?"
Example:
Joomla hacked
↓
Website compromise assessment
↓
Website security modernization
↓
VPS firewall
↓
Backup and disaster recovery
↓
Managed security
↓
Request assessment
The visitor is therefore guided from education toward action without aggressive selling.
25. Calls to Action
The websites should avoid having every page end with:
"Contact Us."
That is too generic.
Use context-specific actions.
Early-stage visitor
Read the Security Guide
Problem-aware visitor
Assess My Environment
Technical evaluator
Discuss the Architecture
Buyer
Request a Proposal
Research organization
Discuss a Research Project
Procurement customer
Find the Required Equipment
This makes the CTA correspond to the visitor's decision stage.
26. The Assessment as the Gateway Product
One of the strongest strategic mechanisms for KeenComputer is an assessment-first model.
Instead of attempting to sell a large project immediately:
Start with diagnosis.
Examples:
SMB IT Modernization Assessment
Review:
- infrastructure;
- endpoints;
- Windows;
- Linux;
- networking;
- backup;
- security;
- cloud;
- websites;
- ecommerce;
- operational risk.
Website Security Assessment
Review:
- CMS;
- extensions;
- accounts;
- database;
- files;
- hosting;
- firewall;
- backups;
- logs;
- monitoring.
Ecommerce Architecture Assessment
Review:
- Magento;
- WooCommerce;
- OpenCart;
- infrastructure;
- caching;
- database;
- deployment;
- security;
- payment;
- performance.
AI Readiness Assessment
Review:
- data;
- workflows;
- knowledge bases;
- security;
- governance;
- RAG opportunities;
- automation opportunities;
- ROI.
The assessment becomes a bridge between education and implementation.
27. The "Diagnostic First" Business Model
This creates a progression:
Free educational material
↓
Initial conversation
↓
Assessment
↓
Technical roadmap
↓
Implementation
↓
Operations
This reduces the customer's perceived risk.
It also allows KeenComputer and IAS-Research to demonstrate expertise before asking the customer to commit to a large engagement.
28. Technology Taxonomy
A technology catalogue is still necessary.
But it should exist as a structured secondary layer.
For example:
Infrastructure
- Linux
- Windows
- Ubuntu
- Nginx
- Apache
- PHP-FPM
- MariaDB
- MySQL
- Redis
- Varnish
- Docker
Application
- PHP
- Java
- Spring Boot
- WordPress
- Joomla
- Magento
- WooCommerce
- OpenCart
AI
- LLM
- RAG
- vector databases
- graph databases
- agents
- workflow automation
- embeddings
- local inference
Engineering
- ARM
- RISC-V
- STM32
- RTOS
- Yocto
- QEMU
- SystemC
- TLM
- MATLAB
- Simulink
- PSCAD
- FPGA
- VLSI
But the technology page should answer:
What problems does this technology allow us to solve?
rather than simply listing products.
29. The Architecture of a Technology Page
Every technology page should include:
What it is
Short explanation.
Why it matters
Business or engineering significance.
Problems it addresses
Specific use cases.
When to use it
Decision criteria.
When not to use it
Trade-offs.
How we use it
KeenComputer/IAS methodology.
Related technologies
Context.
Example projects
Evidence.
Related solutions
Commercial pathway.
This turns technical content into decision support.
30. Strategic Differentiation
The biggest opportunity for the three organizations is not claiming to know more technologies.
Thousands of companies can claim:
- AI;
- cloud;
- cybersecurity;
- Linux;
- web development;
- software engineering.
The differentiation should instead be:
The ability to connect business problems, research, engineering architecture, implementation and operational reality.
That is much harder to commoditize.
31. The "Systems Thinking" Position
The organizations should present themselves as systems thinkers.
A customer problem rarely exists in isolation.
For example:
Website Problem │ ├── Application ├── Database ├── Server ├── Network ├── DNS ├── Security ├── Backup ├── Monitoring ├── Business Process └── People
A website failure may therefore actually be an organizational systems problem.
Similarly:
AI Project │ ├── Data ├── Knowledge ├── Security ├── Infrastructure ├── Model ├── Workflow ├── Integration ├── Governance └── People
This is where research, engineering and IT operations intersect.
32. Second-Order Thinking
A first-order question is:
"Can we deploy this?"
A second-order question is:
"What happens after we deploy it?"
A third-order question is:
"What new dependencies, risks and operational requirements does deployment create?"
The websites should demonstrate this level of thinking.
For example:
AI deployment
Not merely:
Deploy an LLM.
But:
Data → Retrieval → Model → Security → Governance → Evaluation → Integration → Monitoring → Human oversight.
This establishes credibility with serious technical buyers.
33. From Services to Capabilities
A traditional service list might say:
Web Development
Cloud
Cybersecurity
AI
A capability model says:
We can investigate complex technology problems, design architectures, build systems, integrate technologies and operate them over their lifecycle.
That is a stronger proposition.
34. From Vendor to Engineering Partner
The desired strategic perception is:
Not simply:
"IT company"
Not simply:
"web development company"
Not simply:
"AI company"
Not simply:
"consulting company"
Instead:
A technology engineering partner capable of moving from problem definition to architecture, implementation and operational improvement.
IAS-Research strengthens the intellectual and research side.
KeenComputer strengthens the implementation and operational side.
KeenDirect strengthens the physical technology supply side.
35. Recommended Cross-Site Architecture
The three sites should use related but distinct terminology.
IAS-Research
Research → Strategy → Architecture → Prototype
KeenComputer
Assess → Design → Implement → Secure → Operate
KeenDirect
Select → Source → Supply → Support
Together:
CUSTOMER │ ▼ PROBLEM │ ▼ IAS-RESEARCH Research / Strategy Architecture │ ▼ KEENCOMPUTER Build / Implement Secure / Operate │ ▼ KEENDIRECT Source / Supply │ ▼ TECHNOLOGY │ ▼ RESULTS
36. Content Governance
A common problem with growing websites is uncontrolled content creation.
Every new article should have a purpose.
Before publishing, ask:
- Which customer problem does this address?
- Which audience is it for?
- What decision does it support?
- Which solution does it connect to?
- What evidence does it provide?
- What page should the visitor visit next?
- What business capability does it reinforce?
If there is no answer, the content probably should not be published.
37. The Content Matrix
Each content asset should fit into one of five categories.
|
Content type |
Primary purpose |
|---|---|
|
Problem article |
Attract problem-aware visitors |
|
Educational article |
Build understanding |
|
Technical article |
Demonstrate competence |
|
Case study |
Provide evidence |
|
Commercial solution |
Convert qualified interest |
This creates a deliberate content funnel.
38. Research White Papers as Strategic Assets
Long-form white papers can become major strategic assets.
For example:
IAS-Research
AI Engineering for Industrial Systems
KeenComputer
Cybersecurity Architecture for SMB Web and Ecommerce Platforms
KeenDirect
Selecting Infrastructure Hardware for Small and Medium Enterprises
Each paper can generate:
- website articles;
- newsletters;
- LinkedIn content;
- presentations;
- technical diagrams;
- webinars;
- assessment offers;
- consulting opportunities.
One research asset can therefore become an entire content ecosystem.
39. Measurement Framework
The success of the new IA should not be measured solely by traffic.
Important metrics include:
Discovery
- organic search impressions;
- qualified traffic;
- problem-specific searches.
Engagement
- solution-page visits;
- case-study views;
- technical-document access;
- assessment-page visits.
Decision
- consultation requests;
- assessment requests;
- proposal requests;
- procurement enquiries.
Commercial
- qualified leads;
- opportunities;
- project value;
- customer acquisition cost;
- conversion rate.
Strategic
- research collaborations;
- engineering engagements;
- recurring IT work;
- technology procurement;
- cross-site referrals.
40. A Better Website KPI
The most useful question may be:
Did the website help the visitor make progress toward solving a real problem?
This is more meaningful than simply asking:
"How many visitors came to the site?"
A visitor who reads one technical page and requests an assessment may be substantially more valuable than hundreds of casual visitors.
41. Implementation Roadmap
Phase 1 — Discovery
Inventory:
- existing pages;
- existing articles;
- technical content;
- case studies;
- services;
- projects;
- products;
- research papers.
Then classify every item according to:
Problem / Outcome / Solution / Capability / Evidence / Company
Phase 2 — Customer Research
Identify primary personas:
- SME owner;
- CTO;
- IT manager;
- engineering manager;
- developer;
- researcher;
- procurement manager.
Document their:
- problems;
- terminology;
- questions;
- objections;
- desired outcomes;
- decision criteria.
User research should continue throughout development rather than being treated as a one-time activity. (GOV.UK)
Phase 3 — Information Architecture
Build:
- primary navigation;
- solution taxonomy;
- problem taxonomy;
- capability taxonomy;
- evidence taxonomy;
- technology taxonomy.
Avoid allowing the technology taxonomy to dominate the primary navigation.
Phase 4 — Content Migration
Existing content should not simply be deleted.
Map each existing page to:
- keep;
- rewrite;
- consolidate;
- redirect;
- archive;
- replace.
This is especially important when rebuilding an established website.
Phase 5 — Conversion Architecture
Create:
- assessment pages;
- consultation pages;
- project discovery;
- research collaboration;
- proposal pathways;
- procurement pathways.
Phase 6 — Evidence
Create:
- case studies;
- project pages;
- white papers;
- architecture diagrams;
- technical notes;
- demonstrations.
Phase 7 — Measurement
Install analytics and establish a baseline.
Measure:
- entry pages;
- problem pathways;
- solution discovery;
- case-study interaction;
- CTA interaction;
- qualified enquiries.
Use evidence to improve the IA continuously.
42. Recommended Top-Level IA
IAS-Research.com
Home │ ├── Problems │ ├── Solutions │ ├── Research │ ├── Engineering │ ├── Capabilities │ ├── Projects │ ├── Insights │ ├── About │ └── Start a Research / Engineering Project
KeenComputer.com
Home │ ├── Problems │ ├── Solutions │ ├── Secure │ ├── Modernize │ ├── Build │ ├── Automate │ └── Operate │ ├── Assessments │ ├── Technologies │ ├── Case Studies │ ├── Insights │ ├── About │ └── Start a Project
KeenDirect.com
Home │ ├── Shop │ ├── Computers │ ├── Components │ ├── Networking │ ├── Servers & Storage │ ├── Engineering Hardware │ ├── Solutions │ ├── Procurement │ ├── Guides │ └── Request Equipment
43. The Unified Strategic Model
The three properties should ultimately communicate one larger idea:
Complex technology problems require more than products. They require understanding, architecture, engineering, implementation and ongoing support.
IAS-Research provides the intellectual foundation.
KeenComputer provides engineering and operational execution.
KeenDirect provides technology procurement.
This produces a complete lifecycle.
44. Strategic Positioning Statement
A unified positioning statement could be:
From research and architecture to implementation, infrastructure and technology supply, the Keen ecosystem helps organizations solve complex technology problems through practical engineering, strategic thinking and evidence-driven execution.
IAS-Research emphasizes:
Research. Architecture. Innovation.
KeenComputer emphasizes:
Engineering. Security. Modernization. Operations.
KeenDirect emphasizes:
Technology. Equipment. Procurement.
45. The Core Strategic Principle
The most important rule for the websites is:
Do not make the visitor understand your organization before you help them understand their problem.
The organization can be explained after relevance has been established.
This produces a better sequence:
Their Problem
→ Their Desired Outcome
→ Your Solution
→ Your Method
→ Your Technology
→ Your Evidence
→ Your Organization
→ Their Next Step
This is the reverse of the conventional corporate website.
And that is precisely why it can be more effective.
46. Conclusion
KeenComputer, IAS-Research and KeenDirect have the opportunity to create something stronger than three technology websites.
They can create a connected technology ecosystem.
The strategic architecture should be based on first principles:
Customers do not buy technologies merely because technologies exist. They invest in outcomes, reduced risk, increased capability and solutions to important problems.
Therefore, the website should begin with the problem.
The second layer should explain the desired outcome.
The third should explain the solution.
The fourth should demonstrate the methodology.
The fifth should provide technical depth.
The sixth should establish evidence.
The seventh should establish trust.
The eighth should make the next action obvious.
This creates a website that functions simultaneously as:
- a marketing platform;
- a research portal;
- an engineering knowledge base;
- a technical credibility system;
- a lead-generation mechanism;
- a sales-enablement platform;
- a customer education system;
- and ultimately a decision-support system.
The strategic architecture can be summarized in one sentence:
IAS-Research helps customers understand and architect what should be done; KeenComputer helps them build, secure and operate it; KeenDirect helps them obtain the technology required to make it real.
The resulting ecosystem is not organized around what the companies happen to know.
It is organized around what the customer needs to accomplish.
That is the fundamental shift from a technology catalogue to a decision architecture.
Appendix A — First-Principles Website Test
Every major page should pass this test:
Problem
What problem does this page address?
Audience
Who has this problem?
Outcome
What does success look like?
Solution
What can the organization do?
Method
How will the problem be approached?
Technology
What technologies support the solution?
Evidence
What proves capability?
Trust
Why should the visitor believe the claim?
Action
What should the visitor do next?
If a page cannot answer these questions, reconsider its role in the architecture.
Appendix B — The Five-Level Content Model
Every major topic should be available at five depths:
Level 1 — Executive
"What does this mean for my business?"
Level 2 — Professional
"What solution should I consider?"
Level 3 — Technical
"How does it work?"
Level 4 — Engineering
"How would I implement it?"
Level 5 — Research
"What are the underlying principles, assumptions, models and evidence?"
This allows one ecosystem to serve:
Owner → Executive → CTO → Engineer → Researcher
without forcing everyone through the same level of technical detail.
Appendix C — The Ultimate IA Formula
The proposed information architecture can be reduced to:
PROBLEMS ↓ OUTCOMES ↓ SOLUTIONS ↓ CAPABILITIES ↓ TECHNOLOGY ↓ EVIDENCE ↓ TRUST ↓ ACTION ↓ RELATIONSHIP ↓ CASE STUDY ↓ RESEARCH ↓ CONTINUOUS LEARNING
This creates a learning organization on the web.
Every customer interaction produces knowledge.
Every project produces evidence.
Every project can become a case study.
Every case study can inform research.
Every research result can improve a solution.
Every solution can generate new customer conversations.
That is the long-term strategic opportunity for the IAS-Research → KeenComputer → KeenDirect ecosystem.