Tag Archives: DevOps

Why Enterprise IT Plans Rarely Succeed

There are five factors why successful implementation of most enterprise programs is almost impossible.

Factor 1 – Lost in Translation

We all know the major steps in a software development life cycle (SDLC):

Step 1 – Identifying Strategic Direction and Imperatives
Step 2 – Creating Business Requirements
Step 3 – Developing Technical Architectures
Step 4 – Developing Technical Designs
Step 5 – Code Construction

Each step in an SDLC represents an interpretation of a prior step’s deliverables into this step’s deliverables. But it’s almost like translating from English into Mandarin Chinese. There will be gaps in this translation. Every step is, we hope, conducted by people who know their own step very well, yet they have a limited knowledge of the prior or the next step.

Subject-matter experts (SMEs) writing requirements more often than not have a very limited understanding of all the current market needs, and even less of an understanding of future market trends. They for sure have no idea about underlying architecture. By the way, making strategists write requirements produces the same result. So let’s not even ask BCG or Bain to create requirements. Unfortunately, there is no magic button we can use to verify the created requirements’ compliance with the strategic direction, or how well architecture satisfies strategy or even business requirements. And the issue applies to every SDLC step.

Let’s assume we are very good at what we do. Let’s say we improperly translate only 10% of what was created by a prior step. This means that the probability of delivering something useful to a target market and to our internal business just dropped to below 60%! And this even before we take into consideration the budget and time overruns. So, at least 40% of objective market needs are not satisfied because they are lost in translation. And this is the best possible case.

Factor 2 – Implementation Time Is Our Enemy

These steps represent our subjective interpretation of what’s required by the target market players and by our internal business. So, the only objective entity here is our target market. And this market changes much faster than we suspect. While CIOs can ask or even demand during long-running programs to freeze changes to business requirements, we can’t ask the same from our markets and customers. Our target markets do not wait for us to complete software development.

See also: Expanded Role for Alternative Capital  

It is not uncommon for an enterprise program in insurance to last around 36 months. Let’s assume that one of the success factors is defined as not having a need for significant changes to the production code for the first 24 months after deployment. I even quantify a significant change as a change requiring 15% of the cost of initial implementation. That means that our strategy team must identify market needs with almost absolute accuracy for the next 60 months. Futuristic analysis like that is impossible for one simple reason – there are too many factors influencing consumer behaviors in a market, especially for such a long period.

The longer we take to implement, the more likely it is that our understanding of objective market needs will change, and therefore the less accurate the initial assessment was. That means that by the time we deliver, we are already too late. What we deliver will be functionally outdated and must be immediately changed.

We can certainly refresh our strategy every year. But what to do with the requirements that have already been implemented? And how to deal with new upstream and downstream process dependencies? DevOps approach, gaining popularity now, due to internal architectural dependencies of most legacy and even more modern off-the-shelf products, produces very limited success.

Factor 3 – Measuring Success at the Wrong Spot

When we measure success of the core systems implementations (and this kind of projects represents the majority of enterprise-sized programs), we count numbers, but the best way to measure success is to measure our internal users’ satisfaction. Right? No, not right.

Remember the only objective entity? The only true measure of success is our target markets. If our work does not increase market penetration and does not result in revenue and cost improvements, then it doesn’t matter how good our organization feels about new, modern applications. It is that simple.

So why do we so seldom measure the effects of our work on the markets? Because so often our business case is not really based on market needs and does not measure the effects of new systems and processes on our consumer.

Factor 4 – The Wrong Reasons for the Program

In my experience, as much as 70% of all programs represent a replacement of legacy systems by more modern applications. That’s the only business case. In some cases, my clients were losing vendor support, and in some cases teams that developed their legacy systems left the company. A true story: I was on an engagement for a client who wanted to have new tech so that she could move it to the cloud and save about $25 million in annual support cost. To do that, she was willing to spend around $200 million on core system replacement. There was no return on investment (ROI). She was not an exception.

It’s amazing how often insurance companies get into long-term projects to replace one technology with another technology – without targeting or achieving any revenue increase, and without opening any new markets. Maybe it’s less expensive to train your people on older technology and keep supporting this old technology on your own while developing a real business case for replacement? Just saying.

Factor 5 – Hero Worshiping

One of the first questions I’m asked by my clients is what other insurance firms are doing. This question makes me very uncomfortable for many reasons. For one thing, I can’t disclose confidential information.

But another reason is even more important. As a matter of fact, it is fundamental. Just because a perceived industry leader does something does not mean you should follow in his steps. Doing so relegates you to the position of a follower. Do you really want to be No. 2 or number ”anything except 1?“ Second, even leaders make mistakes. The difference is – big companies can mask their losses, but, if you work for a mid-size insurance firm, you can’t afford to fail. You have no billion- dollar budget to mask a $20 million loss. Finally, just because a leading insurance firm does something, that doesn’t mean that it does it right. Besides, a market leader’s customer profile can be vastly different from yours.

So please do not jump from this roof because someone your worship jumps. It is bad idea for them, and it is an even worse idea for you.

See also: Pulse Check: How Do You Approach Risk?  


There are only two events in the life of a modern Information technology organization that result in mass firings of executives. One of them is a security breach. Another one is the almost hopeless journey to implementing core system replacement and any large enterprise program.

Before you embark on this journey, think about the real chances of your success, and think long and hard about what success really means to you. Are there simpler and less expensive ways to deliver value to your customers? Is doing nothing better than doing something? Are there better places to spend money? Try answering these questions before starting an enterprise program.

A New Way to Develop Products

The long-term sustainable value from insurtech lies in its ability to change how insurance products are created. The economic model behind how startups bring their products to market is bending — no, breaking — the traditional development cost curve. Insurers that recognize this dynamic and adjust their innovation activities accordingly will create more value from insurtech than their competitors.

Insurtech has already gone through at least two iterations in its short lifespan. A little more than a year ago, the market was abuzz about widespread disruption. Now that it is recognized that there is value in integrating insurtech, partnership is the rage. The next phase will see an increase in greenfield operations. Over the next 12 months, the economics of insurtech development will result in a significant increase in spin-offs and stand-alone propositions.

See also: 10 Trends at Heart of Insurtech Revolution  

The reasoning is this – economics will motivate different behavior. Traditional insurance product development is typically characterized by these approaches/tools/techniques:

  • Product or process-centered design
  • Waterfall development (although agile techniques are catching on)
  • Centralized, on-premise infrastructure
  • Package or custom-built software
  • Periodic release and control procedures
  • Service-oriented architecture (SOA) integration

Contrast that with insurtech operations. They are typically characterized by these approaches/tools/techniques:

  • Customer-centered design focused on delivering a minimal viable product as quickly as possible to the market
  • Agile development using small teams
  • Cloud infrastructure
  • Microservices architecture
  • Use of DevOps to control updates
  • Use of open source software
  • API integration

Here is where the economics comes in. Without reading ahead, answer the following question:

If you spend $1 delivering a specific set of functionality in the traditional approach, what amount would be needed to deliver exactly the same functionality using the new development approach?

I have been asking this question for the last two months. It is a tricky one, because the best input comes from the limited number of people who have delivered insurance products in both the traditional AND the new development approach. These few professionals have “lived” both environments. My sample size is small so far, but I have polled about 30 people.

The answer ranges between 20 and 30 cents on the dollar. So, call it a quarter. That means that a $4 million project delivered with the traditional approach is only $1 million using the new tools/techniques. Or, better yet, entire propositions, which include changes to both the insurance product and a new automation platform, can be delivered for less than $4 million. (For more on this, see the @Celent_Research report Slice Labs: A Case Study of Insurance Disruption.)

With this cost profile, a greenfield startup approach becomes much more attractive. Investing in a new product/market approach is much less risky given the smaller level of investment. If we marry this with the innovation fatigue expected as incremental efforts fail to deliver sufficient value to the core business, the environment is ripe for spin-offs.

This is not to say that the current “partner with a promising insurtech firm” or the “we want to make innovation part of our culture” approaches will go away. However, expect to see significantly more stand-alone efforts than we have seen in the past.

Immediate adjustments to this opportunity include:

  • Insurers should include multiple startups in their innovation portfolios
  • Insurance software/IT services providers and venture groups should help both insurers and insurtech firms to set up greenfield propositions
  • Insurtechs should look beyond incremental solutions and apply their talent and techniques to entire insurance propositions

See also: How Technology Breaks Down Silos  

As some of the spin-offs succeed (and most of them fail), insurers will learn how to develop in the new environment and will transfer these techniques to their core business. As a result, the true value of insurtech will not be an either/or choice, but change through absorption of new approaches and techniques.

Insurtech = new way to develop insurance products.

Better Way to Assess Cyber Risks?

As the saying goes, there are two kinds of motorcyclists: Those who have fallen off their bikes and those who will.

The insurance industry assesses the corporate world’s cybersecurity risk much the same way. Everyone is equally at risk, and, therefore, everyone pays the price for higher insurance premiums.

Not a day seems to go by without news of a high-profile security breach. It’s no surprise, then, that the cybersecurity insurance market is expected to rise to $7.5 billion by 2020, according to PwC. Even worse, the industry does not have effective actuarial models for corporate cybersecurity, say Mike Baukes and Alan Sharp-Paul, the co-founders and co-CEOs of UpGuard.

The two audacious Australians have developed what they say is a better way to assess the risk for cybersecurity breaches.


Alan Sharp-Paul (L) and Mike Baukes (R), Co-Founders and CO-CEOs, UpGuard

The pair’s company recently unveiled its Cybersecurity Threat Assessment Rating (CSTAR), the industry’s first cybersecurity preparedness score for businesses. UpGuard’s CSTAR ranking is a FICO-like score that allows businesses to measurably understand the risk of data breaches and unplanned outages because of misconfigurations and software vulnerabilities, while also offering insurance carriers a new standard by which to more effectively assess risk and compliance profiles.

According to Baukes and Sharp-Paul, many companies forego available policies due to perceived high cost and uncertainty that their organizations will suffer an attack. With countless patches and endpoint fixes slapped onto IT infrastructure to hastily remediate breaches, companies have found themselves with less visibility into their core systems than ever before and, as a result, no way to understand how at-risk they are for hacks. With CSTAR, businesses are able to regain transparency into their own stack and take the appropriate steps to bolster their cybersecurity. Insurance carriers, meanwhile, can make smarter underwriting decisions while accelerating the availability of comprehensive and cost-effective cybersecurity insurance policies for businesses. It’s a win-win for both the insurance industry and for businesses.

After spending years in financial services in Australia and the U.K. and witnessing the disarray of corporate IT, Up-Guard’s two co-founders decided they could make a difference by developing a better way for corporations to understand their software portfolios and their associated potential risk for security breaches. Baukes says, “Our experience showed that that there were thousands of applications and thousands of machines powering all of this critical infrastructure. And the thing that we learned throughout all this was just how hard it is for an IT organization to understand and get a handle on what they’ve got.”

“Today, everything is out in the cloud,” Sharp-Paul says. “We’re all more connected. Employees are connected 24 hours a day, seven days a week. Now what keeps CIOs and CEOs up at night is, ‘If we get breached, I could get thrown in jail. I could get sued.’ It’s a very, very different world we live in today. We built a system to help companies understand and prevent downtime, and helping them save on project costs is just as relevant today from a security perspective.”

The two initially started a consulting company to help companies catalogue and manage their software platforms and applications. According to Sharp-Paul, “We realized the biggest problem companies have from an IT perspective is that they don’t really have appropriate visibility into what they’ve got and how it’s changing because so many things are changing daily in these environments that it’s really hard for them to know what ‘good’ looks like.”

Sharp-Paul and Baukes’s consulting led them to develop software to automate the process, providing the means to quickly and effectively crawl every server and software application to present a profile of what needed to be updated or patched and to identify the system holes that allowed for security breaches.

As Baukes tells it, “Getting that all to mix well and be safe, secure and capable of pinpointing where problems go wrong really quickly is an incredibly difficult task. So, we built up the first commercial version of the product—a very rudimentary version—and we shopped it around, and people were very excited at the time.”

From there, the pair realized their software had commercial potential and implications more far-reaching than what they had first thought. “We started with that very simple version with a few sales and no sales force—just Alan and [me] at the time—growing to the point now where we now have 3,000-plus customers, and the team is steadily being built,” Baukes says.

Now, the company has nearly 50 employees and is growing fast. The Mountain View, CA–based company attracted early seed funding from the likes of Peter Thiel, Dave McClure and Scott Petry, leading to a near $9 million Series A funding underwritten by August Capital.

The co-CEOs admit the co-managing arrangement is unconventional and would be challenging to make work under different circumstances. However, Baukes and Sharp-Paul feel their skills and temperament complement each other.

“To be honest, when people ask us about it, my first response is always that it’s a terrible idea,” Sharp-Paul says. “And that’s not because it’s been a horrible experience for us. It’s because I kind of think we’re really the exception. And the only reason I say that is that I know the unique things we went through and the type of people we are that makes this work. I can’t imagine that being a common thing at all.”

Baukes is generally a more aggressive and strategic thinker, while Sharp-Paul describes himself as more pragmatic and conservative.

Sharp-Paul and Baukes first worked together at the Colonial First State Investment firm back in Sydney, where the two lived the DevOps experience before DevOps became the buzzy concept that it is today. There, Sharp-Paul was a web developer, and Baukes was a systems administrator, and they talked a lot about things like continuous integration and continuous delivery.

“Now these are all fantastic things,” Sharp-Paul says. “But you need a foundation or a basis of understanding what you have. I mean, we like to say you can’t automate what you don’t understand. Or you can’t secure or fix what you don’t understand. And that’s always missing. Everyone’s trying to rush to this goal of DevOps or moving to the cloud. Everyone wanted to be there, but companies and vendors in particular weren’t helping businesses on the journey there.”

Baukes says, “Once you have that base understanding of what you have, then that opens everything else up. You can think about DevOps. You can think about automation. At the time, we were thinking, ‘Why hasn’t anyone thought to do this before?’ It seemed like such a foundational, basic thing. It was almost like it was so foundational that everyone just moved past it, and they were looking at the next shiny thing down the road. I think that was the white space. That was our opportunity. We jumped on it.”

As it turns out, in the world of corporate IT, applications never get retired. Even worse, the people who manage them move on because the life cycle of an employee at a company is short. As as result, the institutional knowledge about these applications is lost.

“Corporate memory is so short typically,” Sharp-Paul says. “They often get to this point five years down the track where they rediscover this server or this application, and everyone’s too scared to touch it because they don’t know what it does. They don’t know how it works. The people with the knowledge just left with it all in their heads. We come across that all the time.”

Sharp-Paul and Baukes had always seemed destined to do something on their own.

“I always had a healthy disrespect for authority. Throughout my corporate life, I was looking outside to see what else is [WAS?] out there,” Sharp-Paul says. “I actually started the first step of creating a business on my own—with something as mundane as a French language website that I used when I moved overseas for a couple of years. … It taught me that I can actually build something myself that makes money.”

Baukes agrees.

“The big difference is that I grew up in an immigrant family in the middle of nowhere, effectively. I won’t say the Australian Outback, but really rural,” he says. “We built everything ourselves. My father was a great wheeler and dealer. So, I learned a lot of from him. I fell into all of this by playing computer games and was really good at it, frankly. For me, that was a springboard into an accidental corporate life. I always knew that I would do something else.”

Now, for the future?

Baukes says, “It makes good business sense to quantify the risk in your company’s IT systems and report it effectively. And I think that for us, we could continue growing our business with that in mind—giving people visibility, helping them get to the truth of what they’ve got, teaching them how to configure it, and showing them if they’re vulnerable. That is beginning to accelerate for us, and we’re incredibly proud of that.

“We truly believe that, over time, CSTAR will be adopted as an industry standard that companies and carriers alike can rely on to make critical coverage and cybersecurity decisions.”