SoylentNews is people
SoylentNews
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”.
(Score: 4, Insightful) by physicsmajor on Saturday August 06 2016, @11:56PM
I'm involved with the scientific Python community, which is an excellent example of where this kind of development is needed. There are core projects which provide important math/science routines that move slowly, then as you move farther away from those you get to the cutting edge where development is fast and furious. This works fantastic for science, though it's worth noting that having actual separate projects for all of this is probably why it works. That plus true package managers like Conda/Canopy to handle inter-dependencies.
The core - NumPy, SciPy, Pandas, Jupyter, Nose, and Sympy - moves slowly with extreme emphasis on stability. It wasn't always that way; NumPy itself is only a little over a decade old. Early on development was fast and looser than it is now. However, today these projects are depended on so heavily by the rest of the ecosystem that they've become very much Mode 1.
The edges though? That's active research territory. The scikits have an intermediate development velocity, and beyond that projects are very agile in nature.
(Score: 0) by Anonymous Coward on Sunday August 07 2016, @03:14AM
Works fine for research. Doesn't work at all for business.
For one thing, this is paying to develop the same thing twice, which is usually frowned upon in a place where profits are valued. For another, when something works "well enough" in a business environment, it's generally delivered. Sure time could be spent fixing up that which they've already finished, making it better or more robust or trimming out that rare bug, but that time could instead be used to produce 2.0. Businesses prefer to work on new profitable things rather than perfecting what they've already delivered.
In business practice, the 'slow but sure' stream is quickly left behind unless it's the sole focus.