Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Saturday August 06 2016, @11:24PM   Printer-friendly
from the tread-carefully dept.

Arthur T Knackerbracket has found the following story:

Gartner defines Bimodal IT as: “the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed”.

I find myself more than a little bemused by the concept. First of all, why would I want to manage two separate modes of activity? That means that either I have to employ different people with specialisms in different approaches (expensive) or I have to take on people who are skilled in both areas (which by definition means they're not going to be best-of-breed in either).

Second, I have a strange liking for the concepts that Gartner mentions in Mode 1: safety and accuracy. I find it useful that my IT systems don't kill people; here in Jersey, for example, it's frowned upon if too many employees die in tragic business systems accidents. And in my experience, the CFO tends to be quite irritable if the month-end numbers don't add up. I also find security and integrity fairly useful too, along with availability – all things that can suffer in Gartner's so-called Mode 2 at the expense of agility and speed.

Although the term “bimodal IT” is relatively new, the concept isn't. Back in the 1990s I worked in an environment with two distinct approaches to IT: one slow, steady and methodical, and the other fast-moving and bleeding edge. Did the latter break more than the former? No, actually it didn't – but only because it was done by a small number of very technical people who could respond quickly to issues. Did it bring advantages? Yes: it was doing IP-based wide area stuff long before the other part of the IT world.

Would I go back to that setup tomorrow? Not on your nelly – it put a group of techies out on a limb, largely unsupportable by the other team and hence permanently lumbered with supporting bleeding-edge technology whenever it threw a tantrum and interfacing it tenuously into the core systems in the face of reluctant sighs from the core support group.

I had another of these “parallel” examples more recently, when a new senior techie decided that he would spin up cloud-based servers seemingly at random alongside the company's well-managed, well-documented and extremely stable infrastructure. He took exception, for some reason, when someone called him a “f**king cowboy”.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by khallow on Sunday August 07 2016, @03:00PM

    by khallow (3766) Subscriber Badge on Sunday August 07 2016, @03:00PM (#384977) Journal

    And I said: "Testing is a part of development, as is coding, software arch/design and all the rest. Why do you think testing is worth a special mention, when all the others contribute equally to the safety?"

    I think testing warrants special mention unlike the other parts you mention because it was an important example of flexibility and "agility". For the most part, tests are lightweight. They're meant to be low effort to construct (otherwise you're not going to make many of them), rapid to deploy and modify. If a new issue shows up, you don't want the tests coming out a few years later.