How to (not) become a digital Enterprise – Bringing Technology to the Heart of your Company

By
  • Blog
  • >
  • How to (not) become a digital Enterprise – Bringing Technology to the Heart of your Company
TOPICS

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.

TRENDING CONTENT

This blog post is the third of a five-part series based on the keynote I presented at CamundaCon 2019 (You can find the recording on YouTube). You can read the first blog in this series here.

In essence, I recommend:

  • Prioritizing customer-focused innovation.
  • Bringing technology to the heart of your company.
  • Automating your business, one project at a time.
  • Putting executives in charge who care about long-term success, their people and the world.

Bring Technology to the Heart of your Company.

For my second recommendation, we need to look at the history and future of “Business versus IT”.

The history and future of business vs. IT in the 70s & 80s

50 years ago we had the first broad-scale introduction of software development practice in many companies. Hence this was also the first interaction between people who needed programs and those who created them.

Unfortunately this did not always go well. Business people felt misunderstood and programmers found the business was constantly changing its mind. So both sides felt they wanted stronger commitments, which eventually led to the waterfall software development practice being broadly adopted. But let me stress this: this adoption was driven by frustration.

The history and future of business vs. IT in the 90s

Despite the waterfall model, this frustration grew stronger over the years and soon the business wanted to put “market pressure” on IT, which led to more and more power plays and politics. It was during that time that the idea of business management software, that you can buy off the shelf to run your core business operations, became very attractive. Also, more and more companies started to outsource their IT to subsidiaries or external suppliers. You can wonder if this is the best possible precondition to become a “Digital Enterprise”? In the middle of that same decade, however, there was also a paper published by Ken Schwaber and Jeff Sutherland, that described a thing called “Scrum“.

In 2001, the famous “Agile Manifesto” was published. And one of the most relevant problems Agile was going to fix was the dysfunctional relationship between the people who needed programs and those who created them.

A few years later, some software vendors thought that model-driven development platforms for process automation could make a lot of sense, or at least a lot of money. So they created BPMS products with a value proposition that was basically: “With our product, you can create programs, without programming. So you don’t need programmers!”

What could possibly go wrong?

Today, 15 years later, a few of those products are still around, but when you look up their revenue growth and P&L statements (it’s all online), they do not seem to be doing very well. And just think about it: They had 15 years to prove their point and put “real” software development out of business. But if their concept had actually made sense, today Amazon would be running their entire operations on one of those products. Just to be clear: They don’t.

And the reason why I sometimes rant a bit about Robotic Process Automation (RPA) is not because RPA doesn’t make sense – it makes a lot of sense for automating certain granular, recurring tasks. But history repeats itself and some executives can’t stop hoping for this low-code silver bullet that will allow them to automate their core business operations end-to-end without any actual software development.

It’s a vicious cycle.

vicious cycle

During these past five decades, we could basically observe a downward spiral happening in many corporations. Their poor software development caused serious issues, like urgent business needs not being fulfilled. But instead of fixing the root cause, they went for some apparently quick workarounds. So just like a sick person that doesn’t go to the doctor but is just popping some painkillers, they didn’t invest in a strong software development practice, which made things even worse. I very much doubt that Amazon would run their core business operations on software they bought off-the-shelf, or outsourced it to wherever, or implemented it using low-code or RPA. Amazon is not doing any of this. In fact they became so strong at developing and operating their own stack, that they even productized the underlying infrastructure – AWS.

But things are changing.

In 2011 Marc Andreesen published his famous article basically stating that software companies are in the process of dominating each and every industry on this planet. Later, Goldman Sachs’ CEO proclaimed that GS is a technology company, employing more software developers than Facebook or LinkedIn. The German Commerzbank decided to re-insource their IT activities and German retailer Lidl canceled an SAP introduction project after spending seven years and shelling out €500M.

Today we’re seeing more and more organizations that want to break the aforementioned vicious cycle and going forward they are now putting the development and ownership of software technology at the Heart of their Organization. We believe this trend will continue, and they will be ramping up their software development practices and truly modernizing their legacy IT systems, instead of just slapping band-aids on top of them. They are bringing business and IT back together, as one team. Of course, licensed software off-the-shelf, preferably provided in the cloud, can run those processes that are not core and unique to their business.

Their core business model, however, will be running on solutions that they will be creating and owning themselves, which exactly defines a Digital Enterprise.

Sounds ambitious? We looked at a life insurance startup in the beginning of this post, let’s now look at a German Life Insurance company founded 150 years ago. I’d say they probably have a legacy to deal with. In this article (in German), their IT director Peter Blenninger describes their digital transformation journey and it is a great example of what you can achieve when you truly make this a priority.

Their need is to bring new products to market faster. In order to do that they are replacing legacy monolithic systems with microservices orchestrated by Camunda. They are literally removing any barrier between their business users and software developers, they are leveraging hybrid cloud and they are adopting agile paradigms. Mr Blenning claimed that buying some off-the-shelf software would not have made sense for them because the existing products in the market are “too old already”. In other words, the software vendors are not able to keep up with the innovation pace of their potential client. And that is exactly how it should be, that’s what a Digital Enterprise is all about.

So, what does this look like in action?

Interested in learning more about the practical ways you can swing the pendulum from “buy” back to “build” to support rapid software development in-house?

Join our November 12th webinar: How to Build Scalable Business Automation with Microservices with award-winning BPM analyst, consultant and author Sandy Kemsley, who’ll discuss key requirements and success strategies for developing a scalable business automation platform that supports internal application development by distributed teams and delivers true business agility.

You can also catch up on her CamundaCon 2019 keynote here.

Plus in next week’s blog, I’ll be discussing how to automate your business, one project at a time.

Try All Features of Camunda

Related Content

We're streamlining Camunda product APIs, working towards a single REST API for many components, simplifying the learning curve and making installation easier.
Learn about our approach to migration from Camunda 7 to Camunda 8, and how we can help you achieve it as quickly and effectively as possible.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.