1. Introduction

The Semantic Eye Framework takes successful industries as role models and proposes a disruptive, strategic approach to overcoming the «digitalisation malaise» (see next chapter) in the digital transformation of organisations:

2. Key Areas

The Semantic Eye Framework was designed to support this two-pronged strategy by addressing five key areas to ensure digital-transformation success:

3. The Semantic Compass

The semantic compass is part of the conceptual foundation. It provides orientation and guidance (hence «compass») on how to get from the vague idea for a product (top left in figure 2-3) to a working solution (bottom right). In typical digital transformations today, most of the deliverables are either documents in natural language, informal diagrams or program code. So, these projects rely on highly ambiguous artefacts for most of the time, then jump right to highly precise program code at the last moment (grey curve). During this jump, all the ambiguities need to be sorted out (Precision Gap)—which does not happen. As a result, the wrong solution (code) is produced.

In contrast, the Semantic Eye crosses from the vague to the precise side as early as possible (green curve in the figure) by making all deliverables more precise and more formal. This enables early digital-tool support and automated quality checking.

4. Organisational Processes

Organisational processes are an end-to-end description of where and how an organisation creates value.

Every organisation has organisational processes.

They are arguably the most frequent and relevant subjects of digital transformations. Organisational processes are the kingpin of the Semantic Eye Framework and thus receive great support by the Framework.

5. The Organisation’s «Cosmos»

At the heart of the Semantic Eye lies the «Cosmos», a conceptual organisation-tier model, consisting of three parts that make up, describe and later govern the organisation, its activities and business:

• the organisation itself;
• the relevant and/or affected subject areas;
• the organisational processes.

The subject areas represent the «real world» with all its objects, relations and rules. The processes in the Cosmos tie the organisation to the subject areas:

who needs to do what and when.

The Cosmos belongs to the Organisation tier. The Technology tier should build its own models that reference the elements of the Cosmos models for traceability.

6. Digital Tools

Formal models are a prerequisite for the design and implementation of digital tools able to create stringent, challengeable «blueprints» of organisations, processes and subject areas. A first integrated digital workbench  relying on a state-of-the-art open-source framework is under development. It is able to run in an internet browser and comes with first-class LLM support to assist the building of the Cosmos of the organisation.

7. Transformation Journey

The framework promotes the collaborative and iterative building of a comprehensive, explicit Cosmos for organisations, with strong domain semantics.

The Semantic Eye divides the journey into a before and an after choosing and onboarding software and technical partners. The journey consists of four phases, the last of which repeats forever:

• Understand: Create a Cosmos of the solution «as is», carefully analyse it and the new strategy;
• Frame: define the organisational solution «to be» in a new or updated Cosmos;
• Take: Scope, design, implement and deliver an MVP, a minimum viable product (here: a process);
• Evolve: frame and take ever-more highly digitalised Cosmos and solution versions.

Each phase is best carried out in iterations towards its phase milestones.

8. Patterns

Whenever languages, methods and tools are being applied, best practises for their application emerge over time and can be documented as solution patterns. The tool platform should provide explicit support for patterns. By their statistical nature, LLMs favour repeating patterns and can play a big role in suggesting suitable patterns. AI agents can then apply them automagically.

9. Key Benefits of the Semantic Eye Framework

Every organisation can benefit from the Semantic Eye.

Here are the top three benefits the Semantic Eye Framework offers to organisations:

• The framework gives organisations a playbook that can be studied, taught, discussed, challenged, adapted and improved over time.

• The expertise embedded in the framework, its goal-driven and methodical approach, and its tool-based application significantly reduce the risks of transformation projects from their start by aligning stakeholders and avoiding unforced errors.

• An organisation’s Cosmos is a first-quality knowledge-capturing and -management instrument. It enables the organisation to describe, study, learn, plan, align and optimise subject areas and processes long before software is being built.

10. Where to Start?

Organisations that see potential benefits in using the Semantic Eye Framework (or parts of it) for their own digital transformation should consider these steps:

• Study the «Semantic Eye White Paper» that can be downloaded over here.
• Get professional guidance and support by Depuzzle (website coming soon).

1. Automation and Innovation are Hard

Digitalisation is an automation problem, and automation is the holy grail of any discipline. Automating even a small part of a subject area requires  a level of awareness and domination of that area and of its complexity that is beyond the successful daily operations. Also, automation also goes hand in hand with innovation. Innovation is equally hard.

What compounds the complexity is the fact that both the solution before the transformation («as is») and after the transformation («to be») have to be considered and mastered.

Designing a new or simply a «better» solution requires several «ingredients», for example:

• a deep understanding of the organisation, its strategy, the involved subject areas and processes;
• a body of precise requirements for the new solution;
• a solid grip on the technology currently in use and on the candidate technologies for the new solution;
• the ability to envision the solution to be and to evaluated its effectivity, efficiency and acceptance;
• creativity, courage and persistence.

Obviously, understanding is key. In complex environments, understanding is a group exercise in communication and knowledge management—yet another huge challenge for organisations.

3. Overwhelming Organisational Complexity

The principal reason behind the recurring problems of digital-transformations of organisation is as simple as it is sobering:

Most organisations do not master the combined complexity of their strategy, requirements, subject areas and processes at the level required for automation and innovation.

Let’s call this the organisational complexity. Mastering the technical complexity is the responsibility of technical experts and partners.

It is worth noting that the weak point in digital transformations is usually not the actual development of the software programs and components—once the development teams have a clear, high-quality specification for what to build. Both software development and software quality have made enormous progress in terms of methods and tools over the last 20 years thanks to automation.

4. Breaking Down Complexity

At this point, the three tiers of transformation become a helpful instrument: digital transformations break down into activity on three mutually-dependant tiers:

• The Strategy tier must identify and define the goals and the future products and services of the organisation; it must explain why a transformation is needed.
• The Technology tier defines what is feasible and how, and eventually provides the resources to do so.
• The Organisation tier ➊ masters the knowledge, rules and complexity of the relevant subject areas; ➋ coordinates the resources provided by the Technology tier, to realise the given strategy.

The Organisation tier is the actual scope and focus of the Semantic Eye initiative.

5. Mastering Organisational Complexity

Now, why are other industries able to successfully manage even greater complexity? Again, the answer is simple:

While other industries have developed powerful concepts, engineering practises and sophisticated software tools at great cost, digital transformations still apply amateurish methodologies and use no digital tools worth mentioning.

The  construction industry is a great role model here: it introduced precise, true-to-scale blueprints in the 15th century in order to address precisely the issues discussed earlier. Construction blueprints changed everything: they can convey both the big picture and accurate details through a standardised visual language that everybody in the industry understands. Blueprints allow for a clear, geographic separation of planning, costing, offering, tendering and execution.

Today, construction projects use sophisticated digital tools like CAD and BIM to create 3-dimensional models of buildings. These models are carefully validated and improved by many experts in order to eliminate errors, unplanned costs and delays once construction starts. People work on such models sometimes for years before, eventually, excavators set to work.

6. The Blind leading the Blind

What do we mean by «amateurish methodologies»? A popular approach to mastering complexity is agile methodology. A joint team of members from both the organisation and the software partner start on one end of an extremely complex problem, gather a bunch of requirements, and implement a solution for them. Then, they evaluate the result, gather necessary improvements and the next bunch of requirements, address those, and so on. What these teams do is progressive feature negotiation on the Technology tier:

The collaboration is problematic in various ways:

• The requirements are often described by members of the organisation who have no formal training to do so; often they were hired specifically for this role but lack deep know-how of the subject matter. The completeness, coherence and quality of the requirements is dubious at best.
• The members of the technology partner are not trained in requirements engineering either, and usually have no previous knowledge of the relevant subject areas and processes.

Thus, the two groups don’t share a common «domain language» and never fully understand what the other side is up to. A case of «the blind leading the blind».

7. No Explicit Solution Description

A big issue of progressive feature negotiation is the fact that only the requirements are documented but not the resulting solution. Eventually, the only reliable «documentation» is the software code. Software code is not helpful for domain experts and, in fact, for most stakeholders.

Not documenting the solution in a form that can be understood by everybody means there is no «big picture». This precludes studying, challenging and improving solutions before they are actually built. With the effect of many unnecessary conceptual defects that must be fixed in the aftermath at great cost.

8. Agile in Digital Transformations

Advocates of agile methodology like Scrum argue that an elephant must be eaten small bytes, and that errors need to be made in order to learn and improve. Their assumption for this methodology is that all organisations and subject areas are chaotic. And their rationale is that mastering the complexity of chaotic environments up front is impossible.

Errors and learning are important, but does every team need to make the same mistakes all over again? Or can we learn collectively as an industry, like other industries have before us?

We argue that, in most cases, unclear or chaotic situations can be converted at the Organisation tier into understood and predictable ones.

A discipline that does this is engineering. It delivers with the help of mathematics (including graph theory or statistics), other formalisms (e.g. chemical formulae), or formal models (e.g. 2D or 3D blueprints, musical scores, particle flows).

The Semantic Eye embraces the agile approach, however, first at the organisation tier until clarity and alignment is reached; then at the technology tier.