devopsy.kinsta.cloud

Category: Features

DevOps and Infor’s Journey to the Cloud

Infor, a leading provider of micro-vertical application suites, has introduced DevOps as part of an initiative to migrate its enterprise application suites to a cloud platform. The significance of this should not be lost. Infor is not a young, Web 2.0 unicorn that was born with DevOps DNA.   Infor is a 14 year old privately held software supplier with over 70,000 customers across multiple micro-vertical markets. Infor’s industry-specific applications are mostly deployed and managed on-premise. The move to a cloud based AWS platform is as much of a paradigm shift for Infor as it is for its diverse customer base.

Infor Labs Journey to the Cloud

Infor’s leadership team launched the company’s annual user conference last week with keynote details about Infor XI’s cloud strategy and partnership with Amazon Web Services.   CEO Charles Phillips explained the reasoning behind the move while COO Pam Murphy recounted the technical efforts behind the scenes. Both acknowledged the necessity of creating a function that would be dedicated to cloud operations. Standing in front of thousands of customers, Ms. Murphy described Infor Labs and how its DevOps practices would ensure that the right operating procedures were inserted into the development lifecycle. According to Ms. Murphy,   DevOps would bring “fully automated hands-free cloud operations that improves efficiency, effectiveness, consistency and security while reducing manpower requirements. “

Infor’s recognition of DevOps as a critical business success factor for its next generation of industry suites is impressive. Brian Rose, Senior Vice President of Infor Labs and a key member of Infor’s management team for the past nine years provided some insight. “The motivation behind developing and growing the DevOps team was driven by our ‘Cloud First’ strategy. Over the last 18 months, Infor underwent a significant transformation to deliver industry solutions in the cloud. This required development teams to gain a new understanding of the technical operations so that our products operate optimally and cost effectively in the cloud.”

“Our DevOps team worked closely with the development and cloud operations teams to develop standards for the cloud. Further, they were responsible for setting and maintaining the cloud standards including the development of architectural components that allowed for the automation of provisioning, patch processing, upgrades, backups, restores, monitoring and the development of a portal to provide a self-service option for these functions,” Rose explains.

Infor Labs has already seen results from DevOps. “The benefits that we have experienced include the reduction of the provisioning of an industry suite from weeks to minutes, decreased implementation time and costs for our customers, and solutions that are optimized from a technical ops perspective that allow our cloud infrastructure to scale so that we can support the thousands of customers that we have today in the cloud and the ability to scale to support the thousands more that we see moving to the cloud in the future, ” says Rose.

While DevOps is not intended solely for applications in the cloud, software providers such as Infor that publicly promote the value of their own DevOps culture increase proof of concept while serving as role models for their enterprise customers.   If the primary objective of DevOps is to improve speed to market and time to value, who better than a trusted commercial software provider to demonstrate real world insight and results.

September 25, 2014
Top 3 Must-Haves in Development/IT Operations Project Handoffs, Part Two
As you may recall, in part one we uncovered 1.5 of the top three must-haves in development/IT operations project handoffs. We now know that operations really needs to know what the normal and abnormal operating conditions are for any software that development produces. We know that development needs to share the accumulated technical debt for that software as well. And we had just begun to understand the role that Big-O Notation plays. If you have not read part one, you may want to do that first. Now here we go with part two.

Here is an example of O(n). Given the goal of computing the sum of all elements in an integer array, for example, the algorithm would work like this: start with the first element, add the second, add the third, etc. In Big O Notation, this is O(n), which is linear, i.e. adding one element means executing an additional step in the algorithm.

Here is an example of O(log n). Given the goal of finding a particular value in a sorted array of integers, the binary search algorithm would work like this:
1. Find the middle element and check to see whether it is the value you are looking for. If it is, return it.
2. If the middle element is bigger than the searched value, continue with step 1 over the first half of the array.
3. If the middle element is smaller than the searched value, continue with step 1 over the second half of the array.
In Big O notation, this is O(log n), which represents logarithmic complexity, i.e. adding one element will (usually) not increase the number of steps, but adding K elements will add one step.

There are many types of algorithms that fall in different groups of Big O notations. The general rule of thumb is:

O(log n) < O(n) < O(n log n) < O(n^2) < O(n^3)

So, if for example operations knows that the algorithmic performance of a software component is O(n) (expected linear performance), but it behaves like O(n^2) (quadratic, i.e. adding one element exponentially increases the operations needed for processing) they will realize that there is something wrong from an operational perspective.

“I would like to have that information because it helps me do capacity planning, it helps me understand dependencies and intricacies, it helps me do my job in an optimal way (no need to get that expensive 10G network controller if our current implementation is unable to hit 1Gbps),” says Vachkov.

Number Three Must-Have: The Architectural Diagrams for the Overall System and Its Components

“This is somewhat understood and followed. However, the diagrams and documentation are not usually comprehensive enough, if at all comprehensive,” says Vachkov. Many operations people have a deep understanding of the software development lifecycle. They need to know the inner-workings of software components to properly design reaction procedures, dependency checks or checklists, and run-books.

Here are some examples. In many environments, operations personnel will develop their internal procedures in the form:

If you see A -> do X
If you see A, but B -> do Y

This applies to reaction procedures, scripts, and runbooks, according to Vachkov.

Dependency lists are a bit more complex, sometimes called checklists. These have the form:

if you need to do A then:
-> check if AA
-> check if BB
-> check if CC
-> do X

“These can be complex and cover different areas, from installation of software components to deployments of new tenants in multi-tenant systems to troubleshooting and post-mortem analysis,” says Vachkov.

“When this kind of information is lacking, the software is a black box. Being a black box is bad for operations. I need to know that the software expects to find a MySQL server on the same host (because it only uses a UNIX socket to communicate with it) and I should not need to figure this out on launch day,” says Vachkov.

Extra Pointer!

“Very big Bonus Point to all developers who keep lists of all the hidden knobs and switches that operations can use in run-time to deal with a particular failure or abnormal scenario,” says Vachkov.
September 24, 2014
Paying Down Technical Debt

When watching IT shops over the years it seems some, despite trying to cram two weeks worth of work into six days a week, never seem to move very far forward. And yet other teams seem to make tremendous strides in productivity and outcomes despite not working as many hours as the poorer performing organizations.

Why is this? Like many aspects of life and business, it’s about working smarter, not harder. When it comes to enterprise IT that often means avoiding technical debt. The generation of demand for work to fix issues that should have, could have, been avoided had the work been completed properly the first time. “In an engineering context, I believe we are talking about the negative side of the tradeoff ledger,” says Kevin Behr, the chief science officer for the CXO and Board Advisory Practice at Praxis Flow. “Engineering inherently involves trade offs between what we would like to do and what we can actually do, so we often cut corners in the name of expediency,” Behr says.

Aater Suleman, co-founder and CEO of Flux7 put it another way: “It’s when you have urgency that takes precedence over the right thing to do. In that rush, you’re not making decisions the right way, you’re just getting things done really quickly in the heat of the moment. And you have to go back and fix those later,” Suleman says.

The high cost of technical debt
How much technical debt does your organization have? How much latent work is hiding in rework and hurdles that need to be leaped because of shortcuts taken and ongoing bad decisions made in design, infrastructure, and operations. How much debt has been accumulated today, this week, month, or year? And, more importantly: how do you pay down that debt and not accumulate new debts in the future?

According to Donnie Berkholz, an analyst at Redmonk, DevOps relates to technical debt in that DevOps is a more collaborative approach to software development and enables the people building and running the software to have a fuller understanding of all the places technical debt can live. “Sometimes it’s not directly in the code base but rather in the release tooling, or the production systems,” he says.

An example Berkholz cites as a n example of the potential cost of technical debt is Knight Capital’s $460 million loss due to lack of documentation and automation of their server configuration.

Paying debt down
As a way to help reduce technical debt, Berkholz advises enterprises consider running “blameless postmortems” after outages or issues. “It’s about explicit acknowledgment of the facts as well as setting aside time to fix underlying problems without searching for blame,” Berkholz says. “Technical debt won’t fix itself; you need to set aside time and effort to pay it off, without worrying where it came from beyond lowering future debt as much as possible,” he says.

And for avoiding technical debt during ongoing operations, Suleman advises enterprises continuously test their operations and applications. According to Suleman, most companies that have taken on significant amounts of technical debt actually don’t have adequate testing in place. That, by itself, is a challenge itself, but it turns out many organizations actually have another issue – some enterprises hold an unsubstantiated level of faith in their testing. “I’ve seen many companies where they think they have automated testing, and hence, they rely on it. But the testing is not exhaustive or complete enough to actually rely on,” says Suleman.

For instance, Suleman explains, it’s rare that enterprises conduct performance tests on the code they commit. “Which is why performance testing provides a classic example regarding technical debt, because the enterprise can be doing everything right, and adhere to all of the general DevOps methodologies, and yet the application doesn’t run properly because they haven’t tested correctly,” he says.

When balancing the IT ledger, think long term
While it may sound straightforward enough to start testing applications and system changes continuously, and spending a little more time thinking through design issues upfront to avoid trouble later – continuous improvement efforts, such as trimming past technical debts incurred, don’t take root in organizations overnight. It takes time to build these processes in. Think marathon more than sprint. “Continuous Improvement is not as much for the impatient as it is for those willing to invest in steady, long-term activity,” says Behr.

September 23, 2014
JumpCloud launches new Directory-as-a-Service offering

The cloud is a great equalizer that enables startups and smaller companies to scale quickly, and play on a more or less even playing field with larger organizations. Managed cloud services free businesses up from implementing, configuring, and maintaining the underlying infrastructure, and allow individuals to focus on the business. With all of the freedom cloud services provide, though, there is still a need for a directory service that defines who the users are, and controls which individuals have access to which resources. JumpCloud wants to move that to the cloud as well.

JumpCloud has established itself as a leading solution for managing security across a vast, rapidly-changing, virtual ecosystem in the cloud. Today, JumpCloud is announcing a new offering that takes builds on that foundation, and applies its experience to deliver Directory-as-a-Service (DaaS). JumpCloud claims its new service will allow organizations to stop managing directory services locally, and enable them to move to a fully-managed, cloud-based alternative to LDAP (Lightweight Directory Access Protocol) or Microsoft AD (Active Directory).

“As we have seen with the transitions from Siebel to SalesForce, Exchange to Gmail, and file servers to DropBox, JumpCloud is enabling the transition of one of the last on-premise technologies to a fully managed service: the user directory,” says Rajat Bhargava, JumpCloud’s President and CEO in a press release statement. “Directory-as-a-Service brings IT teams the simplicity, ubiquity, and security of user and device management, all from the cloud.”

The JumpCloud DaaS services can act as the sole user store for an organization, or it can extend existing AD or LDAP user stores to the cloud. JumpCloud DaaS also integrates with single sign-on (SSO) providers so that IT admins are not forced to manage multiple directories.

“JumpCloud understands the need for directory services in the cloud,” said Salvatore D’Agostino, CEO of IDmachines. “Building on their secure shell configuration management tools, this offer puts in place cloud-to-machine, user authentication and other directory services. At IDmachines, we see this as a big need in current XaaS.”

JumpCloud DaaS promises to help organizations be more agile and more effective whether they’re just implementing a directory service, extending an on-premise directory service to the cloud, or migrating locally-managed directory services to the cloud.

A cloud-based DaaS offering makes sense. No matter what size an organization is, managing the user directory through local, manual processes is an obstacle to realizing the full benefits of other cloud services. It creates complexity, and introduces reliability and security issues. Cloud-based services need a cloud-based directory service—a directory service that can keep up in terms of availability, scalability, and flexibility.

JumpCloud DaaS—like other managed cloud offerings—takes the burden off of local IT to manage the backend of the directory services infrastructure, and places it on JumpCloud. Customers can focus on building things, and authenticate and authorize cloud infrastructure, servers, applications, users, and devices.

JumpCloud’s Directory-as-a-Service is available immediately. Pricing plans start at $10 per user per month, and the first ten users are free forever. JumpCloud supports the LDAP protocol and works with Windows, Mac, and Linux devices.

September 22, 2014
Top 3 must-haves in Dev/Ops project handoffs, Part one

There isn’t much that makes IT operations happier than receiving that brand new application neatly boxed, wrapped, tied with a bow, and outfitted with exhaustive instructions for every what-if, what-then, and what now scenario.

Before you give the gift that keeps on giving in all the wrong ways, take these top three must-haves in developer to IT operations project handoffs to heart.

Number One Must-Have: Define Normal and Abnormal Operational Conditions

What does the development team consider normal operational parameters? At what point does the software break? How? If, giving an extreme example, at 20K users per server IT operations should expect ~50-70% CPU load but at 2K users per server they should not see 100% CPU load, they need to know this.

“Development can outline similar behavior/symptom scenarios for infrastructure (CPU, MEM, DISK, NETWORK) and application-specific (USERS, SESSIONS, USE LATENCY, TIME BETWEEN ACTIONS) metrics,” says Ivo Vachkov, whose title is literally DevOps Engineer, Xi-Group Ltd (Bulgaria; www.xi-group.com). This is the kind of information that helps operations to recognize when a software component is in trouble.

This may sound like obvious information for developers to include in an application handoff. “But many developers (if not most) will not be able to precisely define what is the normal operational condition for their software,” says Vachkov, lecturer in networking and programming security, New Bulgarian University (http://nbu.bg/entrance.php).

IT operations needs to know about factors that affect normal operation including whether the software is CPU-bound, i.e., whether its performance is directly related to the processing power of the computer it runs on. Another such factor is whether the application is IO-bound, whether its performance is directly related to the throughput of the IO (MEM, DISK, NET) subsystem.

Development should prep operations about other software behaviors and risks. If the application will degrade gracefully under increased load, they need to know that. If it will come to a screeching halt under load, they need to know that even more. If the software will crash when it slams up against an administrative/technology timeout, operations can deal with it, if they know ahead of time.

“As operations people, we usually don’t expect too much. I would usually be happy to know that at 50k users per server the main process will crash. And this is OK, because I can work around it. I have the tools to prevent a breach of that limit. I would be happy to know that every night there is a batch processing that will hit the DB hard, instead of being awakened by an alarm about my DB being inaccessible,” says Vachkov.

Number Two Must-Have: Share the Known/Collected Technical Debt

In many cases the technical debt is not obvious, i.e., the documentation states that the component needs library X to work properly, but due to some particular reason, the developers used a specific version of the library that is not available in the default package repository of the OS. Someone needs to build it in manually and take additional care to keep the configuration in sync to make the code work. “Technical debt may have many faces, from bad/rigid pieces of code to bad algorithms to unspecified dependencies,” says Vachkov.

Technical debt is also commonly omitted by the development team. “Pride, politics, other considerations are in play here. Many developers will just not keep track of technical debt. But this is crucial for proper operations. I want to know the shortcomings of the piece of code I’ll be dealing with,” says Vachkov.

IT operations wants to know, for example, whether that key algorithm is O(n) instead of O(log n) because this will enable them to correlate metrics and explain what’s going on. These notations are part of Big-O Notation, which is used in mathematical and algorithmic analysis and generally represents a function that describes the upper limit of performance of a particular piece of code in relation to the number of input elements it needs to work with, according to Vachkov.

Cliffhanger!

This concludes part one of “Top 3 Must-Haves in Development/IT Operations Project Handoffs”. Tune in for part two when we take up with technical debt and Big-O Notation, learn more about why the Big-O is so important to operations and to corralling unwieldy software, and discover the third and final must-have in development/IT operations project handoffs. Don’t touch that mouse or touchscreen! Stay tuned to www.devopsy.kinsta.cloud.

September 22, 2014
Harvard Business Review Survey: IT responsiveness predicts business success

Increasingly, the C-suite is finding that the speed with which companies today are able to take advantage of new technology and exploit their IT operations determines the success of the entire business. A new survey out by the Harvard Business Review and Oracle this week shows that IT responsiveness stands as a huge arbiter of overall business agility, which starts with CIO leadership and trickles down into the way organizations leverage processes and technology. The results can be seen as a testament to why DevOps practices are gaining momentum in so many organizations, as respondents report a nearly one-to-one relationship between IT’s ability to react to business demands and overall business performance.

“Leaders are focusing on speed and broadening their view of where IT begins and ends,” the report explains. “They’re rethinking roles and relationships—and their own value proposition. And they’re making sure their company doesn’t miss opportunities because the IT department was too slow to respond.”

However, many companies are experiencing just this pain. Nearly half of respondents reported that their companies have missed opportunities because their IT department was too slow to respond to shifting business needs. And approximately 49 percent reported that a lack of bandwidth in IT is the primary obstacle of the organization to take advantage of digital technologies.

Conversely, when IT organizations are able to quickly move on line-of-business needs, bottom line success follows. Among those respondents who identified their companies as having responsive IT organizations 42 percent strongly agreed that their IT departments were highly successful at leveraging new technology for business advantage. Only 10 percent of those with moderately responsive IT could say the same.

This most recent finding bolsters another study out this year by Puppet Labs, which showed that high-performing IT teams using DevOps were more than twice as likely to exceed profitability, market share and productivity goals over more traditional IT shops, and they also had 50 percent higher market capitalization growth over three years.

The advantages of IT agility comes in many forms according to the Harvard Business Review study. For example, 68 percent of high performance IT organizations reported new technology had an impact on customer engagement, 64 percent said the same about work processes, 62 percent said new tech impacted product offerings and business models, and 59 percent reported new technology positively impacting core business operations and processes.

According to the survey, performance is highly dependent on IT’s ability to prioritize investments, a capability that a third of organizations do not have. Similarly, collaboration within IT and with line-of-business staff is another bellwether. The survey showed that only 21 percent of respondents believe that the IT organization alone primarily drives digital business innovations. Aproximately 40 percent say that it is actually an equal mix of IT and other business input, while 34 percent say the business primarily drives the technological innovation. However, organizations have a ways to go on the collaboration front. Approximately 42 percent of organizations report that they have a poor track record of facilitating collaboration across IT and business functions.

September 18, 2014
Collaboration in Progress: Making DevOps a Reality

Everything on your company’s DevOps checklist is accounted for. It’s got the vision and the talent. It’s identified the problems and mapped out a solution. It’s got a culture that allows the flexibility that such a plan requires. Now’s the time to put the plan into action and let the benefits begin.

The truth is that it may not be that simple. A great plan won’t mean anything unless everyone understands how to achieve it. And whatever a company’s DevOps strategy consists of, collaboration is the key to making it a reality.

Collaboration is at the heart of DevOps. It’s even conveyed in the phrase itself. No matter the size of your company, this new process of teamwork and transparency relies on combining strengths between Development and Operations to achieve goals that otherwise wouldn’t be possible.

Breaking Silos with a Full-Circle Approach

With one department responsible for writing code and another responsible for implementing it, silos can naturally form as each group focuses on its job. This kind of structure is what commonly gives rise to software deployments taking longer than they should and even little or no communication taking place between the two departments.

DevOps has come about as an antidote to these kinds of siloed situations in which inefficiencies and a lack of teamwork are the norm. Yet for DevOps to take off, both Development and Operations have to participate fully and understand that collaboration requires equal cooperation from both sides. Such collaboration has to take place not just at certain stages, but throughout the life of a project. When each team is invested in the effort by providing feedback, helping identify future problems and continually learning from day-to-day deployments, a company has a great chance of seeing benefits from these new collaborative efforts. Without complete buy-in from everyone, the process will never get off the ground.

The Evolution of Collaboration

Just as DevOps is about moving beyond the assembly line process of software development, the concept of collaboration itself is evolving. DevOps-style teamwork can consist of more than breaking down the silos between different teams. In an agile infrastructure, team members can wear different hats and swap responsibilities depending on the demands of the day. Instead of a scenario in which people work on single specialized tasks without any interaction with the larger group, you’ll have contributors who can play multiple roles within a team and understand how this boosts productivity for the entire company, rather than just a single department. It’s possible that a team member can function as a developer one day and then work on deployments another. Through DevOps, an organization can advance beyond one-dimensional departments and one-dimensional contributions.

Real-World DevOps Teamwork

For many within the IT industry, DevOps is already a working reality. Breaking silos and becoming more agile are goals for companies that know how increased collaboration can help their business. A good source that lays out some first-hand experiences of DevOps practitioners can be found in the recently published Rackspace e-book, The DevOps Mindset: Real-World Insights from Tech Leaders. It features interviews with IT experts who discuss what led them to adopt a DevOps approach and recommendations for those interested in a new agile approach to software deployment.

When discussing the importance of agile teamwork, James Kenigsberg of 2U remarks that, “To achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only.” As a provider of online university programs, 2U faces a huge demand for quick, dependable deployments and underwent a transition to increase teamwork at the company. “We had to flip the model,” Kenigsberg explains, “from the idea of personal heroics and siloed responsibilities to real, cross-functional collaboration.”

Jim Kimball of fund administrator HedgeServ reiterates this cross-departmental approach. “Repeatability and scalability are our business,” he explains. “The capabilities that DevOps gives us directly enable this by encouraging collaboration within the organization to come up with better solutions.”

Forging a Partnership Between Dev and Ops

Assembling a skilled and talented group that will be the envy of your industry is the ideal every company would like to have. If you’re able to gather a team that’s the IT equivalent of the X-Men, it’s not enough to just assemble that talent and assign them siloed roles. Without frequent teamwork, not only will company goals become difficult to achieve, but solving problems will be nearly impossible.

When Development and Operations see themselves as working in partnership with each other, the foundation for greater collaboration will be in place, and company goals, such as greater speed to market, increased productivity and an all-around agile performance, will be within reach. With the right mentality, DevOps can be an evolutionary step in company functionality and reach new levels of efficiency that otherwise wouldn’t be achievable.

September 16, 2014
Fighting federal agencies culture shock to get over cloud and DevOps hump

As federal agencies face budgetary pressures that drive them toward more agile IT pushes around cloud deployment and DevOps practices they must first tackle big perceptual and cultural roadblocks. Case in point is a survey out last week that showed that 89 percent of federal IT professionals still feel apprehension about migrating to the cloud, with 43 percent saying that it felt like giving their son the keys to their new convertible.

Conducted by government research firm MeriTalk on behalf of NetApp and Arrow, the study shows that only 44 percent of agencies report having mature data governance practices in the cloud, and cite data exceptions, data integration, and collaboration and interoperability as their top challenges. Security still tops that list, though, with just one in five IT pros completely confident in their cloud vendors’ security.

Interestingly, just a third of agencies met the June deadline this year to make sure their cloud solutions meet the security criteria laid out by FedRAMP. Among those who didn’t make the deadline, another third plan to do so within a year.

The push to do so could present opportunity to work on the associated applications and cloud integrations with a new approach that could potentially embrace DevOps principles. For example, IT staff at the National Renewable Energy Laboratory recently used its initiative to gain FedRAMP compliance for its AWS integration as a chance to establish a DevOps pilot program.

According to Keith Trippie, executive director for enterprise system development at the Department of Homeland Security, federal agencies’ ability to improve through DevOps, security and cloud deployments will all play important roles in improving time to value for citizens.

“I look at the budget challenges we have today as a change agent for the government. It’s going to force us to innovate quicker than we have,” Trippie says. “It’s part of a healthy IT diet, where we’re looking at DevOps, we’re looking at continuous assurance on the security side, we’re looking at cloud in commodity IT, which will enable us to provide services more quickly than we have before.”

On the cloud front, one of the big ways agencies can drive more safe deployments is through better governance. According to the MeriTalk survey, 52 percent of organizations don’t have well-understood data integration, 50 percent don’t have defined data owners and 49 percent have no known systems of record. The survey showed that the more mature organizations were in improving data governance programs, the more likely they were to be comfortable with turning over IT services to cloud vendors.

The cultural stodginess and lack of groundwork laid by federal agencies to make cloud migrations possible could also potentially prove the biggest stumbling blocks for federal DevOps deployments.

“The federal government will have to call into question some well established practices in order to implement DevOps,” wrote Mike McGarr of Netflix recently.

A current engineering manager for the Netflix Build Tools team, McGarr previously worked as a federal government contractor. He advises agencies to avoid the sales people who will try to sell DevOps in a box and take a deep look at processes both within the agency and contractor organizations.

“There are number of practices, rules and even regulations that inhibit government IT evolution. Government agencies need to continually ask ‘why do I really need to follow this rule?’ and keep asking,” he writes. “Get to the core goal of these restrictions, and propose a better way to solve this problem.”

September 15, 2014
How Change Management Serves the Developer

Change management first comes to mind as a means to keep errant, untested, unapproved code from entering production. But did you know that what is good for IT operations is good for developers, too?

Developers appreciate change management. They enjoy the change management benefits of Linus Torvald’s popular Git version control system http://git-scm.com/, which maintains successive versions of the code in question, and spawned GitHub https://github.com/ where developers share and network with their community. Perforce is another version management tool http://www.perforce.com/.

But what are the benefits to developers from change management as taken in the former sense? How does the same change management that protects the production environment help the coder?

Lightening Developer Workload

Change management saves developers a lot of work. Developers benefit by focusing on the work that stakeholders agreed on when discussing and scoping the project. These are the tasks that come from their lead developer, who receives it through proper channels.

When developers do this instead of accepting countless requests from managers for adds / changes that fall outside the scope of the project that leadership agreed on, they save themselves from potentially repeating their work to replace those unauthorized changes with the coding implementations that the team leader originally tasked them with. Developers save themselves and the customer many headaches by completing planned, authorized project items rather than the requests that undermine the corporate vision.

“Change that is not properly managed is destabilizing. Unapproved changes send ripples through every aspect of project task assignments. The ultimate outcomes are unpredictable,” says Steve McConnell, the oft-quoted author of “Code Complete” (Microsoft Press). And by the time upper-management hears of the scope creep and project dilution, the damage is far reaching.

Yet, even stakeholders who felt they clearly communicated what they needed will come back at a project landmark or at mid-project to say that they require some feature that the development team is not addressing. This creates scope creep and additional person-hours that are out of the development team member’s hands. Clearly, developers see enough challenges such as this without managers visiting the developer’s cubicle once the project is in full swing, seeking adjustments for their users.

“But this duality is a specific phenomenon that I and the industry have seen. There is the official workload and then there is the unofficial plan and workload consisting of favors garnered from individual developers, which undermines the project manager, creating work that causes work to go on with the PM unaware,” says McConnell. Following change management protocols and project structure is necessary so the right hand (PM) knows what the left hand (developer) is doing.

Avoiding the Crossfire

“Developers get caught in the crossfire between unofficial requests and change management. The proper chain of command funnels down blame to the developer when their task X is not done. Yet that only happened because the VP of Sales came directly to the developer, saying he needed another feature,” says McConnell. Because the developer saw the VP as his superior, he felt he couldn’t say no. Suddenly, the developer has several bosses. As a result, development staff don’t get project tasks out on time. “This leads to prioritization of work that does not reflect the priorities of the organization,” says McConnell.

When a developer remains firm, however, sending the VP to the project manager or development team leader with any new requests, that can limit some of the crossfire.

The Joy of Completed Work

Another benefit to the developer in following change management protocols is the satisfaction of finished work, which is possible when they are not constantly changing direction. “Developers have a high desire to complete work successfully,” says McConnell. To not have to frequently change focus and to rather get work done day-to-day and week-to-week is very fulfilling for developers. “The Holy Grail for developers is to receive clear direction throughout the course of the project,” says McConnell. Developers like their work to move in a straight line. It is frustrating to change focus so often.

Developers are most motivated by the work itself. They are task-oriented people who enjoy the relief that comes with task completion. If the work is constantly redefined, that can be demotivating for them.

Coming Full Circle

“There are benefits to the developer from change management including improvements in productivity and morale. But the largest benefits accrue to the business. Change management gets things done by investing more time in moving in the right direction,” says McConnell.

September 11, 2014
Three essential elements to maximize business value with DevOps

DevOps is fast becoming the winning strategy needed to accelerate the continuous delivery of exceptional software without sacrificing quality and cost efficiency. With its focus on better communication, collaboration and feedback within and across development and IT operations, DevOps is gaining many fans – even in the business, where performance is seen as being directly attributable to its adoption.

I’d be the first to agree that buzz plus a liberal dash of hype follows any new tech trend. We’re seeing this big time with DevOps. Already it’s one of the most Googled tech trends.

Many vendors are washing and making ready their ‘DevOps products,’ while the #DevOps noise is shall we say, trending – we just love disruptive technology. If you have read the Puppet Labs 2014 State Of DevOps survey, organizationswith high performing DevOps teams were 2.5x more likely to exceed profitability, market share and productivity goals, and had 50 percent higher market capitalization growth over three years.

Don’t get me wrong I’m a disruptive tech fan too, but there’s a caveat – technology disruption is nothing unless it’s truly transformative– and that’s where I place DevOps. It’s not a technical nicety, but actually a business imperative for companies to thrive in an increasingly software-driven world.

Software applications are rewriting business. They’re no longer in the background ‘counting the beans’ and running the supply chains – they’re front and center – the mobile systems-of-engagement that shape your brand, delight your customers and, here’s really the cool part – disrupt markets.

Sounds great you might say, but there’s a problem– the traditional fixed speed limit on the super highway of business computing.

Enterprises have been stuck in the same gear for years maintaining large, complex/interconnected legacy systems. Mainly transactional and supporting complex business processes, the norm has been to change when only necessary (or forced to change?) – never exceeding the speed limit. Now however, consumerization of IT has dictated rapid delivery of software innovations. This requires a DevOps approach, where teams have a shared responsibility for not just keeping the lights on, but powering business.

Being able to increase pace is important, so too nimbleness. By making IT infrastructure more flexible and the instrument used to digitally engage and interact with customers, cloud drives business agility. But it’ll never realize its full potential if IT continues operating in silos using manual processes. This is why DevOps collaboration, shared processes and tools are so critical for harnessing the cloud – or using and an analogy – if cloud is the supercharged engine of business – DevOps is the fuel that powers it.

So with mobility and cloud computing being essential to a software-driven business, what additives do we need in our ‘DevOps fuel’ to spark agility and generate the greatest returns?

There are three big ones:

Agile Parallel Development

DevOps must reduce all elements of waste. This is a tough nugget to crack because existing IT environments generate tremendous inefficiencies. Often separate dev teams have to contend for physically constrained resources, with quality compromised by poor test data, shortcuts and bottlenecks. Testing especially is seen as IT’s “angry monkey”; something to be loathed, when in fact it should be a unified process that bakes excellence (functional and non-functional) into everything – from mobile apps and API’s to back-end systems – from dev day 1 and persisting right through to production.

With Agile Parallel Development and shifting testing earlier in the lifecycle, teams avoid delays in the development of high-quality code. Toolsets are important here, especially service virtualization, which by removing testing constraints reduces cycle-times plus prevents bugs finding their way into production. And, since business will increasingly engage customers across digitized multi-channels (mobile, API’s), teams will exploit real-time intelligence to test new ideas and experiments – pinpointing how functionality and performance converts to business gain.

Continuous Delivery

Release delays are a classic business fail. Now, success depends on delivering a continuous flow of value from new mobile apps, APIs and software innovations. These types of services will be constantly enriched to capture new markets and customers yes, but they’ll also be operating within shorter windows of business opportunity – faster lead times mean everything.

For IT, this ‘quick or dead’ imperative means teams must challenge a culture based on avoiding change and fear-of failure by using Continuous Delivery processes and tools to accelerate and streamline complex, multi-tier releases; automating the testing, deployment and promotion of changes across all environments. Additionally, these processes should integrate other management requirements – for example, establish service-level monitoring and reporting with the application when released.

Agile Operations

Agility must extend to operations. For too long we’ve been asking questions like – “how long can we go between failures?” or “who’s to blame for this problem service?,” but we should be asking – “If we want to increase customer conversion rates from our mobile app, what levels of performance are needed?” or “how can we detect and remediate performance problems before code reaches production?”

This shift requires Agile Operations – shared processes and tools that optimally manage applications, but also feedback intelligence to the extended team. For example, Application Performance Management should pinpoint operational problems faster, but also ‘gift’ development rich insights they can use to improve code quality. Furthermore, teams will leverage advanced analytics (like how, where and when mobile apps are being used) to drive just-in-time enhancements –that’s a new take on end-to-end– customer ‘engagement-to-experience.’

Business demand for software innovations is insatiable, and for good reason. Now the simplest mobile app experience or secure API can transform your business or screw it up completely.

By establishing a rampant innovation culture with DevOps and the right processes and tools, IT will not just meet expectations – it’ll be the spark for growth and innovation.

About the Author

Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is on twitter @aruna13 and on Linked in

September 10, 2014