Innovation
Communication is one of the most important success factors for projects and companies. Good is what leads to communication. But what makes good communication? And what does this have to do with APIs?
Communication is the success factor in life. Everything we do together requires communication. Linguistic and symbolic communication enables culture and progress.
When do we communicate successfully? There are theories about this - but what does this mean in the day-to-day work of an organisation? Communication requires organisation so that not everyone has to talk to everyone about everything. The organisation serves to provide complex benefits while keeping communication as simplicity itself as possible.
When everyone who has to deal with each other is organisationally (and physically) close, distances are shortened. Unfortunately, this is not always possible - tasks change more frequently than the organisation.
It is almost always good what promotes communication and bad what makes it more difficult. Apart from good organisation (which also includes clearly separating unrelated things), the what and how much are just as important as the how and when.
It is always people who communicate, not organisations. A good boss (manager, project leader, team leader) lets the right people do the right things. People are most productive in challenges that they enjoy, that neither over- nor underchallenge them.
If the organisation is not right, communication is more difficult because the organisation has to break down barriers that hinder communication.
Communication works best when it takes place directly between people who are pursuing the same goals, at the point in time when people are engaged in that goal.
Services such as Slack fulfil precisely this need and are therefore very popular.
We require employees to assess the consequences (impact) of all their actions. Of course, this is especially true for developers. Transparency is therefore necessary; only those who have an overview can assess their impact. This includes an overview and unhindered additions to planners, status and resources. Openness almost always has more advantages within projects than confidentiality.
For example, our issue management with JIRA(opens in new tab) supports communication by providing an overview of all issues and their status at all times. Manual lists that are not up to date, on the other hand, hinder communication and lead to unproductive overtime.
If we don't speak the same language, misunderstandings happen (Lost in Translation(opens in new tab)). If these are not eliminated quickly, entire projects can fail. That is why development, IT, project management, marketing and other stakeholders should find a common language.
If developers have no idea about the domain and business experts have no idea about software, it won't work despite all the agile methods. Techniques such as Domain Driven(opens in new tab) Design can work as a translator; user stories or use cases alone are not enough, because they are limited to just one language, that of the users.
Large organisations like to leave external communication to the professionals: the communications department has to enter into a dialogue and bring information from the outside back into the company. Therefore, all employees are also ambassadors and must take care of their communication.
We suffer from information overload and still don't feel informed enough.
Less is often more. Familiarising yourself with a project with hundreds of pages of unstructured documentation is just a little simpler than if nothing is documented. Documentation needs abstraction to avoid getting lost in the details.
The classic Concepts and Facilities manuals (from IBM and others for many software products) are concise, exemplary documentation; together with a tutorial and a Troubleshooting Guide, they often suffice as documentation.
With an intuitive user interface, a description of the interface is quite superfluous and usually outdated anyway.
We should also consistently avoid superfluous artefacts in planning. Only what has balance and can be maintained should be created at all.
"Reduce to the max" is therefore called for - but more difficult than adding a shift of documentation to the cake as decoration.
This article is not about communication technology (Swisscom's bread and butter) - except for one topic: APIs. This is because APIs connect human and machine communication.
Processors can technically handle large data without structure, e.g. shared memory.
Processors can technically handle large data without structure, e.g. with shared memory. When people talk about big data or non-SQL Data Bases, they think of unstructured data. What is meant, however, is that the data does not easily fit into a schema and we first have to recognise structures.
APIs allow data and processes to be exchanged across the boundaries of systems and organisations. They allow the people involved (usually developers) to understand and orchestrate the exchange without having to dive deep into the other system or organisation. For example, I may need an API from Twitter without having to worry about how Twitter scales its service (this is similar to human communication: I can talk to someone about a Problem without knowing how they organise their day).
APIs are the central connection of systems and organisations; they are a foundation of digitisation.
Feedback is always welcome!
Head Application and Business Services
Find the job or career world that suits you. In which you want to help shape and develop yourself.
What you make of it is what defines us.
