Working with legacy applications, systems, and portfolios

Elisabeth Greenbaum Kasson asked me recently for advice on working with legacy applications. Check out her piece on it. Here’s the full reply I sent to her in email:

Her topics:
– The steps someone could take to get themselves up to speed on their employer’s legacy software.
– How this knowledge can make them indispensable (I know that term is relative)
– Why this type of expertise is so necessary, especially when it comes to integrating said software with new and/or evolving products.

When it comes to “dealing with legacy,” there aren’t that many good options. We often think of “legacy” as software that must be changed but that we’re afraid to change. If you’re not afraid to change it, you often just think of it as “our software.” Legacy has this connotation of it being risky, scary, or maybe just boring.

If someone wants to go down into the mines of legacy management, the first thing I’d recommend is doing some history work to find out why the legacy system in question was created, what it’s currently used for, and, hopefully, who the current stake-holders/owners are. You’d be surprised – or maybe not! – how often some or all three of those are totally unknown: with unknown stake-holders, I sometimes hear tale stories of IT departments just shutting down systems and waiting to see who calls them.

Understanding the why, what, and who of a legacy system will tell you most of what you need to know when it comes to managing it. Further up the management chain, having a good grasp of and on portfolio management is valuable. Given the why, what, and who, you should be able to prioritize any given “legacy application” relative to another with respect to funding and attention. Is fixing the application that’s used to schedule office party birthday cake orders more important than the application used to re-order plungers for the warehouse bathrooms? You won’t know between cakes or plungers if you don’t do portfolio management.

The other aspect is simply learning the technologies you need – operationally, programming, and sometimes physical management – to keep the thing up and running and to modify it. This might mean learning, for example, about operating systems for mainframes, AS/400, UNIX, older versions of Windows, and sometimes even exotic things like OS/2. There’s dozens of programming languages out there, and you’ll need to learn not only the appropriate “old” language, but how the build, version control, and project management tools around those old stacks function.

For more, I wrote about dealing with legacy in my cloud native journey booklet last year.

Getting collaboration right in Agile & DevOps – Press Pass

I don’t do press passes as much as I did when I was an analyst, but here’s one from a recent email interview for a ProjectsAtWork story:

Q: What’s your favorite tip to improve collaboration when an organization moves to agile and DevOps?

A: I think the core DevOps thing with collaboration is getting people to trust each other. Most corporate cultures are not built on people trusting each other and feeling comfortable: they’re based in competitive, zero sum structures or command and control management at best.

Organizations that are looking to DevOps for help are likely trying to innovate new software and services and so they have to shift to a mode of operating that encourages collaboration and creativity. Realizing that is a critical step: we want to create and run new software, so we need to understand and become a software producing organization.

In contrast, if you operate differently if you’re just driving down costs each quarter and not creating much with IT. We’d counter-argue that if you’re a large organization and you’re not worrying about software then you’ll be creamed by your competition who is becoming a software organization.

If forced to pick one tip to increase collaboration I would say: do it by starting to work. How you do this is to pick a series of small projects and slowly expand the size of the projects. These projects should be low profile, but have direct customer/revenue impact so that they’re real. It’s important for these projects to be actual applications that people use, not just infrastructure and back-end stuff. It will help the team understand the new way of operating and at the same time help build up momentum and success for company wide transformation later down the road.

As a basic tactic, Andrew Shafer has a fun, effective tactic about having each people on the team wrote fantasy press releases about each other to start to build trust.

(See the full piece by Will Kelly over on the site.)

Enterprise DevOps interview with iThome Weekly

A little while back I did an email interview with Ray Wang from iThome Weekly, in Taiwan. It’s a little piece about DevOps getting more and more into the enterprise. To read the Google, robot translation, it looks like I did some things “single-handedly,” where in fact I was one of many hands.

As always, here’s the original email exchange we had:

Q. You mention about software-defined business in your article, can you tell more details about what is software-defined business? Why CEO have to think about the software-defined business? Why DevOps is so important for software defined business?

“Software defined businesses” are companies that are using custom written software to dramatically change and enhance how they run their business. Uber is a good example. Instead of just being a taxi or car service, they use software they wrote to change how their business runs: calling and paying for a taxi on your sell phone is much different than hailing a cab and paying in cash. Insurance and banking companies that are moving more and more of their daily business and interaction with customers to run over mobile apps and other custom written applications are another good example; we see this happening at Pivotal customers lie Allstate, Humana, and banks that use Pivotal Cloud Foundry.

Q: What’s your definition of DevOps? Does DevOps equal to Continuous Delivery?
Which definition of DevOps you don’t like most and why?

In general, I think of DevOps as the process and “culture” you wrap around continuous delivery to get the full effect of CD. I tend to speak about them interchangeably at this point; I suppose you don’t need DevOps to get the full benefits of continuous delivery, but they seem to go together well (you could always have just a jelly or just a peanut butter sandwich, but they seem to show up together a lot). CD is always looking to automate as much as possible, delivery to production frequently, and use the feedback loop this rapid cycle gives you (you an observe what your users does each week or day instead of each six months) which are many of the things DevOps seeks to enable as well.

It’s easy to get caught up in DevOps conversations that spend all of them time talking about “culture” and the need to change. I’m interested in that, but I always want to hear about actual, tactical things companies can do to get the benefits of DevOps. We all know how businesses use IT needs to change to be better, and that it’s hard to do so. I want to make sure the overall community is giving advice that’s helpful and, dare I say it, “actionable.”

Q: Should companies have to implement agile development before implement DevOps? Why?

It certainly helps to know what agile development is as a school of thought and to have done some form of agile to trust that way of thinking. If you’ve never done agile before, it just becomes part of trying to do DevOps. It’s certainly hard to think of being successful at DevOps without also doing agile software development.

Q: If CIO want to tell his CEO boss about what’s the value for non-technology companies , what’s your suggestion?

Time to market is the main, measurable, benefit. What that means, to me, is that software is being given to customers more frequently. New features and fixes come out weekly instead of once every 6 to 12 months. The business (the CEO) has to figure out what to do with time to market. If you can put a new features in production each week, how will that help the business? In the consumer space (where much of this mentality comes from) you can add more and more features to out-compete competitors. In the business space, the actual business has to change and evolve at a fast pace to fully take advantage of time to market. All that said, I don’t think any CEO is satisfied with the pace of change in IT. They’d all like it to move not just “faster,” but to get more meaningful features in production more often. Humana provides an interesting example: because they had been honing their software delivery process they were able to launch an Apple Watch app in just five weeks. That timeline is pretty amazing for most enterprise IT projects, let along being in the App Store on the first day of the Apple Watch’s release.

Q: Gartner say 2016 will be the year of DevOps. Do you agree with that? why or why not?

Sure, but I think you’ll see the next 3 or so years be the year of DevOps. I don’t think there’s any one year in particular that will stand out. I don’t think there was “a year of Agile Software Development” in the 2000s, it just took over slowly. What important is for companies to understand what DevOps can help give them – faster time to market for their software-driven products and services – and figure out what they’d do with that new ability. “Doing DevOps” is not easy, so you really need to value the end result or you’ll likely loose interest in the transformation process and let it unhelpfully fizzle out.

And, check out the recording of the DevOpsDays Austin talk referenced in the article if you’re interested.

Embedding OpenStack in Solaris – Press Pass

Oracle announced that it’s putting OpenStack into Solaris, which is good fun. James Niccolai asked for my thoughts on the topic for his story. I hadn’t been briefed, so it was just speculation, but here’s the full text of what I sent over:

Solaris was always – and no doubt still is – technically advanced. For example, the zfs filesystem, dtrace, and zones were always tasty looking for Linux folks. At the end of the day, Solaris is a rock-solid UNIX system that got run over by Linux becoming equally rock solid: but Solaris is still what it’s always been, a solid operating system. Layering OpenStack over Solaris is a good step for Oracle who’s always been dodgy all the way up to Larry on cloud. I’m eager to see how the OpenStack community reacts to this – it’ll be all over the map (the first salvo will be to question Oracle’s genuineness, followed by “yeah, but how much will be open source?”), Oracle having a mixed reputation in the open source world, unfortunately. To pick one technology of interest: Docker is of course a darling of the cloud world for the last 6-7 months. Docker is built on Linux containers, which are painfully similar to Solaris zones. And since Docker is OpenStack…you can start to imagine that you’d be able to do Docker/container magic with Linux containers and/or Solaris zones. Then there’s zfs which has all sorts of file system magic: seeing how that gets applied to the OpenStack world will be interesting.

Finally, Oracle’s database and ERP portfolio is widely used in IT departments now. If Oracle gets to the point where you can run its database and ERP apps on OpenStack (even if it’s Oracle “proprietary” version vs. the Red Herring of “OpenStack mainline”) then that’s a big deal for the OpenStack world.

Here’s James full story.

Embedding OpenStack in Solaris – Press Pass

VMware and Citrix team-up with Google Chromebooks to run Windows apps – Press Pass

I spoke with a couple of reporters earlier this week on the partnerships between Google and VMware and Google and Citrix around supporting Windows XP on Chromebooks. VMware has $200 off Chromebook discount for business buyers, and Citrix has a discount as well. Both are deep into vying with each other around the Desktop-as-a-Service market and interested in dominating that market which is looking to be driven by a pretty simple need: providing a way to use Windows applications on non-Windows devices.

The role of Chromebooks in all of this is interesting: perhaps it’s the cheapest “non-Windows end-user device.” It hasn’t seen massive market-share, but has been growing quickly to something like 2-5%, to throw out a wild-guess driven broad range. (ABI and NPD have some recent Chromebook marketshare estimates as well.)

Amazon launched a DaaS offering recently as well, which I covered in a 451 report; VMware released their DaaS just a tad before Amazon; Citrix, of course, sells a DaaS platform to others who want to run it, and of course has its current virtual desktop empire.

Back to the press part! Both Kevin McLaughlin of CRN (his story) and Dan Kobialka of Talkin’ Cloud (his story) asked for my take on the VMware/Google partnership, and then on Citrix’s involvement. Here’s the amalgamation of my responses to them:

Last I saw somewhere in Twitter there’s something like a quarter of the market still running XP which is certainly significant. I’m not really sure how many customers would take advantage of switching over to DaaS: the time and expense to do so might be the same as just upgrading to Windows 7 depending on how grueling the process was.

When I look at VMware and Citrix (just announced) working with Chromebooks the impact is mostly about adding legitimacy to Chromebooks as a viable business tool. VMware’s partnership means that there’s one way to keep using Windows applications on Chromebooks, through Horizon via the Blast protocol. Citrix announced a similar partnership today as well. Both have a constellation of service provider partners who do Desktop-as-a-Service (VMware has it’s own DaaS as well), or enterprises could just use their own on-premise virtual desktop setups, which both vendors support as well.

I’m not sure how many Windows applications are out there, but there’s likely an uncountable amount ranging from older packaged software to custom written applications used inside the confines of corporate firewalls. Rewriting all of these applications to be pure HTML or native iOS and Android is sort of ludicrous at this point, so as things like BYOD and the spread of iOS and Android devices in the enterprise plays out, companies will need some way of accessing these Windows apps. Android and iOS have had the kind of virtual desktop support needed for awhile, and the Chromebook work that VMware and Citrix are doing here is making it so that Chromebooks can fit, technologically at least, into that corporate mix as well.

VMware and Citrix team-up with Google Chromebooks to run Windows apps – Press Pass

Infor ERP moving products to AWS – Press Pass

A few weeks ago, I talked with Chris Kanaracus for his story on Infor moving parts of their application portfolio to Amazon Web Services. Chris said this looked like a pretty strong endorsement for using AWS, and asked for my thoughts, which were:

Yes, this a nice vote a confidence for AWS. However, I think most SaaS companies would look at AWS as capable of being used like this. There might be questions about pricing long-term, but technologically it’s just a stack of middleware running on a bunch of servers. The larger bet by Infor is around that: do they want to align their application to Amazon’s services and cloud-based middleware? (Maybe they’re not and just using raw EC2, S3, etc…but you’d assume they’d want to use things like Red Shift and other services/middleware offered by Amazon).

What with the pricing war that Google is announcing right now (reducing cloud prices by 32% across the board for it’s Google Cloud offering, and deeper for some other services), Infor has to be thinking that the costs will be cheap. The longer-term hope is that their agility – measured by how fast they can code and releases features to their existing products, as well as modify how current features work – will increase as well. We all know in our guts that after 4-5 years, software is incredibly hard to change due to the code getting stale, supporting middleware being antiquated, and the difficulty of shifting around the underlying infrastructure. I’m not sure “cloud” will solve those problem, but hopefully it’ll make it a bit better.

(Enterprises tend to be more leery of relying on cloud and are feeding the current interest in “private cloud”, along with vendors who’d love to preserve that market. Enterprise FUD around public cloud is mostly because their needs are much different than ISVs/SaaSes: enterprises have 100’s, if not 1,000’s of applications behind their firewall that must be supported that may be technologically, culturally, or otherwise incompatible due to drivers like policies and regulations.)

Infor ERP moving products to AWS – Press Pass

Press Pass: PaaS in 2014 (Pun!)

Paul Krill asked a few questions about the future of PaaS last month for an omnibus appdev article of his (it’s a nice round up!). Here’s the only slightly edited full reply I sent him:

Q: Does 451 Group see 2013 as a banner year for PaaS? If so, why?

PaaS has always had the issue of being “big next year.” The nature of PaaS has shifted around so many times that it’s little wonder it’s yet to achieve escape velocity. To my mind, PaaS has come to mean “integrated middle-ware and services developers use to run cloud applications,” and in that sense I think PaaS will have an interesting year in 2014. The tools and practices behind DevOps are reaching mainstream, and the fast rise of things like Docker and mainstream hocking of Cloud Foundry are all encouraging. I still think PaaS needs to evolve to something close to that looser middle-ware-as-a-service definition than the clearly defined and contained platforms we’ve seen in years past. One thing is for sure: developers are going to keep writing application destined to live on the cloud to support web and mobile apps. It’s unclear if they’ll chose classic ideas of PaaSes (Heroku, etc.) over assembling their own middle-ware stacks with the help of things like Chef, Puppet, and Docker.

Everything I hear from the buy side of the market indicates that they’re hungry for better ways of developing and delivering cloud applications (whether to support classic web apps, mobile, or analytics applications). To me, this means a big uptick in spending in the middle-ware and developer categories, or the PaaS part of the cloud market. Companies like Pivotal Labs are premised on this opportunity, and numerous other vendors seem convinced as well.

Q: From Forbes: “Platform-as-a-Service (PaaS) will attain a 41% CAGR through 2016, generating 24% of total cloud revenues. 71% of PaaS revenues will be generated by vendors over $75M in sales according to the study.” Does 451 still stand by these numbers?

As Greg Zwackman put it in Paul’s article:

Analysts at 451 Research also see improved prospects for PaaS. “For 2013, we are projecting well over 50 percent growth over 2012,” says 451 analyst Greg Zwakman. The research firm expects PaaS usage to grow 41 percent each year through 2016, to account for 24 percent of total cloud revenues.

My reply: I believe this segment of the market will grow fast and be a large part of spend. It’s clear that deploying custom written software is a large part of what cloud is used for, and developers are always looking for better mouse-traps. Also, included in these numbers if I’m right, are ALM (Application Life-cycle Management) and supporting services and tools. From what I can tell, developers are eager to move to cloud-hosted versions of these tools, and vendors like IBM are starting to respond as well.

Q: How does 451 define PaaS?

Here’s the official definition: “A PaaS is a cloud-enabled development platform designed to let developers interact with code and create running applications, without maintaining or operating the runtime.”

And the longer definition:

“PaaS is defined as a remotely hosted framework that supports the building, deployment and ongoing management of applications throughout their life-cycle (development, testing, deployment, runtime, hosting and delivery). PaaS provides the computing environment on top of the infrastructure where multiple applications share a single plat- form for development and deployment. It also provides all the tools necessary to build and deploy applications and services via a Web browser, and offers user-friendly functionality streamlining workflow collaboration and speeding up production and time to market. Included in this category are vendors that provide the entire stack of PaaS functionality and partner with third parties (i.e., hosters) for the infrastructure component, as well as those vendors that provide the infrastructure themselves. Cloud computing components of the PaaS marketplace we track include: PaaS From SaaS, Stand-Alone PaaS and Application Life-cycle Management as a Service (ALMaaS). Within the ALMaaS space, we categorize vendors in two sub-sectors: Pre-Production & Testing and Integration as a Service.”

Q: What’s next for PaaS in 2014?

This year the PaaS market needs to decide if the Cloud Foundry approach (a very loose, buffet of services that interlock together, reminiscent of J2EE vs. the more clearly defined approach you’d get on AppExchange or even Heroku) is the winner. Also, how something like Docker fits in, and by extension the idea of using Chef, Puppet, AnsibleWorks, and Salt instead of a PaaS are important. Put another way: do developers want to build their own stacks and control the configurations of them, or do they want to deploy into a more clearly defined “app server,” to use a Java analogy.

Press Pass: PaaS in 2014 (Pun!)

Press Pass: GitHub Traffic Analytics Comments

Paul Krill asked for some quick input on GitHub’s newly released analytics. Here’s what I sent over for his story:

As the blog post says, it does look like fun, though pretty minor in the grand scheme of things. GitHub has been a major driver of getting the development community to care more about social interactions and collaborations, here, tracking who’s looking at your code and where they’re coming from – standard web analytics stuff. Before GitHub, most of the community around code was pretty faceless: it was just forum posts, really passive users and lurkers around the code. With things like this, and GitHub as a whole, developers can get a better sense for who’s interested in their work. Developers have been learning to use this kind of meta-data in their applications to do A/B testing (is this feature better implemented one way or the other) and it’s interesting to think that they’d do some meta-data navel-gazing on their own code.

Another class of user – marketers – would find this extremely valuable. I like to throw out the idea of “code as marketing” to illustrate the idea that code can be a good source for driving a vendor’s marketing needs. As an example, you can see Rackspace putting out command line tools and other developer SDK-ish things to market to developers. More than just “tools” to use on Rackspace’s cloud, this code is a marketing artifact. Since code is, essentially, the major currency of developers, if you want to do more marketing to them, you need to spray more code their way, hopefully that’s useful. In that instance, marketers will want to intimately track who looks at what on sites like GitHub, and this will give them an even more complete picture.

Press Pass: GitHub Traffic Analytics Comments

The plight of the DBA – Press Pass

What’s a DBA to do in a cloud world where platform as a service and PaaS-like automation seemingly removes much of the need to constantly car for pet databases? Well, there’s still troves of existing databases left and, really, things aren’t that perfect in cloud-land. I spoke with Klint Finley on this topic last week for his story on Heroku. He asked, “are the days of the DBA numbered? to which I responded:

I don’t think the DBAs days are numbered just yet. Last I checked, the US bureau of labor statistics is actually predicting an increase, if that’s anything. DBAs definitely need to learn new technologies and be less gruff about helping developers out.

Consistently, I see developers driving the use of cloud across the market (ask any vendor what their cloud stuff is use for and it typically amounts to delivering custom written applications: developers) which means DBAs need to start talking with developers more. The other important thing to realize is how much "traditional” IT exists out there now. I can’t figure out how to calculate it (yet) but I feel like we’re just scratching the surface of The Great Cloud Rewrite over the next 10 years in the enterprise space. That’s were DBAs have a strong hold and if they get cloud religion soon enough, they can set themselves up nicely.

DBAs actually have a wealth of knowledge and it’d be painful for developers to have to rediscover and learn all of that. That said, if all DBAs do is say “no, and it’s going to take 6 weeks,” they’ll be dead.

The plight of the DBA – Press Pass

PaaSes in the OpenStack world – Press Pass

The past month has seen all sorts of hijinks on PaaS from whatever Solum is to Mirantis chest-beating, to Canonical buddying up to CloudFoundary. On that last note, I spoke in email with Jim Mortleman
who asked, essentially, what’s the significance of this?

Here’s what I replied back, in full:

Most cloud deploys I’ve encountered are ultimately used to support application development and delivery, so naturally, the community would look towards adding PaaS on-top. While there’s yearly, glowing hope about the sparkling city on the hill that is PaaS, few of the PaaSes available over the years have caught on like wile fire. CloudFoundry, at least, has been intellectually open enough to seem passable for broad developers who want lots of customizations to their dev stack, and the ongoing, though small, momentum of companies like ActiveState that build on-top of CloudFoundary is a good sign that company has been working on PaaS and CloudFoundary on-top of OpenStack for awhile now ).

In the OpenStack world, (like Rackspace’s private cloud GM, Jim Curry)I’d expect to see a lot of different integrations with PaaSes. Indeed, Havana ads Docker support which is another run at solving the problems PaaS does (making it easier for developers to package up and then run applications in production) without being called PaaS. Then there’s whatever Solum will evolve into. Slotting CloudFoundry on-top as well will be good for the overall OpenStack community which seems to value bespoke maximal choice, leaving prêt-à-porter to commercial vendors.

Canonical is a strong leader here, though it’s way too early to tell who’ll “win” the OpenStack distro competition (between RedHat, SUSE, Canonical, Mirantis, and others like HP, Nebula, Cloudscaling, Piston, etc. who’re doing embrace and extend around OpenStack). Based on the Linux distro shakeout of the late 90’s and 2000’s, if history repeated itself there’ll essentially be two winners that the entire IT world will rely on, with some regional anomalies (Japan always seems to make its own choices, and often Germany). Many are placing their mental money on RedHat; if they can get their pricing right and speed it up (the flurry of releases during this OpenStack Summit is encouraging) RedHat would be well positioned, leaving slot number two open. Canonical has ubiquity with ubuntu and that panache that trickles down from Shuttleworth, while SUSE seems like the slow and steady wins the race type. And who knows what interlopers like Mirantis and others will do: there’s no way to start picking horses in this race until all the horses grow up and actually get to the track.

This would make a good “spotlight” for 451, so I’m curious to hear more from you, dear readers, to flesh it out into a larger piece.

PaaSes in the OpenStack world – Press Pass