Sandy Kemsley’s Vlog - Business automation best practices #1 - Introduction
Sandy Kemsley Photo
Vlog

Business automation best practices

#1 – Introduction

By Sandy Kemsley

Video Time: 4 Minutes

Hi, I’m Sandy Kemsley of column2.com. I’m here for the Trisotech blog with the first in a series on best practices in business automation application development.

I want to set the stage for this series by talking today about what I call the automation imperative. We have a lot of cool technology now, that can be applied to automating business processes and decisions:

Now, all this technology makes more automation possible. These newer technologies let us automate things faster and better, and in fact automate things that were never possible before. But this has a downside. Yours isn’t the only organization with access to these technologies and everyone else is trying to automate their businesses using the same methods and the same technologies. That means whatever market you’re in it’s become more competitive. Since that rising tide of new technology is floating all the boats, not just yours. More nimble competitors will force you to automate in order to compete, or you’ll die in the marketplace. This is the automation imperative. It’s essential that you leverage automation in your business, or you just won’t be able to survive.

So easy right? Just plug in some of these new technologies and off you go? Sadly not that easy. A study done by Boston Consulting Group, showed that 70% of “digital transformation projects” don’t meet their targets. 70! 7-0, that’s a big number. Well okay, digital transformation is one of those loose terms that gets applied to pretty much any IT project these days, so let’s focus that down a little bit. Ernst & Young looked at RPA projects. Now, robotic process automation vendors claim that you’ll have your return on investment before they even get driven all the way out of your parking lot.

Now, what E&Y found though, is that 30 to 50 percent of initial RPA projects fail. So, if organizations aren’t succeeding with a technology that’s supposed to be the most risk-free way to improve your business through automation, then there might be some problems with the technology, but probably, someone is doing something wrong with how they’re implementing these projects as well. We have billions of dollars being spent on technology projects that fail. A lot of companies are failing at business automation. You don’t have to be one of them.

Now, this series of videos is focusing on best practices, that will help you to maximize your chances of success in application development for business automation. Or if you want to look at it in a more negative light, they will minimize your chances of failure.

I’m going to split the series into three parts:

So we’re going to be covering quite a bit of territory and looking at a number of things.

Now, in each of these videos, I’m going to discuss a couple of things you should be doing. So those best practices and also some of the indicators that you might be failing. So some of these anti-patterns that you can be looking for as you were going through your projects to figure out if something’s going off the rails maybe before you have a serious failure. So stay tuned for the coming videos in this series.

That’s it for today. You can find more of my writing and videos on the Trisotech blog or on my own blog at column2.com. See you next time.

Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ll blog

View all

Sandy Kemsley’s Vlog - Composability: leveraging best of breed
Sandy Kemsley Photo
Vlog

Composability: Low-code versus model-driven

By Sandy Kemsley

Video Time: 7 Minutes

Hi, I’m Sandy Kemsley of column2.com. I’m here today for the Trisotech blog with a few more thoughts on composable applications. In my previous two videos, I talked about the general definition of composability, and why you need to consider a best-of-breed approach to components. Today I’m going to look at how model-driven fits into the landscape.

Now, although it’s not strictly necessary, most platforms that fall into the composable category are also low-code, meaning that you don’t write a lot of technical code in a language like java, but you graphically assemble applications using building blocks in a way that’s more easily understood by less technical citizen-developers and business analysts. Some low-code environments use predefined application templates that are customized by modifying parameters, so they’re even easier to use. Others allow the developer to create some simple models like a linear workflow and the data structure of the parameters, but that’s not necessarily fully model-driven.

Now, let’s look at these three concepts together and see how they fit. They are somewhat independent but there’s overlaps.

As I discussed in a previous video, application development environments can be composable without being either low-code or model-driven. The concept of composability is almost as old as programming itself and it includes things like calling external libraries from traditional coding languages.

Now, low-code on the other hand, does not imply that the environment is either composable or model-driven it could be a walled garden for creating applications based on modifying parameters of predefined templates, and did not even allow any external components to be added.

And model-driven doesn’t necessarily enforce composability since it could just be for modeling and executing applications that don’t even call external services. Now, however model-driven is usually considered to be, if not low-code, at least not full-on technical coding. Although it’s usually quite a bit more technical than most low-code.

Confused yet?

Let’s go back to the definition of model-driven engineering. It’s about creating these conceptual domain models of everything related to your business: process, decisions, data, and much more. And then, instead of having to write code that explicitly defines these entities, applications are created based on these abstract representations by putting together these models. Now, business process management systems or BPMS, are a great example of model-driven application development. Since they allow you to create a graphical process model using a standardized notation and then that model actually executes, it is your running application.

You need a bit more than just the process model for an entire application, of course, but a lot of the business logic can be represented in a process model using BPMN, which is the modeling standard. It’s the same with case management and decision management. We have these three related standards: BPMN, CMMN for case management, and DMN for decision management. And these provide graphical representations for modeling, as well as the underlying execution semantics that allow these models to be directly executable. So, they’re not just pretty pictures that represent what you want your application to do, they are actually part of the application.

Now, one argument against the wider use of these modeling standards — the BPMN, CMMN and DMN — is that they’re just a bit too technical for the audience that’s targeted by low-code systems. In other words, they are low-code-ish. Definitely less code than a traditional coding language, but more of a visual coding language than most low-code environments. And in fact, you can call these executable models as components from a traditional coding language. So, even though the models might be created graphically and were done model-driven in a relatively low-code environment, then used as components in a composable environment, the whole end-to-end application development would not be considered low-code because it would be coming from a more traditional coding language like java.

So, let’s sum it up then.

So, that means instead of the overlapping Venn diagram that I showed you earlier, which is technically correct, the way that these systems are practically created and used today would fall into more like these patterns:

So, that puts model-driven as a subset of low-code, and low-code as a subset of composable. So, you need to look at your developer audience to know which of these things are going to be important to you.

Are you looking at just a composable environment?

Always, you definitely want to have a composable environment because there’s too many third-party services and components out there that you might need to put together — and see the previous video that I did on best of breed to kind of understand more about that.

Do you need to have low-code?

Yeah, if you have less technical developers, or even your technical developers can use it either for prototyping or for applications that don’t need the type of optimization or hardening that would usually be done with more complex written code.

What about model-driven?

I would say, if you’re going low-code, go model-driven. Go with something that allows you to create models, such as data models and flow models, even if they’re fairly simple models, rather than using this limited just configurable template sort of paradigm. Technical complexity can obviously vary a lot with model-driven, from these very simple kinds of models to full BPMN and DMN, but you’ll find something in there that meets all application developer needs across whatever the spectrum might be.

That’s it for today you can find more of my writing and videos on the Trisotech blog or on my own blog at column2.com. See you next time.

Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ll blog

View all

Sandy Kemsley’s Vlog - Composability: leveraging best-of-breed
Sandy Kemsley Photo
Vlog

Composability: Leveraging best of breed

By Sandy Kemsley

Video Time: 5 Minutes

Hi, I’m Sandy Kemsley of column2.com. I’m here for the Trisotech blog with a few more thoughts on composable applications.

In my last video, I went through the basics of composability, and some of the benefits of composing applications by assembling components or services. Having the ability to reuse components in multiple applications is definitely one of the big benefits. As well as being able to stand on the shoulders of other developers, by calling their components from your application rather than developing everything yourself. I also spoke briefly about interoperability, which means that any service or component written by anyone, using any programming language, can be used by anyone else, creating a new application using potentially some other programming language, as long as they both use standard interfaces for interoperability.

Now, we’ve been through a few generations of these interfaces. Some of you must remember Corba and Soap, and the current gold standard is REST. As long as the component has a RESTful API and the application knows how to make a REST call, then they can work together. Now, all of this interoperability is important, because it allows organizations to take a best-of-breed approach to composing applications.

Why would you use the substandard functions that your monolithic application development environment provides when you could directly add in a better component from a best-of-breed vendor? Now, we see this a lot in the business process management world, with this push towards IBPMS (all in one app dev environments that have process engines and decision engines and user interface and everything bundled in there). Now, there are a lot of vendors that have really great process engines, and then they’ve bundled in some not-so-great versions of other capabilities, just so that they can tick all of the IBPMS boxes. Now, you can still use best-of-breed external components in your applications, but many organizations won’t because they’re already paying for the monolithic vendors’ walled garden. Plus the vendors would have you believe that things just won’t work quite as well if you don’t use their components. Now, can you really trust a vendor that wants to sell you an environment for creating composable applications, but doesn’t want you to use anyone else’s components?

The whole idea of composability, is independent building blocks after all. So you can plug and play any type of functionality into your application. If a third-party component won’t work as well, according to the vendor, you should be asking them: why not? Are they doing something non-standard behind the scenes, that would become obvious if you use someone else’s components? Are they denying external access to some shared infrastructure like an analytics data store? Or are all of their components actually one big inseparable monolithic engine under the covers?

Now, you’re going to need some capabilities as well, that just aren’t offered by your platform vendor, and this is really where best of breed becomes important. And these are usually things that are specific to your industry. So let’s say you found a great AI-driven chatbot for insurance claims, that you want to integrate into your claims application. Or a SCADA component that integrates with industry processes and physical machinery for running your manufacturing plant. You want to be able to locate any of these components in service directories and marketplaces, then plug them right into your applications. Now, I really believe that creating enterprise-strength applications that are still lightweight and agile relies on avoiding monolithic environments. Select the best low code environment for your application builders, select the best analytics platform, the best process automation, the best decisioning, the best artificial intelligence and machine learning, any other components for your particular needs. Then use that low code environment to compose them into applications. As you build those applications, figure out what other capabilities that you need, and add those. If a component no longer serves your needs, then replace it with a more appropriate one, possibly from a competitor and with cloud-based environments. You don’t even need to worry about where the component exists. Only that it performs when you call it, using that standard REST interface.

I’m going to continue on the composability topic for at least one more video. In the next video I’ll talk about the difference between low code and model driven for composability, because there’s a difference and there’s a lot of confusion over that. That’s it for today, you can find more of my writing and videos on the Trisotech blog or on my own blog at column2.com see you next time

Blog Articles

Sandy Kemsley

View all