My professional activity began in mechanical engineering with computing and
analysis of strength/deformation fields in railway cars. To balance the concrete nature
of this business, I gradually moved to pure mathematics and
even to metamathematics, trying to understand the very foundations: set theory
and logic upon which mathematics is built (a couple of papers can be found
here). However, the abstract atmosphere of the foundations turned out too
rarified for a former mechanical engineer, and I made a new turn: moved to
computer science (and back to industry) to work in a project on view integration
and database design. Despite the logicbased nature of software
engineering (especially in comparison to mechanical engineering), the abundance of
syntactical and terminological forms with little (if any) precise semantics made my
first years in computer science really hard. A reminiscence of that can be found
here).

My life in the database world became much easier when I discovered that the
abstract patterns of mathematical category theory (CT) can be quite adequate for
modeling many artifacts in software engineering. Understanding the universe to be specified
as a toposlike structure of variable sets and, correspondingly,
provided a consistent mathematical framework, in which the contents of many papers written on these subjects could be compactly presented in a precise way. The approach at once, like a magic key, opened new horizons and made it possible to advance a few difficult issues in knowledge representation and metadata management (particularly, the infamous problem of view/schema integration). The first impression was so strong and exciting that together with Boris Kadish we wrote a propagandistic Manifesto.

Of course, time cooled down emotions and placed our predictions into a
more realistic framework. Yet I was never disappointed with the fruitfulness of
applying categorical ideas to software engineering problems. A few
years of working in an industrial environment as a business analyst/modeler,
convinced me of the extreme practical usefulness of formulating the problems to be solved in
an abstract way. Certainly, this idea has nothing to do
specifically with CT: viewing things abstractly (in terms of abstract sets,
mappings and relations) is just a normal mathematical practice. However,
the universes to be dealt with in business/enterprise modeling and their
software models are built from sets and mappings, and from mappings
between these primary universes, and from mappings between these
mappings and so on. Categorical concepts appear here quite naturally as
seemingly the only way to precisely specify and manage these wild mapping forests.
Moreover, sometimes categorical patterns and software models are such
a good match that we can well say that software engineers themselves rediscover and
implicitly use categorical patterns
(some examples can be found here).

Though CT is extremely elegant mathematically, I rarely had a chance to study
or work with it in a pure mathematical context. I was usually motivated to
understand different pieces of CT by practical problems I was dealing with.
Over years, this practiceguided (it may be better to say practiceforced) journey
through CT outlined some territory including categorical logic, categorical algebra and coalgebra,
and fibrations (which seem to be everywhere in software engineering). It is exciting to see how these abstract
constructions reappear again and again in software engineering models and
languages. A more detailed list of interests can be found in the Publication page. 
[ Home  Publications/Research interests  Research biography  Resume (pdf) ]