Effective Case Management within a BPM Framework

In real life, organizations have workflows which may not fit into prescribed, sequential process path or which require human intervention or approval before the entire process can be completed. Within the business process world, more unstructured and unpredictable work is handled through case management rather than process management.

There are slightly different standards defined for case management and process management, which reflect the differences in the types of process flows and data being handled in each type of model.

But the question for business architects is which standard to use or whether to try to balance both — and then for developers to try to create models on different or shared development platforms.

A Quick Comparison of CMMN and BPM for Development Standards

First, it may be helpful to explain why there is a difference between business process management and case management. Both models are defined by two separate specifications, Business Process Model and Notation (BPMN) and Case Model and Notation (CMMN), respectively.

Continue reading “Effective Case Management within a BPM Framework”

Announcing AMQ Streams: Apache Kafka on OpenShift

Cross-posted from the Developers Blog. See the session at Red Hat Summit on Apache Kafka and AMQ data streams on Thursday, May 10, at 11:15.

We are excited to announce a Developer Preview of Red Hat AMQ Streams, a new addition to Red Hat AMQ, focused on running Apache Kafka on OpenShift.

Apache Kafka is a leading real-time, distributed messaging platform for building data pipelines and streaming applications.

Using Kafka, applications can:

  • Publish and subscribe to streams of records.
  • Store streams of records.
  • Process records as they occur.

Kafka makes all of this is possible while being fast, horizontally scalable and fault tolerant. This makes Kafka suitable for a large range of use cases, including website activity tracking, metrics and log aggregation, stream processing, event sourcing, and IoT telemetry. The forthcoming AMQ Streams product will provide Red Hat customers with a supported offering for running Apache Kafka on Red Hat Enterprise Linux and on Red Hat OpenShift Container Platform.

As more and more applications move to Kubernetes and OpenShift, it is increasingly important to be able to run the communication infrastructure on the same platform. OpenShift as a highly scalable platform is a natural fit for messaging technologies such as Kafka. But with AMQ Streams, our target is not to just run Apache Kafka on OpenShift, but rather AMQ Streams makes running and managing Apache Kafka “OpenShift native.”

Uniting the massive scalability of Kafka on an elastic platform like OpenShift involves resolving a number of technology challenges:

  • Kafka brokers are inherently stateful, because each has its own identity and data logs that must be preserved in the event of restarts.
  • Updating and scaling a Kafka cluster requires careful orchestration to ensure that messaging clients are unaffected and no records are lost.
  • By design, Kafka clients connect to all the brokers in the cluster. This is part of what gives Kafka its horizontal scaling and high availability, but when running on OpenShift, this means the Kafka cluster cannot simply be put behind a load-balanced service like other services. Instead services have to be orchestrated in parallel with cluster scaling.
  • Running Kafka also requires running a Zookeeper cluster, which has many of the same challenges as running the Kafka cluster.

AMQ Streams simplifies the deployment, configuration, management and use of Apache Kafka on OpenShift using the Operator concept, thereby enabling the inherent benefits of OpenShift, such as elastic scaling. An Operator is an application-specific controller that extends the Kubernetes APIs and combines them with domain-specific knowledge and makes it easy to run and manage complex applications.  Developers and administrators used to OpenShift’s declarative approach to resource provisioning can now enjoy those same benefits when working with Kafka, Kafka Connect, and Kafka topics.

AMQ Streams makes it easy to:

  • Deploy a complete Kafka cluster, at the scale that suits you, with the click of a button or with a single oc create command.
  • Deploy the Kafka topic right alongside the microservice that uses it.
  • Scale up the partitions of that topic.
  • Trivially scale up and and down the Kafka cluster according to load.

Strimzi Logo

AMQ Streams is optimized for running on OpenShift (as opposed to regular Kubernetes). Not only does it benefit from Red Hat’s years of experience and in-depth knowledge gained from developing and running OpenShift, but there is, for example, special support for building Kafka Connect clusters with the user’s own Kafka Connect plugins. Further, OpenShift-specific features and Red Hat product integrations are anticipated, with the overall aim being a seamless experience with full support from the OpenShift fabric up.

Unsurprisingly, because Red hat is the world’s leading provider of open source technologies for the enterprise, AMQ Streams is fully open source and based on the Strimzi project.

The Developer Preview, which is being made available to interested customers this week, provides the foundation for running Kafka on OpenShift. Interested customers and other interested parties are invited try it out, give us their feedback and, if desired, collaborate on the open source Strimzi project to help shape the future direction of AMQ Streams on OpenShift.

If you’re lucky enough to be in San Francisco this week for Red Hat Summit, then you can hear a lot more about AMQ Streams (and the broader Red hat AMQ product) at the following sessions:

  • Running data-streaming applications with Kafka on OpenShift
    Tue May 8, 1:00 PM–3:00 PM, Moscone South 156
    Marius Bogoevici, Paolo Patierno, Gunnar Morling [L1099]
  • Red Hat AMQ overview and roadmap
    Wed May 9, 11:45 AM–12:30 PM, Moscone West 2011
    David Ingham, Jack Britton [S2802]
  • Introducing AMQ Streams—data streaming with Apache Kafka
    Thu May 10, 11:15 AM–12:00 PM, Moscone West 2014
    Paolo Patierno, David Ingham [S1775]
  • Red Hat AMQ Online—Messaging-as-a-Service
    Thu May 10, 1:45 PM–3:45 PM, Moscone South 214
    Ulf Lilleengen, Paolo Patierno [W1098]

We expect to release further previews as we iterate towards the general availability release, which is planned for later this year.

Please give it a try and let us know what you think.

 

Red Hat OpenShift Application Runtimes: Delivering new productivity, performance, and stronger standards support with its latest sprint release

Red Hat OpenShift Application Runtimes is a collection of cloud-native application runtimes that are optimized to run on OpenShift, including Eclipse Vert.x, Node.js, Spring Boot, and WildFly Swarm. In addition, OpenShift Application Runtimes includes the Launch Service, which helps developers get up and running quickly in the cloud through a number of ready-to-run examples — or missions — that streamline developer productivity.

New Cache Booster with JBoss Data Grid integration

In our latest continuous delivery release, we have added a new cache mission  that demonstrates how to use a cache to increase the response time of applications.  This mission shows you how to:

  1. Deploy a cache to OpenShift.
  2. Use a cache within an application.

The common use case for this booster is to cache service result sets to decrease latency associated with data access as well as reduce workload on backend service.  Another very common use case is to reduce the data volume of message send across in distributed system.

Continue reading “Red Hat OpenShift Application Runtimes: Delivering new productivity, performance, and stronger standards support with its latest sprint release”

The Role of Agile Integration in Open Banking

In the mid 90s, Bill Gates famously said that “banking is necessary, banks are not.” There is certainly a lot of truth in this statement. We all need banking services in some shape or form. But who delivers these services to us is secondary. In fact, Accenture concluded in a study conducted in 2016 asking over 30,000 people in 18 countries that if the tech titans like Google, Amazon, or Facebook would offer such services, 31% of the respondents would switch to them. This clearly imposes a significant threat on traditional banking institutions.

Another challenge that banks are facing worldwide are the increasing demands for regulatory compliance with respect to openness. Such regulations include, for instance, Payment Services Directive 2 (PSD2) in Europe, the Amendment Bill to Japanese Banking Law in Japan, the National Payments Corporation of India (NPCI) with the Unified Payment Interface, UK’s Open Banking standard by the Competition and Markets Authority (CMA), or the Open Banking Regime by Australia’s Federal Government. Banks approach these regulatory challenges in many different ways. Some see it as a serious business threat and only do the bare minimum for compliance; others see it as an opportunity and with smart investment start building banking platforms for the future.

Our suggestion for building the banking platform of the future resides on the principles of agile integration, which is an architectural approach centered around application programming interfaces (APIs) and API management. At its core, agile integration resides on the three pillars: distributed integration for greater flexibility, containers for the ability to scale better, and managed APIs for re-usability and hence speed. We described the details in an earlier post.  

Continue reading “The Role of Agile Integration in Open Banking”

The State of Microservices Survey 2017 – Eight trends you need to know

During the fall of 2017, we conducted a microservices survey with our Red Hat Middleware and Red Hat OpenShift customers. Here are eight interesting trends discerned by the results:

1. Microservices are being used to re-architect existing applications as much as for brand new projects

There seems to be a strong emphasis in the market by technology vendors for positioning microservices as being only for new projects.  However, our survey reveals that organizations are also using microservices to re-architect existing and legacy applications.

Sixty-seven percent of Red Hat Middleware customers and 79 percent of Red Hat OpenShift customers indicated this. This data tells us that microservices offer value to users all along their IT transformation journey — whether they are just looking to update their current application portfolio or are gearing up new initiatives. So, if you are only focused on greenfield projects for microservices, it may be a good idea to also start evaluating your existing applications for a microservice re-architecture analysis. Microservices introduce a set of benefits that our customers have already started seeing, and they are applying these benefits not just to new projects but to existing ones as well.

Continue reading “The State of Microservices Survey 2017 – Eight trends you need to know”

Eclipse MicroProfile 1.2 is Now Available

Eclipse MicroProfile, an open forum to collaborate on enterprise Java™ microservices, today announced the release of Eclipse MicroProfile 1.2.

Eclipse MicroProfile 1.2, which builds on the 1.1 version, updates the config API and adds the health check, fault tolerance, metrics, and JWT propagation APIs.

Continue reading “Eclipse MicroProfile 1.2 is Now Available”

What is agile integration?

If you Google the term “agile integration,” you’ll come up with about 30 million results, but they focus heavily on one area: continuous integration within agile development. That definition of agile integration is based on the build environment.

However, it is possible to have another definition for “agile integration,” one that looks at the platform architecture.

In this definition, “agile” doesn’t relate to the process or the infrastructure, but to the flexibility and adaptability–the agility–of the application architecture. Integration within this context has a more strategic role, as the architectural framework that defines the interoperability of services and with a focus on the application functionality.

Traditional vs. agile as an architectural approach

There are functional similarities between traditional integration and agile integration – like routing, connectivity, and orchestration capabilities. The difference between traditional enterprise application integration and agile integration is not in the tasks performed, but in the strategic perspective of those tasks. Put simply, integration can be viewed as a necessary but often limited part of the infrastructure (traditional) or it could be viewed as the core framework of the application architecture (agile).

Continue reading “What is agile integration?”

The future of Java EE

At this stage the future of Java EE looks brighter than it has for quite a while as Oracle, working with Red Hat, IBM, other vendors and the wider community to move the specifications, TCKs and overall innovation to an open source foundation. I think in general most people in the Java community see this as positive but there are a few naysayers, even more of them in other non-JVM areas. The common thread throughout is along the lines of “who cares these days?” or “it’s far quicker and easier to accomplish the same things with framework X or language Y, anyway.” I’m not going to try to address all of the concerns which have been raised because many of the comments I’ve seen have clearly been subjective and bordering on click bait. However, I’m writing this piece to reiterate some things I’ve said over the years and which remain just as relevant today, in my opinion

I want to start though by saying that in all of this I am trying to remain objective. Of course in my current role I and Red Hat have a vested interest in Java EE but if you’ve known me long enough over the years you’ll know that I’m also a scientist and as such I base my opinions on observations and facts born out by those observations. If a fact or piece of data goes against a theory then I don’t ignore it, I review and likely update or replace the theory to match the facts. I’ve changed my opinion on many things throughout my career and I’m sure I will do so again.

OK so back to Java EE. Does this move to open source help the wider community? Is Java EE still relevant or has it had its day like so many technologies before it? I’m not going to link to other things I’ve written on Java EE and its future over the years as they’re easily searchable through your favourite engine. But in short, many people forget that Java EE represents an evolution of essential middleware capabilities which many mission critical applications require. It’s had a lot of bad press since its inception, some of it accurate and some of it less so. I think one of its big failings is that, like my favourite topic of transactions, it has been used and misused in environments where it wasn’t really appropriate. No stack or framework is going to be applicable to every problem space and of course developers are going to get frustrated if they try it and find it wanting and failing as a result.

Continue reading “The future of Java EE”

There is no magical OFF switch for legacy apps

I really dislike the term “legacy apps,” especially when it is used by vendors. It feels like they are calling my baby (i.e. my app) with a bad name.  I love the quote by Martin Fowler, “All we are doing is writing tomorrow’s legacy software today.”  I am certainly not advocating to stick to your old applications forever.  All applications and systems have a life-cycle that goes from build to retire. Somewhere in between lies the stage of renewing the capabilities of the system, often named as modernization, enhancement, or rehab. This is the most important phase from the perspective of extending the life of the application and enhancing the long term value harvested from it.

In IT, each generational transition has called for modernizing and redesigning applications, business processes and IT infrastructure to exploit new technologies’ capabilities and efficiencies. App modernization isn’t carried out as a fashion statement or status symbol but for hard business reasons. Regardless of the era, the benefits of a periodic app overhaul include better performance, more features, greater usability, and higher reliability.

Continue reading “There is no magical OFF switch for legacy apps”

3 ways to effectively prepare for process improvements in your digital journey

In our journey to transform our ways of working, our focus on our customers wishes and our plans to pivot to a digital business there is always a need for process improvement.

While the transformation to a digital business can encompass many aspects that are new to your organization, there are always existing investments in technologies and processes that need to be evaluated.

Some can be modernized and migrated on to the new infrastructure that will support the digital business and others end up remaining in place as legacy systems of record.

One thing is for sure, evaluating existing business processes and looking to improve their effectiveness is going to be a necessary step. With that in mind, here are three ways to effectively prepare for process improvements in your digital journey.

1. Effective BPM theory

The first step in any journey is to plan effectively and gather as much information from the experts as you can. For this step you have many options, but the following example previews the open technology and tooling that will ensure you are ready to tackle process improvements.

 

Schabell_JBoss_front1

2. Inventory existing processes

Identifying the list of existing processes in a business, both automated and non-automated processes will be the next step on the journey.

Businesses have processes in place that might be automated in some form, but showing signs of age or lack of effective execution. Others might have partial automation and exhibit a need for further automation at the time of evaluation. Finally, there can potentially be processes in your business that are crying out for automation and are hindering other processes with their lack of automation.

Collect all this information for evaluation without regard for size, level of automation or making decisions on priority for the next step.

3. Short list processes

Now that you’re able to browse all processes in your organization, identifying the short list where quick wins on process improvements is critical to the project’s success.
Everyone wants to see gains and building momentum with processes that can be improved both quickly and effectively builds confidence. Identify processes that have impact, are visible and can be effectively improved without having major impacts to the existing architecture or business process owner perceptions. This will be different for every organization, but crucial to building success and ensuring a smoother transition on your digital journey.
Armed with these three guidelines you’re ready to effectively prepare for process improvements in your digital journey.