Content Copyright © 2017 Bloor. All Rights Reserved.
This blog was originally posted under: The Norfolk Punt
My impressions of the privatised BMC from BMC Exchange 2016 at Twickenham are still favourable. Paul Appleby (EVP Worldwide Sales and Marketing) gave us an upbeat keynote “Fast Track to the Digital Enterprise” that still seemed to tell an exciting story, if not much different, at a high level, to the stories being told by its competition these days. There were some interesting details, however.
The mainframe is clearly still important to BMC; and it is important that it becomes a first-class player in the emerging https://www.bloorresearch.com/trends/ – that is, the Enterprise in a constant state of reinvention and evolution in response to its changing environment – not an unwelcome parasite, something bolted onto the outside. There are still a lot of workloads, in large enterprises, that work best (and most cost-effectively) running on the mainframe. The secret of the mainframe is high utilisation – unlike the usual PC, a mainframe works best and is most cost-effective at about 100% utilisation.
What this means is, that if you must have a mainframe, then move as much work onto it as possible, it’ll cope. These days it is unlikely that you’ll be running work that isn’t important on the Mainframe (unimportant stuff started to get moved off Mainframes when the Y2k crisis was addressed) – but don’t overlook modern mainframe capabilities such as bladeservers for distributed processing; specialised Linux virtual machines and hardware encryption services for emerging workloads; it doesn’t have to be just for “big iron” CIX processing.
Using a mainframe to the maximum implies, to me, that you can abstract the mainframe, with tools that operate across the whole of your environment. If you can generalise the skills needed to manage and operate a mainframe, then you don’t necessarily need as much specialist mainframe support (there are capabilities unique to the mainframe that staff will have to know about, of course, but, in a lot of ways, it is just a big, very resilient, server).
Integrating the mainframe into the general environment fits well with BMC’s strategic visions around the mainframe and DevOps and machine learning. Robin Purohit’s ITSM blog doesn’t mention mainframes specifically, but the ITSM vision he describes must apply in the world of the mainframe, just as it does elsewhere. BMC is not saying that you can operate your mainframe without specialist mainframe staff (although I’d see that as a worthwhile aspiration at some point) but it does say, “we are making mainframes easier to manage and operate, with advanced automation and easier-to-use management software that supports DevOps and agile development, and which won’t look foreign to a millennial”.
As I’ve said before, back in June, there are several views of DevOps, once you get beyond “breaking down silos with fast software delivery pipelines”. Both the traditional developer role (“Dev”); and the operations role (“Ops”) that traditionally got the software into use by the business and delivering its potential benefits; are still important, of course, but these roles can be automated. To hear many DevOps enthusiasts talk, it looks like Dev taking over Ops, writing code to perform the Ops role; but it could equally reasonably be seen as Ops taking over Dev, as (increasingly) business applications can be orchestrated out of pre-written components and prebuilt services (including “wrappered” legacy), which is more-or-less traditional Ops workload scheduling, with the addition of automated testing. Is BMC part of an “ops takes over Dev” story? I think so, in the medium/long term, anyway.
In fact, neither side will disappear, but I see the importance of Dev decreasing, as writing new software from scratch becomes the last resort for the business, only if it can’t find an effective pre-written service. In light of this, I found BMC’s intention to use open APIs, and its Innovation Suite (which will eventually replace BMC Developer Studio) to turn its specialist tool platform, BMC Remedy, into a general low-code development platform, although it has always had some of this capability. Well, perhaps it won’t be pure “low code” – it’s more of a hybrid, with 3GL code for heavy lifting, I think (similar to the approach taken by Salesforce with Force.com, Heruko and Apex, with only Force being really low-code). It is probably relevant that Paul Appleby has Salesforce.com in his background.
What BMC is doing has similarities with what ServiceNow (which even features in Forrester’s “Vendor Landscape: The Fractured, Fertile Terrain Of Low-Code Application Platforms” report) is trying to do, more than with what Salesforce did, simply because BMC’s platform is built on top of IT service management (ITSM) rather than on top of Salesforce’s customer-facing CRM product. Applications such as employee on-boarding seem an appropriate target for BMC developers, and will give them a development role that is visible to the business. I suppose that BMC has two cultures to convince with this innovation: its traditionally rather conservative Ops and ITSM user-base; and new business users (including “citizen” developers), who’ll need to see orchestrating services and APIs (with quite a lot of technical help) as relevant to the business and “sexier” than writing code. I was pleased to see that BMC is taking an interest in Open Source and wants to work with “disruptive startups”, which bodes well for its relations with the second group.
For what it’s worth, my bet is that the “https://www.bloorresearch.com/trends/” will come down on the side of low-code services orchestration – whether BMC can take full advantage of that remains to be seen, but I like that it is making the attempt. The barrier, as usual, is likely to be the imagination of BMC’s customers, rather than the capabilities of its technology.
I also like that BMC was talking about “the Interface adapts to a person, not a person to the interface”. This, I think, means that if the BMC infrastructure contains information that could be useful to the business, it should be accessible without the business needing to take a course in ITSM.
BMC also seems to be taking machine learning and cognitive computing seriously, which is good – partly because I think that humans won’t be able to cope with the complexity (and possibility of emergent behaviour) in the very large next-generation, loosely-coupled, asynchronous infrastructures/systems, without help. For the foreseeable future, of course, the AI will be dealing with the mundane and leaving people to deal with the hard stuff – but, how far out is the “foreseeable” future? So, BMC seems committed to taking AI seriously and using it to exploit the investments its customers have made in “big data” and the network; to enabling “idea collisions” (serendipitous results from bringing creative minds together); to the reinvention of interfaces as open APIs – and to working with disruptive startups (perhaps using its Innovation Suite). It is now, it claims, focussing on business outcomes, not on ITSM as an end in itself.
Finally, BMC does have an interesting take on “bimodal IT” as espoused by Gartner. Mode 1 encompasses areas of the enterprise that have certainty, clear objectives and well-understood cause-and-effect (in particular, regulated or business critical systems, perhaps) – and these systems sometimes, but not exclusively, of course, run on mainframes). Mode 2 has unclear and changing requirements and things are less well understood at the start (perhaps the world of business apps). Often, and according to Gartner, this is wrong, Mode 1 is seen as “business as usual” and Mode 2 as entirely separate (there is even a myth that everything will move to Mode 2). BMC doesn’t seem to disagree with any of this overall but doesn’t agree with the degree of separation Gartner seems happy with. True, some things can be allowed to change quickly; others probably can’t. But, BMC thinks, the two models can’t be decoupled; they must be loosely, but fairly strongly, coupled; and perhaps, I think, AI has a place in this coupling.