In modern IT operations, the trend towards containerization has lead to the memorable saying that you should treat your servers like “cattle, not pets.” The meaning is that you don’t run systems on any one named server, but instead on a large number of virtual server instances that you don’t really care about individually. It also implies that if there is a problem with a server, you simply kill it and start a new one.

Unfortunately, the same approach is often applied to IT workers, where it is less appropriate. This is the thinking that has led to productivity-killing open plan offices. It is well documented that these decrease productivity and are roundly disliked by the majority of workers. However, they allow management to pack in more human cattle in less space.

Desparate to remain productive, IT professionals don noise-cancelling headphones to try to counteract the incessant disturbances that their employer has decided to burden them with. Now, the future tech design branch of Panasonic has taken the logical consequence and invented blinders for humans just the ones used for horses. I think this is taking the livestock thinking one step too far.

It is not a good idea to hire expensive IT professionals and then give them poor working conditions. Ideally, you should place everyone in individual offices or small team rooms. Failing that, learn from the one successful open-plan offices concept humanity has come up with: Libraries. Open plan offices can only work if rules are laid down and implemented. Measure the productivity and happiness of your team, implement Library Rules and measure again. You’ll be amazed at the difference.

This post originally appeared in the Technology That Fits newsletter. Don’t miss the next one, sign up.

Last week, I participated in Software Architecture Open Space (SAOS) 2018 in Copenhagen. This is a symposium that brings together senior IT architects for a full day of discussions, and one of our findings was that the metaphor of “architecture” we have adopted from civil engineering no longer serves us.

There are three problems with the idea of IT architecture:

• Foundation focus
• Project thinking
• Illusion of permanence

Firstly, buildings are governed by the laws of nature which leads to foundation focus. We have to start buildings by pouring tons of concrete to create a foundation, and once that is set, the outline of the building is fixed. That carries over to a mentality in IT projects of spending way too much time building “foundation” in the misguided mindset that we can’t change it later. With the need for speed in modern IT, we can build ten small systems on rickety foundations to determine which ones meet the needs of the business. Once we discover what is promising, we can change any aspect of that system to allow it to scale.

The second problem is project thinking. Buildings are built as discrete projects with a start and an end date, and we try to build IT systems the same way. This engenders a starry-eyed focus on some ideal future when everything is “finished.” In the meantime, we build bad stopgap solutions that are only intended to last until we have “finished.” Only we never finish, and our bad temporary solutions become permanent.

The third problem is illusion of permanence. Barring a major natural disaster, buildings keep standing on the ground where they were built They decay very slowly and with minimal maintenance can last for decades or centuries. This leads us to allocate a minimal or non-existing budget for maintenance of IT systems, and to allocate nothing for ongoing refactoring. But our IT systems live in a much more dynamic world than a building. Reorganizations, mergers, divestments, new products, new regulatory demands and a million other factors mean our IT systems do not stand on solid ground.

So if architecture doesn’t work as a metaphor for modern IT development, what is a better idea? We came up with IT gardening. A gardener doesn’t stack flowers on top of bushes on top of trees. That removes the foundation thinking problem. A gardener knows that a garden is an ongoing work that is never finished, which removes project thinking. A gardener will never implement a bad temporary solution while he waits for his ideal vision to materialize. And a gardener has no illusion of permanence. He knows that if he turns his back on his garden, it will start to deviate from his idea and eventually revert to a dark jungle. So he keeps weeding and pruning the garden so it stays close to his idea of what it should look like.

I encourage you to challenge your IT architects to think of themselves as gardeners instead. It might lead them to reconsider some dogma that doesn’t serve you anymore.

This post originally appeared in the Technology That Fits newsletter.
Don’t miss the next one, sign up.

Oracle has an excellent database product, but they have been loosing database market share since 2013. Incidentally, that’s about the same time as they stopped providing updated versions of the free Oracle Express Edition database.

It didn’t seem to worry Oracle, who happily discontinued the reasonably-priced Standard Edition One database and replaced it with SE2, which had half the power and twice the cost. Many independent Oracle enthusiasts (including me) told Oracle this worried us, but our pleas fell on deaf ears.

It is becoming clear that Oracle is still lagging far behind in the cloud and will never catch up. As e.g. Synergy Research Group shows, they are a small niche player and growing slower than the cloud market.

That might have been what prompted them to rediscover the database and finally release a new 18c version of the free Oracle Express Edition (XE) database.

This is seriously good news for anybody who needs a database. The new 18c XE database is much improved over the previous versions and has a lot of the advanced features otherwise only found in the expensive enterprise edition. Of course, it has technical limitations: 2 cores, 2GB RAM, 12 GB user data. But the license agreement makes it clear that you can freely use it in production (except that “You will not use the Program for … development, design, manufacture or production of nuclear, chemical or biological weapons of mass destruction.”

With this powerful product, Oracle developers and DBAs finally have a real contender in the database discussions recently dominated by MySQL and PostgreSQL.

This post originally appeared in the Oracle Tool Watch newsletter. Don’t miss the next one, sign up and get an independent opinion on Oracle development in your inbox every two weeks. You also get a free copy of my whitepaper “What Oracle is Doing Wrong (and Right) in the Cloud“. 

Organizations are busy hoarding data from every source, cheered on by over-enthusiastic articles in the IT press spewing nonsense like “Data is the new oil.” The implication is that you can somehow extract business value from raw data, so the more data you have, the richer you will become. It doesn’t work that way. A few companies like Facebook and Google are data mining businesses, but most are not.

Data does not deliver business value until it has been processed into useful knowledge. The path from data to knowledge is currently long and hard, and the oil analogy is false. Crude oil can easily be turned into useful products by simple distillation, as the Chinese were doing in the first century AD.

Today, data is more like gold ore. A commercially viable gold deposit contains a few grams of gold per tonne, and the process to extract that gold requires heavy machinery, skill and nasty chemicals.

That is because the field of AI is still very immature. By the time a young child has seen four cats, it can recognize cats. But to teach an AI to recognize cats, you need millions of pictures of cats. And image classification is an easy AI challenge, one of the few that has been industrialized to a form where you can buy a cloud service usable by regular people without a PhD in Data Science.

Notice the red box is correctly predicting “cat” with a 96% confidence. Fine. The AI is also stating with 61% confidence that the blue box is a suitcase. Less useful.

At a recent conference, in a session on AI, the presenter asked how many were working with AI? About half the room raised their hands. How many have AI in production, he asked. No one.

Stop hoarding data and throwing terabytes of it to a few self-trained “data scientists” with the instruction to produce disruptive insights that will revolutionize your business. Instead, have someone track the development of industrialized AI cloud services that can be implemented by regular programmers and trained on small data sets. Evaluate this small subset of the AI landscape against your business needs. You might find something useful. But most likely, you won’t. Yet.

This post originally appeared in the Technology That Fits newsletter. Don’t miss the next one, sign up.

At this time of year, the industry press is full of predictions for the coming year. Technologies you can’t afford to miss out on in the coming year are blockchain (again), virtual reality (again), and artificial intelligence (again). You do not need to jump on any of these bandwagons.

Instead, make a useful New Year’s resolution for 2019: Do not add any new technologies to your technology stack.

In first aid, they teach you that the first thing you do at the scene of an accident is to stop the accident. To prevent further injuries, you stop traffic, put out fires, or move people in danger to safer places.

The first thing you need to do in your IT environment is to stop the situation from deteriorating further. Most people I work with are up against the complexity wall. This is the place where the total complexity of their IT landscape has reached a point where nothing can be changed, no matter how much effort you put into it.

Adding a new silver bullet technology that will supposedly cure all your ills is not going to help. It will just deepen the paralysis.

If you decide to forgo hot new technologies (that your developers will be clamoring to use), you can instead start to carve out pieces of your landscape into well-defined Bounded Contexts with clear interfaces to the surrounding world. That will allow you to take a step back from the complexity wall in 2019. If you succeed, you can look at adding new technology in 2020.

I work with organizations to reduce the complexity of their IT landscape – send me an e-mail if want to learn more.

I wish you a happy and productive 2019.

This post originally appeared in the Technology That Fits newsletter.
Don’t miss the next one, sign up.

The preliminary report from the investigation of the crash of a brand-new Boeing 737-8 in Indonesia last year is out, and it seems like a computer error killed 189 people.

The trigger for the accident looks to be a faulty sensor, which told the computer the nose of the aircraft was too high. Pulling the nose of an aircraft up will eventually result in a stall, where the wings stop generating lift. To prevent that, the computer was programmed to push the nose down if it was too high.

Chilling data from the flight data recorder shows the fight between human and computer.

The orange line is the automatic trim, ordered by the computer. Each period below the line shows the computer pushing the nose of the aircraft down. The blue line shows the manual trim, ordered by the pilot. It is clear that after each time the computer trims the nose down, the pilot frantically trims it back up. Until the computer wins. And the plane crashes.

When you build systems – both administrative procedures and IT systems – you need to make sure there is an override. The world is complex and there will always be situations where your system will result in a stupid, costly or even deadly outcome.

On the small planes I fly, we deal with pitch trim runaway by pulling the circuit breaker that provides power to the trim engine. With no power, the trim motor can’t move the control surfaces and the pilot is back in control.

Do you have circuit breakers in place in your systems?

This post originally appeared in the Technology That Fits newsletter. Don’t miss the next one, sign up.

It’s
been more than 40 years since Fred Brooks wrote the timeless IT classic
“The Mythical Man-Month.” In that book, he refers to solid research
documenting that the difference between the worst and the best among a
group of already experienced programmers is 10:1. This concept has been
documented and described again and again, lately called “the 10x programmer.”

It
stands to reason that you would want the team implementing your
important project to include some of these rare people – or at least
some 5x, 3x or 2x programmers.

In
practice, your project is staffed with the cheapest programmers who
match the keywords defined for the position. They don’t even have to
match the necessary skills, just absurdly broad keywords like “Java” or
“SQL.”

Is it any wonder that IT projects continue to fail?

The
impact of a good IT architect or lead developer percolates through the
entire project, dramatically increasing the chance of success.
Similarly, the impact of a mediocre or downright bad architect or lead
developer can run an otherwise competently staffed project into the
ground. I am more capable and expensive than the average IT architect,
but I am rarely even called in for an interview. Instead, the HR
department sends out a request, gets a bunch of CVs and selects the
cheapest person who has written the word “architect.”

If
you were going to the hospital to have a brain tumor removed, you
wouldn’t say “get me the cheapest brain surgeon you can get.” Make sure
you are not staffing your IT projects with the cheapest people you can
get.

If you were going to the hospital to have a brain tumor removed, you wouldn’t say “get me the cheapest brain surgeon you can get.” Make sure you are not staffing your IT projects with the cheapest people you can get.

This post originally appeared in the Technology That Fits newsletter. Don’t miss the next one, sign up.

I was waiting for a friend on the patio outside a restaurant in Manhattan, and the nice people from the New York City Department of Transportation had arranged entertainment for me. You see, right beside me was a puzzle box called a “muni-meter.” It looks like this:

Based on the big white-on-blue “P” on the side, it was obvious that it had something to do with parking. But based on my field studies, it was also obvious that the puzzle was way too hard for the average motorist. During 20 minutes I observed:

• One person fiddling with coins before giving up
• One person fiddling with a card, then trying to download a parking app before giving up
• One couple getting into an argument over how to use the device before both had to give up and they walked away, still arguing
• One person managing to use his credit card, but apparently accidentally bought too much time. He then called the number on the meter and got into an argument with the helpline
• Two people seemed to manage to buy the parking they wanted

That’s a 33% success rate. Now, if your true goal is to maximize fines for illegal parking, that is a success. If your goal is to allow people to park, it is an abysmal failure.

When
you are implementing any device or IT system, do usability testing with
real users. Ideally, you would have User Experience professionals as
part of your team. Failing that, you can still avoid the worst disasters
by having a few volunteers try out your design. Remember that testing with just 5 users will uncover 80% of problems.

Unless your true purpose is to make sure people can’t use the system. 

This post originally appeared in the Technology That Fits newsletter. Don’t miss the next one, sign up.

Last week, I was in Ukraine last week for Devoxx Ukraine 2019. I attended a number of sessions, spoke to a lot of people and gave my popular “Everything That’s Wrong with IT” presentation.

I noticed that while a few people would grudgingly admit they were connecting to an Oracle database, nobody wanted to have anything to do with Oracle software if it could in any way be avoided.

Organizations running Oracle software tend to assume that everybody is. But they aren’t, and they don’t want to. That is going to become a problem as your Oracle Forms programmers, PL/SQL experts and Oracle Service Bus developers retire or move on to other things. There is no next generation learning these tools.

You need to decide which Oracle tools and technologies are strategic to you and formulate a plan.

• For those Oracle technologies that are strategic, you need to figure out how to retain existing talent and train the next generation. It’s not enough to give Joe a raise, ask him to live healthily and hope he doesn’t retire for another few decades.
• For those Oracle technologies that are not strategic, you need to figure out how to replace them with something sufficiently popular that you can get the developer and administration talent you need.

If you want to hear me speak about this topic in more detail, come to the German Oracle user group (DOAG) conference in Nürnberg in a few weeks. I’ll be presenting “Untangling Yourself from Oracle” on Nov 21 at 10 a.m. in room Prag.

If you want to hear me speak about this topic in more detail, come to the German Oracle user group (DOAG) conference in Nürnberg in a few weeks. I’ll be presenting “Untangling Yourself from Oracle” on Nov 21 at 10 a.m. in room Prag.

This post originally appeared in the Oracle Watch newsletter. Don’t miss the next one, sign up.

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!