ICYMI: The Advisor Says Red Hat JBoss BPM Suite Is Mature and Covers All the Bases

The Advisor (subscription required) has some very nice words about Red Hat JBoss BPM Suite. What is apparently a pleasant surprise is the Suite part of BPM Suite.

bpm

JBoss has had its BPM project since 2003, jBPM. jBPM does business process modeling; at its core, it is a Java-based workflow engine. While it has a graphical editor (for more traditional, less technical business analysts), it also works with Eclipse, which makes it a business process tool specially adapted for Java developers to work with.

Red Hat JBoss BPM Suite, however, has expanded over the past few years to include functionality outside business process modeling, included but not limited to:

  • Rules modeling
  • Complex event process modeling
  • Business resource planning
  • Simulations and optimization

It’s not exactly bedtime reading (at 127 pages), but this reference architecture walks through the development process for a BPM application, including all of the different choices at each step and the reasoning for choosing a specific option. For a simpler look at the functionality, you can also see the JBoss BPM Suite data sheet.

 

* ICYMI: in case you missed it

The Core Value of Integration

There is a new Red Hat infographic that summarizes the benefits (and power) of integration. I am only using excerpts here because it is a large-ish infographic, and it’s definitely worth viewing the whole thing. This is just a taste. (Even better, download the underlying whitepaper; it is very much worth reading.)

value-fuse-integration

The headline-making numbers come down, not surprisingly, to cost-savings:

  • 488% ROI in three years
  • Payback in 8.2 months
  • Over $1.4 million in annual savings

The most interesting thing that I saw is definitely part of that headline, but it’s a smaller part of it — over half ($838,800) of those annual savings come from making your IT staff more productive. When an application is integrated, it requires about 41% fewer staff to maintain it. There is a lot a variation here (defining integration is a whole ‘nother blog post) but the idea of saving money, increasing individual productivity, and reducing the staff to maintain applications doesn’t necessarily translate into cutting costs or reducing staff. The power of that, the core value of integration as I read it, is reallocating those precious resources to different operations for your company. Instead of keeping your current apps running, you could have a lot more available people and space to try to do new things, to reinvest in what your company does and move forward.

That’s pretty cool.

A Commenters’ Debate on Java

There is “A Defense of Java” post over on DZone, which is an interesting enough post itself, by a guy from AppDynamics. What verges into very cool reading is the comment section (which made it DZone’s #1 commented article on Monday). There is a strong debate about the future of Java, other languages like Python and Node.js, and how major enterprises are building apps for high-traffic sites.

Finding Value with (Red Hat) Subscriptions

Your business has probably purchased a lot of proprietary software the same way it purchases any other goods – you buy product A and install it on machine B. There was something like a warranty period, where you may receive a certain level of support or a replacement for serious issues, but otherwise, it was just a good that was purchased. If it doesn’t meet your needs, you go out and buy something else – even if it is the same product just a version or two later.

But with open source, there’s a slightly different approach. There has to be. Unlike proprietary software, where the software is the product, with open source software, everything is already out there and available. And not just the end package; the sourcecode itself is freely available to your engineering department.

According to Gartner, 95% of companies are using open source software, so it is entirely reasonable to ask what are we purchasing?

What open source companies (like Red Hat) offer you isn’t a product; it’s an ecosystem of improvement and support.

A License Isn’t a Subscription

One thing to clarify – a software license is not the same thing as a software subscription.

Continue reading “Finding Value with (Red Hat) Subscriptions”

Intro to Scalability

Scalability is one of those words that can mean very different things to different people, even in the same context or the same project. It’s not so much nuanced as it is that the definition matters on perspective — scale can be different for different goals.

There will be upcoming posts on data virtualization, in-memory data grids, integration methods — all areas where an understanding of your current and future needs, resourcing, and loads are critical for planning. Going into those concepts, it helps to understand scale — not just “make it bigger,” but how you make it bigger and when and why.

Continue reading “Intro to Scalability”

Something Special, for Your Development Team

The Red Hat Developer’s Program has added something new: A developer’s subscription. For free.

Typically Red Hat subscriptions are associated with a system (physical, virtual, or cloud) to make it easier to audit where software packages are installed and how many subscriptions you need to purchase. Developer’s subscriptions work a little differently; they’re associated with a specific person, not a specific machine. This allows developers to have multiple systems running in their dev environment without being limited by available corporate subscriptions.

Some of the vital statistics for the developer’s subscription:

And More

The developer’s subscription covers Red Hat Enterprise Linux and its toolsets, but there is another toolset available that is critical for developers who are using container-based applications. That’s the Container Development Kit (CDK). Members of the Red Hat Developer Program can access the CDK in addition to the developer subscription. The CDK helps create containers which can run on Linux, RHEL Atomic, or OpenShift v3.

ICYMI: A Better App Server Translates into Better Productivity

In case you missed it, there is an infographic based on research from IDC that IDC and Red Hat released (executive summary), nicely illustrating the business value of Red Hat JBoss Enterprise Application Platform 6.

idc-value-of-jboss-eap

Continue reading “ICYMI: A Better App Server Translates into Better Productivity”

If All Men Were Angels…

If all men were angels, no government would be necessary.

James Madison made the case that no system is perfect precisely because people aren’t perfect. That was, admittedly, a defense of a political revolutionary moment, but it holds true in software design as well.

Mark Little, vice president of engineering for middleware at Red Hat, has a blog post on this topic this week on jboss.org. The entire post is terrific (and readably brief), but there are a couple of points worth highlighting. His premise starts with the idea of what causes (or devolves) a system into a monolith, and he points to this:

Lack of architect (leadership); the original architect(s) leave the project and those who come in to replace them (if they are replaced) can’t control the developers or perhaps don’t understand the architecture enough to ensure it remains “pure”. Likewise, different developers coming into the project to either add to or replace those there already, can dilute the group knowledge and understanding of the architecture, leading to unforeseen and accidental divergence from the original plan.

What leads to an inflexible, centralized monolith application is, ironically, a lack of central vision. Mark sums it up with a really good point about the risks in microservice architectures:

I believe in and understand the need for distributed systems composed of (micro) services. However, what worries me about some of the current emphasis around microservices is that somehow they will naturally result in a better architecture. That’s simply not the case. If you don’t put in to place the right processes, design reviews, architecture reviews, architects etc. to prevent or forestall a local monolith then you’ve no hope of achieving a good microservices architecture. [emphasis added]

This is such an amazing point, it bears repeating. There is frequently this unspoken, sometimes unrecognized, belief that The Next Good Thing will some how solve all of the issues of the Last Good Thing without requiring special effort. But there are no perfect systems — clear planning, good communication, good team processes are required no matter what architectural pattern you’re using to develop your applications.

 

“Tech Preview”: A Look at Wildfly Swarm

The story of Wildfly Swarm, from a business perspective, is kind of a story of microservices. Microservices are small, isolated, and focused service applications; as an architecture, microservices is an approach that decomposes larger systems into those smaller, focused, isolated services. These services talk to each other through a shared, common API, but are otherwise independent in design and deployment. Microservices, then, are frequently aligned with DevOps – which uses small, agile teams to quickly develop and push software for continuous integration (of systems) and continuous delivery (of software).

But what is Wildfly Swarm, in that context.

Continue reading ““Tech Preview”: A Look at Wildfly Swarm”

Intro to Microservices

An increasingly common buzzword in cloud computing is microservices. Like a lot of things associated with cloud technologies, a precise definition is difficult to find — and it can mean a lot of things to a lot of different people, depending on the context. Since this is a blog devoted to middleware issues, I want to define microservices within the context of that middle layer in computing, for application development.

A Definition

Microservices is an architectural approach for a software system. Meaning, it defines how individual services fit together and how those services are constructed (like, general constraints or best practices). What sets microservices apart from other architectural approaches is that it treats each service as a discrete and independent part of the architecture. That means that services themselves (within that system) have very clear definitions:

Continue reading “Intro to Microservices”