Tag: agile

  • DevOps Hiring: What Do You Need?

    DevOps Hiring: What Do You Need?

    IT has long had a problem with hiring. I’m not certain where it started; most of us blame HR, and that’s probably incorrect, but gives us someone to blame. It’s that we post jobs with insane requirements. Sometimes this is done to keep the applicant pool down, but most of the time it is a simple case of throwing in the kitchen sink. We have laughed at advertisements that wanted applicants to have more years in a given technology than the technology has existed. The laughter was because someone quipped, “So what we really want is only liars to apply.”

    But it doesn’t stop there. How many advertisements have you seen for a person to join an already good-sized team of developers, and the requirements include experience in every single language/tool the person might encounter—and sometimes ones the organization might use in a year or so? And DevOps, with its increase in toolsets and broadening complexity, make this problem worse.

    If you want good DevOps team members, you have to focus your search. We’d all love to have unicorns who could do it all on day one, but those people don’t really exist. Even with experience in every single tool in your chain, they still have to learn apps and environment. Try to craft job requirements that focus on the couple of core tools, and then filter for ability to learn and adapt. Because the only certainty about IT at this point is that technology will be shifting, so focusing on the tools you are using today is pretty limited.

    Role plays a part in this also. While we like to pretend DevOps is one thing, it is a rare application or portfolio for which there are not specializations on the team. If you are looking for someone who will lean more toward the DEVops side, do you really need them to be operational wizards with three years each in storage, networking and container management? Conversely, if you are hiring someone more for the devOPS side, do you need them to have expansive experience in Javascript, or do they just need to know who to call if it gets beyond their ability?

    Maybe your company is one of those shops where everyone on team X is expected to be an expert at everything. Kudos for you, but there aren’t a ton of those people out there. There is a different mindset to DEVops versus devOPS, and even if unofficial, most employees lean one way or have a more proficient side. If a candidate fits the bill in an area you are weakest, consider training them on the job in the area you are strongest, rather than waiting for who knows how long for the perfect person to fill the open req.

    And we still have a need for hardware specialists. I’ve said it before, but do you want your EMC (or Cisco or whomever) person to be a generalist, or do you want that person to make the infrastructure that underlies a huge chunk of your applications hum? Hire specialists for specialized skills, hire broad knowledge for app-spanning needs.

    It’s been a problem for years, and only you can fix it. Call out overambitious job postings and make managers ponder what they’re actually looking for. You know you have a need, you know what the position will do. Help hone down postings so that they fit the actual requirements, not some blue-sky version of potential requirements.

    And get the best people for the job. After all, you are going to have to work with them.

    — Don Macvittie

  • DevOps and Agile: Your New Year’s Resolution

    DevOps and Agile: Your New Year’s Resolution

    Don’t apply Agile principles to DevOps. That’s not how it works.

    We in the west often celebrate the new year with a promise to do more or less of something in the coming year. While these promises are often broken, they can occasionally be transformational.

    And it’s time your organization had a transformational one: More DevOps, less Agile++.

    It is still a pervasive issue that people look at the successes of Agile development and attempt to apply them to the operations side. That’s not how it works. Really. There is a fundamental difference between DEVops and devOPS that means what is perfect for one is terribly imperfect for the other.

    While having a developer who specializes in the language du jour is important for a DevOps project—just like having a systems administrator that is proficient in given platform X—that really is where the similarity ends.

    Operations is a daily thing. It takes specialized knowledge and uses it to keep systems purring along on the chosen platform with vendor X, Y and Z. For a lot of organizations, storage has moved to the cloud. For a lot more it has not, and there is a difference there. But in the end, management of that massive blob of storage falls on your storage specialists. If your environment is internal, they’re worried about hardware and software both, but even if you’ve taken a massive leap to the cloud they have access and backup and hierarchy concerns.

    And given our worry about virtualization sprawl, a large number of organizations seem to have pitched that out the window when cloud and DevOps came along. Those instances still need monitoring and management, even if some of it is automated. In fact, the growth in numbers pretty much negates the automation goodness.

    So take a close look at the devOPS side of your operation. Think about it. Include it in DevOps from the start, rather than applying Agile principles to a group that it just doesn’t fit well. We’ve (mostly) gotten past the “Developer is Kingmaker” mentality, and have started to reintroduce standards so that we don’t have 50 different database products to support. But far too many have yet to truly approach DevOps as an integrated whole that relies on the wisdom of operations—even though operations is going to be involved with this project far longer and more intimately than development.

    And they are disparate functions. DevOps makes getting to market and maintaining the application far more streamlined, but when it comes down to it, 90-plus percent of you aren’t keeping a java developer watching an application for life. They’re moving on to the next project, and operations is left with more of development’s input and advice than previously, but all of the responsibility.

    So step up, apply DevOps in the manner it makes sense for a given bit. If you are running DevOps on VMware, operations input will be different than if it is on physical servers or public cloud or private cloud. Take that input and develop around it. Personally, I’m a fan of application release automation (ARA) for achieving the melding, but however you do it, don’t say, “We’re DevOps,” and mean, “We’re going to wedge Agile into the entire org,” anymore.

    And have a great year! Here’s to more apps, more responsiveness and more security!

    — Don Macvittie

  • Common Hidden Dependencies and How to Uncover Them

    Common Hidden Dependencies and How to Uncover Them

    It’s no secret that a truly Agile approach minimizes the risk organizations assume with waterfall or other traditional project management methods, by letting teams iterate and inspect and adapt as they go. But many companies lack clear visibility into real-time dependencies at the team level—even with daily standups, iteration and release planning, and a regular cadence of cross-team check-ins. This lack of visibility impacts organizational agility and can erase the value of an investment in agile.

    As Dwight D. Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” When it comes to planning within an enterprise, being aware of the biggest risks of hidden dependencies will help you keep a proactive approach and drive value from strategic objectives to tactical execution. Here are some of the risks of the most common dependencies and how to uncover them:

    1. Teams that are distributed (or use multiple Agile platforms) do not have the flexibility to work across teams as easily as their co-located counterparts. This slows down response time, which in turn slows down releases. Teams must make dependencies transparent at the highest level to stress their importance. Make sure your team has an advocate, such as a Scrum Master, to raise red flags when dependencies or risks emerge.
    2. Medium- and large-scale organizations may run multiple release planning sessions for one product. Running them at the same time, or in a sequence but in different locations, increases the risk that teams will overlap work and not plan for dependencies.
    3. Many organizations and teams try to plan for dependencies by adding more time to their estimates as a buffer. While this seems like a good idea, it hides a problem by burying wait time and masking the real blocker. Organizations and teams should ensure that estimates are only based on complexity and effort and do not reflect “waste” such as wait time. Doing so helps reveal impediments for what they are.
    4. In larger organizational structures, infrastructures are complex and teams tend to be highly dependent on one another delivering work, with a chain effect of one team’s work beginning only after another finishes. As they look to adopt and scale Agile, organizations should closely examine their structure to ensure it is optimized. This will reduce risks and dependencies, rather than exaggerate them.
    5. Team members often allow “blockers” and “dependencies” to get in the way of completing work while still committing to a sprint or release goal. If team members foresee a dependency or blocker with key features, user stories, etc., they should not commit to the work. It is the responsibility of each individual to refrain from committing to work that they know they cannot complete.

    Visualization is Key

    Organizations can adequately manage dependencies and risks if they can plan for them. One helpful technique is to create a road map for releases. When consistently updated throughout at the end of each sprint, a road map helps teams identify risks and evaluate dependencies continuously. Selecting a platform that allows real-time visualization into dependencies is another way to prevent time-wasting while giving insight into the right details at the right time.

    — Andrey Mihailenko

  • Boxes vs. Services: The Infrastructure Equation

    Boxes vs. Services: The Infrastructure Equation

    Infrastructure is changing as more services replace the need for hardware-based architectures

    There has been a lot of change in the last few years, and that change shows no sign of slowing down. I’m one of those people who likes to know they could work offline if needed, yet in this day and age if you want me to install a fat client on my laptop, I go looking at your competition.

    Granted, for me the selection of these apps is small—I like having Office on my desktop to be able to use it to write or create presentations at will, regardless of whether I’m connected—but for most people, it is growing at a faster pace. The idea of buying a monolithic system that you have to install and maintain is becoming less and less appealing.

    That same syndrome is occurring in the data center, too, but with a twist. It is largely infrastructure that is feeling this pinch. Just prior to cloud/container mania, the idea was that each non-compute box in your infrastructure was a platform. It offered you a ton of functionality, all designed to simultaneously lock you in and help you get your job done. All in all, it wasn’t a bad trade-off, and we can see the same idea in the large public cloud vendors.

    The difference is, with an infrastructure box, you were making a serious investment upfront that offered you other functionality to sweeten the deal. Once that investment was made, it was natural and realistic to want to take advantage of the bundled platform functionality rather than search for yet another box to drop in your network.

    Containers and what survived of software-defined networking (SDN) have changed all of that. The ability to quickly spin up something in software that fits your needs perfectly and can be automated with your DevOps toolchain makes the idea of a platform box—with its high cost of entry and bells and whistles you will never use but might have to lock down—seem quaint.

    In the agile/DevOps world, boxes for low-level infrastructure are still necessary. Don’t get me wrong on that. If you are a large org, you are using one of a few vendors to do core switching and routing. But top-level (layer 4-7 and 8) networking is not something you would use those static boxes for.

    It used to be that all networking functionality was the same—it needed to be rock-solid and slow to change to guarantee that apps were functional. Over the last few years we have seen a move from “all networking is networking” to “this is low-level stuff that must be rock-solid, that is closer to application layer stuff that we can change rapidly, and thus need not be in the ‘rock solid’ category.” Load balancing is a great example of this (and yeah, I used to work for F5, which is the king of load-balancing): Load balancing was a network function that you went to a hardware vendor for if you were beyond a certain size. The resulting physical box might serve one or 100 apps and required specialized training or experience to manage.

    Today, load balancers are a systems function that you go to a software vendor for and work into your network with as many copies of the software load balancing as you needed. Or you turn on load balancing within your container management system and manage it there. Either way, it fits in with your agile/DevOps environment better, and is easier to get budget for your project.

    I expect to see this change intensifying. There is power in physical boxes for some things, but there is also power in portability and packaged deployment scripts. And a physical box is not portable to a public cloud, nor is it readily dropped into container management tools (though container management integration is getting better in most network security/performance appliances). Portability and ease of use will win over technical edge, in my opinion. Not because people are cheap and lazy, but because portability is key to agility and they are too busy.

    There are still things that just aren’t that portable, and I have yet to see convincing tools to make them that portable. Data is my go-to example because it is easy. If you have 2TB of data, your portability options are limited. For those with 2PB of data, there is no real option; the app is going where ever the data is, and that data is unlikely to move. Oh, if you were motivated, there are ways to move that much data, but then you’ve just shifted the problem to the new platform, because the data is still largely non-portable, and apps will have to go where the data is. Again.

    But for most functionality? Anything that can be made into highly portable software will be. And that software will run wherever it is most needed or most beneficial to the user.

    All in all, this is a good result. Multi-core, multi-network, multi-terabytes of memory PCs can rival many appliances for speed and functionality, and portability plus ease of integration makes software a winner. Just stay aware of where/when a physical box still makes sense, because the world doesn’t change as fast as high-tech marketing wants you to believe. A working appliance that does what is needed quickly should not be ripped out just because a software solution is available.

    But you knew that. Because you all rock. Keep kicking it, and use whatever solution serves the business best—which is a different equation for every business.

    — Don Macvittie

  • Where is the Next Generation of Mainframe Talent?

    Where is the Next Generation of Mainframe Talent?

    Are we potentially facing a shortage of mainframe talent?

    “Three of us set up this tool in 1989. One is retired, and the other person is somewhere in heaven!”

    That was the remark of Alf (name changed), the senior mainframe architect at a large European enterprise, as he pointed toward the ceiling of the meeting room. Everyone else in the room let out a half-nervous smile, unsure how to react to the statement and hoping for some visual cues from Alf. We were all talking about a specific version control and packaging tool on the mainframes, which was heavily customized to suit this particular enterprise. The attendees were a mix of DevOps enthusiasts and mainframe architects and engineers with the purpose of re-evaluating the existing tooling stack on mainframes with a view to modernize them as part of a wider agile/DevOps initiative. Alf’s remark in the meeting has stayed with me ever since.

    Later that week, I was having lunch with a group of new joiners in the technology department, who were all part of a greenhouse initiative to in-source digital skills. During the conversation, I asked which areas where they focused on and the career direction they had in mind. The answers were predictable: data science, python, Nodejs, UX, blockchain, JavaScript etc. If all the new kids on the block are learning the newer technologies, then who will take over from mainframe people over the next few years when they retire?

    The reality is that 96 of the world’s top 100 banks, 23 of the 25 top U.S. retailers and 9 out of 10 of the world’s largest insurance companies run IBM’s System z mainframes. Most digital transformations have barely scratched the surface of the legacy stack.

    Like many other enterprises, this enterprise had outsourced most of its application estate to IT service providers. In few years’ time, Alf will move to a well-deserved, retirement phase of his life and take his mammoth knowledge base that the enterprise  had always taken for granted. There are many more Alfs across various enterprises today with significant mainframe know-how who are set to disappear from workplace over the next few years, making these enterprises entirely dependent on external service providers—so much for those bold visionary statements for the CXOs such as, “Technology is business and business is technology.”

    Most enterprises today have ambitious digital transformation agendas, investing millions on various initiatives ranging from digital, DevOps, agile, UX and blockchain. This will manage to “DevOpsify” the enterprise skin (aka front end, customer experience layer, or mode 2 apps) and, in many cases, possibly, their non-legacy middle-end system as well. However, the majority of the back-end stack, especially in financial services, remains in the legacy world (zSeries  or iSeries).

    One might argue with a seemingly coherent logic that, “Well, we won’t have mainframes in a few years as we will move to newer platforms soon.” But it helps to remember Mark Twain’s quip, “The rumors of my demise are greatly exaggerated,” applies so well to the mainframe world!

    In simple terms, your enterprise most likely will adopt a combination of the following strategies to deal with the legacy challenge:

    • Retire mainframe app, in some cases.
    • Extract business logic and move it to distributed platforms.
    • Componentize the monolithic mainframe code and hook them to APIs for external consumption.
    • Build new platforms to replace legacy apps.

    There is one least common denominator for any of the above strategic direction that your enterprises take: ever-diminishing mainframe knowledge! So, I ask again: Where is the next generation of mainframe talent?

    — Aditya Vadaganadam

  • Empower Agile Teams with a ‘Bell Curve’ Approach

    Empower Agile Teams with a ‘Bell Curve’ Approach

    There’s no feeling better than ending a project on a high—until you notice the mountain of work looming ahead for your next project. At those times, it may seem hard to start grinding all over again. The struggles of adjusting to new teammates or a new client can be daunting. When a new project kicks off, early success is a must. Quick wins secure the customer’s trust and help keep projects moving swiftly. Agile methodology has proven to be one of the most effective delivery models for early wins: According to Harvard Business Review, innovation cycles can be compressed by more than 75 percent thanks to agile.

    But in search of these early wins, teams often bite off far more than they can chew. They take on the brunt of huge projects before being fully prepared. To be self-managing, teams need to take into account their group maturity before tackling new projects. So, how can teams make sure their delivery models and their maturity models are aligned?

    Solving Team Maturity Issues with a Bell Curve Approach

    One of the clearest ways for teams to make sure that they are taking on appropriate projects at appropriate times is for them to follow a bell curve approach.

    The idea is to follow the agile delivery model, prioritizing risky unknowns and high-value work early, but not too early. First, the team needs to ramp up, ensuring that team maturity is at a high-performance level. The team dynamics models of Bruce Tuckman or William Schutz are helpful to understand how to put together and develop a group to autonomous self-management and hyperperformance.

    By requiring teams to focus on less complicated projects first, a bell curve approach allows teams to adapt and refine their practice as they work their way up to the most difficult tasks. Similarly, the approach ramps down after the most complex iterations, increasing the chance of success and lowering risk. Here’s how teams can follow a bell curve approach:

    Warming Up

    The ramp-up period is part of the front end of any successful project. During this phase, the team learns its way around each member’s style. Some hiccups and tension will naturally occur during this phase, but the idea is to work it out early so that everything is running at peak optimization for the height of the curve later on.

    Think of it this way: Old cars with carburetors needed to be warmed up during the winter months before they could run. Gasoline is thicker in the cold, and the fuel must heat up so it can mix with air and reach the vaporization point to be used by the engine. Otherwise, the vehicle risks stalling out.

    That’s how I like to think of this stage of the project. We must first regulate the environment and work out the kinks of the team before we move forward. If we don’t control for a good foundation, the team and project may later stall out in the middle of a critical stage.

    Find Your Peak

    After the team finds its rhythm during small, early challenges, it’s time to ramp up and get the real business done. While there still may be smaller tasks to accomplish, you’ll get to those later. Now is when you want to capitalize on fresh energy right as your team hits its stride to deliver on the the most critical portion of the project.

    This phase—at the height of the bell curve—is a true test of the rhythm that a team has found. Don’t be surprised if some moments give way to tension as the members push through the most challenging portion of the journey.

    Coming Back Down

    On the way down from the peak, work intensity slows as the team starts completing the lower priority pieces of the puzzle purposely left aside when the project kicked into high gear.

    In addition to tying up loose ends, a slower period on the way out of a project provides the opportunity for reflection. What would you do differently during peak time on the next round? What aspects of the project can use fine-tuning? These important questions are much easier to consider with a clear head and a shorter to-do list after the most critical and complicated components have been put to bed.

    This sort of approach is not only applicable to software development teams. From administrative to marketing, teams across an enterprise can institute a bell curve approach to their big projects. By embracing agile methodology, any team can streamline its members’ output and decrease risk in high-pressure, mission-critical projects.

    — Patric Palm

  • Agile Service Management in Practice

    Agile Service Management in Practice

    It turns out agile and service management go together quite nicely. But how, and how do you translate the agile philosophy to actual changes in your work? There is much to learn on the topic.

    Agile Service Management: A Checklist

    Here are several practical examples on how to make your service management more agile:

    Make Sure Everything You Do Adds Value for the Customer

    IT departments usually place a good deal work into tasks that have little actual value for their customers. For example, a colleague of mine recently visited an organization where its IT department had written an extensive manual for a new smartphone it offered. While this might sound useful, most of the information was already available to users on the internet. That and next OS update would have made the manual outdated and useless.

    Plainly speaking, this is a waste of time and resources. There’s no need to replicate work already done and content that is readily available anywhere on the web. Taking a focus on agile, a better way to go may have been of documenting information to keep the manual limited to what is strictly necessary, and provide these instructions to a small test group. In doing so, only describe company-specific information, such as how to synchronize your work email with the new smartphone, and respond to the documentation based on the feedback you receive from your test group. Following this feedback, you are able to update the documentation before you officially begin to supply the smartphone, for example.

    Always Work Closely with Your Customers

    As it designs its services and processes, service organizations must make many assumptions about the needs of its customers. For example, for years a facilities organization encouraged its customers to log a call when something was wrong in the office building. Recently, it discovered that customers were annoyed to receive five or six status update emails after they log a call—one reason many customers stop logging calls altogether.

    In agile service management, you always involve your customers as soon as possible with everything you do. Using the example above, come up with a solution together with customers. When customers log a call, they can tick a box saying they want to receive status updates. One question and a single checkbox can spare a great deal of frustration.

    The Right People in the Right Place

    Many IT organizations lean heavily on processes, unfortunately, but their goal is to guarantee consistent quality of services, no matter who supplies the service. While good in theory, in practice it matters who supplies a service. For example, an unmotivated service desk likely probably leaves a less-than-positive impression on your customer than a happy, motivated employee. You simply can’t cover this outcome with a “process.”

    An important part of the agile mindset then is providing enough time and attention for your team members, which only functions well with people who are good at the work they do and when the work they do makes them happy. If a team member is no longer motivated, talk to the employee and see if you can find a role where they’ll be happier, and better able to support the organization as a whole.

    Make Your Processes as Flexible as Possible

    ITIL processes are usually not flexible, to say the least. Change management is a great example. A request for change must go through a set number of predefined steps. The only choice you usually have in the process is approve or decline the change. There’s no room to change plans and if you want to change them, you need to stop the process, make a new plan and get approval. Plan, change, stop with obstacle. Plan change and plan all over again. Not efficient in most cases.

    Your design and planning must remain flexible enough to address ever-changing organizational demands. This, however, doesn’t mean you need to implement every single planned change, and you also must allow your team to deal with new processes as they see fit.

    Design, Implement and Improve Your Services Step by Step

    New software or services implementations can take up months and even years. When the implementation is finally done, you’ve gained new insights and probably want to change many things, but by that time there’s likely little budget left or the project team members have moved on and it’s up to the application manager to process all the feedback on their own.

    Delivering new services in an agile way means you deliver something workable as soon as you are able, collect feedback and use this feedback to improve the product. The process isn’t perfect, but that’s okay. While you continue working on the next process, you can receive feedback to improve your incident management.

    Keep Your Services and Operations Straightforward

    Requests for services often contain a good deal of unnecessary management authorizations. In many cases, IT department leaders assume that department management wants control over every individual request or, alternatively, the IT department doesn’t carry any responsibility. This creates a process unnecessarily full of authorizations and a manager who gets loads of emails with authorization requests.

    Nothing should be this cumbersome. Things will be much smoother when the IT department members ask managers how much control they really want or need. They usually don’t really want to receive a number of emails, but there is an alternative solution: Requests don’t need to be authorized and managers can receive a monthly overview of the costs. This way, the manager still has control over costs, but he or she doesn’t have to process numerous emails. And the employee, the user, is helped much more quickly.

    Making Your Incident Management More Agile

    Where do you need to start when you want to work with agile? The response to this question depends on the organization. The best approach may be starting with taking a look at your current services and compare these with agile principles. For example, where’s the friction? What improvements are easy to implement? That’s where you begin. Then you start by making a small improvement, ask for feedback and move on to the next improvement.

    Incident management is the most important process of a supporting department. It’s also quite straightforward, but how can it be made more agile? Simply start by stripping out everything from the incident management process that has no customer value. Take a critical look at your current processes and evaluate each step by asking yourself if every step of the process adds value for the customer. To answer this question, you first need to know what your customer want, which is probably nothing more than a quick solution.

    Every step in your incident management process must contribute to how quickly an incident is processed. If there is a step along the way that doesn’t contribute to your goal, remove it. Eliminate everything wasteful from your process.

    — Nancy Van Elsacker Louisnord

  • DevOps: The Things We Must Stop

    DevOps: The Things We Must Stop

    Anytime there is a popular movement in technology (and I would argue any other field), people get carried away. We’ve seen it over and over, and DevOps attracts this kind of attention. In fact, DevOps caters to those who get carried away by mainstream folks screaming, “THIS CHANGES EVERYTHING!” That type of hyperbole pushes those who get carried away even further. And marketing always takes things to whatever place they have to in order to, well, sell their ideas to the market.

    Rack ’em Stack ’em Robots

    My all-time favorite purposeful over-the-top is the tendency to pretend that prior to the cloud, every project was started with “rack ’em, stack ’em.” This is demonstrably false, as by the time the cloud was taking off, VMware’s market penetration was significant. And yet, the number of blogs/amount of marketing material that starts out with the premise that every application required waiting for physical server delivery and configuration is insanely high.

    No. Enterprises, in particular, had to wait for VM allocation and configuration.

    Another that isn’t really mainstream—and I’ve mentioned in other locations—is the AWS TCO calculator. The simple calculator is not a bad tool, and I’ve used it numerous times in the past, but the TCO calculator makes some assumptions about deployment costs that are a little wild, such as that TCO includes the cost of VMware and its supporting hardware for an individual app. Of course, that’s not how enterprises do it. There is a VMware infrastructure and it is shared across apps. While it would increase the complexity a tiny bit, a simple checkbox that asks, “Do you already have a VMware cluster?” would go a long way—or better, one that asks how many apps you are running on VMware and divides the overhead by that number before including it in TCO. But of course, if you are getting your TCO comparisons from a competitor, expect the TCO will be stilted, no matter who is generating it.

    Oversimplification

    Whether it is infrastructure orchestration or app deployment, there is a lot of content out there that talks about how much easier infrastructure as code will be, and how much less documentation we will need. This, sadly, is a bogus premise. Whether you’re using the 50,000 service offerings of AWS or the power of HashiCorp’s Terraform—or any of half a dozen other competitors—it is complex. We’re not doing anyone any favors by glossing over the complexity that inevitably occurs in enterprise-class deployments, and we’re doing a massive disservice every time someone claims that documentation needs will be less because it’s “self-documenting code.” Self-documenting code sucks without a ton of comments in App Dev, and it’s worse in deployment. Employees new to the process need, and should be provided, solid documentation on how the system works and where different pieces fit.

    We’re deploying complex apps on complex infrastructures with evermore complex compliance and security requirements. It is not simple.

    All or Nothing

    There is a belief among too many aficionados that their way is the “One True Way.” The fact of the matter is that all enterprise application portfolios are complex and there is a metric ton of extant code that must be managed. A startup with one web-based app (no matter how large it may be) or a games developer focused on Android as its only platform might well have agile and DevOps as their only development/deployment methodology. No one else does. The enterprise running a hundred or a thousand different apps on several platforms is not going to flick a switch and say, “We’re all X now,” no matter what X is. Anyone who has tried to standardize the database in an enterprise knows that just doesn’t happen (I did, as an architect in a financial services org. It was ugly).

    Some projects are simply great fits for agile and DevOps—those with a high rate of change, where a little bit of instability in return for rapid feature rollout—while others simply are not—ones that maintain data that must be rock-solid, ones with a low level of change, etc. Any given enterprise is a mix of these things. Back in the days of the language wars, I used to say, “Right tool for the job,” and today, in the days of the architecture/automation wars, I say the same thing. If the project is rapidly evolving and you want lots of small changes in a constant stream, agile and DevOps are the right tools. If the project moves slowly and has an emphasis on stability or data quality, it’s not a great candidate for these tools at this time.

    I’ve talked about some of the bad vendors in this post, so I’ll call out IBM for being a good vendor on this point. Looking at the company’s model for moving the mainframe is a good example of how you could look at all of your IT, because IBM doesn’t say, “This changes everything!” It says, “Here’s how to tell what offers the most bang for the buck in moving to agile and DevOps.”

    Just Keep Rocking It

    Working in IT? You’ve been keeping your org running. Don’t start second-guessing your gut now just because the new shiny is being waved in front of you. Learn, change, do. But don’t rush into something with misinformation. Obey your gut and keep rocking your org’s world.

    — Don Macvittie

  • Repeat Warning: There is No Silver Bullet in DevOps

    Repeat Warning: There is No Silver Bullet in DevOps

    As the cycle of DevOps is repeated in a growing list of organizations, I feel compelled to reiterate the warning that this is not the pinnacle. Anyone who has been around for a while knows that the current fad is not the last fad.

    [[Cue DevOps people screaming at my choice of the word “fad”]]

    Of course it’s a fad. DevOps (and to a much lesser extent, agile) is the cool toy in the midst of Gartners’ (in)famous hype cycle. That doesn’t mean nothing will come of it; it means that people freak out when you tell them it doesn’t solve every problem.

    All of the process/solution fads that have come along have offered some benefit to IT. DevOps promises to offer more, and in many environments it does. But grabbing your broadest brush and screaming, “DEEEEVVVVVOOOOOPPPPPSSSS!” while painting everything in sight is not problem-solving; it is thinking there is only one path to quality and it flows through the Chosen Process.

    The reason DevOps is different from previous hype cycles is obvious: It has the built-in assumption that this is not the end state. It assumes you will keep moving forward and things will change. Previous “new way of doing things” ideas have assumed that there was some nirvana you would get to and everyone would relax there, sipping ambrosia and enjoying immortality. DevOps makes no such claim. About as close to a final state as it gets is increased communications between the various parts of the DevOps life cycle. And that is because there is only so far you can go with increased communications before you’re flooded. And even that leaves room for new tools such as Slack to augment communications.

    But don’t look at every problem with DevOps blinders. This is the real world, and while some will (possibly correctly) claim that every software dev/deploy cycle can benefit from DevOps, the real question is not “Can it benefit?” but rather, “Is the cost/investment/risk less than those benefits?” And to the chagrin of those who live and breathe DevOps/agile, I’m afraid the answer to that question isn’t always a resounding “Yes.”

    I’m undeniably a fan of both agile and DevOps. What I’m not a fan of is finding the nearest round hole and cramming everything—including square pegs—into it. Look at each project/process objectively. As a simple and blog-length example, let’s examine standalone app that does some important back-end process and is only updated once or twice a year: Why ever would you rip the process for that apart, invest man-hours to bring it into the DevOps and agile folds, then … only update it once or twice a year?

    If you are building a new project, and you have DevOps processes in the building, it would take a convincing argument to not use them. The same should be true the opposite direction. If there is an existing project that doesn’t have delivery delays, it should take a convincing argument to move it to a whole new development/deployment methodology. Choose wisely. Invest resources where they’re required, not where ever the broad brush falls. IT has enough work to do, don’t add to it, just so you can say “We’re a DevOps shop.” Better to say “We’re a right tool for the job shop.”

    And keep kicking it. Business doesn’t run itself, IT runs business. Keep making it work.

    — Don Macvittie

  • Enterprise Infrastructure:  Adapt or Face Extinction

    Enterprise Infrastructure: Adapt or Face Extinction

    In my previous blog, I explored how new ways of working—DevOps, Agile, cloud and startup thinking—have brought in a tectonic shift in the ways of working of enterprises. For infrastructure leadership and management, this is nothing short of a perfect storm that they need to navigate.

    While these new ways have impacted every aspect of technology including development, testing and project management, infrastructure and operations have remained the last bastions of traditional thinking, practices and approaches. Even with the rapid rise of DevOps practices in the recent years, we have just seen pockets of change in the infrastructure space, be it adoption of infrastructure-as-code practice, cloud in its numerous variants (private, public or hybrid) or containers and cloud-native technologies. But these changes all fall short of an enterprise-scale change that matters. What is missing is a systemic view of infrastructure as a value stream and transformation that ventures beyond the skin-deep changes limited to a few front-end digital capabilities.

    Infrastructure Transformation on the Horizon

    However, this is changing now; one by one, the barriers to infrastructure agility are breaking down. To put it simply, there are four dimensions of this change, based on various enterprise transformation initiatives that I have been involved over the years

    Radical new Operating Models

    New operating models are emerging to meet the business demand for infrastructure agility. There are primarily five patterns or a combination that enterprise are espousing in the operating model space:

    1. Shared service: This typically involves applying lean, value-stream mapping and Kanban techniques—in simple terms, the emphasis is on transparency, business-aligned prioritization of work and limiting work in progress.
    2. Responsive shared service: In this model, specific infrastructure members are “seconded” to application squads for more responsive service. However, there are limits to secondment model, in the ability to scale beyond a few iconic programs of work.
    3. Cross-skilling: This model involves infrastructure and application team members learning skills across each other’s disciplines with the goal of making delivery teams self-reliant.
    4. Disrupting with cloud: As the name suggests, enterprises are disrupting their own traditional infrastructure capabilities by aggressively pursuing private, public and hybrid cloud capabilities.
    5. Insourcing: Increasingly, there is a trend to insource responsive cloud and DevOps-based services to near-shore locations. “Almost twice as many CEOs are intent on building up in-house technology and digital capabilities as those plan on outsourcing it (57 percent and 29 percent, respectively),” according to Gartner’s survey of CEOs in 2017.

    Reimagining the Legacy Technology Stack

    Legacy systems based on technologies such as the AS400 or mainframes have been the bedrocks of technology for decades, but they also have been blamed for constraining agility. Many organizations have realized that replacing legacy systems with open system stacks is not an easy feat. Consider the fact that IBM continues to report an increase in mainframe sales over the last few years, including Q4 2017. This points to the fact that legacy will be part of the enterprise landscape for years to come—as such, incumbents need to be able to leverage the legacy stack to compete with digital challengers who are unencumbered by similar technology constraints.

    However, it is not all somber. There is a new wave of optimism driven by old guards, including CA and IBM, and new, including Compuware and ARCAD, that are bringing modern engineering practices such as continuous integrationcontinuous delivery (CI/CD), automated code analysis, virtualization, lightweight integration and test automation to these platforms. These new practices not only give these systems a new lease on life, but they also enable modern enterprise systems to be built iterative and incrementally—and not be handicapped by legacy constraints anymore.

    Intelligent Enterprise Resource Planning Software

    ERP software such as SAP/R3 are the backbone of many enterprises across industries. Historically, ERP software products have not kept up to speed with modern engineering practices and flexible architecture, which are fundamental to agility. The good news is that the ERP landscape is changing as product vendors are embracing cloud and API-led integration—IDC calls this “intelligent ERP” or “i-ERP.” Consider this: In 2025, SAP/R3, the largest ERP product in use, will no longer be supported officially, and enterprise planning programs (albeit, in a waterfall way) will move to SAP HANA Enterprise Cloud, the company’s new generation ERP platform.

    Culture and People

    Years of the drumbeat of Lean, Agile and DevOps ways is yielding results, especially in those organizations that see this as a people change as much as technology change. People in the infrastructure world are changing  from operating being behind a queue toward being customer-focused, collaborative and value-seeking. Organizations need to address the structures that restrained it from moving forward on the journey. Traditional organizational structures don’t account for team strengths, nor do they give everyone fair input in regards to overall direction. Rather, structures should be set up that allow managers to empower teams instead of teams living to carry out management demands.

    Ultimately, the key to creating agile and responsive infrastructure in organizations starts at the top, from the CXOs who need to realize the scale of change and inspire their teams on the need for change—or face extinction.

    — Aditya Vadaganadam