Last week I introduced key agile concepts including the history of and essential roles required for Scrum practices. I described a real-world example of how DevOps could have saved my organization major headaches and expenses.
In Part Two of this post on using agile Scrum methodology within DevOps ecosystems, we'll examine the Four Values of Agile and learn how to change your organizational mindset to accommodate this new paradigm.
In early 2001 I was involved in a software development project on integrating bolt-on application to a JD Edwards ERP software platform. The team completed the initial requirements collection and developed a comprehensive Business Requirement Document (BRD), investing roughly two to three months. The team had multiple review sessions to identify gaps in the requirements process and after a few cycles received approvals to proceed to the development phase.
While development was in progress, some of the EDI-based vendor data sources changed the mapping. This situation created chaos in the project. The management team decided to hold off the development phase. The project had to go through the requirements cycle again to identify the gaps. This situation impacted the schedule and budget, creating massive frustration in the organization. The first six months of the project investment was on hold. The sequential software development process we followed did not allow the flexibility to deliver any incremental value to the organization since the beginning of the project.
If we had followed an agile approach, this challenging outcome might have resolved in a different manner. The short intervals of development would have produced incremental value to the organization. Therefore we would have minimized the organizational concerns of not providing any value for six long months.
Here's how agile practices, Scrum, and DevOps all work together. Learn how to overcome adoption obstacles and several keys to Scrum success in this two-part blog series.
Hybrid cloud management spans beyond setting up your IaaS environment. The majority of enterprises use a mix of on premises infrastructure (both legacy and newly deployed) and cloud-based resources. Often a major hurdle remains: applications that are not ready to connect to the cloud.
Enter Integration as a Service. We know, we know. Everything as a Service overload! This emerging field involves a vendor who can help architect enterprise IT apps to work across on premises and cloud environments, complete with real-time exchange of data.
How does Integration-a-a-S work and what should you expect from a cloud integration provider?
As you transition towards CloudOps, DevOps, DevSecOps, and general continual iteration and continuous improvement type IT management strategies, there are a number of common mistakes you’ll want to avoid.
DevOps at all costs is not going to provide any additional business value. Nor is it likely to be great for your IT team morale. Make sure you keep in mind these three common DevOps pitfalls as you evangelize and adopt DevOps practices throughout your IT department or larger organization.
DevOps practices have moved past pure software development and into enterprise adoption, facilitating faster updates to applications and associated infrastructure.
The crux of DevOps is the unification of tools and processes between development and operations teams to decrease time to market/deployment and implement continuous improvements throughout the development, testing, implementation, and ongoing maintenance of applications and underlying infrastructure.
Despite widespread DevOps adoption — or at least the majority of surveyed enterprises reporting they have started the journey towards it — many organizations are still struggling. Enter DevOps as a Service. But is DevOps as a Service a legitimate offering? The definition is still evolving, and different MSPs may offer different takes on DevOps-a-a-S.
While microservice application architecture dates back to 2011, enterprise IT tends to move relatively slowly when it comes to the adoption of new technologies. The concept and methodology has been refined in concert with the rise of cloud computing, and now microservices are a popular way to build, deploy, and most importantly scale applications.
Microservices can improve your agility, security, and resiliency, but they require a major adjustment to your development team’s workflow and the architecture of your application itself. Read on to learn the advantages of microservices and potential caveats for their use.
Let’s be honest, most of us who play individual games like golf are cheaters. We don’t play by the rules of the game 100% of the time. OK, labelling ourselves cheaters may be a harsh indictment of our collective scorekeeping.
As an information management executive, you (and by extension, your team) need broad and deep insights into the performance and security of your data management infrastructure. This is the case whether your business applications reside on five servers, fifty, or five hundred.
The holidays are looming, meaning many DevOps teams are about to have their apps take a beating as hundreds of holiday orders and new device users slam them all at the same time. Whether or not your systems are consumer-focused, there will eventually come a time when the overall load on your servers is pushed to the limit.
Load testing applications in the cloud allows development and testing staff to perform scale testing to see at what point virtual machines need to scale, when to add additional resources like storage or bandwidth, and when a failover solution might be necessary.
By thoroughly performing load tests throughout the DevOps process, your organization eventually lowers costs and your team doesn’t have to scramble during a major event. Here are some best practices when performing cloud-based load testing.
While your admins might have virtualization experience, transitioning to a cloud-first IT strategy involves a real paradigm shift across your entire IT team. You’ve heard some of this before: you’ll be more agile, your team will be focused on service delivery instead of hardware, you’ll work on business issues rather than break/fix.
What you may not have considered are how the roles of your new cloud team may shift from previous responsibilities, or just how far reaching the culture change may be. Here are some tips to build a successful cloud service team within your organization.
