Sep 16 ’13

Agility in the Data Center: An Interview With CA Technologies Troy Coleman

by Craig S. Mullins in Enterprise Executive

Recently, I had the privilege of interviewing Troy Coleman on the topic of agility in the data center. Troy is senior principal product manager for CA Technologies and is responsible for CA’s DB2 for z/OS tools. Troy also writes the DB2utor blog for IBM Systems Magazine and has extensive experience in all facets of database systems development. You may have heard Troy speak at your local user group or one of the large international conferences. He’s also a former adjunct professor for Concordia University-River Forest where he taught database management systems.

Craig Mullins: Troy, let’s dig right into our discussion by making sure we have our definitions aligned. The dictionary definition of ‘agile’ is ‘characterized by quickness, lightness and ease of movement; nimble.’ Given that definition, applying agility to business, software development and database management seems like a good idea. Wouldn’t you agree?

Troy Coleman: Yes, I would agree. Having an agile organization means being able to move forward fluidly without concern about the increasingly varied skillsets of your team. An agile team can react quickly to changes and adapt its systems to more closely align with its business operations. By reducing the time to respond to business needs, the agile organization can reduce costs, improve return on investment and beat its competitors in the marketplace.

Mullins: On the other hand, agile has taken on a meaning all its own within the context of software development and IT. The Agile Manifesto [http://agilemanifesto.org/principles.html] lists the principles of agility in terms of developing software. It begins by stating that ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’ Does this imply any trade-offs in terms of what types of things should be favored during the software development cycle?

Coleman: I think agile is one of those words that can mean different things to different people in different contexts. The Agile Manifesto has some good ideas in it, but it isn’t the be-all, end-all definition of what agility in the data center has to be. For example, the manifesto states that it values ‘Working software over comprehensive documentation.’ But I want both working software and comprehensive documentation—and so should you.

At any rate, there are always trade-offs in the development cycle. It’s just like the old saying goes: ‘You want it to be good, fast and cheap … you can pick any two.’

Mullins: How does agility serve to empower individuals within an organization?

Coleman: An agile organization must be able to provide high-quality products and services to its customers amidst cost reduction efforts without interruption or performance degradation. By giving individuals the tools they need to succeed—and the authority to use them as appropriate—turnaround time for projects can be reduced. This form of self-empowerment to do what’s needed as it’s needed relies on having the proper tools. Often, your use of the most current software can help ensure your performance is optimized and your resource utilization is maximized.

We’re both database guys. So let’s think about it in terms of DB2 for z/OS. An agile data center that relies on rapid reaction to customer needs will be constantly developing new software. And new software typically means new database requirements. How the DBAs make those changes can greatly enhance, or impede, the schedule for the project. Having tools that understand how to make changes appropriately to database structures with minimal to no impact on availability is a key criteria for agility, in my opinion.

Mullins: As you suggest in that answer, one of the tenets of the agile movement is continuous development. The thinking goes like this: The real world is always changing so the software we are developing should be able to be always changing. Doesn’t this imply that software development projects are never completed? And wouldn’t that have an impact on developer morale?

Coleman: Yes and yes. Continuous improvement means ongoing software development. But I think you may have been implying a negative impact on morale and I see just the opposite. A programmer working in a shop with ongoing projects always has work to do. And that means he has a job, right?

Mullins: That makes sense, Troy. Another aspect of agile development is to break things into small, manageable pieces: tasks, teams, etc. The point of doing this is to improve focus and ability to deliver. But it also complicates communications, especially for larger projects where multiple, smaller tasks worked on by multiple groups need to work together for the whole. How can agile teams conquer this challenge?

Coleman: Again, I would point to intelligent automation and tooling. If projects are controlled and tracked by means of tools, then anyone who wants to know the status of the project can readily track it using the approved tools. And the tools make things simpler, reducing the amount of time, effort and human error involved in implementing and maintaining efficient and effective applications and systems.

To be agile, you must reduce risk to ensure longevity and optimal performance of your data center. This includes adopting solutions that automate otherwise manual tasks and consolidate disparate solutions as well as partnering with a provider who has strength, stability and proven solutions.

Mullins: How has CA adopted agile techniques into its product management and development activities?

Coleman: The DB2 database management product line transitioned from waterfall to agile about four years ago and we’ve seen great improvements in customer satisfaction scores due to improved quality, documentation and functionality. With agile, we ensure QA is a part of the development team and build automated test scripts during the development. In the traditional waterfall methodology, the QA person gets the product at the end with little time before the product goes out the door. We also ensure the technical writer is a part of the team and writing the documentation that goes along with the new functionality. With the success of agile in the DB2 database management product line, CA has embraced agile development across most of its product lines with a focus on meeting the customer needs. CA understands the importance of customer involvement during development and is investing in this area by adding more product owners who have a focus on reaching out to our customers and getting them involved during the development process.

Mullins: It would seem to me that agile techniques are worthwhile for certain types of projects and within certain types of organizations. What projects and organizations do you feel are best-suited for adopting an agile approach? How can readers best identify how and where they might be able to use agile techniques in their organization?

Coleman: An evaluation of your data center can often yield greater agility to ensure you’re using products to their greatest capabilities and using products that help you operate at optimal productivity. It makes sense to work with partners to conduct such an evaluation because internal IT folks can be too close to their own situation to recognize issues.

It makes sense for database administration groups to adopt agile techniques. We both know that sometimes DBAs can be viewed as bottlenecks to progress. An agile DBA group will be seen as an ally within the organization, reacting to change requests, proactively improving performance and responding to issues rapidly … instead of being viewed as a roadblock.

Mullins: What can CA do to help customers adopt agile techniques and achieve success by embodying them within their organization?

Coleman: Let me answer that by walking through an example of a DBA task that can become agile using CA’s solutions. Consider a situation that requires database recovery. As we both know, recovery isn’t something that a DBA does on a daily basis. It’s a task that’s performed only when problems occur. So right off the bat, the DBA is working on something he isn’t necessarily comfortable doing. And given there’s a problem, it’s possible your manager will be breathing down your neck, asking how soon before the problem is fixed and the system is available again.

Well, with software tools that automate the task of analyzing, creating and executing a recovery scenario, the risk is reduced. The DBA is less likely to make a mistake because the tool has the built-in intelligence to monitor the situation, analyze the various recovery scenarios that are possible and build the job to execute the appropriate recovery. Do we need a point-in-time recovery or recovery to current? Should we use image copy backups or can we generate undo/redo SQL from the log? What’s our recovery time objective and what techniques will help us achieve that? Considering all these things in the hectic environment that’s recovering from a database problem is difficult without the guiding hand of automated tools.

And that recovery can take less time because not only was the analysis time automated (thereby quicker and less error-prone) but the recovery job can also take advantage of fast utilities to reduce the processing time of the recovery. I just don’t see how an organization can be agile without having tools of this nature.

Mullins: How do you think an agile approach to technology can benefit companies? Is there anything that hasn’t yet been impacted by agile techniques that you think could benefit from agility?

Coleman: At CA, we’ve been working on a unified workspace wherein elements can be organized and customized by discipline. For example, the DB2 database administration workspace is organized in a coherent way to maintain and troubleshoot database software and manage workloads and operational processes. The duties are backed up by the CA tools used by DBAs. So, instead of having to know the capabilities and functionality of each and every tool, the DBA just needs to know what he needs to get done. The discipline-based interface simplifies the manner in which the DBA gets the job done. So, if the DBA needs to tune a particular program, he wouldn’t have to worry about which combination of tools needs to be done to accomplish that. The workspace directs the tasks by the discipline that’s undertaken.

That’s agility on a different scale than IT professionals have ever seen before. This is what CA Chorus is all about. CA has delivered the DB2 database administration workspace for Chorus, as well as workspaces for mainframe storage administration, mainframe security and compliance administration and the just released mainframe infrastructure management. By deploying CA Chorus, our customers can greatly enhance their agility.

Mullins: Thank you for your time, Troy. I think we all have a better idea of agility in terms of how it impacts the data center in general, and DB2 administration specifically.