When Cigna developers needed to improve their application testing processes, they teamed up with Red Hat Consulting to implement agile methodologies. Iterative development has helped Cigna prioritize features based on customers’ needs, and as a result, the quality of Cigna’s software has improved.
In the video below, representatives from Cigna and Red Hat Consulting discuss how working together to instill behavior-driven development principles helped Cigna:
• Increase speed to market by aligning application delivery with customer expectations.
• Reduce risk by engaging subject matter experts and stakeholders in regular reviews.
• Sustain application quality by identifying and fixing defects early in project life cycle.
• Ensure on-time delivery and predictable performance.
Continue reading “Cigna becomes more agile with behavior-driven development”
Date: Thursday, August 1, 2013
Time: 16:00 UTC | 12:00 pm (New York) | 6:00 pm (Paris) | 9:30 pm (Mumbai)
Duration: 60 minutes
Your business analysts and application developers need to be on the same page to model, automate, measure, and improve their processes and policies. Miscommunication creates delays in delivery, increases costs, and compromises innovation.
Behavior-driven development (BDD) is an agile, customer-driven software development method that brings together subject matter experts, testers, and developers to improve the speed-to-market and quality of rules-based applications.
Cigna increased productivity and quality with BDD
In this webinar, Red Hat Consulting gives and overview of the BDD method, and Cigna, a global health service company, discusses how adopting BDD helped them transform their DevOps practice by:
Continue reading “WEBINAR: How Cigna builds better applications, quicker with agile testing”
by Satish Irrinki (Red Hat)
Increasingly in today’s world, data centers are moving towards software-defined computing, networking, and storage. IT infrastructure that supports the application and data workloads is moving from bare metal servers to cloud. While the most obvious justification for this shift can be summarized as increased efficiency, capacity utilization, and flexibility (to scale up or down), there are less obvious fundamental economic and financial principles in play that contribute to overall business stability of the organizations and lines of business (LOB).
Cloud computing has changed the cost structure of IT infrastructure. Historically, IT infrastructure was considered a capital expenditure (CapEx) that requires large upfront investments leading to higher fixed costs for the business. With the advent of cloud computing, primarily because of its pay-for-use billing model, IT expenditure shifted from fixed operating cost structure to variable operating cost (OpEx) model.
This shift not only decreases the need for larger cash flow requirements or, in lieu, higher liabilities on balance sheet (akin to capitalization of lease expenses) for the CapEx, it also reduces the volatility in the operating income for the business.
Continue reading “Cloud Adoption for Enhanced Business Stability”
by Jurgen Hoffman (Red Hat)
OpenShift is great! Developers can quickly start development on a new project. Just log into the web console, create a new application, select a gear and start coding. When you are done implementing a feature you push to OpenShift and after a few seconds you can admire and share your work with the whole world.
But there is more to consider when working with OpenShift. What if you develop in teams? Usually applications are not directly deployed into production. How can I implement a staging process harnessing the OpenShift Infrastructure? How do I know if my changes passed an Acceptance Test or failed it? How does a test team know which features have been implemented?
The answer to these questions are usually not easy, and every company has implemented their own set of processes to address these problems. Although some Organizations have automated some of their IT Infrastructure, there are still a lot of manual processes and changes involved when it comes down to taking a particular software release from development into production. On the other hand, the business stakeholders have a high interest into a fast and efficient Release process, because every day that my feature is not in production and available to my users, is lowering my ROI.
Continue reading “What if you could make DevOps easy and reliable?”
by Alan Hale (Red Hat)
The following article originally appeared here in the UK and here in Germany.
Who could have predicted the impact on mainstream businesses of data coming in via social media and mobile technology, the escalating importance of trends such as ‘big data’ or the move towards cloud computing that is now gathering momentum?
The sources of data coming into the enterprise IT infrastructure are proliferating, with new channels and touch-points constantly emerging at an unprecedented rate. Clearly, in an uncertain world, flexibility is a critical component of any business IT strategy.
With today’s customers choosing to interact through multiple channels, businesses are wasting time and budget ‘hand-carrying’ information from application to application, frequently without adding value at best and introducing human error at worst.
Continue reading “Building the intelligent enterprise: easy and inexpensive?”
by Satish Irrinki (Red Hat)
It’s a truism that adopting open source software (OSS) reduces costs, but that’s not all. Let’s make a deeper dive into the business value of adopting OSS and uncover how the adoption provides immense value at multiple levels of an organization. The value proposition for OSS can be attributed to three groups within an organization – Technical Buyers, Business Buyers, and Economic Buyers.
Technical buyers can be best described as the line managers who are operating under stringent budgets to do more with fewer resources. As a result they aim to reduce costs and increase efficiencies within their operating units. In a bid to increase their resources utilizations, the technical buyers seek to increase reliability and flexibility in their operations. To achieve these goals they use systems that are reliable, adhere to standard specifications, and low in cost.
The high level of collaboration and contribution within the OSS development model accelerates the number of features that typical open source software provides. Availability of source code allows the adopters to make custom changes and tailor the software for specific needs. The ability to reuse software components across the organization (develop once and use within multiple systems) reduces the unit cost of development. These virtues of OSS mesh well with the goals of technical buyers and make OSS a viable option when making technology decisions.
Continue reading “Business value of open source software”
by David Kang (Red Hat)
Cloud is not software, cloud is not hardware, cloud is not virtualization, and cloud is certainly not a panacea for broken IT. Cloud is an architecture: a set of fundamental tenets that have different implications at different levels of IT, from network, to hardware, to applications, and to the IT process itself. To say you have a cloud is to say that you have a cohesive architecture, technology set, and most importantly processes, that work towards a defined goal under a set of well-understood principals. Building your cloud is as much about defining your goals and governing principals as it is about investing in technology.
Building your cloud and consuming cloud services
Step one is defining your governing principals. This is a crucial step before embarking on your cloud journey as the policies and principals you define will help you navigate your journey through the rapidly expanding cloud ecosystem. This is also an opportunity to ask tough questions and examine what your principals and processes are, and why you have them. Process is ultimately about managing risk, so consider what risks are acceptable under your governance policies and weigh them against the potential benefits cloud can offer. Both Facebook and Google have adopted “deploy to production” models that seem to fly in the face of process conventions such as ITIL or RUP, yet somehow they seem to survive. The penalty for not doing this exercise is ballooning adoption costs, or failed rollouts all together.
Continue reading “Cloud Sniff Test: Cutting through the jargon”
by Zach Rhoads (Red Hat)
One of the core tenants of agile development is to focus on the tasks that are the highest priority and immediate need. This is sometimes referred to as “Just-in-Time” development. The idea is to focus on the tasks needed to ship the feature now and worry about everything else when it is actually needed. Another tenant that goes hand-in-hand with “Just-in-Time” is the idea of failing early. Basically, a team should know as early as possible if something is going to fail, that way the team does not waste time going down the wrong path. This means the team should develop a feature and solicit feedback in short cycles, allowing the team to quickly understand what works and what does not.
Continue reading “Reducing friction in agile development using cloud”