Back to writing
E-036 / Essay

İnovapark: From software to institutional memory

What questions emerge today from İnovapark’s work, which began with software development and grew to encompass decision structures, working methods and an open knowledge archive?

Concepts in this work

Follow a concept to discover related writing and work.

More concepts (2)

What needs to be in place before software can work well? I look at İnovapark’s history and its emerging knowledge archive through this question.

When software is installed, we expect work to become more orderly. Records will be brought together, tasks will be tracked and decisions will become easier. But if nobody knows who should approve a request, if the same word means different things to two teams, or if the evidence needed to consider a task complete is unclear, will adding more fields to a screen be enough?

This question offers a starting point for understanding how İnovapark developed.

The structure behind the tool

Software development at İnovapark began in 2005. In 2007, organisational needs that limited the effective use of software became clearer, and early trials and tests followed. In 2008, the work expanded into consultancy. This trajectory describes an inquiry that began with technology and turned towards how companies make decisions and organise their work. History

The central issue is the direction of alignment. İnovapark’s approach considers software alongside the company’s structure, starting with its purposes, responsibilities and processes. To decide which work a tool should make easier, we need to understand who does that work, under which rules and in what way. An approach specific to each organisation

Consider a simple example. A purchase request is waiting. Software can show its status. To understand why it is waiting, we also need to examine approval authority, budget limits and how exceptions are handled. Adding another notification and clarifying decision boundaries are different interventions. This is a thought exercise that makes the relationship between a tool and an operation visible, rather than an account of a particular client.

Seen this way, software design opens further questions: Where should a decision be made? Which information should be shared? Who should be able to stop the work, and under what conditions?

Different paths through the same accumulated experience

In the İnovapark archive, one framework for working through these questions is the ReJourney, InStructure and ProJection trilogy. ReJourney focuses on transforming existing operations, InStructure on organisational structure and governance, and ProJection on growth and future capacity. Today, these should be read as methods shared through the archive. Programmes

This distinction is useful because it does not give every need the same starting point. Understanding a bottleneck in a workflow is different from organising decision responsibilities in a growing company. Both, however, require the problem to be described, the proposed change to be implemented and the outcome to be reassessed.

What interests me here is how the methods connect. Improving a process may lead us to a question of authority. Clarifying authority may require us to question the reliability of the information being used. Following a question can change the boundary we drew at the outset.

What does a document help us remember?

Turning this body of work into an archive also raises the question of how its documents should be read. We can see the arrows in a process diagram. We cannot always see why they were drawn there, which option was rejected or under what conditions the decision should be reconsidered.

This is why, when thinking about institutional memory, I want to keep decision rationales alongside the files. When a document’s purpose, basis and limits are visible, reusing it in a different context becomes a more deliberate undertaking.

An authority matrix may need to be revisited when a role changes. A work instruction may lose some of its steps when the tool changes. Keeping a document and maintaining its validity need to be examined separately. It is a question I find worth asking of an archive: Under what conditions is this record still useful?

From an open archive to new questions

İnovapark ended its consultancy activities in 2026 and no longer accepts new clients. Its website is now an open archive where accumulated knowledge is being processed and shared in stages. Bringing that knowledge into an AI and agent-based experience is a separate development direction. The publication of documents does not mean that the entire experience has been released. The AI and open archive phase

The question that interests me in this transition goes beyond finding an answer inside a document. Can a system also show the conditions on which an answer depends? Can it distinguish a recommendation from permission to act? When carrying a method that once suited its context into the present, where should it stop and ask a person?

I see these as new questions opened by the accumulated work, rather than as İnovapark’s completed results. A path that began with how software is used now extends to how knowledge can be preserved, tested and reused.

İnovapark Open Archive is a starting point for exploring this path through documents and programmes. As I read, I want to look at both what a method says and the question that gave rise to it.

Continue reading

Publications that share subjects with this article.

Software · Systems · Knowledge

A task’s journey through a2

A two-record example tracing the contract, execution path, output checks and the record left at the end.