Information Systems is the discipline of designing, using and governing systems in which people, processes, data and digital technology work together to support organisational action. It is not merely “business computing,” and it is not identical to Computer Science. Computer Science asks deep questions about computation itself. Information Systems asks a different question: how can information and technology be organised so a real institution can coordinate work, make decisions, serve users and change safely?
The ACM/AIS IS2020 competency model treats Information Systems as a distinct professional and academic field and organises its curriculum around competencies rather than a simple list of technologies. The model includes areas such as data and information management, systems analysis and design, application development, secure computing, infrastructure, project management and organisational domains. Source: ACM/AIS IS2020 Competency Model.
Reading routes: begin with the child-friendly explanation; follow the people–process–data–technology boundary; explore requirements, processes, data, enterprise systems, integration, security, analytics, governance, change and failure and repair; then use the learning workshop.
Explain Information Systems to a child: make sure everyone is looking at the same story
Imagine a school library. One notebook says a book is available. The librarian’s computer says it is borrowed. A student already has the book in their bag.
The problem is not that the school lacks information. It has three different versions.
An information system decides which record is authoritative, how that record changes, who may change it and how everyone else learns the new state.
The lesson is simple: a good information system helps an organisation know what is true enough to act.
1. An information system is a socio-technical system
Technology is only one component.
People interpret information. Processes define work. Data represents state. Technology stores, transmits and transforms those representations.
A technically perfect database can support a broken process.
A well-designed process can fail if users lack training or authority. Information Systems studies the complete socio-technical arrangement.
2. The system boundary should follow the business outcome
Suppose a hospital wants to reduce missed appointments.
A narrow IT boundary might focus on reminder software.
A wider information-system boundary includes scheduling, contact information, patient preferences, clinic workflows, cancellations, transport constraints and how unused slots are reallocated.
The useful boundary is the one large enough to contain the mechanism producing the outcome.
3. Information reduces uncertainty only if the receiver can use it
A dashboard with 200 metrics can contain more data and create less understanding.
Information becomes useful when it changes a decision.
For a warehouse manager, stock quantity, expected arrivals and committed orders may matter more than last year’s total sales.
Information quality therefore includes relevance and timing, not only accuracy.
4. Data, information and knowledge are related but different
Data are recorded representations such as values, codes and events.
Information is data interpreted in a context.
Knowledge includes patterns, rules and experience that support action.
A temperature value of 38.5 is data. “This patient has a rising fever compared with baseline” is information. Knowing which clinical response is appropriate requires additional knowledge.
5. Requirements begin with work, not software features
“We need a mobile app” is a proposed solution.
“Staff need to approve urgent requests away from their desks without losing auditability” is a requirement.
The second statement leaves room for several technical designs.
Systems analysis separates the underlying job from the first technology suggestion.
6. Functional and non-functional requirements answer different questions
A functional requirement says what the system should do: create an order, register a patient, generate an invoice.
A non-functional requirement describes qualities such as availability, response time, security, accessibility or recoverability.
A system can perform the right function too slowly to be usable.
It can respond quickly while violating privacy. Both categories matter.
7. Stakeholders see different parts of the same system
A customer cares whether the order arrives.
A warehouse worker cares whether the pick list is accurate.
Finance cares whether revenue and tax are recorded correctly.
Management cares about margin and service levels. Good requirements work finds the shared process beneath these perspectives.
8. Process modelling makes invisible handoffs visible
A process model can show activities, decisions, queues and handoffs.
Consider a purchase order: request → approval → supplier order → receipt → invoice match → payment.
If one approval is missing, downstream staff may improvise.
The model helps identify where state changes and who owns each transition.
9. A process is a repeatable path from input to outcome
Processes coordinate work across people and systems.
Some are highly structured. Payroll follows defined rules. Others are adaptive: handling a customer complaint can require judgement.
Information Systems should not automate ambiguity away before understanding it.
The design needs enough structure for coordination and enough flexibility for legitimate exceptions.
10. Automation changes where judgement occurs
An automated approval rule can make decisions faster.
It also moves judgement from the moment of the case into the earlier rule design.
If the rule is wrong, the system can reproduce the error consistently at scale.
Automation therefore increases the importance of governance, testing and exception handling.
11. Workflow systems need explicit state
An application should distinguish requested, approved, rejected, fulfilled and cancelled rather than compressing everything into “done/not done.”
Clear state supports auditability and recovery.
It also prevents two teams from interpreting the same record differently.
The How State Machines Work route provides the deeper mechanism.
12. Worked queue example: information delay becomes operational delay
Original teaching model: a support team receives 120 requests per day and can complete 100.
The backlog grows by 20 requests per day if demand and capacity remain unchanged.
After five days, 100 requests accumulate beyond the starting backlog.
A new dashboard showing the queue more clearly does not solve the capacity imbalance. Information can diagnose the problem without removing it.
13. Data modelling turns organisational meaning into structure
A database might contain customers, orders, products and payments.
The important design question is how those entities relate.
Can one customer have many orders? Can an order contain many products? Can one payment cover several invoices?
Data modelling makes these rules explicit.
14. A primary key preserves identity
Names are poor identifiers because people and products can share names or change them.
A stable identifier lets records remain connected through changes in labels.
This is an information-system version of persistent identity.
The Persistent Identifiers route explains the general mechanism.
15. Normalisation reduces contradictory copies
Suppose a customer’s address is copied into 100 order records.
After the customer moves, 99 records can remain outdated.
Normalised relational design can store the authoritative customer address once and connect orders through identity.
Historical requirements may still justify preserving the delivery address used for each past order. The correct model follows meaning, not a rule to eliminate all duplication.
16. Data quality has several dimensions
Accuracy asks whether the value matches reality.
Completeness asks whether important fields are present.
Timeliness asks whether the value is current enough.
Consistency asks whether different systems agree. One perfect field cannot compensate for a record attached to the wrong customer.
17. Master data keeps shared entities coherent
Large organisations often maintain customers, products, suppliers and locations across many systems.
Master-data management establishes common identity and stewardship.
The challenge is not simply choosing one database.
It is defining who owns the entity, which attributes are authoritative and how changes propagate.
18. Metadata explains the data
A field called “date” is ambiguous.
Is it order date, delivery date, invoice date or last-updated date?
Metadata records meaning, format, source and other context.
The How Metadata Works estate carries this deeper.
19. Enterprise systems integrate organisational functions
Enterprise Resource Planning systems can connect finance, procurement, inventory, manufacturing and other functions around shared transactions and data.
Customer Relationship Management systems organise sales, marketing and service interactions.
Human-resource systems coordinate workforce information.
The advantage is shared state; the risk is that one poorly designed configuration affects many functions at once.
20. ERP systems encode organisational policy
When an ERP system requires a purchase order before payment, it is implementing a control.
When it assigns approval limits by role, it is implementing authority.
Configuration is therefore organisational design expressed in software.
An “IT change” can change governance even when no policy document is edited.
21. CRM systems preserve customer memory
A customer should not need to repeat the same history to sales, service and billing if the organisation already possesses it appropriately.
CRM systems connect interactions across time.
This can improve service and marketing.
It also raises privacy and data-quality responsibilities because a wrong customer profile can spread across many future decisions.
22. Supply-chain systems coordinate organisations beyond the firm
A manufacturer depends on supplier forecasts, orders, shipping events and inventory data.
Information arrives across organisational boundaries with different identifiers and timing.
A delayed shipment message can cause a planning system to believe stock will arrive when it will not.
Information Systems therefore extends into inter-organisational coordination.
23. Integration connects independent systems
Organisations rarely run one application.
They connect finance, HR, commerce, warehouses, analytics and external partners.
Integration uses APIs, files, event streams and shared databases.
The technical connection is only part of the problem. Semantics must align too.
24. An interface can be syntactically correct and semantically wrong
System A sends “status = complete.”
System B interprets complete as “customer received the item,” while A means “warehouse packed the item.”
The message is valid and the meaning is broken.
The Semantic Alignment route owns this general interface failure.
25. Batch and real-time integration solve different timing problems
A nightly data transfer may be sufficient for financial reporting.
It may be unacceptable for fraud detection or stock availability.
Real-time integration reduces delay but increases operational coupling and complexity.
The correct choice depends on how stale the information may become before the decision fails.
26. Event-driven systems distribute state change
When an order is shipped, one event can notify billing, customer communication and analytics.
This reduces direct coupling among applications.
But event systems introduce duplicate, delayed and out-of-order messages.
Consumers must therefore define idempotence and reconciliation.
27. Enterprise architecture keeps local projects inside a wider map
Without architecture, every project can create a new customer database, identity system or integration method.
Local speed creates long-term fragmentation.
Enterprise architecture describes capabilities, applications, data and technology relationships so changes can be evaluated across the organisation.
The purpose is not bureaucracy. It is preventing one project’s shortcut from becoming another project’s dependency.
28. Information security protects confidentiality, integrity and availability
Confidentiality restricts information to authorised use.
Integrity protects correctness and authorised change.
Availability keeps information and services usable when needed.
An information system can satisfy two and fail the third.
29. Access control should follow roles and legitimate need
Not every employee should see every customer or HR record.
Access design should reflect job responsibility and minimum necessary privilege.
Shared administrator accounts weaken accountability because actions cannot be attributed reliably.
Security is therefore an organisational identity problem as well as a technical one.
30. Cybersecurity changes process design
Security controls can affect usability and workflow.
Multi-factor authentication reduces some account-compromise risks while adding user steps.
Backups support recovery but only if restoration is tested.
The correct security architecture balances threat, consequence and operational need.
31. Privacy limits what the information system should remember
Organisations often collect data because it might be useful later.
Every additional field creates storage, security and governance obligations.
Purpose limitation asks whether the data is reasonably needed for the defined activity.
A disciplined information system deletes or de-identifies information when justified rather than accumulating permanent memory by default.
32. Analytics converts historical data into questions about the future
Descriptive analytics asks what happened.
Diagnostic analytics asks why.
Predictive analytics asks what may happen.
Prescriptive analytics asks which action might improve the outcome.
Each layer adds assumptions.
33. A dashboard is a representation, not management itself
A red metric does not repair the underlying process.
A green metric can hide omitted populations or stale data.
Dashboard design should connect each metric to an owner and a possible action.
Otherwise the organisation creates observation without control.
34. Worked conversion example: denominators change conclusions
Original teaching example: a website records 1,000 sales from 50,000 visits, a 2 per cent conversion rate.
A second period records 1,100 sales from 80,000 visits, or 1.375 per cent.
Sales count rose 10 per cent while conversion rate fell substantially.
Management needs both traffic and conversion context to understand performance.
35. Business intelligence requires stable definitions
One department defines “active customer” as a purchase in 30 days. Another uses 90 days.
Reports disagree even though both databases are correct under their definitions.
A semantic layer or governed metric definition can restore alignment.
Data governance often fails at vocabulary before it fails at storage.
36. AI systems inherit the organisation’s data and process weaknesses
An AI assistant trained on outdated policy can scale outdated advice.
A predictive model trained on biased historical records can reproduce institutional bias.
AI therefore does not sit outside Information Systems.
It becomes another decision component needing ownership, monitoring, access control and change management.
37. Governance decides who has authority over information and technology
Which projects receive funding?
Who owns customer data?
Who can approve a production change?
Who accepts risk? These are governance questions, not programming questions.
38. Governance separates decision rights from technical expertise
An engineer may understand the system deeply without having authority to change business policy.
A senior executive may own the decision without understanding implementation detail.
Good governance joins these roles through review and evidence.
Neither technical expertise nor hierarchy alone is sufficient.
39. Portfolio management allocates scarce change capacity
Organisations usually have more technology requests than teams can deliver.
Portfolio management compares value, urgency, risk, dependency and capacity.
Approving every project creates queues and multitasking that can delay all of them.
Prioritisation is therefore part of system performance.
40. Project management and product management optimise different horizons
A project has a defined scope and end.
A product or service continues to evolve after release.
Information Systems increasingly needs both: projects for bounded transformations and product management for continuing digital capabilities.
The choice affects funding, ownership and how success is measured.
41. Implementation changes work, not just software
A new system can alter roles, approvals and visibility.
People may resist because the software is difficult—or because the new process removes discretion or exposes performance.
Training cannot solve every resistance mechanism.
Change management should identify what genuinely changes for each stakeholder.
42. Data migration is a translation of organisational memory
Moving from an old system to a new one requires mapping identities, fields and historical states.
A blank field in the old system may mean “unknown,” while the new system interprets blank as “not applicable.”
Migration therefore includes semantic decisions.
Successful file transfer does not prove successful meaning transfer.
43. Parallel running reduces some migration risk
For important systems, old and new processes can run in parallel temporarily.
This allows comparison but adds work and creates the possibility of diverging records.
The organisation needs a defined reconciliation rule.
Parallel operation without an exit plan can become permanent duplication.
44. User adoption is a system outcome
If employees continue using spreadsheets after an expensive enterprise system launches, the project has not achieved full operational adoption.
Shadow systems can indicate missing features, excessive friction or lack of trust.
Simply banning them can hide the evidence.
The better response is to understand which user job the official system failed to support.
45. Digital transformation is organisational redesign using digital capability
Replacing paper forms with identical online PDFs is digitisation.
Redesigning the process because real-time data and automation enable a different service is transformation.
The deeper change can affect structure, customer experience and business model.
Technology is the enabling capability, not the definition of transformation itself.
46. Information-system failures often occur between working components
| Observed symptom | Useful question |
|---|---|
| Reports disagree | Are definitions, refresh times or authoritative sources different? |
| Customers receive duplicate messages | Did retry or event processing create repeated effects? |
| Employees avoid the official system | Which real workflow or usability need remains unsupported? |
| ERP implementation is technically live but operations slow | Did roles, process configuration or training fail to match real work? |
| Analytics model deteriorates | Did data distribution, process or customer behaviour change? |
| Security control blocks urgent work | Was the control designed without the actual operational requirement? |
47. Root-cause analysis should follow data lineage and process lineage together
If a report is wrong, trace where the number came from.
Which source event created it? Which transformations changed it? Which business rule interpreted it?
Data lineage without process context can miss the originating human action.
Process analysis without data lineage can miss a transformation error.
48. Repair should change both the system and its operating knowledge
If a recurring invoice error comes from a configuration rule, correcting one invoice is not enough.
The rule, tests, documentation and affected records should be repaired.
Users need to know the corrected process.
A complete repair returns the system to trustworthy shared state.
49. Learning workshop with worked answers
Question A: a team receives 120 requests per day and completes 100. Backlog growth after five unchanged days? Answer: 100 requests.
Question B: sales rise from 1,000 to 1,100 while visits rise from 50,000 to 80,000. Did conversion improve? Answer: no. It falls from 2.0 per cent to 1.375 per cent.
Question C: System A says “complete” means packed; System B thinks it means delivered. Is the API syntactically broken? Answer: not necessarily. The failure is semantic alignment.
Question D: staff maintain private spreadsheets after ERP launch. What should be investigated first? Answer: the job those spreadsheets still perform that the official system does not.
Question E: a nightly data feed supports quarterly reporting but fails a fraud-detection need. Why? Answer: timeliness requirements differ.
50. Common misconceptions
“Information Systems is programming.” Programming is one technical capability inside a socio-technical discipline.
“More data means better decisions.” More irrelevant, stale or contradictory data can worsen decisions.
“ERP automatically standardises an organisation.” The organisation must choose and govern the configuration.
“Digital transformation means moving everything online.” Transformation changes the operating model, not just the medium.
“If the system is secure, users can work around it.” Workarounds can create new unmanaged security and integrity risk.
51. Working glossary
Information system: organised combination of people, processes, data and technology supporting action. Requirement: defined capability or quality the system must provide. Workflow: sequence of work states and handoffs. Entity: object represented in data, such as customer or order.
ERP: enterprise resource planning system integrating organisational functions. CRM: customer relationship management system. Integration: connection allowing systems to exchange data or events. Enterprise architecture: structured map of organisational capabilities, applications, data and technology.
Data governance: decision rights and responsibilities over data. Business intelligence: reporting and analysis supporting organisational decisions. Digital transformation: organisational redesign enabled by digital capabilities.
52. Evidence and disciplinary boundary
The disciplinary architecture follows the joint ACM/AIS IS2020 Competency Model and related Association for Information Systems discussion. Singapore has a long-established Information Systems academic community; an AIS-published case study describes the field as a distinct and mature academic discipline in Singapore. Source: Communications of the AIS.
The deeper answer: Information Systems works by preserving organisational meaning while work moves
Computers can process instructions perfectly while an organisation remains confused about what its own records mean.
Information Systems exists to close that gap. It turns work into explicit processes, events into shared state, data into usable information and technology into an accountable institutional capability. The final test is not whether the software runs. It is whether people can coordinate through it without losing meaning, authority or trust.
Continue: Computer Science explains computational foundations; Software Engineering explains dependable software construction; Business explains the firm; Marketing explains market and customer systems. Return to the How X Works Hub.