Chapter 15. Finding Shadow IT

Image

When you are trying to consolidate software application landscapes or promote digitalization, so-called shadow IT stands in your way. Every company beyond a certain size uses software that the central IT department is not aware of. All those little solutions that run in business departments and that hardly anyone knows about are often business-critical.

Frequently this software was built by the users themselves. Domain experts who have no formal education in programming are usually unaware of the measures that need to be taken to assure quality, backup, security, and so on. This can become a risk, for example, when the short little Visual Basic script written by an intern to support accounting eventually becomes part of the process that the entire company relies on.

Domain experts often use shadow IT without even realizing, so it is easily overlooked. Domain stories can help IT and management find this shadow IT and see the whole IT landscape.

This chapter is for you in any of the following cases:

• The IT landscape of your business is unclear or has “blind spots.”

• You want to find software that the IT department is not aware of.

• You want to add backup, version control, security, etc., to software that was created by users.

Henning’s Industrial Manufacturing Story

My colleague Carola analyzed the architecture of a large manufacturing execution system (MES) for an aircraft manufacturer. The client’s goal was to have as little production downtime as possible. A single day of production downtime would cost millions. Carola soon realized that a larger view was required: a map of the IT landscape. Not only the MES but many other systems had an impact on production. An evaluation of each system was needed to answer the question, how would a failure in that particular system impact production?

Carola brought me along, and together we visited several of the production plants. We modeled many domain stories with people from production, planning, and IT. Since our aim was to find software systems, we focused on DIGITALIZED stories. Some of them were COARSE-GRAINED, others FINE-GRAINED, all of them AS-IS.

We found the big systems we expected—the software that the airplane manufacturer had bought and built. And we also found many small and not-so-small-anymore solutions that had been written by production engineers over the decades. For example, one domain story showed that the planning system (known IT) exported the shell design to a PDF file on a specific hard drive, which was then converted to an Excel file (shadow IT!). This file was read by the manufacturing controller to initiate the production of the shell.

Once we knew what systems existed, we could discuss the consequences of their failure. For example, we learned from the domain story we briefly just described that without the shell design Excel file, production would come to a halt.

Not Only Software Developers Develop Software

Shadow IT is ubiquitous in large organizations. It starts with an Excel sheet that performs a calculation. The domain expert who wrote this file puts it on a network drive and passes it on. Their colleagues are excited, because they no longer have to do the calculation by hand. Work becomes even easier when a bit of scripting simplifies the use of the new tool.

But the enthusiasm might evaporate when any of the following happens:

• The author leaves the company, and the file is accidentally deleted and lost forever.

• They write a new version and not all their colleagues know about the replacement, and the differences in the results are only detected a few months later.

• The calculation goes wrong unnoticed in a certain edge case and costs a lot of money.

It’s not a bad thing per se if non-IT people write software. What’s bad is that this software is exposed to all the risks that only the trained eye can detect. A domain expert is usually unaware of software quality goals like reliability, maintainability, and security. They may not be aware of the problems that arise from knowledge monopoly or the lack of backups. Also, they probably have never heard of practices like unit tests, version control, pair programming, and many other things that software engineers have had to learn the hard way over the past few decades.

Making Hidden Software Systems Visible

So, you want to bring shadow IT out of the shadow. A first step is to familiarize yourself with this software. Domain Storytelling can serve here as a means to collect information for management of enterprise IT.1

1 We don’t want to go into the details of Enterprise Architecture Management here. However, if you are familiar with it, you might notice that Domain Storytelling can be utilized to support it.

Nontechnical managers often don’t understand the problem with software that bypasses enterprise IT. When IT people tell them about it, they don’t see a major challenge. With domain stories, we visualize the whole picture to show them where shadow IT is used in important parts of the business process. Thus, we make the problem visible.

Back to the Leasing Example

At Alphorn, Harold (the head of IT) had suspected for quite a while that there was shadow IT in the risk department. Until now, he couldn’t convince Becky the boss that this could lead to problems. Now that two external consultants are around, Harold asks us what to do about it. We arrange another meeting with Raymond, the risk manager, and tell him our plan to find the hidden software. Together we walk through the FINE-GRAINED domain stories Alphorn 2–5 (see Figures 8.28.5) that we modeled with him in Chapter 8, “Case Study—Alphorn Auto Leasing Inc..” In Alphorn 4, sentence 2 (see Figure 15.1), we spot an interesting detail—the car price. Stefan opens the discussion.

Image

Figure 15.1 Alphorn 4: Risk assessment—FINE-GRAINED, PURE, TO-BE

Moderator Stefan: “When you are voting on the contract, how does the car price influence your decision? Is it just that the higher the price, the higher the risk?”

Risk manager Raymond: “Oh no, it’s much more sophisticated! Expensive cars, for example, are typically leased by rich people. They could buy the car, but instead they lease it for tax reasons. They have enough money and usually pay their bills. So, the risk with expensive cars is low.”

Stefan: “Hmm, so how do you assess the risk?”

Raymond: “I compare the car price to the price risk table.”

Stefan: “What is the risk price table?”

Raymond: “It calculates the probability of missing payments based on the price of a car.”

Stefan: “Could you please explain that?”

Raymond: “Whenever a customer doesn’t pay an installment, the accounting department informs us about it.”

Stefan: “Ah, I heard something about that when I talked to accounting!”

He brings up Alphorn 9 again (which was written with accountant Amin in Chapter 14, “Deciding Make or Buy and Choosing Off-the-Shelf Software”) and points to sentence 2 (see Figure 15.2).

Image

Figure 15.2 Alphorn 9: Payment, missing payment—PURE

Raymond: “Precisely! When I hear about the unpaid installment, I enter it into the missing payments tracking. From that, the risk price table is extracted with a VLOOKUP.”

Stefan: “Let’s put all of this into another domain story….”

Together, they model domain story Alphorn 10, which is shown in Figure 15.3.

Image

Figure 15.3 Alphorn 10: Missing payments tracking—DIGITALIZED, AS-IS

Stefan: “OK, so the missing payments tracking is an Excel sheet! And the risk price table is another one.”

Raymond: “Yes, that’s true.”

So Harold was right: A significant part of business logic (the missing payments tracking) relies on Excel files. The conversation with Raymond continues and covers topics such as the usability and error-proneness of the current software solution. All of this information flows into Harold’s IT portfolio management. Harold assesses the operational risk of the Excel files and determines a need for action. Together with the Alphorn 10 domain story, he can now convince Becky that he needs funding to make tracking future-proof.

Hidden use of software systems becomes obvious when work objects appear out of the blue. Either you have domain experts telling you that they “look up the XYZ list” or they answer your question “How do you know that?” with something like “I got that from the ABC report.” When you ask them where the XYZ list and the ABC report come from, you will often discover that software systems like Microsoft Access, Excel, Lotus Notes, or shell scripts are used.

What to Read Next?

The systems that are found in the shadows are part of the overall IT solution. They should at least be visible in the context map (see Chapter 10, “Finding Boundaries”).

The shadow systems may be replaced by systems developed by the IT department. Then you will want to work on the requirements (see Chapter 11, “Working with Requirements”) and implement them (see Chapter 12, “Modeling in Code”).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.94.102.228