Contact ITInvolve
x 


Archive for March, 2014

Create Your Own DevOps Movement

Monday, March 17th, 2014

Harnessing the power of collaboration to enable a DevOps-driven IT organization.
by Cass Bishop

I love tech tools.  During my career I have worked for and consulted with many companies, and every time I begin a project I immediately look for tools or frameworks to help me complete things faster.  For a guy obsessed with new tech tools, now is a great time to be in IT.  Git, JIRA, Jenkins, Selenium, Puppet, Chef, Bladelogic, uDeploy, Docker, and Wily (just to name a few great tools) are providing IT with a big box hardware store full of tools designed to help solve technical problems. These tools are variously pitched, sold, praised and cursed during DevOps initiatives – primarily because they are good enough for most needs but still leave some critical gaps.

With such a list, you can try to check off all the items listed in one of those “X things you need for DevOps” blogs that are published almost daily. “Continuous integration…check.  Automated testing…check. Continuous delivery…check. Automated configuration management…check.  Application Monitoring…check.  So now can I say DevOps…check? ” You probably can’t check that box and I would argue you never will with the above list of tools because, unless your IT department fits in one room and goes for beers together every Thursday, you are missing the most important concept of DevOps: the need for continuous collaboration about your applications in all of their states from development to retirement.

Most organizations I have worked with aren’t even close to this level of collaboration across development and operations. They are often dispersed across the globe working in different chains of command with different goals. How does a developer in Singapore collaborate with an operations team in Atlanta? Shouldn’t the incredible number of tools in our arsenal be enough to fix this? “We’ll give the operations team accounts in JIRA, Jenkins and Selenium then give the developer access to Puppet, Wily, Splunk and the production VMs. They can send each other links and paths to information in each of the different tools and they can collaborate in email, IM, conference calls, and a SharePoint site.” Sounds ok until you realize that each of the email threads or chats, which is filled with useful information, gets buried in employee outlook folders or chat logs. Also, when was the last time you heard someone ask to attend yet another conference call or use yet another SharePoint site?

“Maybe we should have them save the chat logs and email threads in the Operations Wiki, the Development Confluence site, or that new SharePoint site?” With these kinds of approaches, you can find the threads based on string-based searches, but anyone reading them has no context about how all of the data points in the discussion relate to actual applications, servers or any other IT asset. In addition to the lack of context, your IT personnel now spend their days hunting for a needle in an ever-growing haystack of data generated by those amazing tools.

What if, as the now-familiar adage goes, there was an app for that.  An application designed  to help bring all this disconnected data together, make sense out of it, display it visually, and had social collaboration built in.

With this kind of application, when your middleware admin needs to discuss a problem with the UAT messaging engine, she can now do so in context with the other experts in your organization. Her conversation is saved and directly related to the messaging engine. If the conversation leads to fixing an issue, the lesson learned can be turned into a knowledge entry specific to messaging engines. Now any IT employee can quickly find this knowledge and see who contributed to it the next time there is a messaging engine issue.

When developers want to collaborate with Sys Admins about higher memory requirements for their application due to a new feature, they can pull them into a discussion in the feature’s individual activity stream. The admins are alerted that they have been added to the conversation by their mobile devices and they contribute to the activity stream and can even add other participants , like the operations manager, so he can weigh in on the need for devoting more memory to the correct VMs.

No tool or application can drop in a DevOps culture for your organization – that must come from within, but there are now applications available that provide the data federation, visualization, and contextual collaboration capabilities necessary to help enable cultural change so you can create your own DevOps movement in your organization.

 


Cass Bishop is Director of Consulting Services at Houston-based ITinvolve (www.itinvolve.com). He has been a middleware, automation, and DevOps practitioner for nearly twenty years and has worked on projects in some of the largest IT organizations in the US.

 

What’s Your Discipline?

Friday, March 14th, 2014

For those of us working in IT, it’s pretty impressive the list of disciplines that have been defined over the years to manage an IT organization and the functions it’s responsible for.

In response to this, some vendors have built different applications for every discipline, which creates or reinforces silos in processes and organizational entities. At ITinvolve, we’re interested in a different approach; an approach that is grounded in information and knowledge sharing, that reinforces collaboration across silos, and arms IT knowledge workers with the information and analysis they need to do their jobs more effectively without having to go hunting for information across applications.

Our approach takes the elements you manage in IT every day from requirements to releases, servers, network devices, firewalls, policies, and much more and puts the information you need in context of those elements and the relationships that bind them together.

In this way, the information you need can be accessed and managed from multiple perspectives. For example:

  • Show me all applications that are governed by our PCI policy
  • Which requirements made the cutline for the next release?
  • If I take this server offline to upgrade the OS, what will be impacted?
  • Who is responsible for this middleware component?
  • Let me see how many instances of that database version we have running production
  • What’s in our service catalog?
  • Is there a known workaround for this issue?
  • What parameters are in this automation?
  • What are the fragile settings for this application?

This is a very small sample list of the powerful types of questions you can ask and the information freely available at your fingertips in ITinvolve.

While ITinvolve doesn’t cover every discipline in IT, we do support quite a few of the disciplines you will find in any good size IT organization.

Check them out:
Disciplines We Support

Matt Selheimer
VP, Marketing