When writing an article (outside SDN) I wanted to use the term Workbench. Simultaneously I was asking myself what a workbench in a technical sense really is. On the web I was not able to find a fitting definition. With regard to SAP NetWeaver the workbench concept plays a role as it represents an integrated environment which always has been important in the SAP world.
Here are my actual findings and some thoughts on the workbench concept.
Definition of Workbench
The first definition found in Google writes:
Workbench: heavy table at which work is done by a carpenter, mechanic, toolmaker, etc.
Let's map this common definition to the technical context.
a) Workbench property: a heavy table
A heavy table can be interpreted in our context as an environment integrating the most commonly needed tools. The property integrated seems very important along with the term workbench. The table is the basis for most work done, see the next paragraph for details. This means a workbench is representing a workplace.
b) Workbench property: work is done on
A workplace implies being the main instance for a worker to work on. To allow someone to work with something to perform tasks on implies a certain efficiency and practicability provided. We want to develop software with help on a workbench. This is my understanding in a technical sense. The software development must be possible directly without using the workbench just as a mediator to call another program being capable of fulfilling the characteristic task of software development.
c) Workbench property: used by an expert
The definition references on a toolmaker, which I set equal with an expert. A toolmaker could then be compared to a developer. A tool is a software that is used to produce more concrete pieces of different software with it. With that also framework developers would use a workbench. Generally, everyone involved in software development could use a workbench to speed up development.
Important is that the work done on a workbench should exceed a minimum threshold to associate the usage of a workbench seriously with fulfilling tasks a workbench is mainly intended for. But that's a common logic one could apply for any other entity.
Examples for a Workbench
Well, the transfer of the above short nontechnical definition into a different context worked quite well. What, then, are popular examples of workbenches? According to the said, an operating system like Windows or Linux itself is not a workbench. It does not allow to produce any-purpose software directly. This postulation has been made above.
Tools like Eclipse or JBuilder are workbenches. It is easier to follow this argumentation when translating the identifier tool with IDE. IDE stands for Integrated Development Environment. As one can easily deduce an IDE is integrated and therefore a potential candidate of representing a workbench. We can agree on the other two properties, either: An IDE only is used by an expert, i.e. for producing software (I know people using an IDE to draw drafts of GUIs, but that's only partial or weak use of the capabilities of an IDE). And finally, IDE's support the developer with powerful mechanisms to building his software.In my company, IT Logic, we use a lot of tools of that kind for online marketing and SEO.
Advantages of Workbenches
Workbenches are domain specific. Domain-driven Development is a hot topic nowadays. I think, with xApps, SAP is going in a direction similar to domain-specific and integrated software.
Because workbenches are kind of special, they provide the domain expert with nearly everything he needs to do his job. Additionally, a workbench is abstract enough to provide a broad basis. As with Eclipse a workbench in some cases is easily extendable and customizable.
The Future
In the future, technology gets more complex, accelerating itself exponentially. Read Ray Kurzweil to get a deeper insight on that. More complexity in our technical world means we need to narrow our main competences. A workbench is a good concept to follow with that. Probably there will be more sophisticated ways of realizing functionalities currently only embraced but not automated.
