Building an API-Based Connected Healthcare Solution: Q&A Followup

Christina Lin (a technology evangelist for Red Hat) and Sameer Parulkar (middleware product marketing manager for Red Hat) conducted a webinar earlier this week about data integration challenges which specifically face healthcare providers. As promised, this is a brief roundup of the major questions that came out of the webinar and pointers to more detailed information about the demo. (If you would like more background on integration challenges in healthcare, we do have posts on integration architecture for healthcare and another on how to overcome integration challenges.)

A Quick Summary

The recording of the full webinar is available here, but I’ll summarize it briefly if you can’t watch it yet.

Continue reading “Building an API-Based Connected Healthcare Solution: Q&A Followup”

Upcoming: Architecture Designs for Camel Developers

Bilgin Ibryam, a senior architect with Red Hat, will be conducting a webinar about design patterns for new architectures like microservices, IoT, and SOA — which Apache Camel developers can use to be more effective in their coding.

Apache Camel itself is based on defined set of design patterns for messaging and integration. This makes Apache Camel a natural framework for designing microservices and IoT applications, which are inherently distributed computing systems. However, developing applications in Camel requires layers of design decisions, because effectively isolating computing components requires a clear understanding of how they will be interacting. This webinar will call out commonly used patterns and design principles for Camel application development, based on real-world examples. This covers a variety of principles, from error handling to complex, multi-route applications, scalability, and high availability.

Registration is open. The webinar is Tuesday, June 7, at 11:00am Eastern Time (US).

register_now

Fun Follow Up: Webinar Q&A

I will collect any questions asked during the webinar, and I’ll do a follow-up post on Friday, June 10, to try to capture the most interesting (or confounding) questions that arise.

Defining A New Value for IT

One trending phrase for CIOs is digital transformation. While the phrase itself has an easily-discerned meaning (digital technologies are changing the way that businesses operate), it is a superficial simplicity. Since every organization has a unique culture, product, and customer set, the ways and means that those organizations will digitally transform is also unique. In a real sense, digital transformation is less about technology and more about culture change.

CIO_ITAccomplishment_4

Although it steers clear of the trendy buzzwords, this kind of culture change is at the heart of the whitepaper and Society for Information Management presentation by Jason Daube and Matt Lyteson of Red Hat IT.

The practical effect of digital transformation is that IT is no longer a back-office department. IT priorities — and IT challenges — now have a strategic impact on business priorities. WHat Daube and Lyteson outline is a high-level approach to aligning IT objectives with business objectives.

Of course, the whole thing is worth reading. For this post, I just want to touch on the foundational layer that they identify: creating an IT-business partnership.

Continue reading “Defining A New Value for IT”

Intro to the Internet of Things

According to a 2014 Forbes article (actually, the autoplay video on the article), 87% of people had never heard the term “the Internet of things.” That has changed rapidly in the last two years (research firm 451 Research pegs 2016 as the year that the Internet of Things goes mainstream). Still, as with many cloud computing concepts, IoT is a vague term.

A Simple Description of the Internet of Things

Consumer-centric devices have emerged over the last forty years, from ATMs to inventory tracking in vending machines. Smart phones were a massive jolt, introducing a new means to connect to and interact with both consumers and physical objects. That networked, digitized environment of physical objects is the Internet of Things. 451 Research had a fantastic term for it: the Internet of things “virtualizes the physical world.”

Continue reading “Intro to the Internet of Things”

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”

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.