Category: Blogs

  • Designing A DevOps Strategy: A Balanced Scorecard Framework

    Designing A DevOps Strategy: A Balanced Scorecard Framework

    Despite all the hype about DevOps, little has been written on a formal DevOps strategy. Too often DevOps initiatives starts with tooling discussion and gets stalled in technology. The larger vision is rarely discussed. The goal of this article is to provide enterprises, large and small, with a framework for creating that vision and unlocking the promise of DevOps.

    Elements of a DevOps Strategy

    A holistic DevOps strategy, at the most basic level, must answer the following questions:

    • Where should we focus our efforts? Where do we begin?
    • What are we trying to solve?
    • What is our goal? How are we going to solve it? How long will it take?
    • How is this going to impact the larger enterprise? Who are our stakeholders and what do they value?
    • Is this worth doing it? What are the benefits and costs?

    If implemented correctly a good strategy provides an organization with focus, creates a common (unbiased) view of the current problems, develops the future state, unveils opportunities for growth and results in better business outputs.

    DevOps Strategy Map: A Balanced Scorecard Framework

    A Balanced Scorecard typically consists of four high-level perspectives that highlight key practices and objectives that are needed to build a strategy. We choose this framework primarily because it does three things really well. First, it provides a disciplined approach towards creating a strategy. Second, it links the key activities together and describes the cause and effect between them. And third (and most important), its easy to use and follow.

    A scorecard is usually read from the bottom up. Enclosed below is a Balanced Scorecard modified for DevOps.

    DevOps Strategy Map
    DevOps Strategy Map

    1. People, Process & Technology

    In DevOps we have the luxury of plenty: an abundance of applications, technologies, competing initiatives, bottlenecks, nebulous problems, tools, etc. The objective of this dimension is to narrow down the application options (system of record vs. system of engagement) and target the problems that really matter (value stream mapping exercise). By doing so, we bring clarity and focus to the organization and greatly improve the chances of success.

    2. Critical Capabilities

    The next step consists of three activities – create a vision (which includes a future state value stream), determine where to invest, and build an implementation plan. Three things to keep in mind as you go about doing this exercise. First, pick hard targets for your vision. Instead of “improve speed” try to get to “improve speed by 25 percent”. Second, pay particular attention to capabilities gaps. Gaps can then be used to determine areas of investment, approximate budget, and a key input into your ROI model. Third, make sure to prioritize the bottlenecks. Putting the priority list on a timeline can be quickly translated into an implementation plan.

    3. Perception by Key Stakeholders

    Identifying your key stakeholders, determining their priorities, and aligning your strategy accordingly is the next crucial step. Some of the key stakeholders to consider are business/end customer, CIO and the IT leadership, development, operations and security. Once identified, match the value drivers from the vision to each stakeholder. This along with the output from the previous section will highlight pitfalls of your future state solution, its feasibility, and political objections.

    4. Value to the Organization

    The financial benefits section serves as the keystone for the balanced scorecard. By using output from the previous sections the business case brings the entire strategy together. As for the benefits themselves, they come in both hard and soft forms. The most common benefits we see are listed in the chart above. To get to ROI, combine the hard benefits with the investments from the previous section.

    One Last Thing

    The strategy map is meant to be iterative—the great thing about a DevOps solution is that it is not a “one size fits all” approach. Play around with all of the above steps. Move things around, change scope, update solutions and redefine vision until you come up with an objective that is both transformative and achievable for your organization.

    DevOps is a journey that’s two steps forward and one step back. Good luck!!

    Special thanks to Sunil Joshi and Emily Pence for helping create the Strategy Map. To find out more on how to use this map, joins us at IBM Interconnect.

    About The Author/Mustafa Kapadia

    Mustafa-KapadiaMustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.

    Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and adviser to start ups.

    Connect with Mustafa LinkedIn | Twitter

  • DevOps Chat: Rachel Reinitz, IBM Bluemix Garage Method

    DevOps Chat: Rachel Reinitz, IBM Bluemix Garage Method

    newlogoIn advance of InterConnect next week in Las Vegas, I had a chance to sit down with Rachel Reinitz,Distinguished Engineer & CTO of IBM Bluemix Garage. I have met Rachel several times and it is always a pleasure to catch up on all of the innovative things her and her team are doing with Bluemix Garage. In this conversation, Rachel and I spoke about open technologies which is a focus for us this month, as well as a big focus of the Bluemix Garage method. We also spoke about “innovating like a startup, while scaling for the enterprise”.  To learn more about the IBM Bluemix Garage Method, please visit: https://www.ibm.com/devops/method/

    You can find our conversation below and a transcript of it below that. Enjoy!

    Alan Shimel:                Hi, everyone. Alan Shimel, DevOps.com here for another DevOps chat. Today’s special guest is Rachel Reinitz of IBM. Rachel, welcome.

    Rachel Reinitz:            Thanks, Alan. It’s always nice to be talking with you.

    Alan Shimel:                Yes, actually I think the last time we spoke was DevOps Enterprise Summit in San Francisco. And Rachel, for our listeners who may not be familiar or didn’t get a chance to see our video which is on YouTube from DevOps Enterprise Summit, why don’t you tell them a little bit about yourself.

    Rachel Reinitz:            So I am a distinguished engineer at IBM and I co-founded and I’m the technical lead for the IBM Bluemix Garages.

    Alan Shimel:                Excellent. And you know, Rachel, there’s been a lot of announcements and news and developments, no pun intended, coming out of the IBM Bluemix Garages that some in our audience may not be familiar with. So give us some of the highlights. First of all, what is the IBM Bluemix Garage? And what’s happening with it?

    Rachel Reinitz:            So we are a consultancy within IBM. We work with customers making them successful in adopting Bluemix. And we are unique in that we are housed in startup communities. We work with both startup customers through to enterprise customers. And really what we work on is taking an idea, a problem or a concept and applying IBM design thinking, lean startup, extreme programming, DevOps to go from that idea to the definition of a minimal viable product and then onto building it and getting it out there and testing it out with users, testing the business hypotheses, all the really good DevOps practices and utilizing Bluemix which also gives us a lot of acceleration because of the kinds of services in the environment that we are in. So that’s what we do. It’s an exciting place to work and we have – and for clients to come into with designers, architects, developers. That’s pretty much what we do.

    Alan Shimel:                Got it. Rachel, I was lucky enough to visit an IBM Bluemix Garage. I guess it was at the DevOps Enterprise Summit, around that time in San Francisco. And the best way I can explain it was it’s sort of a lab, kind of a living lab where experimentation was going on as well as education and development. And it seemed like a pretty cool environment. And both for enterprise as you mentioned, anything from enterprises on up to startups.

    Rachel Reinitz:            That’s right. I think that that’s a good summary of it. We are in the startup community so we work with the startups there. And it really helps enterprises to innovate like startups, to get kind of out of their environment into our environment, a very collaborative space as you saw, when you were visiting right in the hardest heart community, we’ve actually, in some of environment news, we’ve moved to a different space still within the galvanized community in San Francisco, a bigger space, which is really exciting. We just had a little party there. And we have other locations. We are in Toronto and in London and we have a location in Nice. Each one is in a different kind of startup community. And we are working on Melbourne. So you’ll have to come investigate some of our other locations.

    Alan Shimel:                Absolutely. We are actually doing a series of roadshows, one of which will be in London in April. We’d love to get some of the IBM Bluemix Garage folks at that. But we will talk off-line. Rachel, one of the reasons I invited you on was this month on DevOps.com, we are really focusing on what we call the open technologies and open enterprise. And by that we don’t mean just open source software, though certainly open source software is part of it. But there’s more to open then software, isn’t there?

    Rachel Reinitz:            Yeah, I agree. I think that’s knowledge sharing is a big part of open, sharing different kinds of knowledge in different kinds of mediums. And I think where you’re going is to the fact that we’ve now taken what we’ve been taking in the Garage and actually merged it with what we’ve been doing in open source and DevOps Transformation within IBM and we published that as the IBM Bluemix Garage method which is out there in public, open for people to use. And we’re also looking for contributions.

    Alan Shimel:                Absolutely. And it is open, right? The whole methodology, if you will, is open. And I happen to know only because I’ve spoken to you folks before, a lot of the tools you are using are open source tools, traditional open source software. But really, when we talk about the open garage method, as I’ve heard it referred to, it’s open through and through, if you will, right? It truly is open technology.

    Rachel Reinitz:            Yes. So it’s taking the lessons that we’ve been learning, it’s providing prescriptive paths and recommendations and that crosses from our software to what we are doing in the open community and open source, open-source testing tools, third-party tools. It’s what we find is working in projects that we are doing and recommendations around specific kinds of applications like a mobile application. What do we recommend? What did we learn and are sharing those learnings as you were saying out in the open? How do you go about testing them, for example? What are your different options? Things like that.

    Alan Shimel:                Fantastic. Rachel, how big is Bluemix a part of this garage method, though?

    Rachel Reinitz:            It’s definitely a big part of it in terms of we think that using Bluemix and other IBM technologies is a way to really accelerate building these kinds of applications. But it’s not exclusive to that. So when we talk about innovative practices, when we talk about some of our toolchain, no, it could be used with other technologies. Obviously I think there’s a lot of good reasons to use it with Bluemix.

    Alan Shimel:                Sure, sure. And again, you know what, Rachel? We may have some folks who perhaps aren’t even familiar with Bluemix, why don’t we quickly give them a level set. When we say Bluemix, what are we talking about?

    Rachel Reinitz:            So Bluemix is IBM’s platform as a service. It exists in public which is then hosted in our data centers, our public data centers for software. We also have a dedicated version where we provide a managed single instance of that same capability. And then we have what we call local which can deploy onto your own systems behind your firewall. And Bluemix has multiple models for writing applications with Cloud Foundry containers and VMs. And it has a whole range of services. At last count, I think we were at about 140 and those are IBM services like our SQL DB which is a form of DB2. But it’s also third-party services like New Relic. And as I said, it runs Cloud Foundry, it runs open-source runtimes. You can bring your own runtimes. So there’s a lot of openness to it.

    Alan Shimel:                Excellent, excellent. And Rachel, you mentioned IBM was looking to work with third-party partners around this open methodology, open-source. What kind of partners, what kind of contributions would you be looking for that you think makes sense?

    Rachel Reinitz:            So we have the concept of an open toolchain where different technologies can be integrated, again, around solving a particular kind of problem like mobile. And our toolchain team works with different partners. So we are very open to partners coming in and saying hey, can we be part of the toolchain and talking about how you integrate? So for example Slack is part of what we talk about there. That’s one kind of integration. Another level of integration we have is in Bluemix itself. So we have third-party services there and we have a whole program for how a company that’s providing capability that would be of interest to developers can integrate into Bluemix and be part of our ecosystem.

    Alan Shimel:                Got it, got it. And Rachel, believe it or not, we are coming up on the – I promised you it would be about 10 minutes. We are going to run a little over but I wanted to quickly pivot, if you will. Besides this month being open technologies on DevOps.com, we are also featuring our coverage of the upcoming IBM Interconnect Conference in Las Vegas. And I would imagine, pardon me, I haven’t pre-checked; but I would imagine IBM’s Bluemix Garage is going to have a prominent place at Interconnect, correct?

    Rachel Reinitz:            Yes, yes. I’m really excited about Interconnect. We have, in the expo area, we actually have basically a mini garage set up, even with a motorcycle, I’m told. And we basically take you through the journey with a focus on our innovation path and we are sitting right next door to our DevOps team who also support the method so you can come and see what we are doing in terms of serving your innovation process and we show code, of course, and delivery pipeline. And that if you want to get even deeper and know the different options, we have the DevOps booth right near us. We have customers coming and talking about the work they’ve been doing with the Bluemix Garage method. We have workshops where you can get into a roundtable and really dive into it. So there’s a ton of things going on at Interconnect around the method. And of course, I’m presenting, too.

    Alan Shimel:                Really? What are you presenting on, Rachel?

    Rachel Reinitz:            I’m presenting on the Garage and on the method. I’ll be speaking, I think it’s Monday at 6:00 PM and then there’s a variety of different sessions. And then most exciting is I have some of my clients presenting with us.

    Alan Shimel:                Really? In case anybody listening is actually attending Interconnect as they very well might, can you give us – I don’t mean to put you on the spot, but can you tell us maybe customers and which sessions customers are talking at?

    Rachel Reinitz:            I’d have to look up specific sessions but we have KS2 and ManualLife, clients I’ve worked with really closely. Those are a couple of the – oh, and we have Spigot which has a really interesting cloud sourcing platform. So those are some of the customers that are going to be speaking. And there’s maybe a couple others that are ready to be talked about yet.

    Alan Shimel:                Fantastic. And of course, on the expo floor, people can actually get hands-on with the Garage for themselves and see what it’s about.

    Rachel Reinitz:            Absolutely.

    Alan Shimel:                And just again, in case anyone listening, Interconnect is February 21-25, I believe. And it’s at Mandalay Bay and MGM Grand in Las Vegas. Rachel, just one more question. What’s next?

    Rachel Reinitz:            More. More services. More services coming on Bluemix. We just had some – there’s new analytics, there’s new Watson services. It’s more coming, more projects with clients, cool Internet of things kinds of projects, more garages in the future building up the ones we have. Lots is going on. And in the method, too. More tools in the method, more prescriptive paths.

    Alan Shimel:                Do you think we will see a Bluemix Garage method 2.0?

    Rachel Reinitz:            Not 2.0 because we continuously deliver.

    Alan Shimel:                That’s exactly right. Good jump on the answer.

    Rachel Reinitz:            We came out with our MVP at DevOps Enterprise and now we will be having, you’ll see a lot more in there for Interconnect. We will just keep on going.

    Alan Shimel:                Fantastic. Rachel, we are way over time so I’m going to need to call it a day here. But Rachel Reinitz, distinguished engineer of IBM and sort of mother of IBM’s Bluemix Garage. Welcome. Or thank you for being on DevOps Chats today. Look forward to seeing you at Interconnect February 21 out in Vegas. And look forward to continuing development on the IBM Bluemix Garage and Garage method. Thanks for appearing today.

    Rachel Reinitz:            Thanks, Alan.

  • Shouldn’t DBAs Be Part of the DevOps Inner Circle?

    Shouldn’t DBAs Be Part of the DevOps Inner Circle?

    DevOps is changing the culture of IT.  This movement is bringing application development and operations teams to the same table and the same time, working to understand and overcome the challenges facing the entire application delivery process—not just their piece. Development and operations teams are forging new bonds and alliances in the spirit of accelerating software release cycles.

    However, while quickness to market is paramount to success, businesses can’t forget about the internal implications of accelerated release cycles. With that in mind, there is one conspicuously empty seat within the “DevOps Inner Circle,” and that’s the database administrator’s (DBA).

    DBAs hold the keys to one of businesses’ most important assets: the database. But database change innovation has not kept pace with agile development methodologies and DevOps tooling that enable continuous delivery of software updates and changes. The vast majority of enterprises are still updating databases the same way they have been for the better part of the last three decades: through manual script review, validation, execution and individual heroics. As a result, application release cycles ultimately slow down at the last mile—the database.

    It’s time for a better approach. It’s time databases and their stewards, DBAs, be part of the DevOps Inner Circle. Including DBAs can create better, more efficient teams; save time and money; and even help companies create better solutions for their customers’ needs or their own.

    Shattering Silos

    One of the founding principles behind DevOps is the breakdown of silos between development and operations teams. Product managers can easily translate customer needs and communicate that feedback to developers in a way they understand—using epics and themes, for example. This helps bring everyone on the same page so that application updates or changes can be quickly coded, tested and delivered. But before application updates can be released to users safely and effectively, they have to be translated into the changes that will update the database. This is where the DevOps breakdown occurs. DBAs often have to rely on manually intensive, timeworn, error-prone processes and tools to make sure the right changes are made to the database.

    By inviting DBAs into the DevOps Inner Circle, database updates that go against business policy and will ultimately lock the database or “break the build” (think inserting a new column with a default value when the row count exceeds a million) can be found faster and addressed by the development team well before that change reaches the database. Having DBAs involved in release cycles sooner can help ensure developers are coding with corporate compliance in mind, ultimately making changes to the database smoother while adhering to guidelines that DBAs have typically policed.

    There was a time when databases needed protection from changes made by creative problem-solving in development, but DBAs simply cannot stand against the deluge of changes necessitated by accelerated cycles. Inviting DBAs into the DevOps Inner Circle enables teams to consider the implications of new changes and updates across the entire technology stack. Breaking down silos and making teams more aware of catchpoints in the last mile of the release process lets them anticipate and avoid database issues—which means faster releases and fewer headaches for everyone.

    Saving Time (and Time is Money)

    Faster release cycles are good for business, and not just because they get applications in front of end users sooner. Continuous delivery cycles are designed to cut costs associated with application development considerably by saving man-hours. Still, while development timelines keep getting shorter, the workload and time to deploy database changes gets longer.

    Enterprises can have multiple database configurations, so each change needs to be checked for compatibility. As the complexity of data repositories grows, so too does the time it takes to review and approve changes. In a 2015 IOUG survey on database manageability, 41 percent of respondents said changes took a week or more to approve. With multiple change requests coming to DBAs each month, each week or maybe even daily, it’s clear that sheer manpower can’t keep up with continuous delivery forever. Relief for DBAs is nonexistent without automation.

    Remember our earlier example, where we ran the risk of locking the database by inserting a new column with a default value when the row count exceeded a million?  Database automation software protects against outcomes like this by forecasting the impact application changes will have on the database. DBAs can use forecast reports generated by automation software to pinpoint any issues without expensive hours or days of searching.

    As part of a DevOps team, the DBA equipped with automation can do more than save time and headaches for themselves. Protecting against errors that could break the build saves teams from spending time to find and fix the source of a breakdown, and also saves a business from losing revenue while the fix is made. If so much time, money and potential frustration ride on DBAs’ ability to implement changes at the speed of continuous delivery, why are they still on the outside of the DevOps Inner Circle?

    Freeing Up Time for Innovation

    Flashes of inspiration rarely come about when you’re just trying to keep your head above water, and for so many DBAs, that’s the reality of work. Today, enterprises fight a war of attrition with the database, throwing manpower at the final hurdle of the release cycle. In addition to the attractive benefit of saving money on man-hours, bringing DBAs into the DevOps inner circle and automating some of their tasks also creates time and space for innovation.

    The relational database is nearly a 50-year-old innovation, one that changed the way people and computers interface through data. After so much time, and with so much on the horizon, the next innovation seems imminent or perhaps even overdue. The advent of quantum computing may bring with it a fundamental change to the way databases interact with one another. It’s certain to bring a shift in the way data is stored and retrieved, though at this point experts expect only the most complex business processes will benefit from quantum computing. So, while future tech remains out of reach, DBAs will be vital in the effort to innovate faster, more streamlined ways for dealing with zeros and ones.

    The first step to innovation, then, is addressing the needs of DBAs alongside those of customers and developers. Breaking down walls and increasing efficiencies between existing DevOps teams and DBAs will give teams more opportunity to create novel solutions to both their users’ problems and their own. Add another seat to the Inner Circle, save time and money, get quality applications to market even faster, and create innovative solutions to the problems of today and tomorrow.

    About the Author

    Derek Hutson HeadshotDerek Hutson joined Datical as CEO in 2015, bringing more than 15 years of leadership experience in enterprise software. Before joining Datical, he led multiple companies through extended periods of rapid growth and also held several executive roles at IBM. There he served on the leadership team for IBM’s acquisition of Telelogic, and was responsible for due diligence and integration of the acquired sales functions globally. He currently serves on the board of Hart InterCivic and Charity Dynamics. Other board or advisor positions have included CoreTrace (acquired by Lumension), Innography, StreamStep (acquired by BMC) and Phurnace (acquired by BMC).

  • 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 Q&A: Datalink’s Dennis Vickers on MobileApps

    DevOps Q&A: Datalink’s Dennis Vickers on MobileApps

    Companies are custom-building mobile enterprise applications to enhance employee productivity on smartphones. DevOps.com recently spoke with Dennis Vickers, director of Software Solutions at data center services and solutions provider Datalink about this trend and where DevOps fits in to the process.

    DevOps.com: Why does applying smartphones to business initiatives require so much additional custom-built software?

    Vickers: Companies have developed and designed legacy software to group things that need to get done together into applications. With mobile application development the focus is more granular in terms of functionality. It’s not that the applications that we designed for the legacy environment don’t fit on the smaller screen, though they don’t. It’s really that the whole concept of having a group of functionalities in a single application doesn’t really work in a mobile environment. You need to rethink the way that not only your applications work but really the way that you do work. You need to think more in terms of granular work than accumulation of work.

    In finance, for example, you might have an application that combines accounts receivable, accounts payable, even expense management. You would have an application that would have all of that functionality in it. For mobile apps, what would make sense is to break out the expense management part of that and make that a mobile app that allows users to be able to use their smartphones to actually capture expenses as they’re incurred, as opposed to having to save a receipt or remember what your expenses were and then go back to an application and fill that in later at the office.

    DevOps.com: How do you apply DevOps development approaches to provide usability on mobile devices for the most needed features and functions of in-house applications?

    Vickers: Mobile applications tend to be single functions focused on getting something done. Users are much less tolerant of anomalies in the software, whether that anomaly is a bug, a poor user interface or anything that is undesirable about the application. They’re not nearly as willing to look for workarounds with a mobile app as they are with legacy applications.

    You have to have a continuous delivery approach with mobile applications because the time frame between deliveries has to be accelerated. You have to automate that process. We’ve made good use of some of the automation tools, specifically Puppet, around doing continuous delivery. We use tools for source control and QA (quality assurance). Some type of automated delivery process is critical because the turn time for release has to be shortened. There’s just not a willingness for users to wait long periods between releases.

    DevOps.com: Can you discuss the custom-built software project where you developed a custom equipment maintenance app that feeds into the customer’s proprietary maintenance application?

    Vickers: We developed that for an aerospace company that had a requirement to provide field service for one of the Department of Defense systems. They had to be able to maintain large pieces of equipment. We had to build an application that enabled them to be at the equipment and do the data collection that they needed at that time. It walked them through the data collection process right then.

    Before that, they had a paper process where they would print out instructions, go out and write down the information that they needed to collect, and then go back and enter that into an application. This allowed them to be able to do that closer to the actual event, which cut transcription errors and data collection errors and made the whole process much more efficient. That was an extension of a legacy app that added quite a bit of value.

    DevOps.com: For that Department of Defense project, were there particular development tools or approaches in DevOps for the software?

    Vickers: We used an agile methodology where we iteratively released the software and did test and review and then essentially layered the application. We provide a layering process as we build and add features to the application. We delivered to the customer through an automated process using Chef. We use Jenkins to do some release management, but we often revert back to Chef or Puppet.

    What we haven’t done a lot of yet, which I think is important and I see growing in the mobile platform, is monitoring. I think that monitoring is an important part of DevOps. I haven’t seen that move into the mobile environment nearly as much as I think it needs to. I think it will happen in the short term. I think there’s some good monitoring tools out there that are coming online or that are maturing and are going to be adopted for mobile app dev.

    DevOps.com: There was another project where you custom-built a jobs app that enables union members to apply for posted jobs without going into the union hall.

    Vickers: We developed a mobile app so union members can review jobs that are available and request the job through the app. They can receive job assignments and electronic tickets to go out and do that job. It saves traveling down to the union hall on a regular basis and makes the whole process much more efficient.

    The only difference in that project is that we needed to integrate with the back end through an API. The tool we used to help us interface with that API and manage that API integration was Postman. We use it for testing, managing and documenting APIs we build or work with.

  • Using DevOps to Avoid Architecting Application Slums

    Using DevOps to Avoid Architecting Application Slums

    The U.K. high-rise tower blocks and built circa 1950-1980 were heralded as architectural wonders—large concrete towers easily housing the same population as the smaller houses they replaced. With large rooms, excellent views and surrounding open spaces, they initially were popular residences—low cost and futuristic.

    But looking futuristically sometimes has a habit of coming back to haunt you.

    Due cost-cutting, substandard materials, demanding deadlines and rushed construction practices, these modern-age housing miracles became the new slums of the day. By replicating tower-blocks across the country, town planners unwittingly replicated bad designs everywhere. The results: undesirable housing and elevated crime levels, leading to slums and urban decay. Even the surrounding open areas were neglected because no one had ownership over maintenance and supervision.

    In IT, we have our own design and architectural calamities.

    There are many similarities between existing IT apps and decrepit old tower blocks. IT monoliths can be hard to scale, requiring costly maintenance to avoid disrepair. They’re also tough to police, with vandalism and theft being a constant problem. Add to this integration issues (IT’s version of unsupervised open spaces and pathways), and we’re left with systems inadequate to meet the needs of modern digital business.

    Enterprise architecture must change with the times

    DevOps, with its focus on operations and development collaboration across the entire service life cycle, is now seen as the answer to some of these problems—an approach underpinned by agile and lean principles for rapidly delivering high quality digital services. That sounds great, but let’s not forget enterprise architecture (EA), because without it we could still be building IT slums—only more of them and much, much faster.

    Of course, many DevOps stalwarts may argue (with some justification) that heavy EA practices and frameworks haven’t evolved to match the pace of agile. Iterative-style development means where you start isn’t necessarily where you finish, necessitating a transition from set-in-stone architectural designs to a fluid mix on continuously evolving decisions. And, if EA can’t adapt, autonomous and self-managed agile teams increasingly are empowered to make architectural calls.

    But great developers aren’t necessarily brilliant architects; they’re not hard-wired that way. It means they could be charging down a development path without architectural guiderails, or tactically making team-based decisions that compromise program-level objectives. For example, the scalability and performance needed to support a business strategy of tripling the customer base and increasing satisfaction scores could get lost because development focuses myopically on delivering more functionality.

    However, we can’t just lay the blame on developers. Enterprise architects must recognize that any misalignment between their processes (especially the rigid and static ones) and the vision of an increasingly software-driven business will only further isolate the practice.

    Architecting new fluid guidelines and principles

    The role of EA in an agile context is still up for debate, but this shouldn’t hold us back. By using architects and fluid guidelines means we can maintain the pace of delivery while preventing chaos. The trick of course is to limit architectural over-engineering while providing developers with a minimum set of EA to avoid technical and architectural debt.

    Even in minimal mode EA can still help developers identify quickly what should be considered during design. The aim is to guide developers into understanding what architectural facets make up a successful application, and more importantly, how new ways of thinking can support longer and more sustainable software innovation.

    Interestingly, these practices can be presented in a “slum avoidance” context:

    • Avoid substandard or unsupported materials – The tool chains being used will probably comprise both commercial and open source software, but beware of anything unsupported. Just as the cost of maintaining tower blocks reached unsustainable levels, so too, will support burden on an organization if software isn’t commercially backed, especially in IT operations. Also, work with development to understand where constraints lead to testing compromises—the “construction shortcuts” syndrome, resulting in more defects and technical debt.
    • Never use new technologies to rehouse old problems – As tower blocks degraded and vandalism increased, many local authorities tried to contain the situation by housing “problem groups” in the same block. But that just increased problems. Enterprise architects can make the same mistakes—for example, laying down crazy edicts that everything must be containerized, even some legacy apps; not understanding that runtime independence only extends the life of problem applications;  or providing no incentive to drive improvements and clear existing legacy IT slums.
    • Monitor and manage your sub-contractors – Whatever cloud model you adopt, abstracting away the infrastructure or application stack frees development to focus on coding. That’s great, but don’t forget “PaaS-ing” apps to the cloud doesn’t mean relinquishing ownership of application performance and the end user experience. To this end, architects must act as cloud-brokerage advisors—for example, working to ensure any cloud service provides open APIs, so that monitoring can be seamlessly incorporated into a unified solution.

    Of course, architecting great new digital services with DevOps is only part of the answer. The innovations of today may become legacies of the future and many new apps must also integrate with existing systems. It’s essential, therefore, that architecture covers both bases: working in minimal mode to ensure fast construction of quality services, but also applying standards and governance when needs dictate and systems change.

    No matter how good your app designs look on paper, bad architecture just means building more problematic systems and never clearing the existing slums.