Engineering Capability Requires an Engineering Architecture
The first article argued that the central challenge facing computing project education is not artificial intelligence, outsourcing or project assessment. These developments have exposed deeper structural weaknesses. The real issue is architectural: universities cannot consistently produce engineering capability through a project model designed for a different era of computing.
If the diagnosis is architectural, the response must also be architectural. The Integrated Computing Project Engineering Framework (ICPEF) is proposed not as another project methodology, but as an organising architecture for how universities, industry and government can collectively develop engineering capability through computing project education. Its purpose is to move project work from isolated academic submission to sustained engineering, innovation and national value.
Why Architecture Matters
Universities are actively reforming computing education. Some redesign curricula, others strengthen supervision, deepen industry partnerships, promote interdisciplinary collaboration, expand innovation ecosystems or develop policies for the responsible use of artificial intelligence. Each initiative addresses an important part of the challenge. The difficulty is that these reforms often remain disconnected because they are introduced without a unifying engineering architecture.
Architecture is what connects good ideas into a coherent system. Around the world, computing education, software engineering and digital transformation increasingly emphasise systems thinking, authentic industry engagement, outcome-based learning, multidisciplinary collaboration and continuous improvement. ICPEF aligns with this direction while responding to the realities of Ghanaian higher education.
The Integrated Computing Project Engineering Framework (ICPEF), illustrating an integrated university–industry architecture for developing engineering capability, innovation and national impact through computing project education.
The Organising Logic of ICPEF
ICPEF is organised around five interacting domains because engineering progresses through distinct but connected forms of work. Problems must first be understood before knowledge can be integrated. Knowledge must inform engineering decisions. Engineering outputs require validation before they can create value. Validated solutions then become candidates for adoption, further development, commercialisation or research.
The Problem Domain ensures that projects begin with real needs and validated opportunities. The Knowledge Domain integrates disciplinary expertise and contextual understanding. The Engineering Domain converts that understanding into robust digital systems. The Validation Domain verifies technical quality, usability, feasibility and stakeholder value. The Innovation Domain prepares successful solutions for adoption, improvement, entrepreneurship or further academic development. Each domain therefore performs a distinct function while producing evidence and decisions required by the next.
How the Components Interact
The domains should not be read as isolated boxes. Weak problem discovery produces weak requirements. Weak knowledge integration produces poor design judgement. Weak engineering produces fragile systems. Weak validation produces systems that may function technically but fail organisationally. Weak innovation allows useful prototypes to die after assessment.
The circular structure of ICPEF is deliberate. Evidence from validation should improve engineering. Engineering experience should refine knowledge. Innovation outcomes should generate new problems and opportunities. Each cohort should inherit lessons, artefacts and validated knowledge from previous cohorts rather than restarting the same journey. This is the foundation of longitudinal project engineering.
Longitudinal Project Engineering and Maturity
ICPEF challenges the assumption that serious project work should begin and end in Level 400. Engineering capability develops progressively. Students should encounter problem discovery, field observation, prototyping, version control, testing, validation and reflection from the early stages of undergraduate education, including Level 100, rather than concentrating substantial engineering activity in the final year.
Under this model, projects mature across time. One cohort may validate a problem, another may develop the prototype, another may strengthen security or usability, another may test adoption and another may translate the outcome into research, entrepreneurship or institutional deployment. The objective is not to force every project into commercialisation; it is to prevent valuable engineering effort from disappearing after assessment.
Knowledge Hubs and Institutional Memory
A major weakness of traditional project education is the loss of knowledge after graduation. Every project produces requirements, datasets, architectural decisions, code, test results, user feedback, documentation and lessons. If these are not preserved, universities repeatedly lose engineering memory.
ICPEF therefore implies the need for institutional knowledge hubs or engineering repositories where project artefacts, validation evidence and design decisions can be preserved, reviewed and extended. University-based initiatives such as the UPSA Developers Hub demonstrate, in practice, how supervised system development, student collaboration and structured academic–industry engagement can support project continuity beyond a single course or defence session. Such hubs should not be viewed as extracurricular add-ons; they can become strategic platforms for engineering capability development.
The Ecosystems That Sustain Engineering
The outer elements of ICPEF are not decorative. They are what convert a project process into an engineering ecosystem. Problem Sources ensure that projects originate from authentic industrial, public-sector, community, institutional, research and national development needs rather than arbitrary titles. Without credible problem sources, project work risks becoming imaginative construction rather than disciplined problem solving.
The Governance Ecosystem provides policy, quality assurance, ethics, compliance, resources, infrastructure and accountability. Without governance, the domains become disconnected activities rather than a coordinated educational system. Feedback and Learning Loops preserve institutional memory by ensuring that evidence, lessons and insights flow back into future projects. Impact defines the ultimate purpose: graduate competence, employability, institutional transformation, industrial value, research output and national development.
Why Multidisciplinary Engineering Matters
Software engineering became multidisciplinary because software itself became embedded within organisations rather than computers alone. Modern digital systems shape healthcare delivery, financial services, education, agriculture, logistics, transportation, public administration and industrial production. Engineering such systems requires technical expertise, but it also requires domain knowledge, ethical reasoning, legal awareness, business insight, human-centred design and organisational understanding.
This is why ICPEF places the Knowledge Domain before the Engineering Domain. Computing students remain central to system architecture, implementation, integration, security, testing and deployment. However, high-quality solutions also require the intelligence of the domains in which those systems will operate. The framework therefore supports universities that want to move from isolated departmental projects to multidisciplinary project engineering.
From Isolated Projects to National Capability
Ghanaian universities supervise thousands of computing projects every year. Properly organised, this represents an extraordinary pool of intellectual capital. ICPEF offers a way of converting that capital into national capability by connecting student projects to real problems, institutional priorities, research agendas, innovation centres, industry needs and development goals.
This requires collaboration. Departments, research centres, quality assurance units, industrial relations offices, innovation centres, supervisors, industry mentors and public institutions all have roles to play. The framework does not remove academic judgement; it strengthens it by placing project work within a broader system of evidence, governance and impact. Universities do not become innovation ecosystems by supervising more projects. They become innovation ecosystems by ensuring that every project becomes part of something larger than itself.
Dr. Augustina Dede Agor with a group of UPSA Developers Hub members during an academic–industry engagement session with MTN Ghana, reflecting the structured university–industry engagement advocated in computing project education.
An Invitation to Re-engineer Computing Education
Frameworks do not transform universities by themselves. People do. ICPEF is therefore offered as an invitation to rethink how universities, industry and government can collectively engineer the next generation of computing professionals. Its value lies not in the diagram alone, but in the discipline it encourages: begin with real problems, integrate relevant knowledge, engineer responsibly, validate with evidence, sustain innovation and measure impact.
The future of computing education will not be shaped merely by better projects. It will be shaped by better architectures for producing engineers. If universities are to prepare graduates for a profession transforming faster than any educational model built to serve it, then computing project education must become more than a final-year requirement. It must become a national engineering capability system.
Author
The writer Augustina Dede Agor, PhD (Computer Science), is a Senior Lecturer in the Department of Information Technology Studies at the University of Professional Studies, Accra (UPSA).
