Contact ITInvolve
x 


ITinvolve Blog

Keeping Up in an On-Demand World

January 29th, 2015

It’s a fact that business user expectations of IT continue to grow in today’s tech-heavy consumer culture. In a world where we can get access to new capabilities and services quickly in our personal lives, it’s no wonder that business leaders are seeking the same continuous delivery of new capabilities in their work lives.

Here are four tips that will help you adjust your culture and tooling for this era of on-demand IT.

Tip 1: Take notice of the level of collaboration between your company’s business unit managers and the IT department

Ask yourself, is either side pleased with the situation at present? I’ve seen companies invest in roles within IT to foster improved collaboration with the business (e.g. what ITIL calls Service Managers or what Gartner and others call Business Relationship Managers). This is a useful investment for IT organizations to make because it gives a focal point to work with the business, someone who can sit in executive meetings to understand what needs they have and problems they are trying to solve. In a lot of companies the CIO still tries to act as the “relationship manager” for every business unit and sometimes also the head of development tries to do so – these approaches just don’t scale effectively.

Tip 2: Do something every quarter to improve communication and collaboration between non-IT managers and the IT department

Standing still in this area means that communication and collaboration is likely eroding. Both the business and IT sides of the house are moving so fast that it requires a proactive communication and collaboration to maintain alignment. I hear a lot of CIOs talk about the need for an “open line of communication” with other departments and that’s a good mindset, but it’s not enough. We have to move beyond appealing to better communications and the need to align with the business. The question you should be asking is “what are some concrete actions I can take now to improve communication and collaboration between non-IT managers and IT?” One idea is the creation of relationship manager roles as mentioned above. Investing in good quality IT relationship managers and aligning up front on project scope is critical.

But even with that in place, challenges for communication and collaboration will persist. For example, if you’re relying on the relationship manager to translate and explain the business needs to those in IT who need to know about what the business is trying to achieve, the priorities, etc. there can be some big communication gaps because not everyone who needs to know gets the information, or, the business needs are changing so rapidly and people in IT are working with outdated information about business requirements. What’s needed is an ongoing dialog between not just the business and IT relationship managers, but also with project managers, developers, and even those in operations that need to deploy and run the applications.

There’s a lot IT can learn here from enterprise collaboration projects in the business (with products like Jive) and apply that to how IT works with the business. Imagine if the people working on the project in IT could “follow” and collaborate on business requirements with the business like you follow someone on Twitter or have a friend on Facebook. Followers could get updated as things change and engage with the business if there are questions or concerns. Maybe the development manager draws a cut line for the release and the business knows about that in advance and can give feedback on features that need to be added or confirm which others can wait. Perhaps there’s a policy that governs an app but operations isn’t aware of it and is going to deploy it in such a way that they would violate the policy – instead the enterprise governance team can know about it and weigh in before the deployment happens.

Tip 3: Revisit the tools and approaches you use for IT collaboration work today. Be intentional about your go-forward tools strategy

The challenge I see here (a lot) is that IT is still using the same techniques they’ve always been using for collaboration – meetings, emails, conference calls, sharepoint sites, spreadsheets. There is no substitute for meetings and face-to-face interactions and even conference calls are important, however, the challenge is how do we capture and disseminate that information so those in the meeting can refer back to it but ensure others that weren’t in the meeting can still have access to it? What about someone new joining the organization, how can they get up to speed faster without having to go to lots and lots of meetings?

IT needs a new way to think about how we capture knowledge and make it available to people in the context of the work they’re doing so they don’t have to go hunting for it on sharepoint sites, send out lots of emails, search knowledge bases etc. In effect looking for the needle in the proverbial haystack.

What we need in IT, and which we have been lacking, are cross-team workspaces. An area you could bring together the right people with the right tools and information in a workspace that was defined around the context of the activity that needs to get done – whether that’s a development project, an infrastructure upgrade, an incident that needs to be resolved, etc. And then help facilitate the team making the necessary decisions and documenting the actions that will be taken – while also notifying everyone who needs to know.

Tip 4: Accept that complexity is increasing and that your people are key to managing it not just automations

IT environment complexity is a major issue for many companies because their systems have now been linked together so that the user community can move from one system to the next easily and so that data is quickly passed between systems. So now when change comes in it can affect how multiple systems work together. As IT practitioners, we’ve been working so hard to support the business all these years and we now have a collection of lots of legacy stuff and new technologies and it’s all been woven together in a way to help the business as fast as possible.

There’s a lot we’d change if we could go back and do things over, but that’s just not practical, and so for the most part we need to work with the environments we have. The challenge is how do you understand all these integrations, relationships and dependencies, all the tribal knowledge that’s been built up in the IT organization over the years?

There have been several approaches to address this like Configuration Management Databases (CMDBs) and discovery tools, and they help, but they raise their own issues. First, there’s only so much that discovery tools can discover off the wire. They do a decent job of telling you how things are configured and relationships between them but they still miss a lot because they have to be programmed to find “patterns” and there’s no way they can discover things like policies and how those govern your assets.

The other big challenge for discovery tools is that they don’t capture intent – i.e. why things are the way they are. That’s tribal knowledge that’s in your people’s heads. Someone at sometime knew why SAP was configured that way or why a certain port was opened on that server or switch. The problem is that tribal knowledge isn’t well documented, it gets lost as people forget it or leave.

The complexity problem is really a tribal knowledge problem. What we need is a living, breathing CMDB, think of it like a “social CMDB” that leverages discovery tools but then uses crowd-sourcing and peer review, like Wikipedia, to validate what’s been discovered and fill in gaps on an ongoing continuous basis. Until we have this, IT is going to be very resistant to the pace of change the business wants, because we’ll be concerned something might break that we weren’t expecting.

This is another area where you can apply the cross-team workspace concept. The idea of not only capturing the tribal knowledge and continually validating the CMDB but then pushing that information forward in the context of planning a change or resolving an incident. So if people are following the things in the IT environment that they care about, when it comes time to work on a change, the right people can be brought together in a shared workspace (instead of guessing who to involve like in traditional change process management) and arm them with the right information and tools to provide their risk assessment. That way, when the change board goes to review the planned change, they know who’s been involved and what information they had access to and can feel a lot more confident about their decision and approve the change a lot faster to keep the business moving forward.

In summary

The fundamental business-IT challenge in a lot of companies is that the business is simply frustrated with the pace at which IT moves. Fostering good relations with business counterparts and investing in relationship managers as mentioned above is a good start. But having the business engaged in a shared workspace for projects they care about, giving them more transparency into the project and decisions being made about cut lines for releases or the like, will give them a greater sense of ownership and appreciation for the work we do in IT and how it’s not just ‘there’s an app for that’ in an on-demand world.

Matt Selheimer
Chief Technical Evangelist and SVP Marketing

Originally published at The ITSM Review

Be Sociable, Share!

    Collaboration built for IT

    January 9th, 2015

    Let’s be real. Nobody wants more email, conference calls, spreadsheets, document sharing sites, outdated visio diagrams, or knowledge bases to search

    IT teams struggle to effectively collaborate because they don’t have a shared workspace to connect them with each other and the information they need.

    That’s why we created the first application built for IT that engages the right people with the right information and tools to get IT work done more efficiently and effectively.

     

    ITinvolve_workspaces-infographic

     

    It starts with Activities. ITinvolve creates cross-team, in-context workspaces for Projects (like software development, application deployments and infrastructure upgrades); Process activities (like incidents, requests, and changes); What-if Scenarios (like impact analysis and data center moves) and Environment Analyses (quickly answering questions such as where are my single points of failure and which applications does a policy govern?)

    Next, you need to get the right People involved. ITinvolve automatically identifies all relevant experts and stakholders, engages them in the workspace, and keeps them up-to-date on the activities they are participating in.

    Then, you need to display relevant Information and Analysis. ITinvolve ensures the right information from disparate tools and sources is available to everyone using the workspace. We federate data with third-party information sources, provide direct integration to access additional details as needed, and eliminate time wasted looking for the proverbial needle in the haystack.

    Finally, you need a way to Facilitate making decisions and to document planned actions. ITinvolve guides teams through their decisions and self-documents collaborations in the workspace. For example, you can assign and track team tasks and milestones; proactively engage experts and stakeholders to assess risks, validate requirements, and conduct root-cause analysis; you can even post and collaborate around automation tool actions.

    It’s time for a new way of collaborating in IT. Improve your organization’s agility with Cross-Team Workspaces.

     

    Be Sociable, Share!

      A look back and a look forward

      December 29th, 2014

      ‘tis that time of year to look back on all that’s been accomplished and look forward to what’s in store for the next year.

      As we reflect on 2014, there are quite a few achievements we are proud of. On the recognition front, ITinvolve was selected as the best-in-class solution for change, configuration, and release management in an independent review by The ITSM Review. We were also recognized as an emerging vendor by Computer Reseller News and were short-listed as the “Most Promising Start Up” by The Cloud Awards. Not bad for a company that was founded just a few short years ago in 2011, and building upon our recognition as a “Cool Vendor” by Gartner and another best-in-class award for Knowledge Management in 2013.

      2014 was also a great year for product innovation at ITinvolve. In April, we announced new offerings to improve DevOps and IT project collaboration with ITinvolve Agility Manager and to increase understanding of and take actions to resolve configuration drift with ITinvolve Drift Manager. Along with ITinvolve Workspaces and ITinvolve Service Manager, we offer the most robust set of enterprise-class software built on the market-leading PaaS Salesforce1 – a fact that we are very proud of.

      This year also saw the IT management software marketplace evolve as organizations expanded pilot DevOps efforts and came to realize that sharepoint sites, spreadsheets, and emails just don’t cut it for enabling enterprise DevOps collaboration. In fact, Gartner called out ITinvolve and only two other solution providers at the end of November as the only companies enabling the necessary “collaborative workspace to support I&O objectives.” And more broadly, the market category of Social IT, which we believe should be recast as Collaborative IT, has moved out of the “innovation trigger” phase (i.e. early adopters) and into the “peak of inflated expectations” (i.e. early mainstream) according to Gartner’s 2014 Hype Cycle for IT Operations Management.

      So as we bid adieu to 2014, there is much to be proud of yet we are even more excited by what’s to come in 2015. If you are ready for a game-changing approach to managing IT that puts people at the center, then reach out and engage with us – we’re always interested in talking to transformational IT leaders.

      Matt Selheimer
      Chief Technical Evangelist and SVP Marketing

      Be Sociable, Share!

        The Twelve Days of DevOps

        December 17th, 2014

        In the spirit of the holidays, we present to you:

        The Twelve Days of DevOps

        On the first day of DevOps
        I finally achieved:
        Collab’rative IT

        On the second day of DevOps
        I finally achieved:
        2 Git commits
        and Collab’rative IT

        On the third day of DevOps
        I finally achieved:
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the fourth day of DevOps
        I finally achieved:
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the fifth day of DevOps
        I finally achieved:
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the sixth day of DevOps
        I finally achieved:
        6 Chef Recipes
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the seventh day of DevOps
        I finally achieved:
        7 Passed Phase Exits
        6 Chef Recipes
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the eighth day of DevOps
        I finally achieved:
        8 Milestones Accomplished
        7 Passed Phase Exits
        6 Chef Recipes
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the ninth day of DevOps
        I finally achieved:
        9 Test Suites Tested
        8 Milestones Accomplished
        7 Passed Phase Exits
        6 Chef Recipes
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the tenth day of DevOps
        I finally achieved:
        10 Bugs Resolved
        9 Test Suites Tested
        8 Milestones Accomplished
        7 Passed Phase Exits
        6 Chef Recipes
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the eleventh day of DevOps
        I finally achieved:
        11 Kanban Boards
        10 Bugs Resolved
        9 Test Suites Tested
        8 Milestones Accomplished
        7 Passed Phase Exits
        6 Chef Recipes
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT

        On the twelfth day of DevOps
        I finally achieved:
        12 Happy Biz Execs
        11 Kanban Boards
        10 Bugs Resolved
        9 Test Suites Tested
        8 Milestones Accomplished
        7 Passed Phase Exits
        6 Chef Recipes
        5 Good Deploys
        4 Gantt Charts
        3 Jenkins Builds
        2 Git Commits
        and Collab’rative IT !!!

        Be Sociable, Share!

          DevOps with purpose: ACT-ing with greater agility

          November 13th, 2014

          This is Part Four in a four-part series. In Part One, I focused on the critical first step of defining DevOps with a purpose by thinking about DevOps in the context of your organization’s applications. In Part Two, I provided four tips to fostering a DevOps culture in your organization. In Part Three, I discussed the role of tools and how they can amplify (or constrain) individual and team abilities as well as work across teams.

          In this final fourth part of the series, I’m going to weave the three previous topics of (A)pplications, (C)ulture, and (T)ools together and will show how you can ACT with purpose to start your own DevOps transformation. Your DevOps strategy should incorporate all three aspects of applications, culture, and tools. Given the breadth of those three areas, thought, it’s easy to feel overwhelmed from the start. Here’s a tip I learned from a mentor a few years ago. Whether you are a CEO, VP, or team leader, smart leaders set a vision (often at least two or three years out) and then they make small decisions every week with the goal of generally moving the organization or team in the direction of the vision over time.

          I recommend first that you set a vision for DevOps as it relates to your Applications, your Culture, and your Tools. Let’s begin with Applications. In the first article, I shared the concept of the pace-layering model developed by Gartner. To set a DevOps vision for your applications, place each of your current applications into one of the three layers – system of record, system of differentiation, or system of innovation. Then, do the same thing for any applications you are planning to add to your portfolio.

          With that context, specific to your organization, formulate a strategic vision for how DevOps will apply to your systems in each layer. Will you seek to have DevOps principles for continuous integration and continuous delivery in place for all of your systems of innovation, and if so, by when? How about for systems of differentiation? Will DevOps be the norm for each of those applications or just some, and by when? Then ask yourself the same questions about your systems of record.

          Next, turn to your culture. In Part two, I discussed the importance of baselining the degree of collaboration you have between the business, dev, and ops as well as how you view work (in workstations or in end-to-end flow terms). Then I challenged you to incentivize people to modify their behavior both with respect to their roles and as individuals. With this as context, define your DevOps cultural vision. What does collaboration between the business and development look like in the future? What does collaboration look like between development and operations? How about between dev, QA, and ops? And let’s not forget security.

          How will you recognize when your culture is optimized for flow? For example, I recommend documenting a set of indicators that you can measure at regular intervals (e.g. quarterly). Here are three good ones. How much work-in-process (WIP) do we have for Application X today vs. how much was there a quarter ago? What is the average time it takes from the definition of a requirement to its deployment in production today vs. a quarter ago? How often did we make updates to Application X in production this quarter vs. last quarter?

          Now, let’s consider tools. Take a baseline of the tools you are using today for each step of the typical DevOps tool chain from requirements management to source code control and bug tracking through to build management, automated testing, configuration management and deployment. And don’t forget project management tools too. What is the state of your tool investment in each of these areas? Do you have gaps? Do you have multiple tools in the same area, and, if so, is that okay or do you want to standardize on one? Do your tools vary based on the applications they are used with (see pace-layering discussion above)?

          Then take an inventory of your collaboration tools across dev and ops. Are you still mostly using email and sharepoint sites? What role does instant messaging play in your dev and ops teams today? What about conference calls and meetings? Once you’ve baselined where you are today, set a vision for where you want to be in the future. Are you looking to reduce the need for conference calls and meetings, and if so by how much (time or average number of participants)? What issues are you running into around email and IM communications that need to be addressed and also for SharePoint? Have you looked at the emerging class of DevOps collaboration tools and concepts such as ITinvolve and ChatOps? What role can they play in streamlining communications, keeping people informed, and presenting information to staff so they don’t have to go hunting around for it in dozens of systems or call more meetings?

          With this as background, define your DevOps tools vision by setting priorities for filling identified gaps and rationalizing existing investments, then set a general target time frame for each area.

          Now that you’ve set a vision in each area – (A)pplications, (C)ulture, and (T)ools, it’s time to ACT. I recommend you first pick one or two applications to begin your DevOps journey. Ideally, they should be applications that are visible to the business and where you can lay claim to the impact DevOps can have on business goals like time-to-market and responsiveness to customer needs.

          Once those applications are identified, take an inventory of all the people across your organization (including the business), those responsible for the development and delivery of the applications. Develop a specific plan for how you will educate those individuals on DevOps principles (e.g. attend DevOpsDays, read The Phoenix Project, read a sets of articles and watch a set of seminar or demo recordings), and also develop a specific plan for how you will incentivize behavior changes for their roles as well as what is expected of first line managers to take individual personalities, skills, and experiences into account.

          Let me also stress that you shouldnt ignore the people who arent participating in this first DevOps effort as part of your communications. Educate them as well, for example through an all-hands meeting and an email from leadership. Explain why the company is investing in DevOps transformation, why these applications have been chosen, and your long-term vision across Applications, Culture, and Tools to realize the transformation. Help them understand where the organization is going and why, and how it may impact them in the future. Avoid the perception that “the best people were picked for this and you are not among them” or that this group of people is being given license to do things that others can’t (e.g. make changes outside of the standard change management process) – otherwise, you risk reducing morale, good people leaving, and even sabotage of your DevOps efforts.

          Once you’ve completed the above, map the relevant tools you have in place today for managing the development and delivery of these applications as well as the tools on your vision roadmap defined above that will be added or rationalized in the next six months.

          By following the above recommendations, you will now have an action plan for the near term and a long-term vision you can use to guide daily decisions to move you closer to that vision. Lastly, don’t be rigid about your short-term plan or long-term vision, recognize that everyone is learning, including you, and that one of the key principles behind DevOps is the feedback loop!

          Best wishes on your DevOps journey!

          Matthew Selheimer
          Chief Technical Evangelist and SVP Marketing

          Be Sociable, Share!

            DevOps with Purpose: It’s about your tools!

            October 29th, 2014

            This is Part Three in a four-part series. In Part One, I focused on the critical first step of defining DevOps with a purpose by thinking about DevOps in the context of your organization’s applications. In Part Two, I provided four tips to fostering a DevOps culture in your organization.

            By now you’ve hopefully noticed the emphasis on “your” in this series, because, at the end of the day adopting DevOps is about your business, your applications, and your culture. In this third part of the series, I’m going to discuss your tools.

            In IT, we’re indundated with tools. Developers have their favorite tools and sys admins do too, so do the project office, the service support group, and the QA team. There are IT tools purchased by our organization years ago that we are using and others we aren’t, tools we’ve recently started using, and others we are considering at any given point in time. There are also general-purpose tools the company wants us to use for things like document sharing, instant messaging, and so on. It’s got to the point where a lot of IT organizations say, “we have two of everything like Noah’s ark”, yet they still want more tools.

            Part of the reason is that, as IT practitioners, we like gadgets and tools. We like the fact that they can help us do things and can amplify our own abilities, but we also know they can fragment information and can blindside us when someone uses a tool to do something that others weren’t aware of.

            Do we really need more tools to do DevOps?

            DevOps has a close association with the Agile Software Development movement, and one of the core tenets of the Agile Manifesto is to value “Individuals and Interactions over processes and tools”. Nevertheless, it’s hard to find a DevOps talk or article that doesn’t discuss the need for tools like git, docker, jenkins, puppet, chef, and so on. The reason for this is actually pretty straight-forward: continuous integration and continuous delivery are best done through automation so we can follow a repeatable method and roll things back quickly if there are issues.

            At a more basic level, however, we need to acknowledge that there are really two types of tools:

            1)   Tools that help us amplify our abilities as individuals (e.g. I can drive a nail into a board with a hammer much more effectively than with my hand or a rock because of the strength of the hammer’s material and the principle of leverage)

            2)   Tools that help us coordinate work across many humans, thereby, amplifying our individual abilities (e.g. I can build a house much faster and with better quality by leveraging different experts’ skills and using a shared set of blueprints for building construction, plumbing, electrical, heating/cooling, and so on)

            The same distinction holds true for software development, deployment, and operations. One individual can theoretically gather requirements, build the software, test the software, deploy the software, and support the software while simultaneously project manage their personal time. Most computer science students have done this in fact at one time or another, but when we are talking about enterprise applications that support core business functions it clearly doesn’t make sense because of the amount of effort required at each step and the specialized skills necessary for a high level of competency in each area.

            What this means is that we absolutely need tools that amplify our abilities, or that of our individual teams, i.e. the hammers; but we also need to invest in tools that help us coordinate work across teams, i.e the shared sets of blueprints.

            Tools That Amplify Individual / Team Abilities

            A lot of the tools attention in the DevOps community has been focused on: source code management systems like git or bitbucket; requirements planning tools like jira or rally; build tools like Jenkins; automation tools like puppet, chef, and ansible; and project management tools like MS project or AtTask. These tools help us amplify work in each of these respective areas just like hammers, saws, drills, and screwdrivers perform specific functions when building a house and often follow a natural sequence (first you hammer boards in place to create a wall, then hammer on the sheet rock, then saw or drill holes in the sheetrock, screw in electrical outlets and fixtures, and so on.)

            Just like building a house has a natural sequence, so does the sequence of tools from code to deployment and it’s often referred to as the DevOps “tool chain”. This brief article isn’t intended to cover each area of the typical DevOps tool chain (I could have also added bug tracking, automated testing, and other categories too), the point is you need to take time to define what the DevOps tool chain should be for your organization and to do so intentionally with a purpose, taking into account the tool investments your organization already has, the needs and skillsets of your organization, and your own practical budget realities.

            Do you have experience in using and self-supporting open source tools or do you have a preference for commercially provided tools?, Are you comfortable having multiple requirements tools in different teams or business units, or do you want a single standard? Only you can answer these questions for your organization. There is no prescriptive formula for these types of DevOps tools, although I’ve mentioned a number of commonly used ones.

            Tools that Amplify Work Across Teams

             The second area you should focus on are tools to help coordinate work and amplify our abilities across teams, i.e. bridging the inherent gaps in the DevOps tool chain, a subject that has received less attention in the DevOps community to-date. This makes sense because it’s human nature to think first about our own function and team. However, this silo thinking is one of the core problems DevOps was developed to address; the long-time focus on tools for specific IT “work stations” has actually entrenched the cultural silos of development, QA, operations, and project office in IT. For example, most IT organizations have two totally separate systems for tracking issues – in operations, it’s the service desk application and for code issues in development it’s the bug tracking application – and there is little or no relationship between them. In fact, you are lucky if an incident in the service desk can be tied to a bug tracking number.

            If we are adopting DevOps in order to optimize the flow of new software releases to support business agility, then we need to look at how we will coordinate work and avoid information distortion and loss when different teams are using different, disconnected tools. In addition to your tool strategy for optimizing individual DevOps workstations, therefore, you also need to have a strategy for the tools that are going to help you effectively manage flow across those workstations.

            Most DevOps transformation efforts start small with a core team of perhaps a dozen or so members, and their often located in one physical location. In this scenario, you might be able to make do with regular face-to-face meetings and general-purpose communication tools like email, instant messaging, and a SharePoint site or Wiki with MS Office documents. The scope of your cross-team collaboration tools aligns with the scope of your DevOps effort and you might be able to rely on people interactions to unify the tool chain.

            But as you scale your DevOps efforts to larger, distributed teams across time zones and multiple business units and applications, your cross-team tools approach should scale as well. The point-to-point nature of instant messaging, ignored reply-all emails, and SharePoint ‘document dumps’ aren’t effective in coordinating the efforts of dozens or hundreds of developers, testers, admins, and project managers. Information gets lost, information gets overlooked, and the gaps in your tool chain expand. A feature misses a commit and doesn’t get into the build and isn’t deployed. An operational requirement is missed so the test environment isn’t configured properly and the release gets pushed. Three weeks are spent solving a performance issue through code when it could have been addressed faster via hardware. A legacy application dependency in production is overlooked and the new mobile app doesn’t work in production as it did in test.

            There is an emerging class of purpose-built IT collaboration tools, such as ITinvolve, that enable the creation of cross-team workspaces where information is proactively shared as IT teams and tools get work done. This helps large, distributed cross-functional teams collaborate more effectively with each other in-context to raise questions, provide answers, and incorporate what’s happening up and down the DevOps tool chain in their individual work.

            For example, the developer will have better visibility into when the next build is going to occur and can ensure the feature is committed in time or can reach out to the build engineer in the workspace to request a delay in order to ensure the feature makes it in. The operations engineer can have earlier and better visibility into operational requirements so he can ensure the test environment is configured properly and avoid unnecessary delays. The legacy application dependency in production can be reproduced in test to ensure the application works properly once moved to production. And so on. By eliminating the handoff gaps and information loss across the DevOps tool chain, you can reduce risk of communication issues, solve problems more holistically rather than individually, and better achieve the goal of improving business agility.

            In the final part of this series, I will bring together the themes of the first three articles to demonstrate how you can chart a DevOps plan based on your Applications, your Culture, and your Tools to A.C.T. with greater agility.

             

            Be Sociable, Share!

              DevOps with Purpose: It’s about your culture!

              September 9th, 2014

              Four practical tips to fostering a DevOps culture in your organization.

              Today, we find more and more businesses putting pressure on IT to move faster, and, if their IT department struggles to keep up, they are often willing to “go around them” and invest in a cloud or other third-party solution on their own to get what they want, when they want it (aka “shadow IT”). What the business often lacks, however, is a full understanding of the many downstream implications that come with speeding the roll out of new services such as security assessments, integrations to legacy systems, the ongoing cost to administer the solution and take on support for it, etc. It’s true that Ops teams want to control the reliability and stability of software deployments and that can often slow things down, but they do this because that’s what they are paid to do: to deliver stable, reliable, and high-performing services.

              This conflict between the business’ desire for speed and Ops’ charter for security, reliability, and performance, has been brewing for several years and it’s time for some introspection and a few tips on how we can make things better. Ultimately, progress is all about culture, and that’s why defining DevOps with a purpose must include focusing on your organization’s IT culture.

               

              Tip #1: Recognize the cultural challenges between the business, Dev and Ops

              Because Development sits closer to the business in the IT value chain, there’s usually less conflict between the business’ desire to move fast and Development. That isn’t to say Dev managers aren’t sometimes frustrated by how fast the business wants things given the resources available to them, but they usually are motivated and compensated to move in sync with how fast the business wants to move.

              The first tip is to take a step back and benchmark your current culture for both Dev and Ops, because only then will you be able to understand how DevOps may impact those cultures. With Dev, ask yourself, for each line of business “Are we still doing waterfall software development with one release every year or eighteen months, or have we adopted agile methodologies that enable us to deliver multiple releases throughout the year?” Based on your answers, then ask, “Is that in line with what the business wants today? Is that inline with what we think makes the most sense or are there opportunities we could bring to the business if we adopted agile more broadly?” Finally, “what would be the value to the business and cultural impact of adopting DevOps principles for continuous integration of new software development?”

              Next, ask yourself, “How focused is our Ops team on stability, reliability and clamping down on change vs. accepting (and even desiring) change? And how does this vary by line of business or application area?” If you have a risk-averse Ops culture that’s supporting a fragile infrastructure or many legacy technologies, then you may need to tackle some of those challenges first in order to help your DevOps culture evolve. I also suggest looking at your Ops culture through a compliance lens. Ask yourself, “Are we in a heavily-regulated industry that has created its own cultural challenges in terms of change approvals and auditing that we need to take into account?” Finally, what would be the value to the business and the cultural impact of adopting DevOps principles for continuous delivery of new releases?”

              One of the hallmarks of DevOps is the ability to develop smaller pieces of incremental functionality, deploy them faster (perhaps even a few times a day), and quickly roll things back if there’s an issue. This is a big leap for many IT cultures on both the Dev and Ops side so understanding where your culture is today is a critical first step.

               

              Tip #2: Think about how you view work

              Do you view work as tasks done by individual teams or in an end-to-end fashion (e.g. from raw materials to finished goods and customer delivery)? DevOps transformation requires focusing on work in an end-to-end manner. Your goal should be to identify where your IT organization’s bottlenecks are, with the intent of reducing pressure at those bottlenecks to increase end-to-end flow and, therefore, output that benefits the business.

              In The Phoenix Project, the bestselling IT novel (yes, indeed an IT novel) co-authored by Gene Kim, Kevin Behr and George Spafford, the character of Brent Geller in the Ops team is an obvious bottleneck. He understands his company’s IT environment better than anyone and is consumed with both solving high-profile outages and deploying new application releases, the result is that he’s constantly putting out fires and unable to get new software released that’s desperately needed by the business. The book offers a wealth of perspective on how to embrace DevOps principles and what that means for your culture. I highly recommend it. You will likely see quite a bit of your organization in the story, I know it matched my experiences in IT very well.

              Back to Top #2, ask yourself, “Is my organization optimized around end-to-end flow or are we optimizing just at the individual workstations?” If it’s the latter, then you are probably stacking up work somewhere at one or more bottlenecks and should address those first. For example, a development project isn’t done until the code is tested and deployed. So incentivizing developers to finish code without knowing when and how it will get deployed is just going to create more work in process stacking up in your IT factory. It’s just like on an automotive line where you might see cars with shiny paint, brand new tires and cutting edge technical design, but if the cars have no seats they simply won’t be shippable.

              You might also be saddled with a lot ‘technical debt’ – where dollars and resources are tied up maintaining existing applications and infrastructure. It may be necessary for you to focus at first on reducing technical debt in order to reduce those as bottlenecks on your support and deployment teams. Ask yourself, “What technical debt do we have and who can be charged with prioritizing and reducing it?” Treat it just like credit cards and look to reduce the ‘high interest’ debt first.

               

              Tip #3: Incentivize your people

              Don’t assume people will change for the “greater good” – proactively incentivize them to do so.

              If you want to change your culture and create one that’s more agile – if you want to optimize for flow versus workstations then you should incentivize to initiate the cultural change you seek. Old habits are hard to break even when we want to do things differently. As executives we have the tendency to appeal to a higher business purpose and assume the folks contributing on the front lines share the same passion for the company’s success. Often they intellectually understand these goals, but you should seek to make the change relevant to how it will improve their jobs as developers, QA team members, sys admins, and architects not just how it impacts C-level objectives.

              For example, Ops folks usually take particular pride in their indispensability, but to be indispensable they have to compromise family time, working late and on weekends to push out a big high-risk deployment. They may crave the attention and recognition for such ‘extra effort’, but at the same time they are putting more pressure on themselves and more risk on the business.

              As mentioned previously, the move toward a more agile IT means deploying with far greater frequency, and that can actually help you operate with less stress and risk. Errors and fixes are likely smaller in effort, and you will be able to roll back hick-ups much faster. Sure your folks may need to stay late occasionally, but they can do their work more often during typical working hours, reclaim their weekends and have significantly less stress and pressure than via traditional large-scale rollouts where expectations are high and so is the risk of failure, re-work, and long days. Plus, with DevOps you are actually delivering on business requirements faster – instead of deploying what was needed months ago.

               

              Tip #4: Make it personal: everyone is different.

              Related to Tip #3, realizing that everyone is inherently different is critical to incentivizing and empowering your IT team to transform. In most IT organizations, the responsibility is on the first line manager to know their people, understand what makes them tick and channel the right talents and motivations. Some may be seeing a move to DevOps as the ideal resume enhancement opportunity. Some may feel intimidation because they are innately risk averse. Still others may not be sure what to think especially if you have one team doing DevOps while they remain on a separate team doing things “the old way”. What’s important for managers is not to stop at how to make DevOps relevant for a role, but to consider the specific individual. Ask yourself, “How will each of my team members react to this cultural change, and how can I tap into their natural motivations to make them enablers of the change not resistors?”

              From what I’ve seen, there also is a generational aspect to DevOps cultural transformation. Younger employees who don’t know a world without mobile phones and grew up on social media are likely more comfortable with agile, small release deployments. Those with more experience are also more likely to think about the reasons why DevOps ‘can’t work’ and it will be key for first-line managers to engage them, listen to their concerns, and work to address them in a way that benefits the organization and realizes the wisdom of their experience.

              The bottom line for Tip #4 is that if you make it personal you will build trust and that will help you to drive transformation in your organization faster. Perhaps even consider establishing a ‘Take a Developer or Ops Team Member to Lunch Day’. By working to understand each other’s worlds, challenges, pressures and goals you can unleash a swifter cultural change within your organization.

               

              Matthew Selheimer
              Chief Technical Evangelist and SVP of Marketing

              Be Sociable, Share!

                It’s time to evolve to ITSM 2.0

                August 20th, 2014

                Tickets are useful as a status tracking mechanism, but when did our industry decide chasing tickets was the best way to manage IT support and operations work?

                We think it’s time to evolve to an ITSM 2.0 approach that puts the focus on ensuring IT support and operations teams have the information they need to solve issues instead of chasing and filling out tickets after the “real work” is done somewhere else.

                To understand more of what we mean by ITSM 2.0, check out these free resources:

                If you want to get to ITSM 2.0, just click on contact us at the top of the page or call 877-741-8944 and one of our experts will be in touch soon.

                You can also sign up to try it now.

                Matthew Selheimer
                Chief Technical Evangelist and SVP of Marketing
                ITinvolve

                 

                Be Sociable, Share!

                  DevOps With A Purpose — It’s About Your Applications

                  August 8th, 2014

                  Unless you’ve been living under the proverbial rock these days you have no doubt heard about DevOps and the groundswell building around it. Today DevOps is being defined, promoted, touted and discussed as the next game changer in IT. Rather than argue about the best way to define DevOps in a general sense, this article will focus on something hopefully more useful – how do you determine what DevOps means for your organization?

                  A common goal cited for DevOps is to enable faster release and deployment cycles by taking advantage of agile development methodologies; improved collaboration between business stakeholders, application development and operations teams; and automation tools. Beyond these elements, DevOps also requires a cultural acceptance of the need to focus on the flow of work across teams vs. simply optimizing individual teams and their specific units of work.

                  By contrast, defining DevOps with a purpose means ensuring how you do DevOps is grounded in the realities of your specific organization. There is no “one-size-fits-all” DevOps, no matter what pundits, consultants, and vendors might tell you. Start by actually taking a step back. Ensure you are clearly taking into account your industry, your applications, your culture, and your people when developing your DevOps strategy; then apply DevOps principles against that foundation. Because every organization’s purpose will be different, your way of doing DevOps will not be the same as anyone else, even among your industry peers.

                  There are, however, some general guidelines you can start with and then apply them to your specific situation. For example, I recommend analyzing your business goals and application portfolio using the pace-layering method, which focuses on three categories of applications – systems of record, systems of differentiation, and systems of innovation.

                  Systems of record are usually quite stable with infrequent updates. This is often due to regulatory requirements and internal policies for these systems, and they tend to have a high degree of consistency within an industry and even across industries. Systems of record are often good candidates for waterfall development methodologies and longer release timelines. Your general ledger or payroll systems are good examples of systems of record.

                  Systems of differentiation are those applications that are likely common to your industry but where you have an opportunity to differentiate your company from the competition based on functionality and the pace with which you update them. For example, if you are a financial services firm that provides retirement investment programs, you might make changes to your customer portal and how clients select new investment options on a quarterly or monthly basis in order to enhance customer experience and remain competitive and differentiate. If you are an airline, this might be your crew scheduling application, which ensures you have the right flight crews available when needed and can improve your on-time departure percentages to differentiate from the competition. In healthcare, your systems of differentiation might be the applications that health professionals use to store patient information and correlate test results to aid in diagnosis and treatment. In manufacturing it may be your supply chain management, process control, or shop floor applications.

                  Systems of innovation are those truly groundbreaking applications that help you create new markets and revenue streams. In financial services, that might be a new kind of application that gives day traders a market advantage. For an airline that might be a whole new way of providing inflight entertainment, such as when Wifi and inflight entertainment first became available to passengers. In healthcare, it might be a new customer portal that promotes wellness services and reduces office co-pays by uploading fitness tracker data. For a retailer, it might be applications that support a new type of customer loyalty program, such as when Amazon introduced their Amazon Prime service a few years ago.

                  Both systems of differentiation and systems of innovation are excellent candidates for agile development and DevOps principles. This is because they require high degrees of collaboration between business stakeholders, developers, and operations personnel to ensure the applications are in line with requirements, developed and tested quickly, and then made available in the market to drive differentiation and innovation. They are excellent candidates for the continuous delivery concept in DevOps where small releases are deployed quickly (and can be rolled back just as quickly if there are issues). In this manner, a large number of small deployments moves the competitive needle faster and provides greater value to customers over traditional waterfall development and disconnected development and operations practices.

                  Defining DevOps with a purpose starts with an understanding of your industry and your applications. In the next article in this series, we’ll turn to the topic of organizational culture and its impact on DevOps transformation.

                  Matthew Selheimer
                  Chief Technical Evangelist and SVP of Marketing

                   

                  Be Sociable, Share!

                    Knowledge is Power:

                    June 16th, 2014

                    A breakthrough approach for Change, Config, and Release

                    Today, we were thrilled to find out the ITinvolve has been awarded the best-in-class designation for Change, Configuration, and Release Management by the independent ITSM Review.

                    This award acknowledges what our customers already know and reflects the vision, innovation, and effort that ITinvolve’s R&D organization has put into building a breakthrough solution for a rather stagnant market. The result of a months-long evaluation that included extended demonstrations and deep dive Q&A with an independent expert, we are simply glowing at what they had to say:

                    “ITinvolve has taken huge strides in the ITSM arena with Service Manager by embracing the adage “knowledge is power”.  We feel that the developments that ITinvolve Service Manager has made with the fundamentals of knowledge and collaboration, ensuring that all relevant information is available to the right people at the right time (and in a straightforward way), enables risk assessment capabilities that far outweigh those of other ITSM solutions. This provides increased value to its Change, Configuration and Release capabilities.”

                    “The way that these capabilities support and mold Change, Configuration and Release creates a product that gives control, intelligence and awareness back to the IT organisation.”

                    “ITinvolve Service Manager is a progressive and ambitious product. Uniquely combining knowledge capture, analysis, and social collaboration, Service Manager proactively delivers timely and relevant information whenever needed.”  

                    “…regardless of the size of your organisation, we strongly believe that you can’t go wrong with considering ITinvolve Service Manager as your ITSM tool for Change, Configuration and Release.”

                    Learn more about ITinvolve Service Manager and sign up for a free trial.

                    Matthew Selheimer
                    SVP, Marketing

                     

                    Be Sociable, Share!