DevOps – A Valentine’s Day Fairy Tale


Title: DevOps – A Valentine’s Day Fairy Tale

This post is a guest blog post authored by Matt Watson, CEO of Stackify

Once upon a time two people from different sides of the tracks met and fell in love. Never before had the two people found another person who so perfectly complemented them. Society tried to keep them apart – “It’s just not how things are done,” they’d say. But times were changing, and this sort of pairing was becoming more socially acceptable.

They met at the perfect time.

Ops had grown tired of the day to day grind of solving other people’s problems. Enough was enough and she needed a change in her life. A perfectionist and taskmaster to the highest degree, she tended to be very controlling and possessive in relationships. It became more about commands than conversation, making life miserable for both parties. She began to realize she hated change, and felt like she spent most of her time saying “No.” It was time to open up and begin to share to make a relationship work.

Dev, on the other hand, was beginning to mature (a little late in the game, as guys seem to) and trying to find some direction. He had grown tired of communication breakdowns in relationships – angry phone calls in the middle of the night, playing the blame game, and his inability to meet halfway on anything. He began to realize most of those angry phone calls came as a result of making impulsive decisions without considering how they would impact others. His bad decisions commonly led to performance problems and created a mess for his partners. Dev wanted to more actively seek out everything that makes a healthy relationship work.

The timing was right for a match made in heaven. Dev and Ops openly working and living side by side to make sure both contributed equally to making their relationship work. Ops realized she didn’t have to be so controlling if she and Dev could build trust between one another. Dev realized that he caused fewer fights if he involved Ops in decisions about the future, since those decisions impacted both of them. It was a growing process that caused a lot of rapid and sudden change. Although, like most relationships, they knew it was important to not move too fast, no matter how good it felt.

Dev and Ops dated for about four years before they decided to get married. Now they will be living together and sharing so much more; will their relationship last? How will it need to change to support the additional closeness? But they aren’t worried, they know it is true love and will do whatever it takes to make it work. Relationships are always hard, and they know they can solve most of their problems with a reboot, hotfix, or patch cable.

Will you accept their forbidden love?
7 Reasons the DevOps Relationship is Built to Last

  • Faster development and deployment cycles (but don’t move too fast!)
  • Stronger and more flexible automation with deployment task repeatability
  • Lowers the risk and stress of a product deployment by making development more iterative, so small changes are made all the time instead of large changes every so often
  • Improves interaction and communication between the two parties to keep both sides in the loop and active
  • Aids in standardizing all development environments
  • DevOps dramatically simplifies application support because everyone has a better view of the big picture.
  • Improves application testing and troubleshooting



   About the author: Matt Watson is the Founder & CEO of Stackify. He has a lot of experience managing high growth and complex technology projects. He is on a mission to simplify the daily lives of developers and how they support their production applications by leveraging DevOps.

Does It Make Sense to Excise Risk Management from Software Development Methods?

This is a second annotation of an article, Send in the Tech Reinforcements authored by Arthur Herman and John Scott. We’re focusing here on the authors’ point that “the Pentagon relies on a bureaucratic review process that demands contractors anticipate and resolve problems in advance. Every software engineer, however, knows that’s not possible or even desirabled.” (quoted from Messrs Herman and Scott’s article, a link to which has been provided in this paragraph). We are also interested in a comment made further on in the article that “[l]earning by trial and error doesn’t work so well for aircraft carriers or Abrams tanks, but it is crucial for the development of effective software.” (ibid).

We think that the Pentagon process that’s got our authors’ attention, which they find hard to accomodate, is actually operational risk management for software development. In our opinion, the interest on the part of the Pentagon in implementing and exercising operational risk management in order to ” . . . anticipate and resolve problems in advance” is far more than merely a “bureaucratic review process”. (quotes are excerpted from the Messrs. Herman and Scott’s article). In fact, we think it is critically important for the welfare of our military personnel that this type of scrutiny be exercised over custom requirements for software. Regardless of whether specific software is intended for office computing use, or for use on the battlefield, any software application accessed by today’s desktop computers is potentially a trojan horse that could be maliciously exploited by enemies of our country or other individuals with nefarious intent.

To give the authors credit, perhaps their point is that the operational risk management methodology implemented by the Pentagon is ineffectual. If, in fact, the authors are attempting to make just such a point, then, perhaps we can be more agreeable to their point of view. However, by no means do we see how the Pentagon could safely adopt a policy that welcomes a “learning by trial and error” method of software development and still safeguard our military personnel.

Rather, we agree with the authors that attempts at managing the risk represented by custom software have been, evidently, somewhat clumsy on the part of the Pentagon, and, further, ineffectual as regards safeguarding our systems from malicious attack, despite substantial cost overruns. But we think all of this work and little progress points to a real need to rethink operational risk management policies and procedures for the actual task of developing software for military use in 2013. By no means, in our opinion, does it make sense to abandon the attempt altogether.

In the next post to this blog we will look at one last set of points made in this article.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


Some Tangible Rationale for Choosing a Cloud Development Option for Enterprise IT Computing Systems

In an article published on Tuesday, February 12, 2013 in the Wall Street Journal, “Send in the Tech Reinforcements” the authors, Arthur Hermann and John Scott make the case that an ISV like Amazon can ” . . . make over 30 changes a week to its portal, from adding simple code changes to new complex features, without a major glitch.” (quoted from the print edition of the Wall Street Journal. This article is available online. A subscription to the online Wall Street Journal is required to read this article). In contrast, the authors note that “[b]y treating software as if it were a product instead of a process, our military services are shutting themselves off from the kind of cost-efficient innovation that rules in the commercial software and IT industries.” (ibid).

While we do not necessarily agree with Messrs Hermann and Scott’s observations, we do find their mention of Amazon to be one of the best examples of why it makes sense for organizations to seriously consider cloud software offers. We absolutely agree that when an ISV has an opportunity to service an entire customer base with one set of software updates, and, further, when that same customer base is completely unaffected by the changes that accompany completed software updates, then the process is very beneficial to ISV and customer, alike.

Of course, there is nothing very sophisticated about the Amazon example in this article. In fact, the Amazon portal is the same point of access for any/all customers. Certainly, different browsers will expose the content differently, but the source code for the site is still the same. The economies of portal development, maintenance, and ease of access for customers are all very good reasons for ISVs to pursue this approach to systems development and for customers to purchase it.

The question for both ISV and customer then becomes whether the type of rapid development and implementation methods that cloud software systems are capable of supporting is likely to be used with the level of frequency that ISVs should deem worth the effort to build these systems, and, in turn for their customers to justify purchasing them for their use.

Certainly we can imagine scenarios where the speed at which cloud systems can be renovated and implemented makes sense, but, conversely, we can also imagine scenarios where this feature will neither be meaningful, nor worth the trade off with regards to the security of data that we still feel is a serious issue for cloud software services.

In the next post to this blog we will look at some other points made in Messrs Hermann and Scott’s article. Specifically, the cost overruns they mention and our own take on the general poor performance of IT projects, as delivered, when compared to their original objectives.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


Search Engine Optimization Continues to be an Essential Component of Online Marketing

We work very closely with our clients on their product marketing requirements. Our staff can, and often does, play the role of an interim senior executive in a marketing organization. The scope of work for one of our engagements frequently has our staff member thinking a lot about marketing communications in a lead generation context.

Of course, in 2013 online media represent the most important venue for our efforts. Just when it looked as if social media (in the following order):

  • LinkedIn
  • Twitter
  • Google +
  • Facebook

and email marketing automation were going to be the object of a lot of our focus in the remaining winter months of this year, we find ourselves, looking, once again, at a very familiar, but nevertheless still challenging task — namely keyword optimization of web site content for search engine marketing.

We came to this realization when we reviewed the progress of a Google Adwords campaign undertaken by one of our clients. We’re members of the Google Engage program for agencies. Before we jump into what we found when our client’s campaign was reviewed (at a high level by our contact at Google and at a detail level by our team), let’s take a few moments to look at what drove our interest in checking up on the campaign.

We need to note that our scope of work for our client hasn’t included day to day management of the Adwords campaign. We do spend a lot of time, daily, working with Google Analytics, but this work is largely a matter of measuring activity resulting from a technical content marketing effort, which we have undertaken through a blog, Twitter page management, and some posting to LinkedIn alerts and Google +.

As we thought about the impact of relatively pricey email marketing automation campaign options for this client we requested permission to review the Adwords campaign. Regardless of whether the method amounts to implementing an email marketing automation program, or an Adwords campaign, or, for that matter, an effort to use organic Search Engine Results Placements (SERPs), the objective is still the same, and completely aligned with the same objective for technical content marketinggenerating leads that can be developed into a sales ready condition.

In fact, the Adwords campaign (as well as the effort to use organic SERPs) were not delivering on expectations. In the next post to this blog we will provide a bit more description to the gap between expectations for our client’s campaign and results.

This is the first of several blog posts on the SEO and Pay Per Click Theme; therefore, please watch coming posts as we add to this information.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


Logistics Software for Transporting Hazardous Wastes is an Example of a Niche Market based upon an Industry Component

The market for logistic software for transporting hazardous wastes is an example of a niche market arising from a heavily regulated industry. In fact, this niche market is actually the result of a number of heavily regulated industries; for example:

  • Oil and Gas Exploration
  • Energy Production (Nuclear Power)
  • Health Care
  • Environmental Management
  • Transportation

Each of these industries produces waste that is hazardous to human health; therefore, a unique set of policies and procedures — specific to heavily regulated industries — accompanies the normal set of required operations for a typical business in this category. When we Googled the keywords “logistic management software hazardous waste” when came on the web page of a business that is, by no means, a smaller ISV, but, nevertheless, one that certainly started out that way: Information Handling Systems (IHS). IHS, which is now a public company with fiscal 2012 sales of $1.53B and EBITDA of $363.32M.

IHS was founded in 1959 by Richard O’Brien to address a highly specialized, niche market: “as a provider of product catalog databases on
microfim for aerospace engineers” (quoted from the IHS web site) Note how the original business plan included a very tight focus on a highly specific (in other words limited, clearly defined) set of requirements for a heavily regulated industry — aerospace.

In 1967 IHS, itself, was acquired by another firm, Indian Head Company, ” . . . founded in 1953, a broadly diversified company in metal and automotive products, producing glass containers, information technology systems and a wide variety of specialty textiles.” (quoted from the IHS web site). From 1967 forward IHS has grown through a series of acquisition of other businesses, all of which were dedicated on specific niche markets that contributed to the enormous success that this company has achieved.

We are not presuming that every small ISV that successfully build a solution for a niche market will enjoy the success that IHS has enjoyed, but, nevertheless, we do think it makes sense in 2013 for smaller ISVs to consider adopting a contrarian marketing plan, meaning one that eschews the commodity markets that characterize most software development requirements, as well as the push to deliver all sorts of software via a SaaS business model, in lieu of a realistic focus on identifying very promising, albeit limited opportunities — in other words, niche markets.

In all likelihood, most competitors are looking other ways, towards SaaS delivery models, or towards simply provisioning development talent to an enterprise market. Therefore, a smaller ISV may have a glimmer of opportunity to succeed following a model that worked for IHS back in 1959.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


Researching the Components of Regulated Industries can Reveal Niche Opportunities for Highly Specialized Software

This is a fourth blog post on the topic of niche market opportunities for smaller ISVs. It may be useful to take a moment to recap where we have come to in this series. The first point we are trying to make is that smaller ISVs will do well to carefully consider niche market opportunities as they piece together a business plan. As we broadly noted in the first post in this series, niche markets may not offer an opportunity for meteoric growth, but, for businesses with software development expertise that has some track record of success, these markets can be expected to deliver attractive revenue.

The second point we made is that the actual level of competition for these markets among smaller firms is comparatively restricted. The reason why, in our opinion, is a trend, over the last several years, on the part of smaller ISVs to address the market for software application development services, without much more than simply a matching focus on the applications themselves. Of course, the driver for this type of product marketing was the aggregate extensive demand for software application development services from:

  • Enterprise Business Looking to Contract, and even Outsource Systems Development
  • Public Organizations (like the Federal Government here in the United States) After Much the Same Services
  • and Healthy Demand for New Systems Development from Start Up Tech Ventures

As we see it, these three markets (largely as a result of the proliferation of Software as a Service, SaaS, offers from large ISVs) are presently contracting. We think it makes a lot of sense for smaller ISVs to eschew this services focus and, once again, look seriously at product development (including SaaS offers for highly focused markets).

Finally, we started to touch on why we think that heavily regulated industries are a good place for smaller ISVs to start their research for niche market requirements. Of course, competing to satisfy the broader industry needs (for example, for medical systems, or financial systems, or even legal systems) in any of these categories will not make much sense. After all, the large ISVs compete fiercely for this business. But niche requirements can still be won and are worth a serious look.

In the next post to this blog we will start to broadly sketch out a scenario around simply a module of the operations of a hazardous waste management business as an example of a niche in need of its own highly specialized automated systems.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


Heavily Regulated Industries Present Smaller ISVs with Potential Niche Markets

This is the third blog post in our current series on the opportunities for smaller Independent Software Vendors (ISVs) in opting to service niche markets. In this post we will look at a source of product notions that these smaller ISVs may find when they look closely at heavily regulated industries.

Heavily regulated industries share one common characteristic: they are all subject to periodic review by their respective regulatory agencies. Therefore, records keeping — across the board — is a mandatory task for all of these businesses. Extrapolating from this fact, it should be easy to see why these types of businesses are particularly promising for ISVs who offer comprehensive applications, like Enterprise Resource Planning (ERP), or any of the other “enterprise” software packages (Content Management, Document Management, Risk Management, etc). In fact, once one of these businesses standardizes on an ERP solution, every department throughout the organization will need to implement the solution.

With a business intent on migrating all of its operations onto a new ERP platform, there will be, in all likelihood, opportunities to provide customers with what we like to refer to as “follow on” software and services. For example, despite the fact that all departments within a heavily regulated business must, across the board, implement a new ERP standard, these same departments can still complain about the obligation. Further, they can perform poorly with the new software, which can lead to a drop in overall profit for the business or a drop in sales. Regardless of how activities diminish, a requirement emerges to support the customer in its efforts to hasten user adoption across the business, of the new software package.

For all of the above it makes sense for ISVs of all sizes to look closely at regulated businesses. Obviously, larger ISVs have developed lucrative ERP solutions for the largest components in specific industries. For example, for law firms, an Enterprise Content Management (ECM) software package by the name of Hummingbird, which is actually no longer aggressively marketed, is still the standard. Needless to say, quite a number of ISVs have earned meaningful revenue either selling this package, or servicing it.

Similar examples abound for health and human services businesses, financial institutions, and more. But this is fine for larger ISVs. What about smaller ISVs with original Intellectual Property (IP) in mind as a business model. Where are the opportunities for these smaller players in heavily regulated industries? We will take a look at how to filter for some of these opportunities in the next post to this blog.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


Product Marketing for Smaller ISVs Should Maintain a Focus on Niche Market Requirements

Over the last two posts to this blog we have discussed what was a familiar model for smaller Independent Software Vendors (ISVs), namely software product development which was entirely focused on satisfying the needs of niche markets. In fact, these smaller ISVs, or Value Added Resellers (VARs) as they were referred to in the past, could develop into attractive businesses with a lucrative revenue model, all built around highly specialized markets. In fact these market niches almost always included formidable barriers to entry that would discourage likely competitors.

In the last post we provided a brief example of a VAR that grew into a successful business employing 4-5 developers. This VAR sold a complete Enterprise Resource Planning (ERP) automated system specifically designed for the conference market for non profit organizations. There are, literally, thousands (or, perhaps, even millions) of examples of other highly specific software products built by VARs, or smaller ISVs for very specific markets.

However, it does not make sense for these same smaller ISVs to pursue product development for niche markets if the business plan is built around providing software development services to customers. This services business model has been very popular since 2000. The model works as follows: we have a small team of software developers, and Subject Matter Experts (SMEs), for a specific type of software development; for example, application development with PHP, C#, Java, etc. Our revenue model is built on leasing out these experts to customers who may use our team to build their own custom software products. Of course, the custom software products developed by our SMEs remain the property of our customers. Once the project is finished, our team (ideally) proceeds to a new project.

In fact this services business model for smaller ISVs is no longer the revenue generator that it once was. We have written a lot on this topic already; therefore, we are not going to expand on the point here. Let it suffice to say that via a combination of a more global market for SMEs, a push by enterprise ISVs and enterprise customers for Software as a Service (SaaS), and the cool markets for software that characterized the last several years during a global economic slow down, an ISV simply marketing the services of a team of SMEs is not a very promising strategy.

Rather, we think that smaller ISVs need to come back to thinking about product development. Satisfying the needs of niche markets is certainly a good place to start. In the next post to this blog we will look at opportunities for lower cost product development as the result of SaaS resources like Amazon AWS, etc.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


Opting to Service a Niche Market can Provide a Small ISV with an Attractive Revenue Stream

The concept of a “mom and pop store” is seldom applied to the ISV business. But we think that it’s worth the time required for a small ISV CEO to think about a notion like this one, meaning a plan that promises a healthy, albeit, limited revenue stream. The macro setting for this discussion, of course, has to do with scale, which is a very important setting, indeed, but one that we haven’t plans to cover here.

So how does one apply this cliche to the small ISV business? Attending to the specific needs for computer processing for niche markets can produce software that will not only pay for itself, but generate an attractive revenue stream in much the same manner that a small country store that serves as the only source for groceries for a town of a 1,000 people can do so for its owner.

In fact, we saw this done several years ago when we were based in just such a rural locale. A colleague (an ex professor of computer science from a prominent local university) set up an ISV around no more of a business model than as a production house for a software package that automated all of the steps required by non profit organizations as they plan conferences and actually manage them. One can argue that, today, there is a cloud application somewhere that will do all of that, but we have to say that we are not aware of such a package. An attractive unit retail price for this software application promised to keep this ISV running profitably with a staff of 4 or 5 programmers for quite a while.

It makes sense for entrepreneurs committed to an ISV business model, who want to maintain complete control over their business, and are not reluctant to address the needs of small markets with deep pockets to seriously consider product development for highly specific needs. Of course, an effort must be made to ensure that these small markets, nevertheless, still include some players with deep pockets. Certainly there is no excuse for wasting time developing solutions for highly limited markets that lack the financial means to feed a growing business.

But for markets that measure up, it should certainly make sense for small ISVs to build solutions, especially where these solutions can be delivered to customers via a subscription offer that avails of the cloud. Sometimes it makes sense to “think small.”

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved


It Makes Sense for Independent Software Vendors to Seriously Consider Niche Markets

Identifying likely markets should be a critically important activity for early stage independent software vendors (ISVs). Once markets have been identified, it should be mandatory that the base assumptions for choosing specific markets be retested, periodically, over the life of an ISV.

We think it makes a lot of sense for ISVs with limited resources to thoroughly explore any niche market opportunities. After all, niche markets, by definition, are very narrow and call for a highly specific set of solutions. Nevertheless, a set of prospects for solutions that satisfy niche needs can still include some larger organizations with lots of internal groups requiring the same solution. Whether through an enterprise purchase, or through a number of purchases of the same solution within the same organization, software that satisfies a niche requirement can produce meaningful revenue for an early stage ISV.

Despite the importance of these product marketing activities, it is surprising to note how often these tasks can be overlooked, especially for ISVs where senior management is very technically capable, but otherwise lacking as regards business experience. For these ISVs, business just happened. In other words, the CEO is often a software engineer who writes programs. The chosen market is very familiar, as the CEO offers lots of experience writing software for the chosen market from a past career. In sum, no conscious decision has been made by anyone to select the market. This lack of conscious decision-making is a problem that should be corrected as quickly as possible.

Of course, an excellent remedy for this stumbled on business model is to produce a business plan, which will need to include a market presentation. Most businesses, at some point, will require a business plan. For example, any attempts to secure conventional financing for a business through bank loans, or even private investors, will have to be accompanied with a business plan that 3rd parties (banks, private investors, etc) can review.

We think it makes sense for entrepreneurs to produce a business plan before starting a business. Unfortunately, in our experience, it is usually the entrepreneur who has failed at a first attempt to build a business who understands the need to have a reasonable business plan in place before starting up a next time.

In the next post to this blog we will look further at why opting for niche markets makes sense for ISVs looking for a “mom and pop” business model.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved