Decrease the unit costs.
Industrialisation simply boils down to increasing capacity at decreasing unit costs. Industrialisation is well defined for conventional manufacturing processes but not so for knowledge work. This raises two questions: 1.What is a suitable unit of software quantity?
This should depend on the value a piece of software really affords the user. We therefore suggest measuring the quantity of software produced by the accumulated business value of all implemented features.
2.What is the cost of a software unit?
A rash answer would be “required time multiplied by labour costs” but this formula neglects quality debts caused by flaws such as unclean code, careless testing, lacking functions, breached architecture, poor performance or insufficient data security. Software debts tend to go unnoticed for a while but lead to a dead end in the long run: time and money is squandered on imperative repairs while new features grow more and more expensive, with the project being finally brought to a grinding halt. This undesirable state is sometimes called software bankruptcy. The difference between costs of a software change in a normal state and those in a degenerated state is called quality debts, aka technical debts (see Fig. 24.1).
Fig. 24.1Quality Debts
Modifying degenerated software is expensive because in excess of the proper change there is a lot of work to do: The spots affected are hard to find,
The change itself is hard to design,
Side effects are hard to predict and even harder to eliminate if they arise.
This extra work gets more expensive as software degenerates. We therefore urge to put all quality debts on the TCO bill. This paragraph can be summarised by two simple equations: a)Production capacity = accumulated business value of all implemented features divided by required time.
b)Unit costs = required time × labour cost + quality debt
24.2 How Software Industrialisation Doesn’t Work: Offshore
We are talking about the well‐known approach having software developed offshore, by hordes of low paid programmers. The idea is simply to 1.Increase capacity by large teams and to
2.Decrease unit costs by low wages
This might have worked in special cases but cannot be considered a sound recipe in the long run. There are at least two objections: 1.Team size can only be increased to a hard upper bound [1]. Tom DeMarco’s rule defines it as the square root of the total project effort in man months [2]. Teams larger than that are hard to manage and find their productivity decreased.
2.Unit labour costs tend to increase because good developers have always been rare, regardless of global availability. The cheap price of average developers is more than compensated by the quality debts they induce.
24.3 How Software Industrialisation Does Work: Increase of Productivity and Quality
We are suggesting a different approach, suitable for highly industrialised countries like Germany. 1.Increase productivity at constant team size, that is: reduce the time per unit of business value generated, meaning simply to accelerate processes and to concentrate on the most highly valued features. This increases productivity and decreases unit costs at the same time.
2.Keep quality high and quality debts close to zero. Measure quality debts continuously and eradicate them as they sprout. This again decreases unit costs and increases productivity.
The following paragraphs explain by examples how to increase productivity and quality simultaneously.
24.3.1 Productivity by Flow
Whoever has written a program, a book, or done handicrafts knows what flow is: a state of concentration, dedication to a task, undisturbed by the outside, feeling the progress and being imbued with ideas [3]. People are productive when in flow, so we would like them to get there and to stay as long as possible.
Uninterrupted Working
It has been show that interruptions of only a few seconds can reduce concentration and divert from flow for as long as 20 min [4]. This is illustrated by the saw tooth effect: productivity is increasing for a while and then plummeting on the next interruption. Getting back into flow is a painful battle, soon frustrated by another interruption. Minimising interruptions can be achieved by obvious means: Small offices tend to be quieter than open‐plan ones. There are fewer phone calls, fewer chats.
Quiet hours are guarded time slots with no phone calls and no conversations allowed. Even emails must wait.
Rules for interruptions define accessibility. This can be a closed door, a signal light on the desk or any other sign.
Opportunities for retreat: particular offices or the home office as a quiet place to retire to.
Tools protecting against distraction: several tools (editors and others) provide a Distraction Free Mode, inhibiting whatever could get you out of flow.
Perfect Working Environment
It has not always been recognised that flow requires a perfect working environment. People won’t get into flow unless they feel happy and are provided with the best tools available. This means in particular: The offices should be friendly and welcoming, with plenty of light and space.
User friendly tools on efficient hardware are a must. Programmers need two or three large screens of the highest available quality.
24.3.2 Productivity by Automation
Tedious, repetitive tasks cut into the programmer’s flow as much as unwelcome interruptions. We therefore must automate the development process as much as possible, and really, there is a lot one can do, after several errors and dead ends in the past such as model‐driven software development. The first thing to note is that there are two completely different jobs: invention and production. It is invention that adds the value, and it is production that makes it available to users of all kinds, from seasoned testers to unskilled end users. Software developers continuously invent new solutions, casting requirements into code. They therefore need freedom to invent and tools to pin down, try and fix their inventions. Once the software is finished it is passed over to the Build Pipeline [5] which integrates the artefacts of many developers into new software versions delivered to test, training or production. It automatically processes software through stages such as unit test, quality‐check, integration, deployment and distribution.
24.3.3 Productivity by Low Vertical Integration
Minimizing vertical integration means just maximising reuse, and that in three regards: reuse of software, of infrastructure and of knowledge.
Reuse whatever software has been programmed by others, what is available in reusable form and useful to your project. Software development today involves much software OEM (original equipment manufacturing) and comparatively little original programming. A plethora of powerful and well‐tried open source components are available at no royalties. Evaluation and integration are not free, of course, but it would be foolish not to benefit from this treasure. Samples on real, large scale projects have shown vertical integration rates of only 1 to 7% (i. e. share of original code). But quality debts are ever looming large: open source components must be thoroughly evaluated, scrutinized and integrated. Obvious criteria include licence issues, security, side effects, and hidden dependencies. GitHub affords a simple, fool proof access to whatever open source products you can dream of.
Reusing infrastructure is achieved by getting it from professional providers through simple plug‐in mechanisms. The build pipeline, repositories and many more tools run like any other mission critical production software on a professionally managed infrastructure. Processes are automated using tools like Jenkins for continuous integration and delivery. Private servers running unmanaged under the desk and crashing at inappropriate times are long gone. This is a beautiful example of self‐reference: the rules applicable to the development environment are identical to the ones the develo
ped software is subjected to.
Reusing knowledge is achieved by visiting websites like Google Search, stackoverflow and many others. The world’s knowledge is never more than few clicks away. Gone are long shelves of unreadable and outdated manuals. But searching the internet is an art to be taught: how to tell reliable information, which site is useful for what question?
24.3.4 Productivity by Focusing on Real Benefit
Software development has often been regarded as a process casting requirement into code: requirements in, code out. But this simple model falls short of taking into account the requirement’s real benefit. Questions to ask include obviously the following: What is the real benefit of a requirement? Can it be measured?
What if it is dropped?
Are there cheaper alternatives? There might be a completely different approach.
Are there any tools around able to do the job?
The overall objective function of software development is the accumulated benefit of all implemented features, not their sheer number. Focusing on the right features (doing the right things) can increase productivity vastly more than just optimizing the development process (doing things right).
24.3.5 Productivity by Quality
Software quality is holistic. The standard ISO/IEC 9126 defines a comprehensive set of quality indicators but even lousy software sometimes complies with it. Software quality is much more than working functions and few crashes. It includes properties such as Security, data protection, non‐hackability
Performance, reliability, resilience, scalability
Maintainability, portability
Usability, freedom from barriers
All of these properties must be continuously measured, recorded, analysed and published by tools integrated into the build pipeline. This guarantees immediate detection of quality debts and induces within the team the feeling of a crack unit as long as the debts are close to zero. And if they are higher than expected, the management knows at least where the problems are. Let us dwell on this point a bit longer.
Quality debts have the undesirable property to turn up late, when things have really gone wrong. The problem is this (see Fig. 24.2): functions and defects are visible for all users. But compliance to quality measures and the amount of quality debts is often invisible and assessed if at all in selective reviews only.
Fig. 24.2The Essence of Quality Debts
We therefore suggest proceeding in three steps:
Step 1: Defining Measures
We identify measurable properties suitable as quality indicators, including static features laying in the source code and dynamic ones measurable only when the software is running. Fig. 24.3 shows samples of both types.
Fig. 24.3Static and Dynamic Analysis
Step 2: Defining a Quality Contract
For each selected quality indicator we define lower and/or upper bounds, we define what values are desirable, barely acceptable or to be refused to pass the build pipeline. The set of these rules is called the quality contract, see Fig. 24.4. The example shown is the one we are using daily.
Fig. 24.4Our Quality Contract
Step 3: Visualising Deviations
Like any contract the quality contract must be supervised, deviations detected and reacted upon. We are obviously not suggesting a pillory for the culprits, but software debts must be made visible, analysed and repaired.
We use an information radiator (see Fig. 24.5) for this purpose. This is a large screen, conspicuously placed in the coffee corner, showing the software quality or the lack thereof. Reported quality puts everybody in a good mood, beginning decay can be thwarted early. Gimmicks (or attractors) such as news or comics can increase the attention allocated to the radiator.
Fig. 24.5An Information Radiator
24.4 Conclusion
Software development can be industrialised by improving productivity and quality at the same time. We have presented some well‐tried recipes, with offshore deliberately excluded, focusing on increasing each individual’s productivity, the degree of automation, the reuse of software, infrastructure and knowledge. Implementing the right things in the right order is often the most important clue to productivity. High quality increases productivity if suitably managed. It is hence one of the few free lunches in this world.
This is how software development will be fit for international competition, even in a high‐wage country like Germany.
References
1.
F. Brooks, The mythical man-month, Addison-Wesley, 1975.
2.
T. DeMarco, T. R. Lister and D. House, Peopleware: productive projects and teams, Pearson Education, 2013.
3.
M. Csikszentmihalyi, Flow: The psychology of optimal experience, HarperPerennial, 1991.
4.
L. Seiwert, Das neue 1x1 des Zeitmanagements, Gabler, 2006.
5.
J. Humble and D. Farley, Continuous delivery: reliable software releases through build, test, and deplyoment automation, 2010.
© Springer-Verlag GmbH Germany 2018
Claudia Linnhoff-Popien, Ralf Schneider and Michael Zaddach (eds.)Digital Marketplaces Unleashedhttps://doi.org/10.1007/978-3-662-49275-8_25
25. From Digital Retail to Real-Time Retail
Andreas Kranabitl1 and Robert Pikart2
(1)SPAR Business Services GmbH, Salzburg, Austria
(2)Pikart IT Advisory GmbH, Vienna, Austria
Andreas Kranabitl (Corresponding author)
Email: [email protected]
Robert Pikart
Email: [email protected]
25.1 The Digital Retail Tsunami – Retail 4.0
The retail business area is changing due to the fact thatcustomers are more and more using online, realtime applications to gather information on what’s interesting, helpful and attractive. Consequently, the traditional way of how to inform and prepare customers about buying opportunities gets less relevant. Customers are pulling information when they want. Here and Now.
On the other hand, huge customer behavior related data‐volume creates the opportunity for retailers to learn and understand customer needs and desire on individual level. Using these data leads/helps to generate holistic customer’s insights, predict customer’s shopping activities and find out which model of online stimulation motivates and supports the customer best. This means to establish a process, which is permanently monitoring customer’s activities, analyzing reactions, creating stimulation and connect to retailer’s strategies and business models – in real‐time!
Future retail is not only online and mobile. It’s necessary and business relevant to connect online/mobile with physical store shopping experience. This will be one of the key‐success‐factors for the near future. Providing a seamless platform that takes perfect care of its customers by having a tight and ongoing connection to retailer’s guidance and services either through digital channels or directly at the retailer’s store.
We have to achieve customer insights by analyzing and assembling different data in real time. This completely new approach, how to serve, guide, manage and attract customers has a significant impact on the retailer’s strategies and priorities, overall on the internal organization.
While in the past of retail sales was supported by marketing and IT was a technology supporting department, internal positions and responsibilities are now changing. Sales is moving to a more operational level while Marketing takes over the extensive communication with customers. Marketing is strongly using the power of social media and communication. With the support out of the growing market of social services and analytics providers, they are in the perfect position to drive, influence and lead the business strategy. Because more and more activities of retail are becoming customer focused, marketing is starting to act as the strategic dispatcher between business and custom
er. This means, that most of customer related activities have to pass marketing processes and organization. Many of these activities are based on digital, online and mobile services.
This development, moving the strategic focus of retail on digital areas, changes the role of IT organization inside the retail companies and this change moves IT in a strong strategic position very close to the marketing division. This, too, leads to the fact that the collaboration between Marketing and IT becomes much more important and relevant. Both organizations are forced to establish appropriate processes, methodologies, teams and processes to follow the new business requirements. A key success factor in this phase is to align speed of reaction and speed of delivery to the expectations of this dynamic here‐and‐now business approach.
Digital Marketplaces Unleashed Page 34
