devopsy.kinsta.cloud

Category: Enterprise DevOps

Why I Dislike The Term ‘DevOps Culture’
Culture is critically important in an organisation. It’s all of the hidden stuff that actually matters. It’s what people value and it feeds through to how people behave when you aren’t watching them, driving thousands of small decisions per day across the enterprise. A broken culture is a horrible thing to work within and a really tough thing to change because it is so inherent to an organisations DNA.

I also believe that DevOps is fundamentally a culture. If people aren’t approaching IT delivery in a collaborative, emphatic way with a focus on continuous improvement then it probably won’t happen despite all of the change initiatives in the world.

On the flip side, we can have the slowest, most beuracractic, most legacy technology environment, but the right culture will usually transcend all of that and make good DevOps like ways of working happen.

With all of this said, I really dislike the term ‘DevOps Culture’. Nothing tends to get me ranting more in the DevOps arena than hearing that phrase.

Why? Because it is so inactionable.

I speak with a lot of enterprises who are looking to adopt DevOps. Once they have decided to get started, the first question is ‘What Shall We Do First?’ If I was to say, ‘DevOps is about a culture and about people having empathy with one another’. They would say ‘Great how do we achieve it? What do we do tomorrow, next week, next month?’

At this point, some people scratch their heads. In the past I’ve heard, ‘buy dev and ops a pizza or some beers – thats a good first step. Maybe try a rotation or two and the culture will develop.’

Personally, I don’t think that will cut it in a 10,000 person globally distributed IT function. The pizza bill alone would bring down the organisation.

Moving Towards A DevOps Culture

Culture is very hard to influence directly, it’s emergent from much more concrete activities.

The meat of the discussion needs to lie there – in the steps we perform to get the outcomes we want. Things like:
- Moving to cross functional teams
- Cross training or hiring people with polyglot skillsets
- Giving people the same incentives across the IT function
- Empowering people to self optimise their processes and the end to delivery lifecycle
- Encouraging people towards cross-silo collaboration over being tied to a rigid process
- Changing reporting lines in the business
- Investing in optimising the path to production over new features
- Training and coaching developers, testers and IT operations on new collaborative ways of working
- Bringing in new tools to support collaboration across siloes
- ….. & 1000 other concrete activities
To me, roadmaps of the activities above and the challenges and subtleties involved in doing them are much more useful than a nebulous statement about DevOps being a culture. I can actually do something with these!

DevOps needs a much more rigorous approach to achieving it within the enterprise. We need to be develop out all of the steps above and bringing the conversation down to earth. Only when we get to this level of detail will we actually succeed in moving the dial to a DevOps culture.
May 18, 2015
The 3 practical change elements in enterprise DevOps

Culture, Technology & Ecosystem

Most enterprises approach DevOps adoption in a singular fashion: they use a bottom-up approach that is typically technology-driven and groups all considerations like, culture, metrics, processes and communication into a single stream of work that is often led and implemented solely by technology-oriented champions.

However, this singular approach presents a few issues:

(1) First, it leads to poor planning on the change aspects of DevOps that are not (and should not be) technology driven – although we (DevOps Evangelists) are not change experts, we believe we can properly assess impact & lead organizational change just because we are the subject matter experts on the technical topic (DevOps). Accordingly, we miss the wider context and relationships with non-IT functions that would be impacted by DevOps.

(2) Second, it naturally focuses the efforts on the areas inside our comfort zone (technical aspects) and potentially disconnects the DevOps program from the Enterprise priorities. If it didn’t, it limits DevOps to a technical change of tools and automation.

(3) Third and most important, it contributes to the absence of realization that the changes in areas outside of IT is critical to the success of DevOps adoption and that specialist (internal or external) help in these areas may be required and better yet, often acts as a catalyst for change.

The consequence of the 3 points above is that post the initial phases, enterprises reach an incomplete point of “DevOps Equilibrium”; this is the state that enterprise IT reaches after installing some automation tools, setting up a basic practice and changing some behaviors. It takes a lot of effort, dedication and pressure on the organization’s DevOps evangelists to make this initial launch and bring the beginnings of DevOps into their Enterprise. By the time they reach that point, energies are depleted, the bigger challenges of enterprise politics and ecosystem become apparent and the thought of another push to bring in more teams, departments, tools and stakeholders on board becomes a burden.

The question then becomes, why is it a struggle and why is it difficult to adopt DevOps in an Enterprise? The reason is that the singular, technology-driven approach that “considers” the soft aspects of DevOps fails to leverage the value it delivers by transforming it into executive sponsorship and political influence; and the reason this happens is because executives consider a bigger enterprise view that stretches outside of their departments and outside of IT but the technology-driven, singular approach has a narrower view and fails to address the ecosystem of the enterprise that surrounds the technology and the culture, and accordingly all the executives’ concerns.

In my experience, one of the main reasons DevOps evangelists in Enterprises fail to move beyond their point of equilibrium is because they approach DevOps as a singular, technology change not as an enterprise change.

What I have seen from multiple enterprise DevOps journeys is that Enterprise DevOps adoption should be broken down to 3 main “Change Elements” and DevOps Evangelists should plan for each “change element” separately under a single program umbrella:

1st Change Element is “Technology” – Enterprise IT landscapes are typically diverse with bespoke and packaged products. Having the technical expertise to understand what DevOps tools fit the enterprise landscape and how to integrate them into bespoke and packaged products is key. Also, understanding what does “implementing DevOps” mean to different IT systems is crucial; for example, do you need to automate the release of revenue-assured systems where speed is not as important as quality or is it enough to implement quality inspections only? Also, which systems do you start your journey with and based on what criteria did you choose these systems/projects?

2nd Change Element is “Culture” – This is looking into how the IT teams would change the way they work, for example, developers need to check-in more frequently, business analysts need to learn to write behavior-driven requirements and operations should start understanding more about what developers do. Another example is how the developers’ (or testers … etc.) objectives will change to become more DevOps-Friendly? (For example, objectives should focus on the handover points between teams rather than team-specific activities). This is more focused on internal IT rather than the rest of the enterprise. Challenges arise here when adoption is phased without change planning – when developers potentially are required to change their approach when testers and operations teams are not. In this scenario, frictions arise.

3rd Change Element is “Ecosystem” – This is the core of the message and it is about how to plan for organizational change outside of IT. This element is about how DevOps impacts the enterprise outside of the IT space and how to position DevOps to the rest of the enterprise. Here are a few examples of what should be done in this space:

(1) Finding a Context: DevOps evangelists need a context for their initiative and it needs to complement other efforts in the organization. For example, evangelists should choose an organizational pain point like “poor customer experience driven by poor product quality”, and position DevOps as the IT solution among a wider enterprise program to tackle the issue – this helps evangelists take a benefits-driven approach to DevOps adoption, which goes along way in navigating the politics of the enterprise.

Another example is the “lean initiative” – in most organizations I’ve seen, there is usually a process improvement or lean initiative going on in non-IT functions; evangelists need to hook into these relevant initiatives, present DevOps as aligned with the organization’s direction of becoming lean and position DevOps as the IT part of that lean journey.

(2) Second, evangelists need to understand and assess the impacts of DevOps outside of IT. For example, as they change the culture by changing developers’ objectives (see above), how does that impact the overall HR strategy of the enterprise that places roles in bands and have a clear definition of a “Star” and how to promote this “Star”? Similar to HR is financial governance: how does a DevOps lifecycle work with the budgeting and financial governance process of large enterprises that releases budgets in gates/phases that are typically not iterative?

Another example is how do evangelists link their DevOps metrics with the wider organization performance KPIs and business objectives? How do evangelists deal with the enterprise’s managed service providers and system integrators who may very well be located oversees and get them to work in a DevOps way without breaking existing contracts?

(3) Finally, evangelists need to understand the political landscape and how to gain IT and non-IT support to their DevOps journey. Activities in this space should address the following questions: how do evangelists gain IT and non-IT Executive sponsorship to get non-IT teams to support their journey?

Answering all of these questions above requires partnerships and help from other non-IT enterprise departments – but how do evangelists build these bridges?

Because of all these Ecosystem challenges, I believe DevOps adoption in the enterprise should be approached as an enterprise change not a technology change. DevOps evangelists should dedicate separate plans for the 3 change elements above under a single DevOps program and they should not be shy of reaching out for non-IT help (external and internal).

In the next few blogs, I will discuss each change element separately. Then I will answer the question that probably most of you are asking by now (continuing with the analogy): So what happens if the enterprise passes this “DevOps Equilibrium” and reaches a point of “DevOps Escape Velocity”? The point when DevOps is an established and acknowledged enterprise standard. What benefits will the enterprise reap? And why isn’t the point of equilibrium enough?

About the author/ Tarek Negm

Tarek is a DevOps and Lean IT enthusiast with a specific interest in the change aspects of the movement. He is a founding partner at Do Consultants where he helps enterprises adopt and realise the business value of DevOps and Lean IT. Before that, Tarek spent his career in global organisations in the UK and Europe working in IT leadership and Technology roles in a wide variety of industries including Telecoms, Financial Services, Hospitality and F&B. Tarek’s experience spans all the technology lifecycle starting with Linux kernel development to Enterprise Architecture and IT Strategy, in addition to IT change where he previously led a global IT transformation program across 5 European countries. Tarek holds an MBA from London Business School focused on change management in technology. Reach him on LinkedIn:

May 14, 2015
Webinar: Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study

Whatever your conviction, the reluctance by senior management to justify new investments and sponsor major change in existing software delivery practices and technologies, while theoretically understandable, often leaves application development executives and managers lobbying for additional budget and resources putting them and their teams between a rock and a hard place. So the question is how do you monetize the benefits and measure your DevOps results? Join Valerie Scott, Manager of Shared Services Division at HM Health Solutions, Rick Slade from IBM, and Alan Shimel from devopsy.kinsta.cloud as they discuss the process for quantifying DevOps benefits using metrics your business stakeholder will care about the most. They will walk you through the methodology and share customer case studies that demonstrate the impressive ROI that DevOps is providing to IBM clients worldwide.

EVENT RECORDED: Tuesday, June 2, 2015

VIDEO

https://www.youtube.com/watch?v=J5haNExYZ2o

SLIDES

[seoslides embed_id=”f384dfd0ae4e” script_src=”https://devopsy.kinsta.cloud/embed-script/show-me-success-before-ill-invest-in-devops-a-hm-health-solutions-case-study/7686/” overview_src=”https://devopsy.kinsta.cloud/slides/show-me-success-before-ill-invest-in-devops-a-hm-health-solutions-case-study/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study” /]

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Valerie Scott, Manager of Shared Services Division, HM Health Solutions Strategic planner and IT leader with years of architecture and infrastructure experience in the healthcare insurance industry, Valerie is a key player in the IT Transformation efforts by driving a lean wave of change in the HM software delivery pipeline with DevOps concepts and technology.

James (Rick) Slade, Executive Solution Architect, BVA, Cost Benefit Analysis, IBM Rick is an Enterprise Solution Architect at IBM and spends his time helping clients design and automate enterprise software development and delivery practices. He is certified as an IBM and Open Group Distinguished IT Specialist.

May 12, 2015
DevOps Spring Tour 2015: Keeping Cool with ICE

One thing I love about conferences is finding out what other people are doing in industry and getting exposure to new ideas. I like to get external feedback on my work because I find it to be helpful. Here’s some highlights from where I’ve been and what I’ve heard so far in 2015, including Alterconf, RSA, A Data Presentation Course with Edward Tufte, and DevOpsDays NYC.

AlterConf

My first stop was Alterconf in Atlanta this year. I try to support local events and knew I would gain a lot of perspective from the presenters that I probably wouldn’t find elsewhere. There was a lot of discussion about age bias and discrimination for both younger and older people as we all move through those stages during our lives. Starting a culture of continuous learning early in life was a consistently supported goal among the presenters and attendees.

My other take away from alterconf is people may or may not be comfortable representing or discussing the different groups they belong to with anyone. Introverts can have a very difficult time talking tech at an event, for instance. Several speakers at the conference made note of the fact that we will occasionally step on each other’s toes due to what are ultimately misunderstandings and we should be quick to apologize, provide space, and try not to get too upset when someone makes a mistake or appears uncomfortable. I was encouraged to see the consensus lean towards discretely and respectfully bringing any issues up if necessary instead of public exposing someone. Even snapping at a manager in a meeting over a wisecrack about a father ‘babysitting’ his own kids does more harm than good. You shouldn’t stomp on anyone with both feet over failed build either. Having a calmer conversation with a smaller audience if possible was the advice I heard repeatedly throughout the day.

We’ve been having more conversations around anxiety and burn out as a community and talking a lot about comfort, learning, and danger zones. I’m going to openly admit I was more nervous than usual going into alterconf as a white cisgendered heterosexual male. It may have had something to do with the fact that I didn’t know what cisgendered meant before the event. The anxiety quickly passed after I found my seat and realized there were plenty of people there just like me. At a minimum all of us were passionate about technology. It was a very open and welcoming space and I gained a lot of perspective that I wouldn’t have otherwise. There are 5 more sessions scheduled this year if you may be interested in gaining some perspective from a broader range of people that are also passionate about tech.

DevOps Connect @ RSA

DevOps Connect @ RSA was a uniquely awesome experience. I met a lot of security folks coming into the DevOps space for the very first time which was encouraging to see. I also got an up close look at the security industry and why they need to gain some insight from a DevOps perspective. The expo floor was the most commercialized one I’ve ever seen at an event. It reminded me of a midway at a state fair. I wouldn’t have been shocked if someone had called me in for a go at the ring toss. Most of the sales pitches sounded like magic beans to me, bolted on for instant risk mitigation.

The one vendor that separated themselves as an exception to this was Tufin. Tufin’s security orchestration suite is a comprehensive solution for network security management providing visibility, change tracking, analysis and auditing for firewall policies, network devices and cloud platforms. It also provides automatic firewall change management and application connectivity management. It assures a tight security posture, rapid service delivery and regulatory compliance across all enterprise platforms.

I haven’t taken it for a spin myself, but Tufin definitely impressed me with their demo and orchestrated approach to the problems security is currently facing.

Certification was also a consistent topic of conversations at RSA. I think there’s a lot of misunderstanding in this space between arbitrary compliance and compliance that legitimately mitigates risk or provides a return on invested time and energy. This sentiment echoed through Secretary Jeh Johnson’s keynote, as he announced the opening of a satellite cyber security office in Silicon Valley and an invitation to cooperate with concerns surrounding encryption.

Data Visualizaiton Workshop with Dr. Tufte

My next stop was Boston for a data visualization workshop with Dr. Edward Tufte. When I told him I was a devOps engineer working on dashboards in an enterprise environment I could tell he was curious but may have not heard the word devOps before. The person I was speaking with before Dr. Tufte came by mentioned a health care system that still faxed data between offices and the problems it caused with younger employees that had never used a fax machine before. It was obvious to Dr. Tufte that they should switch it to a web based system, and the frustration with compliance and risk concerns that prevent that change from happening were not lost on him. For lack of better words and opportunity, I offered this as the type of problem devOps is currently trying to solve. The perspective I gained from the session that followed was from an experienced professional that can fully appreciate the current state of the art. I believe I appreciate it now more than ever, for which I’m thankful.

DevOpsDays NYC

The topic of discussion was ICE, or Inclusion, Complexity, and Empathy, based on a post by Dave Zwieback from earlier this year. The talks focused on how to try to cooperate better between teams both at home and abroad and suggestions on how to handle departments that are more territorial in addition to dealing with our own stress levels.

Attendees seemed particularly grateful towards John Willis and Justin Lintz for talking about burn out and anxiety in our industry among heavier topics. If you’re inclined to start a conversation about these types of health issues in your community then you probably should. I try to shut up and listen as much as possible, and that’s often helps more than one would think. If you have a venue to show John’s video before an open spaces event all you have to do is book the room and be available. Creating an opportunity to discuss these issues is a huge step forward in my opinion.

But wait! There’s More! I’m giving an Automating Enterprise Security Talk at Gluecon outside of Denver later this month. I spoke about this at devOps Connect @ RSA but I always update my content between talks as I get more feedback from folks. If you happen to be at Gluecon this year we should have a conversation over coffee, a beer, or a meal. From my experience a chat tends to be more fun in person than online, as I for one get tired of staring at screens all day.

May 12, 2015
What lane do you travel on the DevOps highway?

Last week we kicked off our webinar series on Variable Speed DevOps. The discussion was lively and informative. For myself as moderator the webcast was as comfortable as an old pair of slippers. Two of the three panelists, Carme DeArdo of Nationwide and Sanjeev Sharma of IBM are both friends and people I have had the pleasure of appearing with before. Additionally, Lee Reid, fit right into the discussion, not missing a beat. You can listen to the recording or view the slides here.

We discussed Variable Speed IT from many different aspects and how Nationwide has successfully merged onto the DevOps highway. More than any of the other analogies we spoke about or I have heard, I really like the DevOps highway as a good way to explain Variable Speed IT and Variable Speed DevOps. The notion of multiple lanes with traffic moving at different rates in each lane is a good way to think about Variable Speed IT.

Of course if only things were that easy. In the variable speed DevOps world the traffic in each lane is directly connected to the traffic in the other lanes. This is where the expertise of Carmen and the rest of the panel comes into play. In an organization such as Nationwide (see the first two slides of the deck to get an idea of Nationwide’s scope) coordinating Systems of Records with Systems of Engagements, multiple dev and ops teams and doing it all successfully is orchestration worthy of a maestro.

Lee and Sanjeev in their positions at IBM have had the chance to work with several organizations like Nationwide so can take lessons learned across an even wider spectrum of experiences.

All of this added up to a great webinar that I was lucky to be part of in some small way.

Our deep dive into Variable Speed DevOps continues on May 19th with the Canada Mortgage Housing Corporation explaining how they were able to break down IT silos and in both their mainframe environments (yes even mainframes) and others. You can find out more about this one and register here: https://devopsy.kinsta.cloud/blogs/variable-speed-ibm2/?S_Tact=C34701GW.

Variable Speed DevOps, 2-Speed IT, Bi-Modal IT – we are seeing lots of different terms to describe a common fact pattern. We think this series of webinars will explore many of the facets of this subject.

In them meantime we are off to a fantastic start with our first in this series. I really encourage you to go have a listen. Many thanks to Carmen DeArdo, Sanjeev Sharma and Lee Reid for kicking us off with a great webinar.

May 11, 2015
The Heavy Cost and Burden of Shrink Wrapped DevOps

I’ve worked in the enterprise software game for quite a few decades now and for most part it’s been a good gig. Ok, there’ve been a few road bumps that beset anyone working in this oh so fickle and volatile business, but what really keeps me motoring isn’t the software at all – it’s the joy that comes from helping folks learn and grow – even in the midst of all the crap, chaos and confusion that surrounds us.

Paradoxically and sadly, most of this “triple-C” burden comes from over hyping and sensationalizing the real IT goodness. Goodness in the shape of best practices that can help us grow both at an individual level, and in context of supporting team, departmental and business goals.

DevOps is a classic example.

Here we have a set of principles and guidance to facilitate better communication across an often fractured IT function. All simple goodness you might well say. So why is it that clever folks are waxing on at great lengths to proclaim DevOps is the best IT thing since sliced bread? Why are vendors hurriedly washing just about every product (from servers to thermostats) with the DevOps soap? Why is it that our industry is taking something that’s really common sense and shrink-wrapping it in hyperbole and nonsense?

Well, the short and simple answer is there’s a buck to be made. Hey, nothing wrong with entrepreneurial spirit, except of course when the cost and burden of suspect knowledge and overstated capabilities (all packaged in glossy DevOps wrapping), is passed on to you – and becomes – well, another “box” that sits and gathers dusts on the shelf of good intentions.

So whether you’re a working at the sharp end in development and operations or in the management treadmill how do find and put to work all the DevOps business goodness and not end with another trendy IT white elephant? I have some surprising, but simple advice that starts and ends where it’s most effective – with you.

Garbage in, Garbage out – Go on, Google DevOps — 10,900,000 results in 0.23 seconds– isn’t the Internet just wonderful. But in all the noise, how much is actually useful and applicable in context of your daily grind – Not that much, I’d say. Nuggets are especially hard to find when you’re distracted by all rants and raves – like, ITIL is dead – long live DevOps, or DevOps solves Global Warming. Ok, I jest, but for the sake of your sanity, seek out folks who apply common sense thinking as it applies in your world. Personally, I enjoy (although I don’t always agree with) the work from the likes of Kim, Spafford, Haight, Bloomberg, Edwards Willis and Mann (even Rob England for a good dose of Skepticism), but depending on your own craft, look for solid, meaty, practitioner-baked material that makes sense to you.

Greeks bearing Gifts – or anyone for that matter. The good or bad thing (depending on which way you look at it) about DevOps is that being a collection of principles it lacks a formal framework and isn’t a standard. Unfortunately this provides an opportunity for scurrilous types to fill the void with suspect claims. So if a vendor tells you that they have the best DevOps product, or that their product/service is DevOps compliant, they should probably be selling steak-knives on one of those late night promo TV channels.

Don’t Play the Fool – In slang we often use the word “tool” to depict someone that goes along with something without question and never questions the greater purpose. How often do we see the other form of tools (great software products) used in this manner. All too often the business invests in damn fine open source and smart enterprise software, only to have its true potential diminished because of tribalism, parochialism and plain stupidity. So the next time a tool lands in your eager hands, think beyond your silo and see what automation and integration exists to weave the DevOps collaboration fabric between you and you colleagues. Like for example Ops guys using performance management data to auto-generate realistic virtual services that Dev and Test can use to prevent defects reaching production.

Apply the KISS Principle – it’s easy to get carried away in DevOps folklore with grand tales of continuous deployment, microservice magic, containers and design for failure. But back on your planet, old creaking servers still need to be patched, the help desk sucks, and you’re being asked to deliver mobile apps on the smell of an oily rag. Sure, there are great lessons in the DevOps hall of fame, but think practically about what’s applicable in your organization. Like any best practice, DevOps isn’t an all or nothing approach, so cherry pick what works and think big as you progress. Personally, I think the best place to start is by applying lean thinking – that is, clinically identifying and unashamedly owning up to the waste and technical debt that exists in your own department.

DevOps is great, but it isn’t a perfect package. Your role is to take it, shape it, and apply it in ways that work for you and your organization – which always involves, time, cost and commitment.

Shame on anyone who tries to shrink-wrap DevOps in outrageous claims that just add more burden and cost to an organization.

May 11, 2015
DevOps and Bi-Modal IT
Can a business have two competing approaches to delivery and operations of their information infrastructure and be successful? If you follow Gartner recommendations, it would seem that bi-modal IT is the way to go. Bi-modal IT has been explained many different ways, but, ultimately, comes down a failure in leadership; allowing a subset of IT to continue to operate in an non-optimal way because it’s too expensive and difficult to transform. This results in formation of a secondary subset of IT leveraging emerging trends that have demonstrated results to deliver modern information infrastructure faster with reliability.

If we examine from the 50,000 foot view, bi-modal IT actually makes a lot of sense. Disruptions are happening everywhere and businesses need to respond quickly. For many of these businesses IT can barely keep the core systems afloat let alone bear the burden for handling creative exploitation of massive data growth, enhanced customer experience and transformation to new compute platforms. A nimble team with the right skills can facilitate forward movement in these areas with little disruption to the core business. Moreover, they can establish a framework and approach that enables the core business to adopt when ready.

The issue is when we move down to 5,000 feet, this strategic viewpoint becomes a series of tactical actions that have the potential to spell long term disaster for the business. For example, the data that feeds many of the new digital applications is actually housed in systems being managed by the “traditional IT” group, which means that the “fast” team now is reliant upon the “traditional” team to enable access. Needless to say this is fraught with many hurdles; everything from heel-dragging due to animosity to lack of skills to lack of slack time needed to make the changes to support. While the stick might help with heel-dragging there’s little it can do to fix the lack of skills or slack time issue.

Technical and operational debts are finally coming home to roost for many of these businesses. Lack of attention to automation, documentation, training and staffing are now creating a Sophie’s Choice for many IT and business executives.
- Where do we invest?
- Do we spend time and money making what we have work better before addressing the needs to compete in a digital economy?
- If we do this, how far behind will we fall?
- If we follow a bi-modal IT strategy, do we risk losing critical resources needed to support our existing systems?
For years we’ve been telling the business that downsizing and budget cuts for IT is a mistake. The reduction in headcount and budget continued to squeeze existing resources to take on more responsibilities. As we now know through DevOps research the larger the quantity of work-in-progress being managed the more likely the increase in defects during the build process and the higher the likelihood of outages in production.

If there is a possibility to escape this conundrum, it most certainly is not bi-modal IT. Leveraging a nimble team to meet the needs of digital economy is fine, but they must work cooperatively with the traditional IT teams. Prioritization of backlog and increased transparency with the business is critical for moving forward. The business has to accept they can’t do everything they want that’s new and keep all that’s running today. Specialization must be reduced through standardization to reduce complexity and bottlenecks. Increased automation efforts will reduce time spent on manual operations and afford time to support other key efforts. Visualization and communications of work-in-progress across teams will minimize conflict and foster faster prioritization of critical efforts. Finally, moving to fewer changes with increased number of releases will enable the business greater opportunity to prioritize efforts.

In summary, one could say that the fix for IT isn’t going bi-modal, but adopting continuous delivery and lean IT approaches.
May 8, 2015
The Great Legacy Code Crisis Of 2016

Over the next few years, I believe that legacy software is going to become a key factor which will start impacting organisations in fundamental ways, having a sudden and significant impact on their profitability.

Those constrained by legacy platforms will be operating with a ball and chain, holding back their ability to get new features to market, to iterate, and to innovate with software.

Those unconstrained will be able to fly by taking advantage of modern tooling and approaches, and quickly grab market share from an increasingly fickle consumer base.

These modern approaches to software delivery such as DevOps, Continuous Delivery, cloud, containers, infrastructure automation and polyglot MicroServices are exponentially better approaches than last generation technology. Those who are working on these modern platforms can move so quickly in comparison to more traditional enterprise environments that people working on older platforms don’t stand a chance. It’s at least a 5-10x uplift in speed of delivery.

What is scary is that by legacy I am not even talking about mainframes or Visual Basic desktop applications. I’m talking about last generation .NET and J2EE platforms which are too heavyweight, slow and bulky to change. Change, iteration and experimentation is what’s important in the new world and these platforms are just not optimised for that.

Many enterprises who I speak with through Contino are seriously feeling this pain now, even though they don’t consider their technology legacy or outdated.

Why Now?

Of course, people have wanted better, faster, cheaper since the dawn of time. Disruption is a mature concept and legacy technology has also been an issue for enterprises for a long while.

What is different this time is that there is now a burning platform. Every business is competing on the strength of their technology, and nimble startups can come along with lower barriers to entry and eat their lunch. Likewise, more established players who are much better at software delivery can branch out into new markets and beat incumbents on their own turf. For instance, what would happen if Amazon launched a bank? Their technology capability would allow them to leapfrog established players in a very short space of time. Established businesses are seriously exposed.

Decoupling, modernising and re-platforming legacy code takes a long while. Some of these projects are going to need significant amounts of work and significant budgets to re-platform, but the cost of not doing is huge if the organisation doesn’t survive in the new software centric world. I suggest starting those conversations now in order to swerve what future generations could deem as the great legacy code crisis of 2016!

May 7, 2015
What’s the cost of build versus buy DevOps?
Nearly every business today relies on faster, innovative technology to succeed in the marketplace. How about the coffee you drink, or the movie you’re watching, or the phone on which you’re watching it? Name every business or walk of life. You can argue that technology serves to make it better. If DevOps helps deliver the best services and experiences to you, then should companies making the coffee, movies, and phones also make their own DevOps solutions?

I completely empathize with the challenges the developers and DevOps teams face in transforming a team or company from traditional development and delivery to an agile lifecycle. I experienced this firsthand at Trend. I led a business unit that acquired a SaaS company for online backup and storage; this young company updated and deployed code several times a day. To integrate their processes into ours was painful. I wish ElasticBox had been an option then. I cringe when I consider the time and costs of lost productivity, wasted development time, and delays in getting to market.

Faster deployment nirvana

Every day, I speak to several technology companies. Speed is at the top of their mind. They all experience the pain of not deploying and delivering applications to the cloud fast enough. Most have some number of cloud applications, some customer-facing and many internal on both private and public clouds. To give you an idea of how widespread this pain is, see the 2014 451 Research report. The 451 Research team reported that more than 60% of businesses wanted to deploy more frequently.

But moving from agile development to agile delivery across an application lifecycle comes at a cost. Companies calculate the cost implicitly and explicitly. I’ve heard feedback from prospects who say explicitly: “I love your product, but I can build the same thing with my developers in xx country.” They usually have many smart development resources and tend to be born-in-the-cloud companies. Others tell me, “This is not our core competency. We don’t want to maintain a cloud application manager. We want yours.”

Build versus buy DevOps

At what cost do companies decide to build versus buy a cloud application manager from ElasticBox or one of our competitors?
- First, you have to answer this question: What is your company’s core competency? Do you really want to divert resources to build your own cloud application manager versus invest in your core offering?
- Second question: What is the urgency and need? If you have time on your side, taking a year to build your own solution may make sense. If you need a solution tomorrow, then what is the cost, in terms of market impact, competitiveness, customer satisfaction, of delaying a year.
Once you answer that, you calculate the total cost of owning (TCO) the complete lifecycle of build versus buy. These values must encompass all the phases of building and ownership: acquisition, operation, change management, training, ongoing maintenance and internal support. Time and time again, enterprises only look at the initial build or acquisition cost and fail to fully calculate the ongoing implicit costs.

Recently, I met with a VP of Engineering who had built a barebones deployment solution a few years ago. Now she bemoans the fact that the costs of maintaining a less-than-perfect solution is too much. Her TCO calculation included the developers, ongoing maintenance, workflow delays, meetings, support tickets, delayed product launches. Her decision to now buy is a no-brainer.

I’m not arguing that it’s always better to buy than build. But consider the factors—core competency, time-to-market delays, and TCO. We want enterprises to keep building great software that complements their core value proposition. When it comes to agile delivery, consider an experienced partner who handles the same problem for dozens of enterprises. Simplicity, flexibility and speed—those are the barometers of agile delivery success. So developers feel productive, applications deploy faster, and your customers relish the delicious cup of coffee as they watch Netflix on their iPhone.
May 4, 2015
Webinar: Canada Mortgage Housing Corporation breaks down IT silos and speeds up mainframe development

DevOps encourages adoption of lean and agile development practices irrespective of platforms. However in most organizations mainframe and mobile/web development teams are functioning in siloes, resulting in a plethora of technology platforms and tools, fragmented or manual processes, skills shortage causing unnecessary delays, rework and friction among teams, impacting organizations ability to respond to the business needs.

Join Jeff Blackadar, Application Development Manager at Canada Mortgage and Housing Corporation, Alan Shimel and IBM experts as they explore the various DevOps strategies, practices and solutions to increase collaboration, streamline processes and leverage modern tooling to attract next generation of mainframe developers to speed mainframe application development and maintenance.

Event recorded Wednesday April 22^nd, 2015

VIDEO

SLIDES

[seoslides embed_id=”24772d7de05d” script_src=”https://devopsy.kinsta.cloud/embed-script/variable-speed-devops-ibm-chmc/6919/” overview_src=”https://devopsy.kinsta.cloud/slides/variable-speed-devops-ibm-chmc/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Variable Speed DevOps-IBM-CHMC” /]

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Jeff Blackadar, Application Development Manager, Canada Mortgage and Housing Corporation

A veteran at application development, Jeff leads a team that programs COBOL, VB.Net, Java and Enterprise Generation Language applications. He is dedicated towards implementing and upgrading of tools and practices to improve productivity and reduce the risks of making changes to mission critical mainframe applications.

Venkat Balabhadrapatruni, Senior Technical Staff Member, Chief Architect, Enterprise Modernization, IBM

Powered by extensive knowledge of z Systems, software design, development, delivery and enterprise modernization, Venkat is responsible for technical architecture and direction of Rational Developer for System z (RDz) and understanding requirements, emerging technologies, market trends and translating them into a technical strategy

April 28, 2015