Red Hat conceived the agile integration concept to help our customers tackle integration challenges more effectively. As we described in an earlier post in detail, agile integration is an architectural approach centered around application programming interfaces (APIs) and API management. At its core, this concept resides on the following three pillars: distributed integration for greater flexibility, containers for the ability to scale better, and managed APIs for re-usability and hence speed.
When we started designing this concept we actually started from two premises:
- Agility today is the most important business capability — especially for incumbents in traditional markets.
- Every organisation has integration problems.
Typically in most companies nowadays the integration function is centralized and hence technically as well as organizationally a bottleneck. Our two premises contradict each other and we set out to design an integration concept that can solve this contradiction.
In order to come up with a solution that really helps our customers solve their integration problems in the best possible way, we first analysed the market to understand what actually are the problems that users are trying to solve. Although there are of course a very wide variety of often very fine-nuanced problems, it turned out that we could classify all the problems into six typical integration challenges. The following diagram summarizes these challenges and we then discuss each of them in more detail.
Continue reading “Six typical integration challenges that agile integration can solve”
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?”
In an earlier blog, we wrote about how very low latencies in Java-based microservices can be achieved through our plug-in wrapper. That solution was general in nature, applicable to any API service.
In this blog, we show that the plug-in wrapper is applicable to a specific microservices framework – the open source microservices framework Light-4-J. In particular, we took an implementation of a microservices chaining tutorial, built upon it, and applied our Java plug-in wrapper API management component to it.
As we stated in our first blog, this approach may be well used for a particular use-case, i.e. internal API traffic, typically microservice to microservice. Services exposed to external parties, outside the DMZ, can continue to use the API gateway deployment for its routing and security capabilities. And indeed this differentiates Red Hat 3scale from other vendors in that both the plug-in deployment and the gateway deployment are feasible.
Figure 1 – Plug-in approach: API Management intelligence and configuration are decoupled from traffic enforcement and reporting
Continue reading “Low Latency API Management for Microservices framework Light-4-J – with Red Hat 3scale”
The Future-State Business Capability Model How-To is a series to help IT and architecture practitioners think about a few key steps to build a future-state business capability model to influence business and technology senior leaders and executive decision makers. Part 1 ran last week and looked at the first two steps to creating a strategy-defined project planning model: understanding the goals of the organization and determining the architectural scope model to use. This post explores the steps to actually defining and implementing your planning model.
Step 3: Define the plan to develop your future state capability model
- Determine if your organization requires a current state capability model. If your organization does not have a current state capability model, this may be an easier exercise to initiate dialogue and understand the concept.
- Identify how the corporate goals and strategy are applicable to the future state lifecycle. If required, translate the corporate goal to the applicable lifecycle. For example, a Corporate Revenue Goal can be translated into order transaction volume, number of newly hired associates, number of marketing campaigns or new product launches.
- Determine your standard definitions to categorize your capabilities. For example, Core vs. Differentiate is a foundational interpretation. Determine what capabilities are “core” (something required to keep our business running) vs “differentiating” (something that has a direct impact on our growth). This is a helpful reference for modeling: CEB’s Business Architecture Handbook.
Continue reading “Data and Architecture: Business Capability Future State How-To, Pt. 2”
Does your organization need to improve strategic investments and prioritize investments? Do you feel confident in the objectivity of your investment and spend decisions? Are you constrained with annual budget allocations and have to make tough decisions year-over-year with running the business work or “keeping the lights on” versus transformational projects?
Establish a process to integrate an environment of many complex organizational capabilities to simplify and inform specific business outcomes through a future-state business capability model.
Portfolio Planning Prioritization 1.0 (in our blog series) features a way to prioritize investments from a “bottoms-up” perspective, as featured in the figure. The prioritization model identifies current or upcoming projects based on strategic drivers (key elements that align to organizational strategy, key portfolio data, and business value/outcomes) and detractors (elements that reduce value based on longer time periods, cost, and organizational readiness). Although this model is a good way to make data-driven prioritization decisions for the portfolio, it does assume that the organization has identified the critical must-have business capabilities needed to advance the business.
Continue reading “Data and Architecture: Business Capability Future State How-To, Pt. 1”
Happy Friday, everyone.
As we kick off spring break season, let’s look at something a little lighter and happier: the gaming side of technology. Consumer design can be a huge driver even for enterprise technology; the simple UX of Apple products is now influencing design and experience expectations for backend systems. From nostalgia games to astronomical artwork, there is a lot of interesting stuff going on in the world. One of my favorite lines from Graceland (seriously, Paul Simon rocks, people): “These are the days of miracles and wonder.”
Continue reading “Five Links: Fun and Games Edition”
To effectively prioritize an organization’s collection of work, including operational services and projects to support products and innovation, leading organizations develop standard evaluation criteria to make data-driven decisions. These data-driven decisions help leadership make the right investments and ensure the organization is working on the most impactful work to improve competitive advantage. An organization’s decision makers should build simple and clear data requirements to enhance decision making and to better inform leadership and stakeholders.
Portfolio planning is the alignment of an organization’s corporate strategy to data-driven decisions about capabilities and resources to achieve desired business outcomes. Effective portfolio planning and management capabilities should provide the organization with dashboards, reports, and analytics to inform better decision making.
Continue reading “Data and Architecture: Data-Driven Portfolio Decision Making”
Happy Friday, everyone.
Red Hat has a lot of corporate blogs (worth reading!), but a huge part of our culture as a company is collaboration and meritocracy. As in … letting our opinions be known. There’s a reason we actually made a t-shirt to commemorate our corporation-wide mailing list.
A lot of Red Hatters have personal blogs (or active LinkedIn postings) precisely because of the value that we as a group place on transparency, defending ideas, and innovation.
This week, I want to highlight some of the blogs by Red Hatters that I’ve read recently. I’m not even going to call this a “top 5,” because we have a lot of prolific and interesting writers on a million different topics. These are a random sampling of the blogs that I hit periodically.
Continue reading “Five Links: Band of Brothers Edition”
Happy Friday, everyone.
When I was a reporter in Livingston, Montana, I wrote a story about a massive infrastructure campaign that was just kicking off — new sewer and water lines across town, changing traffic flows and redesigning streets, new green spaces and public art. I interviewed the primary architect, and he told me that the designs were influenced by A Pattern Language, published in 1977. That book has fascinated me; from the placement of a single window to the layout of an entire central business district, it breaks down the patterns of human behavior and then analyzes design techniques that best reinforce the desired patterns for a given space. It doesn’t say what should be done; it simply uses patterns to say if you want to accomplish Goal A, use Design Technique B.
In a roundabout way, this week’s series of links look at patterns and how they influence behavior.
Continue reading “Five Links: Pattern Recognition Edition”
In this article, we provide a solution that enables almost latency free API management for Java-based microservices APIs. We build on Manfred Bortenschlager’s white paper Achieving Enterprise Agility With Microservices And API Management. We provide a practical solution for adding the management layer Manfred outlines to internal microservice-to-microservice API calls.
API Management and Microservices
Figure 1 – a typical microservices architecture with depictions of externally and internally consumable microservices
In the white paper Manfred describes a typical microservices architecture consisting of:
- A perimeter service layer that is typically implemented by an API gateway which manages and secures components that follow the backend for frontend (BFF) pattern. The perimeter service exposes APIs to external consumers.
- Internal microservices that are clustered into functional elements and communicate via APIs.
The most common and most decoupled way to achieve API management is through deployment of API gateways on the API provider’s infrastructure. These gateways act as traffic controllers which authenticate, authorize, and report on API traffic to the 3scale API Management Platform. These extensive management features are achievable with very low latency overhead through our caching and asynchronous architectural features. Additionally the gateways provide excellent routing and security protections such as defense against DDoS attacks and more.
Continue reading “Ultra Low Latency API Management for Microservices with Red Hat 3scale”