BizDevOps: Because DevOps is

Not the End of the Story

Volker Gruhn1 and Clemens Schäfer2

1
paluno - The Ruhr Institute for Software Technology,
University of Duisburg-Essen, Gerlingstraße 16, 45127 Essen, Germany
volker.gruhn@uni-due.de
2
it factum GmbH
Arnulfstraße 37, 80636 Munich, Germany
schaefer@it-factum.de

Abstract. DevOps, the common service responsibility of software de-

velopment and IT operation within the IT department, promises faster
delivery and less conflicts of competence within software development
processes and is currently being implemented by many companies. How-
ever, the increasing business responsibility of IT, the increasing IT com-
petence in the departments and the standardization of IT operations
require a restructuring that goes beyond the boundaries of the IT de-
partment.
The logical consequence is the BizDevOps concept: Business, Develop-
ment and Operations work together in software development and opera-
tions, creating a consistent responsibility from business over development
to operations.
In this paper we draft a BizDevOps approach by extending the existing
DevOps approach with techniques from the area of End User Software
Engineering. We present a software platform to support this approach.
Based on a case study at a large reinsurance company we share our
experiences from using both approach and platform in practice.

Keywords: Software Engineering, Software Processes, Information Sys-

tems, Value-Orientation, DevOps, End User Software Engineering

1 Introduction
Development of proprietary software applications for companies is challenging,
especially if the competitive power of a company depends on the delivered soft-
ware in terms of time to market and software quality. Hence companies are
looking into possibilities to speed-up the application development process by
re-aligning the cooperation between business and IT departments. Current ap-
proaches, which (like DevOps) aim at breaking down the silo structures between
software development and IT operations, are one possibility to increase speed
of the application development process and to improve the process outcome.
However, these approaches stay within the boundaries of the IT department and
do not address the gap between the business departments (where requirements
2 BizDevOps: Because DevOps is Not the End of the Story

arise and the actual money is earned in a company) and IT department, where
software is created. Addressing and narrowing this gap promises speeding up the
application development process even more.
The BizDevOps approach addresses the boundary between the two distinct
disciplines: it aims at redistributing responsibilities between IT (who are profes-
sionals in rendering stable and reliable IT systems) and business departments
(who understand the rationale of IT systems from business perspective).
– A BizDevOps approach allows people in the business departments to express
and review requirements in a hands-on manner and thus reduces the nec-
essary knowledge transfer from business to IT and provides fastest possible
feedback cycles (the “Biz” in BizDevOps).
– A BizDevOps approach allows IT departments to govern the whole appli-
cation development process to ensure high quality of the software artifacts
(the “Dev” in BizDevOps).
– A BizDevOps approach provides an integrated and automated tool chain
integration to allow as much automation and thus development pace (the
“Ops” in BizDevOps).
Current approaches for improving software processes either focus solely on the IT
side (like DevOps) or the business side (like End User Software Engineering), but
mostly leave the separation between these two sides untouched. Organizational
approaches like Agile Methods try to improve communication and interaction
at the boundary between IT and business, but they also do not address the
boundary itself.
With the BizDevOps approach we present an approach that makes a change
to this boundary by providing business departments with an active possibility
of creating parts of the final application software. This means, people from the
business department become programmers to a certain extent and within cer-
tain boundaries. This empowerment of business departments is supported by a
conceptual framework which allows IT to mitigate the risks of non-professional
programmers. The approach is operationalized by a platform, which is used to
create applications following the BizDevOps approach.
The remainder of this paper is structured as follows. We first outline the
class of applications that can be realized by the BizDevOps approach. Then we
depict the conceptual baseline of our BizDevOps approach as well as the actual
platform to develop projects based on the approach. Then we present a case
study where we show the implementation of our approach at a large reinsurance
company. Finally a conclusion is drawn.

2 Related Work
Approaches like agile software development [1] or best-of-breed-approaches like
No-Frills Software Engineering [4] aim at delivering software faster and with
better reflection of business goals, i.e. they aim at a deep and widespread un-
derstanding of business rationales to deliver software artifacts that generate the
 BizDevOps: Because DevOps is Not the End of the Story 3

best possible business value. All these approaches still require a transition from
the business domain (problem space) to the software engineering domain (solu-
tion space), since the actual construction of software is always regarded as part
of the IT department, and thus consequently the business departments are only
allowed to present requirements and review final software but not to actively
participate in the actual creation of the software. This is–from our perspective–
mostly due to a mindset that larger software applications (as typical for business
information systems) require well educated and highly skilled software engineer-
ing professionals to ensure long-term stability and scalability of the final software
application. Hence these approaches tend to refrain from handing over too much
control to the business departments.
The idea of letting users in business department perform substantial part of
the coding of applications can be found in literature long time ago, like in the
works of Martin [7], where he discusses how business users can create applications
without IT involvement. It is common knowledge in IT industry that business
departments actually perform software development tasks, often under terms
as “Shadow IT” and the like. Precise insights on how far these development
activities go can be found in the works of Panko and Port [8]. Actual software
engineering performed by non-professional developers is a own field of research
on its own, and a good reflection of the status quo can be found in the works of
Burnett and Myers [2].
The DevOps concept, which lays the groundwork for our approach, is de-
scribed by Hüttermann [6] and–being a Continuous Delivery approach–aims at
breaking down separations between software development and software opera-
tion; compared to our approach it is focusing on a IT-perspective and in its pure
form not suitable to include business users as intended by our approach.

3 The BizDevOps Approach

With our BizDevOps approach we address the boundary between IT and busi-
ness departments in order to allow business departments to participate hands-on
in the development of parts of the system and at the same time having measures
in place that allow IT to safeguard the development process. Such an approach
cannot be a general-purpose approach for all kinds of software projects, but will
be beneficial for a certain type of applications. In the following we will detail out
the subset of business information systems we deem suitable for the BizDevOps
approach.

3.1 BizDevOps for Innovative Systems

An active role for business departments makes sense for systems that reflect
business innovations. In literature there are different types of IT systems with
different needs for innovation and realization. Gartner [3] proposes a classifica-
tion scheme with the categories Systems of Record, Systems of Differentiation,
and Systems of Innovation.
4 BizDevOps: Because DevOps is Not the End of the Story

Systems of Record are the foundation of all organizational IT services. They

have a long lifetime and their changes are slow-paced. Systems of Differentiation
address the differentiating core of the organization; their changes are medium-
paced. At last, Systems of Innovation are subject to fast-paced changes since
they are highly opportunistic and aim at following agile market situations.
For our BizDevOps approach we concentrate on applications from the areas
Systems of Differentiation and Systems of Innovation, since systems from these
two classes need to be individually created for an organization and their success
is directly related to how fast and how exact business requirements are reflected
by the IT systems.

3.2 Characteristics of Applications for BizDevOps Approach

For these innovative systems the following characteristics allow us to identify
applications that are suitable, relevant and will benefit from our approach:
– Time to Market is an issue for the application domain. This means, a com-
pany requires fast reflection of requirement changes in the final software
product.
– Requirements are rather uncertain and unstable. This means, requirements
are evolving (as it is the case for new business fields) or subject to frequent
changes (e.g. in marketing/sales-related fields).
– Requirements reflect a high level of business complexity. This means, exten-
sive knowledge about the business domain is required in order to build the
applications, leading to an extensive knowledge transfer from business to IT
in traditional processes.
Besides these criteria, there are also limiting factors, which result from our aim
to allow business departments participate hands-on in the software development:
– The application part to be developed by business departments needs to keep
an overall low IT complexity, i.e. the application can be implemented by
tech-savvy business people in a straight forward manner once an appropriate
overall architecture has been devised.
– The application to be created by the business department can be isolated
in the overall system landscape such that side-effects can be effectively con-
trolled and mitigated.
A business value perspective adds the following criteria for assessing the rele-
vance of a system whether it should be realized by the BizDevOps approach or
not:
– The intended application has a decent level of criticality, i.e. impact on the
company: it either produces numbers that directly go into the books of the
company or it affects the way the company presents itself to other companies,
competitors or customers.
– The intended application is to be integrated with other systems in an appli-
cation landscape and is not isolated, hence integration of the application is
required.
 BizDevOps: Because DevOps is Not the End of the Story 5

3.3 Rationale for Direct User Involvement

One aspect of our BizDevOps approach is that we provide business departments
with a hands-on participation in the software development process by including
End User Software Development principles. This is motivated by observations in
the field: Since most Systems of Innovation and Systems of Differentiation are
characterized more by their deep business domain involvement than their need
for sophisticated software design, business users often already play an active role
in creating or at least drafting these applications using well-known office tools as
Excel or Access (and thus demonstrate their technical literacy when it comes to
implementing parts of business applications). The reasons for this are obvious:
tools as Excel and the like are readily available and the application problems are
of limited IT-complexity such that business users can implement the solutions
themselves. And most important: by implementing such applications themselves,
business users completely avoid time lags and functional gaps, which makes this
approach intuitively appropriate for innovative systems.
The downside of this approach becomes apparent, when these departmen-
tal applications are to be integrated with existing systems or used for business
critical processes. Such “home-grown” applications cannot be integrated with
business processes, they usually do not scale well, and–most importantly–they
lack any compliance with the regulatory settings that any mission critical IT
service provision has to adhere to.
This means, to solve this dilemma, a BizDevOps approach needs to aim at
allowing business users to create their own applications independently and out-
side the scope of IT, while at the same time fostering integration in compliance
frameworks and existing IT landscapes. Through this, the creative and innova-
tive power of business users is preserved while at the same time the resulting IT
applications fulfill the needs of professional IT service provision.

4 BizDevOps Platform
In the following we depict a software development platform which allows to carry
out a BizDevOps approach as shown before.

4.1 Conceptual Groundwork

Central element of the platform (see figure 1) is a so-called sandbox in which the
tech-savvy people from the business department can create the business logic
hands-on (by means of a domain specific language), the data models and the
user interfaces of the so-called apps.
As mentioned earlier, IT needs to safeguard the application development pro-
cess outcome. For this reason the platform provides so-called managed resources.
These are software components which are under full control of the IT depart-
ment and hence can be put under IT compliance frameworks. These managed
resources are the only connection possibility of the apps in the sandbox with the
outer world, i.e. the remainder system landscape.
6 BizDevOps: Because DevOps is Not the End of the Story

App Creation
Independent
of IT App
Users
Sicherer B

App 1 App 2 App 3 ...

Citizens
App Creation Environment for (Tech-Savvy) Businesspeople
External
Users

Sicherer B
Plugin
...
Managed
Resources IT
Users

Domain- Management
App
specific Components
integration in
extensions
ERP BI DMS IT Landscape

Fig. 1. Elements of a BizDevOps platform

The advantage of this combination is twofold: On the one hand we can provide
full flexibility to the business department in terms of development of the apps,
and on the other hand IT can retain full control over quality of the outcome, since
they safeguard how the parts developed by the business departments interact
with the rest of the IT system landscape.
For technical reasons, the platform needs management components (to govern
the development workflows) and can make use of domain specific extensions.

4.2 Automated Artifact Generation

The apps generated by the business department in the sandbox need to be trans-
ferred into (binary) artifacts which can be deployed in the target IT landscape.
Therefore, our platform provides an automated process for generating artifacts
(see figure 2).
The process of generating, building and deploying applications from business-
generated artifacts is highly customizable due to the use of templates. This allows
the IT to fully control the final architecture of the applications to be put into
operation while at the same time freeing developers in the business departments
from the need to know about the final target architecture.
Automated deployment processes allow the business departments to see their
apps “in action” during the development and debugging process. These au-
tomated workflows can be extended by automated regressions tests and also
sign-off processes to further automate release processes with the possibility of
automated deployments into different target platforms.
 BizDevOps: Because DevOps is Not the End of the Story 7

Citizens
Citizen  Artifact   Central  Management  
Repository   Platform  

Enti-­‐
Forms   Logic  
ties  

Stage  
Application  
Builder   Deploy   Stage  
Generator  

App-Sourcecode Standard-Compliant Stage  

Application Binaries
Compo Inter-­‐ Templa
nents   faces   tes  

Deployable  
Artifact  
Managed   Repository  
IT Artifact  
Repository  

Fig. 2. Software artifact generation in BizDevOps approach

4.3 Platform Realization

Our realization of the BizDevOps platform consists of three major elements:

Fig. 3. User Interface composition for developers in business department

8 BizDevOps: Because DevOps is Not the End of the Story

– The Integrated Development Environment–IDE (see figure 3)–is especially

targeted towards the needs of developers in the business departments. It
allows them to independently create, preview, debug, test and refine their
business applications. Graphical editors allow the creation of data models
and user interfaces; for business logic there is a coding environment with
optimized editing and debugging support. All artifacts created in the IDE
are automatically subject to version control, which is also optimized in order
to reduce complexity to fit the needs of non-IT users.
– An Execution Component provides a seamless integration of the applications
created by the Citizen Developers into the application landscape of the com-
pany and ensures scalability when applications are to be used by a larger
number of users.

Fig. 4. Easy to use deployment workflows for business users

– A Central Management (see figure 4) is the main component containing

the actual logic how artifacts developed by the developers in the business
department and IT-provided resources are stored in version control reposito-
ries and later combined in order to create runnable applications. It handles
the relations and dependencies between the artifacts, manages the version-
ing, and ensures compliance by imposing workflows for quality assurance and
application deployment.
 BizDevOps: Because DevOps is Not the End of the Story 9

5 Case Study: BizDevOps at Reinsurance Company

5.1 Facultative Pricing Portal Realized as BizDevOps Project

Over the last years, we were able to work with Hannover Re, the world’s third-
largest reinsurance company, on an application of our BizDevOps platform for
the pricing of facultative insurance risks [5]. These are risks that need to be
assessed (i.e. an insurance premium needs to be calculated on a larger number
of properties of the risk) on an individual basis with a highly heterogeneous un-
derlying portfolio, ranging from power plants over satellites to fine art. Needless
to say, business domain knowledge is at the heart of the pricing process to be
supported, especially when all these different risks are to be processed by one
single system. Furthermore, the way these risks are assessed may require almost
instantaneous changes when reacting to unforeseen events (like an outbreak of
an epidemic) is necessary.
With our platform Hannover Re give their reinsurance specialists the possibil-
ity of creating pricing tools solely within the business departments, i.e. without
IT involvement. The platform itself is integrated with Hannover Re’s ERP sys-
tem (SAP) and linked to other systems like Document Management and the
like.

Pricing  Portal  

seamlessly  integrated  
BizDevOps  app  

Fig. 5. Final outcome at case study: Pricing portal with integrated calculator app

Today, a yearly premium volume of approximately one billion USD is pro-

cessed via BizDevOps-created applications by a user-base of several hundred
concurrent users worldwide. As shown in figure 5, the overall application has
10 BizDevOps: Because DevOps is Not the End of the Story

been created by IT; the actual pricing tools (right part of the screen) are com-
pletely developed in the business departments (as apps in the sandbox). The
final platform integrates these apps in a seamless manner to provide a unique
user experience. The users claim that they are especially fond of the fact that
the applications are built to their actual needs–in a way which would not have
been possible –or only with huge IT investments and spending much more time
compared to BizDevOps approach–when such solutions would have been created
by IT following traditional process models.

5.2 Lessons Learned

The software system for pricing reinsurance risks at Hannover Re is now in
productive use for several years. This extensive period of usage together with
the fact that the system is used on a world-wide basis 24/7 with a significant
number of concurrent users for a decent number of business decisions each year,
allows us to derive the following lessons learned:
– Expressive power of the approach: It shows that the application of a BizDe-
vOps platform for rendering the various pricing tools produces valid results,
since the restrictions imposed by the sandbox-nature of the platform do
not negatively affect the expressiveness of the platform with regard to the
intended purpose.
– Development pace: Although it was not obvious in the very beginning of the
platform, it became clear that the developers in the business departments–
although tech-savvy but without formal computer-science education–did very
well and also very fast in creating the applications; realizing timely adop-
tions to the applications over the course of time due to market demands was
also no problem.
– Fully functional cooperation between business and IT : It turned out that
cooperation between business and IT along the boundaries which are clearly
defined and enforced by the architecture of the platform worked out very well.
Experience shows that the separation of work between business department
and IT along the lines of the BizDevOps platform allows effective decoupling
of the overall development and integration of the platform (by IT) and the
actual business logic captured in the apps (by business).
– Scalability: Experience shows that the platform provides enough scalability
to fulfill the requirements of a mission critical system, even though the usage
has grown significantly over the years.
– Loose coupling The loose coupling of the apps to the managed resources also
turned out to be an effective means for decoupling development activities.

6 Conclusion and Further Work

For many companies nowadays it is an important task to speed up the software
development process for innovative systems which make up the competitive ad-
vantage of the companies. By addressing the traditional boundaries between IT
 BizDevOps: Because DevOps is Not the End of the Story 11

and business departments and by handing over control over certain parts of the
application from IT to business while at the same time ensuring that IT can
safeguard the overall quality of the system, the application development process
for innovative systems can be improved.
We have shown how a platform can make a BizDevOps approach operational,
where a classical DevOps-approach is extended by elements of End User Software
Engineering. As our case study shows, such approach and platform are power-
ful enough to realize a mission-critical pricing system at a leading insurance
company.
Further work lies in the area of applying the approach to other application
domains. Currently we are working on tariff calculators presented to end-users
in the web. With the approach we hope to provide one possible direction how
software development can evolve in the next year under the light of increasing
technical literacy of the digital natives, the business departments people of today
and tomorrow.

References
1. Beck, K., Beedle, M., Bennekum, A.V., Cockburn, A., Cunningham, W., Fowler,
M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin,
R.C., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D.: Manifesto for Agile
Software Development (2001), www.agilemanifesto.org
2. Burnett, M.M., Myers, B.A.: Future of End-user Software Engineering: Beyond the
Silos. In: Proceedings of the on Future of Software Engineering. pp. 201–211. FOSE
2014, ACM, New York, NY, USA (2014), http://doi.acm.org/10.1145/2593882.
2593896
3. Genovese, Y.: Accelerating Innovation by Adopting a Pace-Layered Application
Strategy. Gartner Inc. (2012)
4. Gruhn, V., Schäfer, C.: No-Frills Software Engineering for Business Information Sys-
tems. In: New Trends in Software Methodologies, Tools and Techniques. Proceedings
of the 9th SoMeT 10. Prague (2009)
5. Hemstedt, F., Schäfer, C.: Lass den Fachbereich entwickeln: Wie die Entwicklung
von Businesslogik im Fachbereich gelingt (in German). OBJEKTspektrum 2015(2),
pp. 16–21 (2015), www.objektspektrum.de
6. Hüttermann, M.: DevOps for Developers. Apress (2012)
7. Martin, J.: Application Development Without Programmers. Longman Higher Ed-
ucation (1981)
8. Panko, R.R., Port, D.N.: End User Computing: The Dark Matter (and Dark Energy)
of Corporate IT. 47th Hawaii International Conference on System Sciences pp. 4603–
4612 (2012)