devopsy.kinsta.cloud

Category: Blogs

Steer SAFely – So how do you do it?
This is the third blog in the DevOps – Scaled Agile series. In the previous blogs, we discussed the characteristics of a successful enterprise agile transformation and provided specific guidance on applying lean and agile practices at an enterprise level. We covered the “why” and a bit of the “how” at a high level, making the case for the need to address all aspects of a scaled agile transformation –people, process, and tools – to achieve success.

By now you should be asking “where’s the beef?!” You get it… now you want to do it. Great! Because we have tooling that can help. Yes, tools are just one aspect of the transformation to a continuous delivery model, but man, wouldn’t it be nice to have tools that just support enterprise scaled agile methodology out of the box so you don’t have to think about that part and get on with the hard stuff – like the cultural aspects of this transformation?

The Scaled Agile Framework® (SAFe®) provides the “rules” for scaling lean and agile across the enterprise; the tools support those rules to get you up and running quickly.

Let’s start by breaking down the organizational structure: SAFe v3.0 describes a methodology for scaling agile and lean across three organizational layers:
- Portfolio: Where investment decisions are made. This is the heart of economic planning, where programs are aligned with the enterprise strategy. There may be multiple portfolios in an enterprise, even within a line-of-business. The decision hinges on strategy and funding; a Portfolio has its own strategy and its own bucket of money.
- Program: Where funding and strategy meet planning and execution. The Program has the resources allocated to deliver on the strategy. Programs are long-lived and require a persistent structure and mission, so they are not exactly equivalent to business-driven “projects”, which might typically have start and end dates. That said, Programs deliver capabilities in support of “projects” through their contribution to Portfolio Epics. And we will discuss more on this later.
- Team: Where the real work gets done! Teams are solely responsible for defining, building and testing their own user stories that contribute to value delivery for a Program. They are independent and self-governing, but they do operate in lock-step with other teams to deliver software aligned with the Program vision and the Portfolio strategy.
With me so far? The tooling that supports SAFe encapsulates this organizational structure, giving you places to capture things like budget, strategy and roadmaps at a Portfolio level along with the “change” artifacts – the work items that identify what will be delivered by the Programs and how it will be delivered by the Teams. By providing a system to hold the data, we can also then provide visibility into status and health of executing Programs and the means to report on trends to demonstrate measured improvement – or not! – as your transformation evolves.

Let’s explore the tooling bottom up, as that is typically how most organizations get started with SAFe.

SAFe Program/ Teams

SAFe Programs and Teams are supported in IBM Rational Team Concert. A process template is provided that you can use to create a Program project area with Teams as team areas within the Program. Alternative topologies, such as Teams in their own project areas or even using third-party tooling, can also be supported.

The process template provides:
- Project Area Initialization
- Work Items & Attributes
- Plans (Roadmap, Kanban, WSJF Ranked List)
- Reports
- Process Guidance
Everything you need to quickly initiate a new program and kick off program increment planning, is available and ready for your team to get started.

SAFe Portfolio

In the next release of the Rational Collaborative Lifecycle Management (CLM) solution, IBM will provide support for the SAFe Portfolio, rounding out our SAFe V3.0 support. As with the Program process template, the CLM Lifecycle Project Area template will provide a Portfolio tooling infrastructure that joins change management with requirements and quality management to fully support the execution of the Portfolio. Through a set of template, we provide you with:
- Portfolio Artifacts & Attributes
- Plans (Roadmap, Kanban)
- Reports
- Process Guidance
As a starting point, the Portfolio includes a set of Programs as team areas, allowing you to easily identify the resources involved in each Program.

SAFe Key Concepts

In the last blog, we discussed three key SAFe concepts that we believe are required to achieve success: Kanban, WSJF for relative ranking, and PI Objective to capture and assess value delivery. Each of these concepts is supported by the tooling.

Kanban System

At both the Portfolio and Program levels, the tooling provides a Kanban plan view to enable your team to drive relative ranking and prioritization discussions based on the Kanban System.

WSJF

To help your Program drive backlog planning, the WSJF Ranked List view is provided with the capability to actively lead a planning session making changes in-line to create a ranked list of Features.

PI Objective

The PI Objective is a work item artifact provided by the Program process template, allowing you to capture planned and actual value delivery consistent with SAFe guidelines. In the next release, we will also provide a new calculated attribute that captures the percentage of value (actual / planned) so that we can provide trending reports that demonstrate the Program’s ability to deliver value over time.

Stay tuned for more with the next few blogs in the series coming soon. Till then do read the last 2 blogs if you missed them earlier – Scaling Lean and Agile for the enterprise: All hands on keyboard!!! and Steer SAFely – Driving collaboration across multi-disciplinary teams.

Also, learn from the experts here:
- Telstra Corporation expands services with agile development and IBM Rational tools
- Google Hangout: SAFe and DevOps Adoption
To learn more about our ongoing SAFe support, visit the SAFe Landing Page: http://ibm.biz/safesupport. We look forward to your feedback! And please join IBM at AgileDC, October 26, 2015, Washington D.C. Submit a proposal through August 15, 2015. URL: http://agiledc.org/2015-call-for-proposals/

About the Author/ Amy Silberbauer

Amy is a Solution Architect charged with the definition and delivery of the Enterprise Scaled Agile and IBM DevOps Plan solutions and strategy for the IBM Systems – Application Platform line of business. She is a recognized subject matter expert on scaled agile and software development lifecycle solutions, including enterprise modernization, SOA and collaborative DevOps. She has been with IBM for 28 years and has two decades of software development experience as an engineer, architect and manager. She is a certified SAFe® Program Consultant experienced in leading and consulting on multiple internal and external SAFe (Scaled Agile Framework®) transformations.

Connect with Amy on LinkedIn
August 27, 2015
ARA tools can help you move apps easily to the cloud

Chances are your organization has already moved some of its applications to the cloud. There, storage and computing capacity are provided as services, and everybody in your enterprise can access the apps and related data via the internet.

As we all know, the cloud enables organizations to scale up or down quickly according to their needs, while giving them tremendous flexibility in maintaining their computing environment. One advantage for using the cloud is that it helps reduce time-to-market and removes the need for upfront investments in infrastructure.

To help you simplify the process of moving apps, you should consider using an Application Release Automation (ARA) tool from a reputable vendor with experience in the cloud space.

Moving to the Cloud Involves Research and Difficult Decisions

The first decision is perhaps the hardest: determining which variant of the cloud is best for your apps and your organization. Private or public cloud? Factors you should consider are: data security, privacy, legal compliance, network latency, whether the organization has the in-house resources to create and maintain a private cloud, and which cloud flavor provides the best combination of flexibility, compliance and cost-effectiveness.

Then, you have to weigh up the pros and cons of using the different cloud flavors, principally these:

•       Software-as-a-Service (SaaS)

•       Platform-as-a-Service (PaaS)

•       Infrastructure-as-a-Service (IaaS)

After the big decisions come the technical issues of how you are going to move your applications. Moving apps can be very difficult as many apps are complex and tied closely to the infrastructure landscape where they are deployed. Moving to a new landscape, such as the cloud, can be fraught with risks and challenges.

What are ARA Tools?

ARA tools focus on the modeling and deployment of custom application software releases and their associated configurations, often for Java Platform, Enterprise Edition (Java EE) and .NET applications. These tools, according to Gartner, offer versioning to enable best practices in moving related artifacts, applications, configurations and data together across the application life cycle. ARA tools support continuous release deployment. They often include workflow engines to assist in automating and tracking human activities.

Core activities include:

•            Packaging — creating a collection of multiple configuration items that must be deployed at the same time

•            Dependency Mapping — modeling full application dependencies between components of the application

•            Software Deployment — using package contents to install applications and configure their operating environments

•            Promotion — delivery of tested packages to an environment of higher criticality

•            Compliance — documenting adherence to processes and validating deployed application configurations

At its simplest, an ARA tool helps developers to map application components and configurations to targets, such as binary code, connection configuration, database updates, queue definitions, and web service end-points. This helps to remove the coupling between the application and its host infrastructure.

First Step in Using an ARA Tool to Move Apps to the Cloud

Using a sophisticated ARA tool, you can install applications in a cloud environment automatically. Nearly all ARA tools will enable you to define the application in the tool, ideally specifying a package for each version of each application. Each package will contain all of the components to make an application run, as well as links to the environments where you want to deploy.

If you use a model-based ARA tool, you will be able to eliminate much of your ‘how’ issues as the tool will automate most of the steps involved.

Second Step

Next, you must decide whether you want to move an app all at once or piecemeal. To err on the side of caution, you would be better off taking baby steps so you can learn and document as you go. Ideally, you might start by just moving some specific aspects such as static web content and front-end web servers. A model-based ARA tool will help you move forward quite effortlessly, whether your targets are in an on-premise or cloud environment.

Interacting with your targets is easy, via SSH, WinRM, REST — in fact, you can choose pretty much any connection protocol. You won’t even need to define new workflows or steps for this, as the tool will take care of the changes and determine the new deployment plan. Of course, if you want to move the entire app to the cloud, ARA tools give you that option, too.

In general, ARA tools will enable you and your team to move apps to the cloud quickly and safely, with full audit trails.

Software deployment is often one of the sorest headache-inducing problems of moving operations to the cloud. However, if you use ARA tools, your problems should diminish if not disappear. Best of all: if you use a model-based ARA tool, you will be able to eliminate much of your ‘how’ issues as the tool will automate most of the steps involved.

About the Author/Tom Batchelor

Tom Batchelor is a sales engineer for XebiaLabs, a leading provider of automation software for DevOps and Continuous Delivery, helping companies to accelerate the delivery of new software.

August 26, 2015
American Psychological Association Finds CI & CD Therapeutic

The American Psychological Association (APA), the largest scientific and professional organization for psychology in the U.S. publishes the PsycINFO database with 4-million records and more than 90 peer reviewed journals, books, and other publications, starts Beverly Jamison, Sr. Director, IT Architecture, The APA. “We maintain a database of psychological tests and measures and psychotherapy demonstration videos,” says Jamison. The APA publishes member information and other data as well.

Because a broad audience including researchers, practitioners, members of other professions, students, the media, and the public use this data, the APA keeps a precise inventory of the data and its elements, checking it for quality and delivering it in a number of ways including as integrated and multimedia materials in B2B and B2C contexts.

APA Dev and Ops Before & After CI and CD

When Jamison joined the APA, some odd number of perl / shell-based coders like her used the VI editor as their IDE while others of the ColdFusion persuasion used Dreamweaver as their IDE. Developers deployed direct to the live system, at off hours, with the developers and perhaps one QA person testing AFTER the deployment was completed, says Jamison.

Today, the APA uses svn for version control for legacy development projects where they are accustomed to that and Git and BitBucket for newer projects that seem to benefit from that. “We use Ant for the scripts to deploy code from version control. For unit testing, we use X-Ray for xquery, JUnit for java, and mocha for javascript,” says Jamison.

The APA uses the Roxy community tool for deployments to MarkLogic to address MarkLogic database instances and configurations, which provides uniformity of the MarkLogic databases, explains Jamison.

The nature and purpose of each team inside Dev and Ops determines the usage of the tools. The work of the MarkLogic team dictates one application usage while the priorities of the identity and integration services team require another. The MarkLogic team deals with data services and data models that are often complex; as such they make a great deal of use of unit testing to ensure that a single change doesn’t lead to broken software throughout, explains Jamison. Identity and integration services uses Jenkins to script their builds and to ensure that each build is current; QA analysts test to ensure that their complex scenarios are reliable, says Jamison. Likewise, the UI team has still another set of priorities and usages.

A Panoramic View of the APA’s New Feature Development Process

First the developer will check out a branch from subversion to a local IDE, make and then test the altered code and run unit and regression tests on existing code, and update unit tests, configuration scripts, and any script changes needed, explains Jamison. The process would then include updating and tagging any JIRA tickets with the appropriate version number for the forthcoming release.

The code would deploy from svn to the given IDE for QA testing, which developers or engineers would run depending on the size and complexity of the system and the current system state with respect to release to the outside world, says Jamison.

“Then the code would deploy to the integrated UAT environment for testing by the business team. Once approved there, we would schedule a production release with the systems engineers handling deployment to live public facing servers,” says Jamison.

How CI & CD Impacts / Empowers This Development Process

CI & CD processes hand the developers and engineers greater freedom in adding new features, relieving their fears of doing extensive damage to existing software releases. A minor feature change or bug fix could see the steps in the above process happen in close succession as CI and CD processes avoid the risks of having to revert the code. “A major new feature or change to a data model would mean taking these steps on separate days with distinct and formal signoffs on each,” says Jamison.

Final Thoughts

In a word to the wise, Jamison reminds that while tools matter, it is how the teams commit to using them in disciplined CI and CD practices that counts.

August 26, 2015
Why I became DevOps Certified

I usually do not care too much about diplomas or certifications. To me, one’s value isn’t reflected by a piece of paper but rather by his or her actions, dedication, motivation and efficiency. And yet, I decided to become DevOps certified and furthermore, become a teacher for that very same certification. Have I gone insane or did I make a choice based on reasons that could appeal to you? Read further to find out.

Set up a standard.

I have been advocating DevOps for years now, reading everything I could about it when it was just a fun word created by Debois and recently writing quite a lot and giving conferences about it too. One thing that always strike me is that, no matter the context, no matter the experience of the people I’m speaking to, there is always one person asking me: “but can you tell me what exactly is DevOps?”.

DevOps strength is also its weakness. By not defining a manifesto, a chart of good conduct or even a clear definition, DevOps leaves room for improvement over time but also creates what it tries to break down: silos. By being so undefined, you end with people “in the know” and the others who are desperately trying to get a grasp of an idea that’s clear to many.

A certification, while arguable, brings exactly that level of standardisation we needed. By enabling me to have a clear definition of what DevOps is, it gives me the opportunity to spread it further but not only that, I also finally talk about the same thing as others around the globe. Gone are the days where you would see a new definition a minute, now that we all know – and agree on – what we are talking about, we can finally start to actually do it.

I could have stopped here, taking the certification, being all knowledgeable about that topic but it would have been a bit against DevOps’ philosophy. Sharing is caring and if I get people to understand at least the basics of I what I preach, then we understand each other better and I make others better at their job (hopefully). And that’s exactly why I became a teacher: to spread the word and get people who don’t know to finally know. People over everything else, right?

The DevOps Institute.

Ok this part will sound a bit like a commercial but I’m just going to explain the reasoning behind my decision to go with that one.

There are many certifications about the topic popping up these days so it was not necessarily an easy decision to make. After all, since we are still discussing whether or not to have a certification on that specific field, nobody was more legitimate than another. And then I read this article by our dear Alan Shimel: here.

The fact that his name was associated with a certification intrigued me and I went to check it out. Then I realized that names I was already familiar with were also a part the institute (Lisa Schwartz and Jayne Groll) which made me think I was actually facing serious people.

I read a bit more about them and discovered that both Gene Kim and Sanjeev Sharma, two persons I highly respect and read a lot from, were part of the institute’s board.

That was it! It all went super-fast after I took contact with the institute. I filled up the usual forms and in no time, I was in the program, training myself to become the trainer, reading even more about DevOps, learning some new things and exchanging with brilliant minds before taking the final exam.

What it all means

While it won’t change your life, those of you who wanted to become unicorns still have to buy a costume for that, becoming a certification trainer gives you the opportunity to meet and help people who want to know more. Whether or not they take the actual test does not really matter. What matters is that you hold the same speech as others around the world and that people who come to you with questions might leave with a bit better understanding of what it is that you talk about.

Before comments rain down on me, telling me that this is heresy and that I should be condemned to watch Nyan cats for 48 hours non-stop, I just want to precise that I do not have any interest in anything other than my job. I am just advocating for a certification and explaining why I took this one more than another.

August 25, 2015
Practice Safe SSH with Teleport

Decentralized Key Management and Sharing Is Not The Answer Practice Safe SSH with Teleport

View PostAll projects start off with the best intentions, user management and security around accounts won’t be an afterthought. Despite those intentions, the requirements to move fast tend to override things suchDecentralized Key Management and Sharing Is Not The Answer Practice Safe SSH with Teleport All projects start off with the best intentions, user management and security around accounts won’t be an afterthought. Despite those intentions, the requirements to move fast tend to override things such as account hygiene, and before you know it, you are trying to manage hundreds, if not thousands, of SSH keys and privileged accounts either manually or with a tool that wasn’t designed for key management. You also probably need to keep track of authorization privileges, and a shared document or spreadsheet is not the correct method, especially when you have systems that need to be PCI compliant or are in SOX scope.

Centralized Key Management

Does your current SSH key management strategy feel like this? Are you using manual methods to distribute and manage SSH public keys? As the number of hosts and users increase, this method becomes more and more unwieldy and also can present you with security and compliance risks. By moving to a centralized approach with Conjur’s Teleport open source solution, you are now able to benefit from the following: ● No more SSH key sharing between developers ● Each developer has their own unique login, with their own distinct set of privileges ● Simple SSH key creation and deletion

User Management

A proper strategy for programmatic provisioning and deprovisioning of user accounts is equally as important as SSH key management. In addition to SSH key management, Teleport also provides an LDAP service that allows for a customized list of users/groups that can be associated with specific projects and environments. When a new developer joins a project, you can quickly programmatically provision the account and access rights, and when a developer departs, you can revoke the rights as well as remove the SSH key.

SSH Key Rotation

Scheduled SSH Key rotation should also be part of the overall security strategy and posture, and for those systems that need to be PCI DSS compliant, SSH keys need to be rotated annually. By providing a centralized SSH key solution, Teleport allows you to seamlessly rotate the keys, as well as keep a detailed audit log around which key was rotated when.

Conclusion

SSH is a powerful tool that provides a great deal of value and security for your developers, but with that great power comes great responsibility. Teleport is a tool that allows you to provide that power to your developers while also knowing that you are practicing safe SSH and are being secure and responsible.as account hygiene, and before you know it, you are trying to manage hundreds, if not thousands, of SSH keys and privileged accounts either manually or with a tool that wasn’t designed for key management. You also probably need to keep track of authorization privileges, and a shared document or spreadsheet is not the correct method, especially when you have systems that need to be PCI compliant or are in SOX scope.

About the Author/Mike Kail

Mike Kail was Yahoo’s CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly scalable architectures, prior to joining Yahoo. Most recently, Kail served as VP of IT Operations at Netflix. Prior to that, he was VP of IT Operations at Attensity, where he was responsible for the Americas data center operations team; including managing various big data systems with their Hadoop cluster, HBase, and MongoDB components. He has been recognized widely for his insightful industry commentary on Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” He holds a B.S. in Computer Science from Iowa State University. Reach out to him on Twitter or LinkedIn.

August 24, 2015
Impacts of DevOps on Testing
I always come across a standard question from testers in any DevOps related presentation. “Will DevOps remove the need for Testers?” A simple answer is “No”. DevOps is not going to replace Testing as a discipline. Firms implementing DevOps have a vision for better product quality workable by brilliant Testing.

DevOps is an enabler for the following.
- Reduction in IT Budgets
- Efficient end-to-end delivery
- Lean delivery framework
- Working end-to-end automation framework
Successful businesses today are design thinking driven. Businesses have a strong sense of urgency, aided by innovative software engineering practices. Businesses today need to have a working continuous delivery practice in place. Continuous delivery also mandates better product quality and zero touch end-to-end delivery. Automaton is key to success across DevOps processes. Delivery by co-located, integrated teams using innovative tools prevents collaboration and communication issues.

Manual errors, Stove-piped communication issues get sorted with a good DevOps Governance model.

DevOps mandates “Fail Fast, Fail Often” driven by “Test First” concept. This means that testing is a continuous process and more extensive in nature. Testing allows for cohesiveness between various teams, automation of everything possible. Testing also allows for continuous improvement in test process delivered via iterations. Intelligent test automation, improved regression, continuous test augmentation are some benefits delivered by DevOps.
- Key benefit delivered byDevOps is the cost reduction in end-to-end delivery.Businesses achieve cost reduction by Automation, manual error reduction and reduction of duplicate effort.
  - Continuous delivery enables streamlined governance and reduces time-to-market.
  - With fail-first, fail-fast, fail-often philosophy, shift-left testing is a reality. With early defect identification, product quality increases. With increased automation, continuous testing is a feasibility.
  - With co-location, productivity of DevOps teams (design, test, operations) improves.
Implementing DevOps could be tricky in organizations having monolithic systems and processes. Culture change is critical for successful initiation of DevOps and Continuous Delivery.

From a testing standpoint, DevOps addresses the following key testing challenges.
- Test Environment – Virtualization, Automated Deployment, Automated build and configuration management, data refresh and maintenance becomes simple
- Continuous Integration, Automation and Verification – Test First centric test driven development, behavior driven development concepts allow test processes to improve in a DevOps Model
As per a report published in 2002 by NIST – Cost of Poor Quality (in US) was $59.5 Billion per year. Cost of poor quality is higher in large organizations running legacy infrastructure. By some industry guesstimates average cost of a production bug is about $7000. Customer experience and agility for quick delivery takes a hit if the organizations aren’t quicker. DevOps becomes a positive catalyst here.

Some skeptics may say “DevOps looks easy on paper but difficult to put in place”. Any innovative change is difficult to implement at first. It takes discipline and drive to run the operations watertight to achieve the goals.

Some key factors to implement for Successful DevOps are
- Cohesive, One Team mentality between teams
- Implementation and Use of Tools that take away manual effort
- Continuous Delivery Phases
  - Superior, Automated Configuration Management Approach
  - Continuous Improvements across phases
  - Continuous Automation
  - Continuous Integration
  - Continuous Testing
  - Continuous Monitoring
Use of tools is key to success of a DevOps program. Plethora of tools are available to support automation. Tools are available for Environment Build, System Configuration, Application Build, Database Setup, Artifact/Document Generation, Testing, Requirement Management, Collaboration, Production Monitoring, and Reporting across DevOps activities.

Like Agile Delivery Programs DevOps needs a strong Team Cohesion to be successful. A DevOps team need to have a Product Life-cycle Management mindset as well. This also means that team needs to unlearn standard SDLC processes. This means, DevOps team should have a clear vision. Vision to Ideate, Implement, and improvise and retire the product. An integrated DevOps team with clear vision will make DevOps projects successful.

Conclusion:

DevOps testing needs to address the need of Business and Technology needs. Automation plays a major role to achieve this aim. DevOps in principle has a goal for better product quality albeit the need for faster delivery. Terms such as “Shift-Left”, “Fail-First, Fail-Fast, Fail-Often” will be regular vocabulary in DevOps. DevOps Test team comprises of Cross Functional Specialists and Testing Purists. A Performing Testing Practice for DevOps will take some time. Testing as a practice has matured over the past two decades and is well equipped to support DevOps. Use of automation and productivity enhancement tools helps testing move faster.

Successful DevOps implementation in large firms with legacy processes and technology is a challenge. A big culture change is the only way to achieve success in such firms. It will be a hybrid DevOps Model as purist implementation will be a challenge.
August 21, 2015
Defining On-Prem

Sometimes, the meaning of a word or a phrase changes so quickly that you don’t even notice that it’s changed; at some point, you just realize that you’ve been using it differently. Take “on-prem,” for example. Not too long ago, if you said that a component of your IT system was on-prem, you meant that it was physically located at your facility. If it was hardware, the hardware was in the IT room down the hall. If it was software, it was running on a server in the IT room. But today it means something entirely different.

(more…)

August 20, 2015
Five things to understand about Enterprise DevOps Solutions
There is a lot of buzz in the industry around selling and consuming DevOps. Unfortunately there isn’t the same level of understanding or even a common definition about DevOps between consumers and service providers. In my experience the past couple of years of evangelizing DevOps, the following 5 aspects come to my mind as critical factors while considering and implementing enterprise DevOps solutions:
1. Evolving Architectural models
If you are a geek like me, and if you haven’t heard any of the following terms, you’ll probably google them immediately – Container technology, Microservices architecture, single page web apps (SPA), Node.js, mobile web apps, The Internet of things (Mobile awareness, sensors & wearables etc.), web APIs – these are the current trends in the application development space. Almost all of them disrupt traditional architectural models. And the reason I point this out is because they’ll also disrupt your traditional software development lifecycle (SDLC). The number of code & deployable units is only going in one direction, and that’s up. Very rapidly actually! That means source code management, build management, deployment & release management, dependency management, all become so much more relevant and cumbersome. The ONLY meaningful way to make these kinds of disruption manageable is through a mature DevOps approach, and a robust platform to enable DevOps. Developers always want to do the new and coolest thing. Enterprises will be well served to adopt a DevOps strategy NOW, before their own developers will cause so much disruption, that their IT strategy may fall flat.
1. Integration with existing security and governance models
More and more enterprises are headed towards a hybrid model of IT which involves traditional on-premise data centers, public cloud, private cloud and consumption of domain specific Software as a Service & Platform as a Service capabilities. Hybrid model also poses the same kinds of challenges discussed with some of the new architectural trends. How do you manage releases across so many disparate entities and providers? A centralized DevOps strategy can help mitigate issues posed in a hybrid model to a large extent. But the question is – what about the corporate policies around security and governance? Do we throw away existing tools & capabilities around change management, ticketing etc.? Disruption is a good thing for innovation, but too much disruption can also lead to disastrous outcomes. One of the key challenges that I’ve encountered while implementing an enterprise DevOps solution is to integrate the platform with existing security models and tools. Not all of them work together seamlessly all the time. But the key to success is to evaluate where the gaps are, and only bringing in new tools or capabilities where necessary, and not just for the sake of it (sell a solution, not a bunch of products).
1. DevOps enablement
One of my mentors in IBM used to say, that “a fool with a tool, is still a fool”. How true that is in the world of DevOps! Tooling is a key ingredient towards automation. In fact the concept of DevOps is not new at all, but the kinds of tools available today make automation possible in so many levels that was unthinkable a decade ago. But just providing a platform of seamlessly integrated tools for SDLC isn’t going to work. A level of “design thinking” is absolutely necessary towards DevOps enablement. A DevOps engineer should always be slotted in as a key member of this enablement team. Someone that can coach teams while starting new projects on – What elements of the tooling would apply for them? How to on-board the DevOps platform? What elements of automation are already available vs ones that’ll need to be newly created? What will be the roles and responsibilities of current team members in a DevOps world? – These are the elements that enterprises struggle with. Without a credible enablement program, a DevOps strategy is bound to be very slow in adoption, or just simply fail.
1. Transformation Investment
An enterprise DevOps platform and enablement program doesn’t come for free. I’ve constantly been challenged with questions like – what Line of business (LOB) is going to pay for it? Can’t we just use “open source” and make this all free? Can we only pay for what & when we use? All these are fair questions. And the debate about centralized IT expenditure vs LOB expenditure isn’t a new one, and will not go away either. But DevOps is disruptive enough and WILL challenge some of these old ideas and habits. “Automation as a Service” is certainly a viable option that can be availed on a consumption model. Open source tools are available by the dozen. And what comes for free with open source tools is just the usage license, and nothing else. You’ll still have to integrate them with your platform, still write automation scripts and manage them, and enterprise grade tools are usually not totally free and there is some cost involved in acquiring and managing them. All that being said, DevOps IS very much an investment. It is an investment for speed of delivery, higher quality of deliverables through automation and perhaps some cost take out in the form of reduced or re-assigned resources that were performing traditional activities in SDLC. There are several models to ascertain return on investment (ROI) on such investments, but I’ll refrain from getting into that discussion in this article. I’ll just leave this with the infamous cliché – there is no free lunch!
1. Top Down vs Bottoms up buy-in
Typically I’ve been involved in DevOps strategy conversations for enterprises at the executive levels, and they seem to be all over it. They love some of the cost take out numbers when they see it, deployment cycle time reduction and aggressive time to market fascinates them. And legitimately so. Getting executive level buy-in and support is absolutely key for any transformation to be successful, DevOps included. But just a top down approach isn’t going to make DevOps successful. It is imperative to reach out to developers and architects under each tower or LOB and get their buy-in as well. Developers and testers love their tools and methods, and are very unwilling to give them up if the strategy calls for standardization of tools (which, by the way has to happen to some degree to gain efficiencies). DevOps also redefines roles in development and testing teams through the level of automation it brings in. This causes a lot of grief amongst the staff, and as a service provider and enabler, I’m sometimes perceived as the ‘enemy’, which is never a good sign for a successful transformation. Developers and testers also have the domain knowledge around how builds are done today, what the application component dependencies are, what test scenarios are more relevant and so on and so forth, information that is so critical to understand for automation. Make friends with the developers and testers to be successful.

About the Author/ Sunil Joshi

Sunil is an Executive Architect with IBM. He is currently the Application Development & Innovation (AD&I) DevOps offering owner for Global Business Services. He is IBM Senior Certified and Open group certified Distinguished Architect. His specialization are in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. He’s created complex hybrid solutions on cloud and DevOps for large enterprises. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA).

Sunil is passionate about international music, multi-cultural cuisine, active sports and mentoring school & college students on career path and technology.

Contact Sunil on
August 20, 2015
How to lower risk in agile development
The increasing complexity of application development and subsequent rise of Agile development is changing the risk appetite in many software development organizations. Unless you’ve got an application which is highly regulated or mission-critical, it’s rarely feasible or sensible to manage Quality Assurance within the zero-bug environment often associated to Waterfall. Software development teams can become handcuffed by the lack of flexibility and struggle to maintain a focus on delivering business value. Agile methodologies paired with DevOps emphasize speed, rapid iteration and a “fix as you go” mentality over driving toward a perfect product out of the gates. So how can we lower risk in agile development?

There are other contributing factors to the growth in software risk, notably the continuing adoption of cloud computing. Given the appealing economics and flexibility for updating and repairing code in the cloud, many teams will choose to host even the most high-risk data on the cloud. Conversely, teams must focus even more attention on security, as the cloud exposes more data outside of the company’s network.

Software interdependencies are another risk; many business processes today rely upon the use of outside services from APIs to OAuth authentication. Teams must be on top of changes in these external systems to ensure that critical functionality can still operate. This is especially true in a mobile context, where even the operating system and hardware components are changing at a rapid pace.

There doesn’t have to be a trade-off between speed and quality. It takes a change in mindset and processes, however: managing software risk in the age of Agile and cloud is a whole new game. Here are a few things to consider:
1. Balance risk with business needs: A shining reason behind Agile’s popularity is the unceasing demand for speed and business alignment. Software and IT organizations have realized that in order for their employers to be competitive, they must operate in ways that are highly business-responsive and adaptive. Agile also helps organizations address the complexity of software development today, given the impact of mobile devices, the proliferation of new languages and tools for Web apps, growth in cloud-based computing and the overall importance of digital processes to a company’s success. QA teams need a more educated and informed approach to testing. That means taking on a measured approach to risk, wherein risk management tasks are implemented with business priorities in mind rather than as a one-size-fits-all strategy.
1. Risk-based testing: In order to take on more risk as part of Agile and DevOps thinking, there must be proper checks and balances integrated within the testing process. Instead of testing every feature and function, and shifting timelines, prioritize testing and quality management measures to fit business priorities. Risk-based testing commonly assigns a risk rating score for individual tests, which gives developers and QA an idea of the level of risk involved in delivering the code covered by that test if the test is skipped. As a result, the product team might spend more time testing versions of the application for devices which comprise the most important or largest sector of the customer base. However, common device types and operating systems are not the only variables that can factor into risk scores. For example, if one particularly large customer relies on a key feature or function, that should mandate additional testing around that area of the application. By linking business drivers to development and testing, organizations can still deliver quickly yet with the assurance of superior results in the areas that matter most to revenues and customer satisfaction. Ongoing testing of high priority application features also results in the avoidance of costly, wholesale changes down the road.
1. Integrate development and testing: As mentioned earlier, integration between development and testing is critical for many projects, yet it is frequently overlooked when managing Agile teams. To maximize success, there needs to be a deeper understanding between coders and testers on potential ripple effects of introducing new features as they are planned. This can occur during the everyday processes of Agile collaboration and sprint planning. Testers should know early on which are the top risk areas affected by a piece of new development; testers and developers both should incorporate development best practices which focus on understanding and planning for interdependencies, such as designing code that limits the downstream impact of integrations.
1. Best of Breed tools: The market for tools has expanded vastly along with the onset of cloud, mobile, social and big data technologies and the DevOps and Agile movements. The average IT shop is using dozens of tools for application lifecycle management (ALM), build, automation, project management, change management and testing. The newer tools, designed for Agile and Web development, allow for rapid iteration yet still provide controls and collaboration features to minimize risk. Beyond functionality, look for tools that will integrate with your existing toolsets. This will allow for faster, real-time visibility on application deliverables, new features and any quality issues that have been discovered.
Software development is more complicated today than ever. The good news is, it’s much less expensive, faster and easier to make a change in the code compared with even a few years ago. Incorporating some risk into a product is good, because it means that innovation and time-to-market are top of mind. However, introducing too much risk in high-priority customer areas or critical periods in a company’s growth can sink a business. Understanding the difference is what can allow you to keep both your customers and executives happy, with a brisk yet manageable pace of innovation.

About the Author/Kevin Dunne

Kevin Dunne is the Director of Product Strategy at QASymphony, ensuring their continued commitment to innovation and delivering tools to create better software. With a deep interest in the emerging trends in software development and testing, Kevin is dedicated to collaborating with thought leaders in this space.

Kevin comes to QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. As one of the first employees at QASymphony, Kevin has seen many facets of the business working in sales, customer support, marketing, and product management.

Kevin holds a Bachelor of Science degree from Vanderbilt University. Connect with Kevin on twitter.
August 20, 2015
How IT Operations Analytics is Delivering on the Promise of DevOps

DevOps is one of the most significant movements in IT of the past several years, and the same trends that are making DevOps so important – speed, automation, and iteration – are also opening up new opportunities for IT infrastructure management. DevOps, at heart, is a matter of adopting new philosophies of working as an IT team, while letting go of legacy processes and technologies that no longer deliver an adequate level of efficiency. DevOps is all about doing things in a more efficient, smart and cost-effective way by adopting the latest innovations, working across siloes to combine the strengths of different people on the team, and bringing different functions together to make a more responsive and effective DevOps organization.

In the same way, today’s IT operations analytics solutions are becoming more friendly to this spirit of collaboration, as infrastructure is becoming more complex and heterogeneous. DevOps teams have to work together in new ways, with different processes and different parts of the organization interacting in unique ways that might not have been expected just a few years ago. Similarly, today’s IT operations analytics world is evolving to run IT more smartly by taking advantage of new opportunities to manage the stack more efficiently.

Ultimately, the role of DevOps and the role of IT operations analytics are about developing competitive advantage. If your organization can use DevOps principles to build packages or release code faster or more accurately, you’re going to be ahead of the game compared to your competitors. If your organization can harness the power of the latest IT operations analytics innovations, you will similarly have a competitive edge because you will have a higher degree of control and visibility into what’s happening within your infrastructure. IT operations analytics can serve as an ideal complement to DevOps – because it helps to reinforce and protect the competitive advantage gains that are realized by DevOps.

Here’s what I mean by that statement: DevOps does a great job of combining speed, automation, and iteration. But as a practical issue, creating competitive advantage is more than new features, the apps you deliver must be reliable and high performance or customer expectations will not be met. IT operations analytics serves as a complement to the speed and agility of DevOps by identifying new innovation opportunities and providing “wow!” moments for the customer. With better IT operations analytics, you can exert better control over your IT infrastructure – and better control leads to bigger innovation opportunities, because you can keep the control in-house without having to rely on an outsourcer for identifying your innovation opportunities.

There are several market segments where the link between IT, the customer experience, and revenue are quite obvious. Optimizing online game play using real-time analytics is a great example, but the trend is much broader than that. With so much of the customer experience determined by IT systems, we are seeing more and more large customers moving to: (a) Continuous Integration and Continuous Delivery to accelerate delivery and (b) IT operations analytics as the way to ensure service delivery. IT operations analytics helps create the stable foundation for the high-speed and dynamic innovations of CI/CD.

With DevOps opening up an unprecedented level of speed, it’s important to have the right tools in place to process significant volumes of data. This is another area where IT operations analytics serves as an ideal complement to DevOps – because today’s IT operations analytics tools are powered by Big Data and machine learning, making it possible to achieve new levels of scalability. Unlike just a few years ago when getting a Big Data system up and running required significantly more resources, companies can get a lot more Big Data bang for the buck today than was possible even 3 years ago.

Now, companies are focusing on the analytic applications on top of Big Data, which is how businesses will find the optimization and innovation opportunities. Companies like Netflix are leading the charge in how Big Data can be used, not only to ensure service levels but also to create great customer experiences. While customer data may be the “crown jewel” of a corporation, IT operational data is the “diamond in the rough” that companies will be mining for the next big wins. We are just barely scratching the surface of what is possible with Big Data analytics of IT operational data – by drawing upon a fuller picture of what’s happening within the stack (various applications, servers, shared services, etc.), today’s IT operations analytics tools are going to help IT managers identify new insights and innovation opportunities that would not have been possible in the pre-DevOps era.

Another lesson of today’s reality of DevOps and IT operations analytics is that the divide that used to exist between customers and IT is almost gone. The future of IT is represented by the Internet of Things (IoT), where every system and behavior is monitored and analyzed in real-time, triggering operational processes from turning off a light to delighting a customer. Everyday objects, from household appliances to cars, are going to get exponentially “smarter,” and our IT processes need to evolve along with them to continually analyze, evaluate and respond to the ever-shifting ocean of data that is silently speaking to us. While DevOps and CI/CD define the trend to more rapid innovation, the collection and analysis of the reams of data generated by systems and customers will be the key to finding and maintaining competitive advantage.

This is where IT operations analytics will have an ever-more-important role as a complement to DevOps – with Big Data analytics and machine learning tools becoming more responsive and integrated into the life of overall IT operations, our IT admins are going to have more powerful insights at their fingertips each day. The convergence of IT operations analytics and DevOps will be a virtuous cycle of enhanced speed, smarter automation, and better control of IT operations for more reliable service and more delightful customer experiences.

About the Author/Omer Trajman

Omer Trajman, Co-Founder and CEO of Rocana. Omer’s fifteen years of front-line business and technical experience guide his vision for Rocana. Leading teams responsible for some of today’s largest modern database management system deployments, Omer has worked with customers and partners to identify where Big Data technology solutions address business needs. Omer’s experience in Big Data includes responsibilities as Vice President of Technology Solutions at Cloudera, focusing on Cloudera’s technology strategy and communication. Prior to this role, Omer served as Vice President of Customer Solutions at Cloudera, which included responsibility for Cloudera University, Cloudera’s Architectural Services and Cloudera’s Partner Engineering team. Before joining Cloudera, Omer was responsible for the Cloud Computing, Hadoop and Virtualization initiatives at Vertica. Omer received his Bachelor’s degree in Computer Engineering from Tufts University and was a visiting scholar at Oxford University reading in Computation and Electrical Engineering with a focus on large scale distributed systems.

August 19, 2015