There are two approaches to security:
- Trust, but verify
The first places hard restrictions on what users can do. Advising development teams, I very often find that development workstations are locked down so tight that a developer can’t install a needed utility without logging a service request. The enforcement strategy always comes with a cost in lost productivity, but nobody bothers to count this cost.
The second places few restrictions on what users can do, but has a rock-solid audit function and people to actually monitor this. This approach doesn’t suffer the loss of productivity that enforcement does, but it does require you to generally trust your users to do the right thing. The problem with the trust & verify strategy occurs when organizations do not truly monitor what users do. This can allow malfeasance to go on for too long.
Make a decision which way you want to go. If you go with enforcement, make sure to calculate the cost. If you go with trust & verify, make sure you truly implement the “verify” part.
What does an e-mail weigh? Nothing, you say, it’s just bits in a computer somewhere.
Wrong. Each e-mail you allow to pile up in your inbox is weighing you down. It’s another item on your to-do list, in addition to all the other to-do lists you have lying around on post-it notes and in half-heartedly maintained task management systems.
Every e-mail in your inbox is an open loop and a load on your brain. You need to establish a procedure for getting your inbox to zero every day. You don’t have to do everything, but you need to have processed everything and have placed it into a system where you are sure nothing gets lost.
Personally, I’m using SaneBox to help me keep my inbox empty, but any procedure or tool is good. Free your mind, empty your inbox.
I’ve noticed that too many meetings drag on and on because people don’t know when to shut up. They answer an question and then drone one with more or less relevant supplementary information.
Vendors wanting to sell their products are especially prone to this. The prospective customer asks a question like “does the product do X?”
Please consider: Sometimes, the only answer you need to make is “Yes.”
As part of a tool selection project, I’ve recently sat through several vendor presentations. In some of them, the vendor showed up with several people to present several different parts of the software suite.
It was amazing to see how the account manager would be checking his phone, completely oblivious to the presentation his experts were giving. Similarly, one expert was obviously not listening to his colleague’s presentation, leading him to repeat information we’d already been given.
If you want to sell your software, is it too much to ask that you can focus on your customer for a couple of hours?
I increasingly come across Scaled Agile Framework, which is normally given the reassuring acronym SAFe. This is an attempt at fitting Agile methodologies into an enterprise setting, and has been met with withering criticism from some sides.
Let’s face it: Agile does not scale. It’s a team methodology that works great on projects that can be divided into team-sized chunks, but agile is being touted as the solution to every people and process problem in IT. It isn’t.
There is a reason why IT developed enterprise architecture. It’s the same reason why armies develop regulations and nation states develop bureaucracies. The reason is that ad-hoc “let’s talk about it” methods do not work when enough people get involved. By all means be flexible and agile in small teams. But don’t run your business that way.
I now know the admin password to the cash registers at my local grocery.
It’s not because I have installed network sniffers on their network, or have been installing secret cameras. No, the friendly staff freely shared the admin password with me and about twenty other people.
They weren’t planning to do this, and in the situation they probably didn’t even notice that they did it. It was a holiday, and the shop was full because many other shops were closed. And all three cash registers were down, causing an ever-growing line of impatient customers.
That’s when a staff member shouted across the shop to another: “I need to reboot. What’s the admin password?” And got the password shouted back.
Have you drilled everyone in your organization well enough that they remember proper security procedure, even when under pressure?
When I was a young programmer, we had something called testing. We really needed that, because the cost of releasing a new version was high, sometimes involving someone manually going around to individual workstations to perform setup that could not be centralized and automated.
It seems this discipline is forgotten in today’s App Stores where you can just release another update if the last one was buggy.
Case in point: The DayOne app. I’m using this for my daily journaling, and it’s a nice app. Except when they release a version that has only been tested against the latest iOS version and they flippantly admit that if you are running something earlier than 8.2, the application will crash.
Testing is a software engineering discipline and no professional tester would have released something that had not been tested against older operating system versions. If you want your IT department to be take seriously by the business, don’t roll out untested software.
On a project planning board on a wall, I recently saw this task:
That is something that is easy to say in a meeting, but this is not a task. It is an amorphous blob of worry that nobody is going to do anything about, but everybody will feel bad about.
A real task is something that someone can actually do. If you really need to check all the interfaces, the first task in the “interface checking” sub-project is to write a list of all interfaces. That is a task you can assign to someone.
There are 10 types of people in the world – those who understand binary numbers and those who don’t.
The group who understands binary numbers can be sub-divided into two groups:
- Those facing the challenges of running real-time analytics against terabyte databases while handling millions of transactions per second
- Those who don’t
The people in the first category get lot of attention from Oracle Sales and Support, and don’t need much community support from user groups etc.
However, most of us fall in the second category. We are faced with more mundane tasks and don’t have a business case for buying expensive top-of-the-line hardware. However, we can benefit from smaller engineered systems like the Oracle Database Appliance. Because these systems are cheaper, we get less attention from Oracle and depend more on community support.
It can be hard for a small user group on its own to deliver the detailed information their members need about products like Oracle Database Appliance. But if Oracle could make demo systems available online that user groups could book time on, we could leverage the power of the user groups for the benefit of the entire Oracle community.
Last year, a total of 720,000 Android-powered wearables were sold. Last Friday, Apple sold 957,000 Apple Watches on the back of their very strong fan base. It is OK for people with disposable income to spend $349 or even $599 for an Apple Watch that will be obsolete in 18 months. But most people should not consider paying $17,000 for a gold-plated one.
We’re seeing strong consumerization in IT where it is now consumer products that drive much of the innovation. We’re unfortunately also seeing consumerization of purchasing, too. This is where organizations buy cloud services on the basis of emotional appeal, disregarding proper vendor evaluation, ending up with expensive and obsolete technology.
Everybody can see that buying a $17,000 gold-plated Apple Watch is a questionable purchasing decision. Make sure your organization is not making equivalent IT purchases.