About four months ago, Red Hat announced that it was acquiring 3scale. (Almost two years ago, Red Hat and 3scale announced a joint solution relationship for 3scale’s API Management Platform and Red Hat’s Middleware portfolio.) As the acquisition settles in, 3scale is already starting to integrate with middleware products, which will strengthen developers’ abilities to design and implement API initiatives and services.
This first point of integration is between the 3scale Management Platform and Red Hat Single Sign-On: more specifically, for the developer portal authentication.
Continue reading “Seamless developer portal authentication with 3scale and RHSSO”
Enterprise goals, the portfolio, work, and investment decisions should all be based on measurable business outcomes. Business outcomes generate metrics, the way to measure value. The key is to standardize the way the enterprise measures business value.
Business Value Standards can help guide the right decisions for the portfolio, based on the work that can generate the most value. The standards list in the table provides six primary business value types with the associated examples and metrics.
Business Value Type
Generate New Revenue
Net new sales, improve lead conversion rates or reduce sale cycle time, improve up-sell/cross-sell
Increase revenue by X currency
Reduce costs for licensing, managed services, maintenance support contracts costs, retire legacy platform, reduce workforce needs due to automation or reduced skills needed
Reduce costs by X currency
Automate or eliminate a process step or task, reduce cycle time or manual hours
# of hours * estimated hourly cost * quantity
Improve Service Delivery
Improve service delivery by reducing cost of performing a service
Reduce cost per day, per hour, or per service
Mitigate Business Risk
Implement new security systems or disaster recovery solutions
Benchmarked industry risk analysis data with (ROM) risk scenarios
These example metrics help define how to measure the results from prioritization of items within the portfolio. The performance of the portfolio is based on the business value results that are realized by successfully executing on business objectives.
One of the challenges of IT management is to balance the enterprise portfolio with initiatives that deliver on objectives and outcomes with varying timeframes and differing investment categories. Yet this balance is key to run, grow, and transform the business now and over time.
Balancing the enterprise portfolio is important to deliver on initiatives within short (within the fiscal year), medium (1 to 2 years) and long (over 2 years) timeframes. This is part of the advice for a lean startup.
Source: Gartner PPM & IT Governance Summit 2016 – Secrets of Prioritizing IT Demand – Audrey Apfel
Continue reading “Portfolio Management: Balancing the Portfolio”
To effectively plan and execute a technology-driven service or product offering, IT and business leaders should start with business architecture. Business architecture is the essential building block for mapping an organization’s business vision of what they want to accomplish. Business architecture is one of the four enterprise architecture domains – including data, applications and technology.
Continue reading “Data and Architecture Simplified, pt. 3: Business Architecture – The Core Diagram”
It was a great day in Minneapolis! The Microservices with Apache Camel was held at Target Field (inside the ballpark, overlooking the field of play). “Takes a lot to put together an event like this but can certainly be a lot of fun! Go microservices!,” says Red Hat associate Jen Fissel.
I had the privilege of hosting the event and kicked off the event with a reference to the connected world we live in that requires enterprises to be agile while being integrated across the systems of yesterday with the evolving applications of the future. The future of Enterprise IT, containers, are here today and microservices are the stars of the show. Welcome to Minneapolis!
Continue reading “It’s a great Red Hat day in Minneapolis — Go Microservices !”
Does your organization need to reduce costs and improve efficiencies? Start with a process-first approach. Before you dive into what software tool to implement or select a new solution to address a business challenge, understand your existing business processes. What steps does your organization take within the business processes? Are things manual? Can you automate and improve the way you do business?
Continue reading “Data and Architecture, pt 2: Process Improvement”
The way the MEAP works is that every month or so Manning puts a new chapter online. As of this week chapter 5 is available and those already in the MEAP will have access to start reading the chapter.
This is a large chapter and it is one of the harder topics to confine to a single chapter. I do expect to split this chapter up in the future so that you have the basics and then more advanced topics regarding learning to effectively implement your business logic with JBoss BPM.
To give you an idea of what’s available so far:
You can read this excerpt online before you decide, but I look forward to hearing from you on the content and stay tuned for more.
Your business needs to better use its data — but what does that mean? Context matters. Data governance, reporting and analytics, business intelligence. When you approach your data architecture, first start with asking the right questions that solve business challenges. What data does the sales team need to increase sales by x %? What data does the engineering team need to work on and innovate products that provide competitive advantage?
Similar questions have inspired companies to disrupt markets. Uber started with asking questions like, how can we optimize drivers at the right locations with the most customer demand? How can we give consumers the ability to call a cab with a click of a button? Tomasz Tunguz highlights similar examples in his book Winning with Data, where he states that “the best data-driven companies operationalize data.” To operationalize data is where companies can use the right data to rapidly change the way they operate.
In order to use the right data, ask the right questions. Gartner states exactly this, “Ask the right questions” in the 2015 article Big Data Analytics Failures and How to Prevent Them. Simply, what problem or toughest business challenge is your company trying to solve with data?
At the foundation and beginning practice of enterprise architecture, dating back to the 70’s with the Zachman Framework, the principle question related to data was “what data is needed to list the things most important to the business?” The framework focuses on the “what”, what is needed, in order to produce the right enterprise, data and technology models for the best use of data.
In order to harness the “Power of Data”, HBR suggests that companies start with the business problem in mind, and then “seek to gain insights from vast amounts of data.” With stating the specific business problem, companies can narrow the search and refine how they are going to find data-driven answers to their most challenging business problems.
Some of the biggest technology trends aren’t necessarily about doing something new. Things like cloud computing (as an environment) and design patterns for the Internet of Things and mobile applications (as business drivers) are building on existing conceptual foundations — virtualization, centralized databases, client-based applications. What is new is the scale of these applications and the performance expected from them.
That demand for performance and scalability has inspired an architectural design called distributed computing. Technologies within that larger umbrella used distributed physical resources to create a shared pool for that service.
One of those technologies is the purpose of this post — in-memory data grids. It takes the concept of a centralized, single database and breaks it into numerous individual nodes, working together to create a grid. Gartner defines an in-memory data grid as “a distributed, reliable, scalable and … consistent in-memory NoSQL data store[,] shareable across multiple and distributed applications.” That nails the purpose of distributed computing services: scalable, reliable, and shareable across multiple applications.
Integration is one of those concepts that is easy to “know,” but becomes less obvious that more you try to define it. A basic, casual definition is making different things work together. The complexity, though, comes from the fact that every single part of that has to be broken down: what are the “things,” what are they doing that makes them “work together,” how are they working, and what is the goal or purpose of them working together. All of those elements can be answered differently for different organizations, or even within the same organization at different times.
An understanding of integration comes from looking at the different potential patterns that you can integrate and then defining the logic behind the integration so you can select the right patterns for your environment.
Integration itself is an architectural structure within your infrastructure, rather than an action or specific process. While getting various systems to work together has long been an IT (and organizational) responsibility, integration as a practice became more of a focus in the early 2000s. With emerging large-scale enterprise applications, there became a growing need to get those applications working together without having to redesign or redeploy the applications themselves. That push became integration.
Integration is subdefined by what is being integrated; these are the integration patterns.
There are different types of patterns, depending on perspective. There are patterns based on what is being integrated and then there are patterns based on the topology or design of the integration. Basically, it’s the what and the how.