Digital Designer – a new IT profession?

“Digital Design” is the name under which Bitkom (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. – Federal Association for Information Technology, Telecommunications and New Media) propagates a new job description. Its necessity is justified primarily by the fact that successful digitisation requires a rethink in software development. Digitisation leads to a qualitatively different form of software development. It is no longer possible to assume clear requirements from the specialist departments. It is therefore postulated that the design was previously taken over by the user – and that the development only needed to realise the design specified in this way. Because technical development makes completely new applications possible, this no longer works in this way – and the design of the software must be taken over by someone else – namely by the “digital designer”.

The Digital Design Manifesto

The “Digital Design Manifesto” is Bitkom’s central instrument for promoting the new profession. [1] With this document, Bitkom wants to justify the necessity for digital design and present what digital design is and should achieve. The question of the nature of digital design is described by the activities of digital designers as follows:

• Digital designers create big and small.
• Digital designers shape the visible and the hidden.
• Digital designers form the material and the immaterial.
• Digital designers design goal, benefit and means in interplay.
• Digital designers define the design process.

Linked to the Digital Design Manifesto is the opportunity to sign it and thus express its support for the initiative.

To round off the picture, the IREB (International Requirements Engineering Board) has announced a new certificate: Analogous to the CPRE (Certified Professional for Requirements Engineering), in the future one should also be able to be certified as a Digital Design Professional. A corresponding curriculum is to be published by the IREB in 2019.

Really new?

We can take a look back on more than five decades of software development. Is it really the case that there has never been a design before? Have developers actually implemented the requirements of the departments directly? And did it really only take one function to collect these requirements and write them down neatly?

Already in the mid 80s of the last century and before then there was the profession of “system analyst”. Part of his job description was the “development of proposed solutions and target concepts for new information systems”, i.e. pretty much exactly what the task of the “digital designer”, as he is now required to be, should be.

So if in the 1980s there was already a job description that was supposed to create “target concepts for new information systems” (which is just another term for “digital design”), why is this job description now being sold as a completely new one? Has knowledge that already existed been lost here?

The answer is complex. But one thing has to be noted: The currently decisive teachings on the development of IT systems do not focus on finding and designing solutions. This applies both to the discipline of requirements engineering and to that of business analysis.

Requirements Engineering and Business Analysis

In the case of requirements engineering, as described in the IREB curriculum, this is confirmed by the four main activities alone:

• Determine requirements.
• Document requirements.
• Check and coordinate requirements.
• Manage requirements.

There is nothing in this list that would remind you of the design of a solution.

The second current standard – business analysis – is similar. The BABOK (Business Analysis Body of Knowledge) is an essential work that defines the content of the business analysis. This describes the business analysis in six “knowledge areas”. Three of them deal with the collection and management of requirements. Solutions occur only marginally – and the finding and designing of solutions does not occur at all.

Seen in this light, the digital designer with the focus on the solution is actually a new development. But what does it actually look like in practice? Is the activity in the IT projects beyond development and project management really limited to the four main activities of requirements engineering? Do the analysts, requirements engineers and as the corresponding job titles are otherwise still called, actually do nothing other than determine requirements and write them down?

… and in real life?

Of course, the role of the designer still exists today – in almost every IT project. This role differs both from the technical experts, i.e. the users, and from the developers. This is where data models are conceived, processes and algorithms described, and user interfaces designed. This role has different names. Often it is even called “Requirements Engineer” or “Requirements Manager”. And yet their area of responsibility is considerably wider than it is described by the four main activities of requirements engineering. The activities go clearly beyond the raising and documenting of requirements. What is actually carried out is: Design.

And – strictly speaking – this does not even contradict the content of the curriculum for IREB certification. The four main activities are to a certain extent the main headings and/or the definition for the Requirements Engineering. If one penetrates however more deeply into the matter, then very well the methods of the modelling and/or also of the prototyping are contained here. If one models, one must concern oneself inevitably with the solution – one must arrange these. Even if no statements about the concrete technical implementation are made with it yet. And this is even more true if you do prototyping.

That is, contrary to its theoretical claim, Requirements Engineering is also very much concerned with solution design. In analogous way this applies also to the business analysis.

Establishment of the “Digital Designer” is necessary

So why do we need the “Digital Designer” as a new job description? Is all this perhaps nothing more than “old wine in new bottles”?

Even if what has been said so far may sound critical, the introduction of the profession of digital designer is sensible, indeed necessary.

Finally, it will teach what is really needed in practice. The profession of IT analysis is, so to speak, turned from head to toe. The actual (demanding) activity of the analyst – namely finding solutions and design – comes to the fore. And the collection and documentation of requirements takes on the role that actually belongs to them: namely the means to an end – no more, but also no less.

Relatively little is still known about what can be learned for certification as a “Certified Digital Design Professional”. But there is hope that future analysts – or digital designers in the future – will learn in this basic training what they will actually need in practice – and that the wrong focus will not be set, as is the case today.

And it is also good for us analysts if we are also seen by the public as what we already are today: not just meticulous administrators of requirements, but creative designers of solutions.

For this reason alone, we should welcome and support this Bitkom initiative, for example by signing up to the list of signatories to the Digital Design Manifesto. I have already done so.

Notes:

[1] The Digital Design Manifesto (in German): https://www.bitkom.org/Digital-Design-Manifest

Josef Falk has published two more post in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.