Tag: bimodal

  • Multi-speed IT: The Reality of Enterprise Agility

    Multi-speed IT: The Reality of Enterprise Agility

    Today’s business demands the ability to change systems at an ever-increasing speed, but for many companies, including their systems of record have created a mismatch in development and operations practices between the traditionally dynamic systems of engagement and the traditionally slower systems of record.

    The problem isn’t in the ability of the systems of record to move as fast; they can change as fast as any other system. The problem lies with the tools and processes used for the systems of record. The traditional view—that to decrease risk you must reduce change—has been shown to be not necessarily true. Manual change or large changes can cause increased risk, but through a completely automated deployment process that includes configuration changes and by delivering smaller changes that have gone through automated testing together, risk actually is reduced.

    The concept of multi-speed IT is not that some systems are slower and some are inherently faster, it is that the changes need to be made at the speed business requires. If a business change is required in the back end, it should be changeable as fast as any front-end change. The reality is, many back-end systems or systems of record provide a set of APIs that are used by the systems of engagement. These APIs can be more stable than the mobile application you are providing to the end user. Imagine a calendaring service—when was the last time the calendar changed? When did we add or remove days from a month? So this one is very stable; the only changes have to do with new interfaces required, such as providing a new REST-based interface. Other APIs will be much more dynamic based on business need.

    So how does a large, storied enterprise bring agility to systems both old and new, mainframe to mobile, while reducing risk and fear of bringing down legacy or mission-critical applications?

    1. Test across systems—Test everything together, where applications old and new cross paths, ensure thorough testing earlier and more often.
    2. Release what you tested together—if you are testing earlier to ensure applications across systems are working together properly, it only makes sense to release those applications together.
    3. Create a singular deployment process for that release—your deployment process should reflect whatever applications or components need to be released in the proper order to ensure functionality across systems.

    Of course, to enable these actions across teams and systems, collaboration and a shift in culture are key.

    Recently we hosted a webinar on how organizations can incorporate continuous testing and deployment into releases across systems and how multi-speed IT can be used as a stepping stone for enterprise agility.

    About the Author / Rosalind Radcliffe

    Rosalind

    Rosalind is a Distinguished Engineer within the IBM Rational organization. She is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture. This includes System z and Power system. In addition she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities. She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM. Connect with Rosalind on LinkedIn / Twitter.

  • Release Automation: Bigger than DevOps

    Release Automation: Bigger than DevOps

    Why DevOps is not for everyone and how release automation helps in bimodal world

    So am I really going to write a blog calling DevOps a big hoax?

    Well, not exactly, but as a follow-up to my previous blog on the difference between DevOps and Continuous Delivery, I want to alert you to a few key facts:

    1. DevOps is not always the right methodology for developing and delivering software.
    2. Agility and speed can be achieved even in a waterfall method if the right tools are in place.
    3. Release automation is bigger than DevOps (yeah, I said it!).

    Say No to DevOps?

    Okay, so here goes: Why is DevOps not always the right way to go? Simply because not all systems are born equal. For a back-end master customer data system, stability trumps iteration. Fail fast and roll forward simply aren’t sustainable in many of today’s most core business applications such as banking, retail, media, manufacturing or other industry vertical. Clearly, these enterprises still need to innovate and provide new and exciting ways for their customers to engage through web and mobile, but not at the risk of a terminal business failure at the back end.

    Delivery capabilities for these back-end systems need speeding so they don’t become the bottleneck for the entire business. However, restructuring teams and changing development along with test and release into tens and hundreds of small/tiny parallel updates cannot be supported by a legacy technology stack (say Siebel or SAP at the back end). It is likely not even advisable at all.

    This doesn’t mean we should accept the realities of the last century, resort to the status quo and leave our release cycles to once or twice a year for key applications. Slowly and surely we would lose any competitive edge.

    Luckily there is a middle ground, and this is why I believe release automation is bigger then DevOps. That middle ground is release automation. I will explain why, but I need to start by examining DevOps a little more first.

    What is DevOps?

    At its core, DevOps aims to get new ideas and functionality into the hands of users quickly and iterate fast. It achieves this by fixing two traditional weaknesses in the software delivery life cycle, namely “overhead” and “rework.”

    Overhead is anything that developers do that isn’t directly related to developing new features or improving existing ones (manual deployments would be a big item in the overhead column for sure, as would debugging production deployment issues or handling configuration problems).

    Rework occurs anytime developers have to go back over a piece of code they already have worked on. However, this does not include bug fixing, so rework occurs when test cycles take a long time and developers already have been working on new functionality, which now needs to be reworked to address a newly found problem.

    DevOps tackles these challenges by attempting to shorten the cycles—for example, by adding smaller changes that developers and testers can test in real time or by using tools such as Puppet or Chef for provisioning quickly to test while ensuring consistency across systems.

    This relies on Devs owning updates and rollouts across the life cycle, including production, which challenges everything in the way enterprise teams are traditionally organized. It calls for completely new processes, which often are a great fit for newly developed applications and modern architectures, but can be a complete misfit (and regulatory obstacle) for so many other core systems.

    I’m sure you can see where I am going with this. Much like the story, “The Emperor’s New Clothes,” DevOps isn’t what people believe it is.

    Why Release Automation is Bigger Than DevOps

    The goals of DevOps are sound, however, which leads me to my last point: Release automation is bigger than DevOps. Done right, release automation can accommodate diverse organizational needs and different types of applications in this new, bimodal world. It improves the software delivery process and its final product by rooting out manual work, improving cycle times, reducing overhead and rework.

    Crucially, release automation enables incumbent businesses to stay competitive and ensure survival without forcing them to completely abandon their DNA across the board in a “big bang” fashion. Such a process could put the very existence of a large enterprise at risk.

    Before signing off on this blog entry I want to make one last thing clear: The argument I am raising here isn’t trying to downplay the benefits of DevOps as a valid methodology. Nor am I denouncing any of the DevOps tool chain technologies out there, which are all welcome advances, of course. This year, 2016, is (according to most industry experts) the year in which DevOps adoption goes mainstream, and I fundamentally believe that it is release automation that drives this adoption, not just pure DevOps conversions.

    Stay tuned!

  • IT Organization: Blend, Don’t Divide

    IT Organization: Blend, Don’t Divide

    Bi-modal is the new normal, but the best way to approach this is to blend operations, not create separate groups.

    There’s been much ado lately about the transition of enterprise IT from traditional, steady operations to a highly agile and services-based operation. Companies of all sizes are moving to the cloud and adopting DevOps, yet many must maintain legacy systems for years to come. Pundits and analysts such as Gartner suggest that CIOs need to split their organizations into two: the Mode 1 group (traditional, “lights on” operations) and Mode 2 (the business-innovating group). In fact, Gartner is so bullish on this idea that the research firm is predicting that 72 percent of enterprises will be operating in a bimodal structure by 2017.

    Yet dividing and conquering won’t work. By creating two separate groups, with likely two different leaders, there’s bound to be tension and turf wars. Overlap of duties will happen, and higher costs may result. Regardless, the two groups will still need to work together—but may have little incentive to do so.

    Let’s take a step back. Bimodal is just another name for transitions that IT organizations have been through many times in the past: analog vs. digital, mainframe vs. client/server, batch vs. interactive, native vs. web-based, on-premises vs. cloud and so on. Creating walls between existing and emerging processes and technologies doesn’t make much sense. It’s possible to manage “old” and the “new” requirements and projects in tangent.

    Instead of creating walls, Mode 1 and Mode 2 processes can coexist and employees with different perspectives can help each other as the company transitions to its next phase of innovation. Over time, the entire organization will shift to the most progressive, efficient and business-aligned way of delivering IT.

    IT organizations should think more holistically about building cross-functional teams made up of the best members to serve that team’s particular purpose. Those teams may have mobile app developers and DevOps managers sitting side by side with network engineers and system architects who have developed deep specialties in enterprise databases and data center infrastructure over many years. There may be Waterfall teams and DevOps teams, and individuals managing cloud providers working closely with data center managers implementing converged infrastructure. It all begins with the business requirements and designing a strategy that is inclusive of both required legacy systems and future, cloud-based initiatives.

    But wait, aren’t the most progressive companies Mode 2 from top to bottom? The answer is no. Companies such as Amazon, Google, Netflix, Facebook, Apple and LinkedIn are IT innovators that also manage solid and stable internal environments.

    It was only in mid-2015 that Apple announced its migration of the Siri application platform to the Apache Mesos platform. This didn’t happen overnight. The team responsible for Siri realized that it could cut costs and increase flexibility for ongoing support and development. It was an evolutionary move focused on front-end scalability and allowing a clustered approach for scale and management—arguably a very Mode 2 approach. That said, it’s also widely known that the data sources for Siri are a mix of traditional RDBMS and No-SQL—massive data repositories handling millions of transactions 24/7. These platforms require Mode 1, utility-grade availability constructs.

    LinkedIn is another innovator running a distributed architecture that blends Mode 1 technologies (data layer and business engines) with Mode 2 clusters focused on presentation of new and existing initiatives.

    Ways to Blend Effectively

    Here are some ways to approach a blended IT organization that incorporate both Mode 1 and 2 technologies and processes without building walls:

    1. Create a best-of-breed environment. Evaluate your applications and create an architecture plan. Identify existing applications that require modernization. Create a clear picture of the gap between current and desired state. Build an architecture for your applications that leverages one or more platforms that can adapt to your application architecture goals, both present and future.
    2. Balance out your weakness. Most large companies in traditional industries will be heavier on the Mode 1 orientation regarding skill sets, tools and processes. To jump-start a transition toward Mode 2 operations, consider hiring people from software startups with ample experience developing, scaling and maintaining cloud-based systems under rapid time frames. These are the people whose failures bring the perspective necessary to empathize with your Mode 1 teams. They might even appreciate the Mode 1 team’s experience.

      Conversely, if your organization is already a strong Mode 2 operation, know that scaling your business will require you to embrace Mode 1 skills to maintain reliability and consistent user experience as demand grows unpredictably. Ideally, find someone with a large enterprise background that has experience delivering reliability for new, web-scale applications.

    1. Don’t force new methods. DevOps, a technique for infrastructure management in support of rapid delivery of applications services that is generally considered to be well-suited for Mode 2 applications, may not retrofit to every situation. For example, one can write code to manage infrastructure systems that expand and contract with the proliferation of application containers. While well-suited for the container-based application model, many of the coding concepts associated can be too complex for scripting the deployment of a multi-tier Mode 1 application. The layers and complexities of the scripting don’t provide enough return on the time invested to justify the upfront efforts. Leveraging a purpose-built automation engine or simply deploying manually likely makes more sense today. Choose the technique that best serves the initiative, not the one that seems the newest and coolest.

    Rather than getting hung up on how to reorganize IT departments, a better use of time is to determine how to blend the best of the old and the new. IT organizations today are frequently in a state of transition, given the pace of new technological developments. By merging tried-and-true tools and practices that deliver stability with the latest innovations for web-scale business models, companies can move quickly in their respective markets without sacrificing business longevity.

    About the Author/Steve McDonald

    Steve McDonald StrataCloudSteve McDonald is Vice President of Product at StrataCloud, developer of a platform for software-defining enterprise data centers. Over the past 15-plus years, McDonald has led cross-functional teams in the delivery of innovative business initiatives, most recently at Softchoice, where he a managed a team of business development and pre-sales professionals in the United States and Canada focused on the profitable growth of the entire Cisco portfolio as well the networking category overall.

  • DevOps and Agility for Multi-Speed IT

    DevOps and Agility for Multi-Speed IT

    Let’s step back for a moment and look at the IT world a bit differently from the traditional technology-centric lens through which most of us IT peeps tend to look at things. Line of business (LOBs) need us, the IT organizations, to deliver capabilities to their customers and users that deliver business value. They also rely on these systems to provide feedback on how customers and users are consuming the business capabilities and deriving value; how they are interacting the business systems; and what capabilities and features they need to get better value. The LOBs are asking the IT organizations to deliver these capabilities with:

    • Velocity
    • Agility
    • Innovation
    • Cost Management

    IT organizations, in most cases, are not designed for velocity, agility or innovation. They are large organizations hindered in their ability to deliver these by legacy systems, myriad practices and tools, overbearing governance and compliance regimes, archaic and siloed organizational structures and cultural inertia. This lack of ability of the IT organizations to deliver agility, velocity and innovation in some cases even results in LOBs creating their own “Shadow IT” organizations to deliver their IT needs.

    Finding Velocity, Agility and Innovation

    The solution of late has been to undergo a DevOps transformation that enables IT organizations to adopt the necessary practices, automation tools and organizational and cultural change to deliver with velocity and agility, and become innovative by being able to deliver rapid experimentation. The origins of DevOps lie in Lean IT, and adopting DevOps is really applying Lean principles to help achieve agility, velocity and innovation.

    DevOps does so by making organizations that are delivering IT systems and software more efficient and lean. Organizations that have adopted DevOps are able to:

    • Get ideas out to production faster
    • Have users/user surrogates use them
    • Get rapid feedback

    Using this feedback the organizations can improve three things:

    1. Applications delivered
    2. The infrastructure delivered
    3. The process by which IT systems and software are delivered

    However, large organizations have been struggling to achieve the results promised by DevOps and achieved by the poster children of DevOps, with whom the movement started. For every Netflix and Etsy out there, there is a large, complex, organization that has been struggling with simply where to start. They may be able to achieve success in some parts of their IT organization—with small, innovative ‘two pizza’ teams working on isolated projects—but not at enterprise scale. They struggle with how to achieve even the results of DevOps adoption they see in their own successful teams, at scale. The organizational and cultural inertia appears to be too difficult to overcome.

    The major reason of this inability to achieve at scale is the persistent struggle in all large organizations between the desire to innovate, and the need for stability. This push-and-pull exists in all organizations—even an innovative startup feels it. The Dev teams are focused on creating innovation thru rapid change and experimentation, and the Ops teams are focused on creating stability and continuity. DevOps addresses this existential struggle by adopting a series of practices that drive cultural change, automation and process adoption that allow these Dev and Ops teams to work toward common goals and balance their needs. Even in large organizations, this can be achieved on small teams that are able to circumvent the legacy organizational structures and practices and figure out how to get all the stakeholders working toward common goals. That is why this works great on small, strategic projects that have well-defined goals and timelines and can “fly below the radar” of corporate governance enforcers. As we move to larger projects with large, potentially distributed teams, spread across different groups and corporate “fiefdoms,” adoption struggles and often fails.

    The Rise of Multi-Speed IT

    One fact these large organizations need to recognize is that they really must have two modes of delivering IT: one focused on innovation (and velocity and agility) and the other focused on optimization (stability and continuity, with agility and velocity). This view is being referred to in the industry as “bi-modal IT” and is actually more of a continuum than a clear-cut two modes model. Hence, the term is evolving now to “multi-speed IT.” However, classifying the continuum into two broad categories based on the business intents of innovation or optimization serves the purpose of determining how to adopt DevOps very well.
    Multi-Speed ITMulti-Speed IT

    One interesting way to look at these two modes is to classify them as:

    1. The ‘Industrialized Core’ that delivers core business capabilities—things that keep the business going, and the primary business intent is optimization
    2. The ‘Innovation Edge’ where experimentation happens and new systems get identified and developed; in other words, the primary business intent is innovation

    Innovation vs OptimizationInnovation vs. Optimization

    The goal of the Innovation Edge is to allow for rapid experimentation, development of minimum viable products (MVP), rapid delivery and fast failure. The goal of the Industrialized Core, on the other hand, is to be lean and efficient and deliver business capabilities in an optimized, predictable, stable and secure manner, with the ability to scale as needed. Note: Eventually systems from the Innovation Edge will need to be “industrialized” once they start serving a core business function. This is a continuum from innovation to optimization.

    The Industrialized Core itself needs to be continuously incrementally industrialized to provide the stability and reliability needed, while getting leaner and more efficient, at scale. The core needs to get to optimization, with agility and velocity, as it delivers the core systems, again at scale. The core, too, needs to adopt DevOps and agile development practices, even for legacy systems, including those on the mainframe. This Industrialized Core is, after all, what keeps the business going and delivers the ongoing business value as the Innovation Edge seeks out new and disruptive business capabilities and avenues to deliver them.

    However, they both need different DevOps approaches and platforms delivering Agility, Velocity and Innovation at different levels.

    These two systems to deliver business capabilities are, in reality, joined at the hip. The systems delivered on the Innovation Edge are dependent on the services provided by the Industrialized Core to deliver the innovations they are developing. The Industrialized Core, on the other hand, consumes most of the budget in typical large organizations, and needs to be optimized to free resources for innovation.

    Consider a typical mobile application (say, mobile banking). To deliver that application, there is a team charged with developing the mobile front end. These kind of applications are developed and delivered in the Innovation Edge. Does all of the data and business logic sit on your mobile phone when you use that application? Of course not. Most likely, the business logic and certainly the data are components of the application that are delivered by pre-existing systems or services in the Industrialized Core. So, the mobile application is hybrid, comprised of components running in both places. To deliver even some experimental features of this mobile app, the company needs to release a hybrid or composite application, delivering components delivered by both the Innovation Edge and the Industrialized Core.

    During the Dev/Test cycle, these two modes of application delivery must be as decoupled as possible, so the development schedules and cycles of one does not drag the other, to prevent the Core from becoming a drag on the Innovation. Creating an API ecosystem is thus essential to decouple the Industrialized Core from the Innovation Edge. The Core provides the business services consumed by the innovative applications being delivered by the Innovation Edge as APIs. A key benefit of developing this API-based architecture is that these APIs potentially can be monetized to third-party partners, generating a revenue source at the same time.

    It is important to note that the architectural and process needs for adopting DevOps in both of these modes are different in many ways. Their needs and how they deliver applications and services differ as they are serving different business goals. In my next post, I will start delving into these architectural and process needs for adopting DevOps for both the Innovation Edge and for the Industrialized Core, which allow the Innovative Edge to allow for experimentation and innovation, and for the Industrialized Core become more optimized.

    Watch this discussion between industry practitioners as to how they have adopted DevOps in a multi-speed IT model: the challenges faced, successes achieved and lessons learned.

    About the Author/ Sanjeev Sharma

    Sanjeev

    Sanjeev Sharma, CTO and Distinguished Engineer – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, Mobile Development and UX, Lean and Agile Transformation, Application Lifecycle Management and Software Supply Chains. He is a DevOps Thought Leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the DevOps for Dummies book.

  • Are You a Transformational CIO?

    Are You a Transformational CIO?

    George V. Hulme discusses the state of CIO Relevancy and Transformational IT with Tim Crawford

    Facing increased consumerization of technology, more autonomy by business units in choosing and deploying IT, citizen developers and increasingly affordable cloud software services, IT departments and the office of the CIO are under more pressure than ever before. To get some answers about how smart IT leaders are ensuring their relevancy, we turned to Tim Crawford, an internationally recognized expert on enterprise IT transformation, cloud computing, IT relevancy and innovation.

    Crawford has held CIO and other senior IT roles with global organizations including Konica Minolta/All Covered, Stanford University, Knight-Ridder, Philips Electronics and National Semiconductor. He regularly speaks at industry conferences on the topics of strategy, applications, services, infrastructure and operations. Crawford also serves as an adviser to global enterprises, government agencies, venture capital firms and startups across numerous industries.

    Hulme: There is a lot of conversation around the relevancy of IT, and it escalated as rogue apps, IT and even citizen developers have taken root in many enterprises. And many are questioning the relevance of the IT organization in the years ahead. What is your take on the current state of IT relevancy?

    Crawford: I think we have to separate the types of IT organizations. There are those that are very technology-focused. They are focused on the latest, greatest whiz-bang, bright, shiny object. These are the folks that look at IT for IT’s sake. They look at IT as the linchpin in the organization and work under a command-and-control management style. Those organizations are really going to struggle. We’re already seeing this happen. We’re already seeing CIOs of that caliber getting removed from their posts. We’re seeing that type of IT organization get marginalized significantly in terms of its strategic value to the organization.

    A good way to test this is to ask someone from elsewhere in that business, “What role does IT play? Are they the ones that you call when the Internet is broken or you need to get a projector fixed or an application doesn’t work? Or, are they the folks that you call when you’re trying to figure out a new strategic initiative for the company as a whole and you want IT at the table? Or, is IT coming to you with different business objectives that actually are substantial and are not about technology?”

    I would differentiate between that—what I call the traditional—IT organization and the transformational.

    The transformational IT organization, on the other hand, is very much in demand and there are very few IT leaders that understand it. There also are very few business folks, so folks outside of IT, that have that level of expectation of IT; that transformational expectation, that business-centric expectation. And the best way to think about a transformational IT org is they are a business organization first that happens to have responsibility for IT. So, a CIO that is very business-oriented as opposed to tech-oriented, that also happens to have responsibility for IT.

    Back to your fundamental question, I would argue that the traditional, not the transformational, but the traditional CIO and the traditional IT organization is very much in decline. The transformational IT organization and the transformational CIO is very much in demand and that trend is something that we are just starting to scratch the surface on.

    Hulme: With that in mind, how do you move your organization to a successful transformational IT organization?

    Crawford: That is the $64,000 question and the No. 1 issue is in understanding culture, understanding people, understanding organization. And notice, technology was not one of those key attributes.

    The problem is not a tech problem; the problem to transform is not a tech problem. Quite often you have leaders that are somewhat sedentary. That’s one category of folks. Another category of folks is they just don’t know; they don’t know how to get from here to there and they need some help. But then you also have those folks that are very much of the mindset this has worked well for us for the past 10, 20 years and that’s what we’ll continue to do.

    But, for those folks that truly want to transform, there are a couple of challenges that they need to be able to get around. One is inertia. There’s a phenomenal amount of inertia within an IT organization that heads you down the status quo path; the traditional status quo path. On the other hand, if you understand the organizational shift and you understand that culture needs to change, then you will take steps in order to do that. And some of that may be the language that gets used, it may be how the IT organization is organized; just the fundamentals of organization. We no longer have an apps org and an ops org or an infrastructure org. They’re all one organization and they’re centered around other functions. And that gets to be a little more specific to the nature of the business and what works for that team.

    There’s a lot of personalization that comes into play. For example, pick you and I. We may have very similar perspectives on many different things, but we’re also two very different individuals. And so the way that you would handle George vs. Tim, and the way you would engage them might be very different. And so there’s a lot of personal work that needs to be done. But it starts with a vision, it starts with a direction and it starts with a game plan or road map to be able to achieve that.

    Hulme: It would strike me that enterprises outside of the IT organization—enterprises that have transformational IT—are going to be a lot better off in their ability to compete than those that don’t have good IT leadership because they may end up floundering.

    Crawford: Absolutely. Without a doubt, that is absolutely true. In order to compete moving forward, you absolutely need a transformational CIO and an IT organization that is of similar mindset.

    Now, to get from here to there, because, remember most enterprises said, “Hey we’re not starting fresh. We’re not an Uber, we’re not an Airbnb where we’re just creating this brand new IT organization where we can pick and choose the people. We have legacy culture, we have legacy systems, we have legacy thinking. We’re not starting out fresh; we’re not starting out new.” Enterprises don’t have that luxury.

    And, this is where we often get into this conversation around bimodal IT. Well, to do that, do you create a startup within the IT organization that focuses more on the transformational aspect and then have a different group that handles the legacy aspect? From experience from the organizations that I’ve seen that have made an attempt, a solid attempt, not just a half-assed attempt but a solid attempt at bimodal IT, they have struggled or failed miserably.

    Hulme: At doing bimodal? Why do you think that is?

    Crawford: At doing bimodal. The reason for that is because a lot of that has to do with the fact that IT is an incredibly complex and integrated system; you know if I can use system in a more generic term as opposed to technology. And so, think about it. You’ve got your systems of record that might be in the legacy camp, but you’ve also got systems of engagement that might be in the startup camp. The systems of engagement still have to connect to the systems of record.

    So how do you start to make those connections and forget about technology for a minute. Now you’ve got legacy folks that are looking at the startup folks going, “How come they get to do all the cool stuff and we get stuff with this legacy?”

    We do have to be a little more mindful that, yes, there are different needs within an organization, but to create more silos, which is what many organizations have tried to do when they’ve tried bimodal, just creates an incredibly more complex problem and takes the organization in the direction away from where we want to go. Especially if you believe in the value of DevOps, for example.

    Now, I’m not saying that bimodal is completely bad and should be thrown out, but there needs to be a very mindful way in which to leverage it. And, at some point, as part of your vision, as part of your road map, you need a means to bring that all back together again.

    Hulme: So, what is an answer to that? Legacy IT, because some of it’s just not going to go away overnight.

    Crawford: You have to divide and conquer. I mean if you try and take the entire IT portfolio in one big bite, that’s the equivalent of the old adage of eating the elephant all at once.

    You can’t do that. I mean, you didn’t build that IT system—the people, the org structure, the technology, the applications—overnight. It took time to put that together. And much of how it’s built is institutional knowledge. It’s not documented anywhere. It sits in George’s head. It sits in Tim’s head. And then what happens when Tim leaves the organization and then something breaks or something doesn’t work? Oh no! Well, we don’t know how to fix it. We now have to re-solve that problem all over again because it was in Tim’s head and Tim’s not here anymore.

    So, you have to divide and conquer. I use the methodology that I’ve developed over the years to do that. To bring some clarity to the areas that require more focus. To get to a position where you can take advantage of newer methodologies and newer technologies like cloud, like containers and some of the new AppDev methodologies, you have to understand what you have and then you have to have a means in which to pick apart the pieces. So you might say, you might take the ripe, low-hanging fruit and say, “You know what? Okay, just because we have file sharing on-prem today in our own data center doesn’t necessarily mean we need to do that moving forward.” Yes, we’re a regulated industry. But there are mature solutions that allow us to audit documents and understand where documents go today on cloud systems. So, let’s go leverage this cloud storage service. Let’s move that out. Great, we just lopped off a huge amount of storage and file servers.

    After that is completed successfully, you move on to a new phase, perhaps you don’t have to run an Exchange server in your environment anymore. There’s nothing unique about it. Yes, you configured the hell out of it. Yes, you couldn’t replicate exactly all those configurations, but do you really need to? And, this kind of thinking is actually a very mature way of thinking compared to where a lot of organizations are today.

    Hulme: You may be bringing old thinking forward that is not necessary anymore.

    Crawford: Exactly, and that’s part of this theme. A lot of that thinking is what hinders us moving forward.

    A lot of that legacy thinking gets pulled forward and this is one of the reasons why I’ve said this before and I’ll say it again: Moving forward, it would almost help everyone if we forget everything we’ve learned up until this point. I know that’s incredibly counterintuitive, but in many ways legacy thinking is what is holding us back—that thinking that we’ve always done things this way, so we’ll do it this way moving forward.

    Note that a common question that gets asked by IT leaders when you want to bring something new and innovative to the table, and this used to drive me batty as I was coming up through rank and file of IT. It was when the CIO would ask, “Tell me who else has done this in our industry at our size.” Now, if you think about it, when the CIO says that, what they’re looking for is stability. They want some validation to know that things are going to be okay.

    Now, let’s change the CIO with the CEO. If you go to a CEO with a new innovative thing, is the CEO going to ask you who’s done it in our industry at our size before they can seriously consider it? Or they going to be looking at it and go, “Ooh, this could be a differentiation opportunity.”

    I don’t care who’s done it before. Doesn’t matter. I want to know what people want and how we can deliver something that’s of value to them. And if it’s a different mindset that is about embracing the opportunity.

    Hulme: What are some indicators organizations should look for to see if they are thinking transformational, or with a legacy mindset?

    Crawford: One key indicator that I look for when I get asked to go in and assess organizations is experimentation. Is experimentation not just allowed, but encouraged? Now, experimentation is a good indicator, but it’s no more than an indicator, but it shows a mindset and an openness for new thinking. So, when you start talking about how do you determine if an organization is innovative? OK. Are they trying things? Are they failing? If they’re failing, great, because that indicates that they’re at least trying something and they’re not afraid to fail. Most times in IT organizations, failure is a big no-no; you want stability, you want an outcome that you’re expecting. Obviously, you have to kind of take that statement with the right perspective? You can’t just fail, fail, fail. The business still has to be able to operate. But you can’t be afraid to fail, either.

  • DevOps Chat: Rosalind Radcliffe and Bimodal IT

    DevOps Chat: Rosalind Radcliffe and Bimodal IT

    I had the pleasure of sitting down with IBM distinguished engineer Rosalind Radcliffe the other day to talk about bimodal IT, systems of engagement, variable speed DevOps and IBM’s upcoming InterConnect 2016 event.  I have interviewed Rosalind many times over the last few years and it is always informative and interesting. I hope you find it to be so as well.

    Below is the SoundCloud streaming audio interview, followed by the transcript of our talk.  Enjoy!

    Alan Shimel:                Hi, Alan Shimel here with another DevOps Chats, and my guest is – for this session is a friend of mine, Rosalind Radcliffe of IBM. Rosalind, welcome.

    Rosalind Radcliffe:      Thank you. 

    Alan Shimel:                Rosalind, I think you’ve appeared on DevOps Chats before, and of course we have done webinars and videos together, and so many other things. But for members of our audience who may not be familiar with who you are; do you want to give a brief background?

    Rosalind Radcliffe:      Sure. So I’m Rosalind Radcliffe, I’m a Distinguished Engineer at IBM, and I’m responsible for our DevOps strategy for Enterprise Systems. So I am not only responsible for driving our product direction, but I really spend a lot of time with clients helping them with their DevOps transformations for their Enterprise Systems – mostly mainframe, and their systems of record.

    Alan Shimel:                Excellent. Rosalind, of course, we’re going to talk a little bit about today about this term that’s been creeping up, Bimodal IT, and then I want to spend some time talking to you about the upcoming InterConnect Conference as well. Maybe we can combine Bimodal IT and InterConnect; I don’t what we would call that, but Trimodal. Anyway, so Rosalind in talking offline before we jumped on here I think we both agreed that we weren’t big fans of the term Bimodal IT, and all that seems to have entailed now. Do you want to share with our audience why you may not be a fan?

    Rosalind Radcliffe:      Yeah. I think the term and the way it’s used isn’t implying that there is a defined slowness for the systems of record. I think it’s important instead of saying Bimodal to say more variable speed IT or something that implies that the systems may move at different speeds. I’m not going to disagree with that, but it’s not that one is inherently faster and one is inherently slower. It’s that hopefully for your system of record you’ve built that as a set of API’s or services, and so you don’t have to change the services as often as you need to change that system of engagement to entice the users to stay connected.

    So it really should be about how the systems of record and the systems of engagement can work together through loose coupling, and through proper services. I do think that is going to happen; there are going to be different speeds at different times. Sometimes, honestly, the systems of record might be moving faster than the systems of engagement, because there are changes needed – regulation changes, etc. But it’s – we need to pay attention to it from that standpoint and that’s the reason why I don’t like Bimodal IT. It’s really variable speed.

    Alan Shimel:                Yep. The other point that gets me with it is this whole idea of Bimodal IT, it almost takes that we have two tracks if you will, that move at different – or two trains on a track that move at very different speeds. But they never interact; it’s almost – it almost reminds me of civil rights, separate but equal. We have the water fountain for the mainframe guys, and a water fountain for the cloud dudes, and they both serve water so that’s okay. But the mainframe guys can’t drink from the cloud dude’s water fountain.

    It didn’t work for civil rights, and – I don’t think it works for IT either. I think a better model when we talk about systems of record, systems of engagement, and this whole world, is more – I call it the Swiss watch model. Where you have gears that turn at different speeds, but they all mesh together in a fine tuned timepiece. To me, that’s a much better model than this idea of separate tracks, if you will. What do you think about that Rosalind?

    Rosalind Radcliffe:      I actually think that’s a wonderful way of putting it. Because I think that – it would be a much better interpretation with the gears and the Swiss watch, and Swiss watch timing is always excellent with their gearing system; so that’s exactly what it is. The teams need to work together, and they need to be using the same tools, the same practices, the same processes, and each system needs to go at the speed that is required for the changes that they need to make. But they’re obviously interacting. Your systems of engagement is nothing without your systems of record. So they need to interface properly, they need to work together to provide this end-to-end solution for their end users.

    So they have to be collaborating, and I – honestly I think the organizations that have brought the teams together, that do the systems of engagement and the systems of record into one team, actually do the best. They’re the most efficient; so they may have variable ability in the speed they’re delivering on different parts. But they’re all working together, they’re all collaborating, they’re all one team; not this separation idea. I think your example is very good, it’s not separate, but equal, it’s one team.

    Alan Shimel:                I agree wholeheartedly. I’m not here blaming Gartner for pushing this whole Bimodal IT name and paradigm. But, Rosalind at last year’s InterConnect I remember having a bunch of conversations with you and Sanjeev Sharma and Carmen Diardo, and we were using the term variable speed IT. Right?

    Rosalind Radcliffe:      Yes, absolutely.

    Alan Shimel:                To talk about it – the similar thing, and, of course, I – we’ve heard other people use the term two speed IT. But I think in larger organizations, there’s actually more than two speeds; there’s a lot of different pieces that move at different speeds.

    Rosalind Radcliffe:      That’s really the right answer. I really think it’s important have that ability to move at the speed required by businesses – the business demands, and that’s why it’s necessary. I think there’s a lot of thought process about Bimodal IT, because there are still or there seem to be people out there that still think the mainframe can’t move as fast, that it can’t use DevOps practices. I think that’s actually the core of the issue. We have to break down this thought process that the systems of record – the mainframe can’t move as fast, can’t be DevOps. It really can be, and it’s a reality – I guess it’s a hot button in a sense right now. I’ve just spent the last two weeks with two different clients, and this week with one of them – the first principle they put up was that there’s nothing about the mainframe that means it shouldn’t be DevOps. That the first principle is it needs to be DevOps, it needs to take advantage of the same pipeline, the same functions, the same capability to be able to move as fast as required in a reliable, consistent way with all the advantages of automated testing and automation.

    Alan Shimel:                Absolutely. Rosalind, let’s turn a little bit to this year’s InterConnect where we will have – whether you want to call Bimodal IT, variable IT. There are out of the 200 or 300, I forget how many DevOps related tracks there, there will be some great ones, and I want to talk to you a little bit about that.

    Rosalind Radcliffe:      Yeah, I’m looking forward to the event as well, though I’m not ready for it yet. There will be a lot of discussion and a number of sessions, both customers as well as IBMers talking about the variable speed IT or the different ways that different parts of the application development need to interact, and need to work together. One of the clients I was speaking with this week will be there talking about their DevOps development, particularly about how they’re literally building brand new applications on the in COBOL CICS applications using DevOps principles. So I look forward to all the different client discussions that are held there, bringing their teams together, and I think your Swiss gear interpretation is a good way of putting it. Because that’s what they’ll be talking about, how they’ve geared the teams together to be able to work together to provide the value the company needs.

    Alan Shimel:                Absolutely. Rosalind, are you allowed – can we mention to our audience what company is that presenting? Are you allowed to say at this point or no?

    Rosalind Radcliffe: So in that case, it’s Rabobank, because they’re published as a session speaker; so they’ll be speaking. There are actually quite a few. Rabobank’s one, UBS is another; there are numerous speakers scheduled – client speakers scheduled who are going to be speaking about their efforts and their transformations.

    Alan Shimel:                Rosalind, what about you? I’m sure you’re speaking.

    Rosalind Radcliffe:      Yeah, I have quite a few sessions that I’ll be discussing DevOps overall, working with clients and their transformations, the capabilities available, as well as having more discussions on the ops side of DevOps. I think one of the things that has been an interesting challenge is the how do we really bring ops into DevOps since we really do have ops organizations. That’s going to sound really strange, but when we think about DevOps a lot of the discussion has really focused on automation and delivery, not really focused necessarily on running the systems. So I’m trying to help some of the discussions bring more of the ops side in. How do we really get the ops collaboration coming in? How do we tie the teams together from a complete end-to-end standpoint?

    Alan Shimel:                Excellent. Rosalind, it’s hard to pick among many, but what do you – besides the ones you just mentioned, give our audience – if they’re wondering should I go, should I not go, not sure; what are the two or three biggest either sessions or points of learning that you think people should know about to jump in here?

    Rosalind Radcliffe:      Honestly, I think there are too many sessions to name, but the way to think about it is there are too many sessions to name. There are lots of client sessions, we’re going to be discussing their experiences. So the value out of a conference like this, one of the key values is the ability to hear from your peers, and to network with your peers to understand how they’ve done this, how they’re getting value. That’s the best way to learn from other people who are already experienced or who are experiencing. You’re going to learn from people who are headed for you, and you’re going to be helping people who are behind you. So it’s the networking, it’s the opportunity – hear those sessions, and the opportunity to meet all of the different people who are working in this space.

    I think that’s the value of conferences like this; the chance to network and take advantage of that. Many people I’ve met in prior InterConnect’s have said it’s the collaboration, it’s the conversations, it’s the meeting of people that have given them the most value. Attending the sessions is also very important, but it’s the sessions that give them those contacts. So they learn in the session, and then they have this contact that allows them to continue to discuss. You always get fun – learn something new, you get some fun stories, you get something you’re really going to be able to take back and provide value to your organization.

    Alan Shimel:                Absolutely. Rosalind, believe it or not we’re just about out of time; we probably have gone over. As usual it’s always — when this happens whenever we talk I apologize. But, I am looking forward to seeing several of your sessions at InterConnect, as well as I should mention – this is a quick plug, I am moderating a session myself on what DevOps will look like in the next three to five years, and I have none other than Gene Kim on the panel with me, which should be a lot of fun. So if anyone listening is attending Interconnect, please come on down for that one.

    But, Rosalind, it should be quite a show, and I’m looking forward to how this whole Bimodal IT, variable speed IT, how it plays out. We’ve said it before, mainframes aren’t going anywhere, and the new way of doing things like DevOps and Agile and stuff it’s going to influence how we use our systems of engagement, but it’s not going to negate them. It’s always a pleasure to speak with you, and look forward to seeing you in Las Vegas February 21 to the 25th correct?

    Rosalind Radcliffe:      Correct. I’m looking forward to it as well, and as you mentioned the panel discussions, those are always wonderful. I’m hoping that I can make it to your session with Gene Kim if I’m not in another session myself. So I’m looking forward to it, and it’ll be a great week.

    Alan Shimel:    Absolutely. Rosalind Radcliffe, Distinguished Engineer IBM, thanks for joining us today on this edition of DevOps Chats