Software Quality

October 12, 2017

Self-Sufficiency endangers Governance

Filed under: Uncategorized — David Allen @ 8:24 pm

I’ve spent years of my life building IT systems that promote self-sufficiency among our customers. But only now have I realized the undesirable, unintended consequence of this.

Early generation IT automated manual processes so users did not have to do things by hand. The ROI was great, as labor was slow and unreliable, and automation was fast and consistent.

Later generations of IT built upon that and offered automated solutions that were configurable within a foreseeable range, freeing users from IT for certain kinds of change. This self-sufficiency empowered the users to experiment, learn, and re-target their strategies to be more effective.  Imagine generation 1 websites: built by programmers. Imagine generation 2 websites: built by business users on a CMS (Content Management System) platform that is purpose-built to allow business users to make changes on their own without reliance on highly trained IT staff.

The gain is great – business users can experiment quickly and often to learn. That trial and error feedback loop is what enables learning.  So users can adapt more quickly and hopefully better meet the needs of their customers. The lead time between “business user recognizes need and pain point” to “resolved problem” is MUCH shorter when the business user can make the needed change themselves.

To understand the risk with this self-sufficiency, think about the days when IT was in the loop:  The independence of IT and the difficulty in doing work, increased the chance that all stakeholders were brought to the table, and proper review and approval occurred.

But once you give business users tools so powerful and easy to use that they don’t need IT expertise, then not only do you free the users from IT constraints, but you also lose the governance role that IT played.  This is not an insurmountable problem. But it must be called out clearly. And any solution that reduces dependencies on others and increases self-sufficiency needs to fully understand the actual role played by those dependencies. Only then can you devise an alternative control procedure to ensure proper approvals occur and project change control occurs.

January 26, 2017

Presentation to Minnesota IT Services on DevOps

Filed under: Uncategorized — David Allen @ 4:35 pm

On Jan 26, 2017, Tom Robbins and I lead a three-hour presentation and discussion on DevOps, for 60 employees of Minnesota IT. This session was part of a broader set of events, organized by Minnesota IT Services, to help employee’s learn valuable new skills and make connections with one another. The training will help these employees as they seek to move their agencies forward, and promote a culture of collaboration. And it is essential in helping Minnesota IT connect Minnesotan’s to the important services they need from the state.

Attendees represented several Minnesota state agencies, including Health and Human Services, Public Safety, and others. Both Tom and I presented. We took over an hour of questions from the audience, indicating a high degree of engagement with the topic and presentation. There was a tremendous interest in the DevOps concepts and practices. We found that the state employees face many of the same issues we face at Be The Match in streamlining delivery of solutions.

It was an honor to be able to speak with the employees of Minnesota IT Services. It’s fun to meet the dedicated professionals behind the many services on which we depend. Our thanks to Jim Kellison, Strategic Recruitment Director, who invited us to speak.

And thanks to our company, Be The Match, for allowing us to take time away from work to deliver the presentation and collaborate with employees of MN.IT.

The slides from our talk can be found at

DevOps Slides – Part 1 – David Allen

DevOps – Part 2 – Tom Robbins

One suggestion I received was that our talk would have been even more effective if we had included a speaker with operations experienced (Tom and I are both developers). This is a great observation, and as our own journey with DevOps evolves, I will look for the opportunity to engage one of our infrastructure partners in future talks.

The session description is below.

Session name and description

DevOps Case Study – Good, Bad and Ugly: DevOps can help IT deliver better solutions. As IT workers, whether in government or industry, we all strive to deliver solutions that meet the needs of our users and customers. Expectations of our consumers are higher than ever, while cyber security threats continue to increase. How are software developers and operations teams responding to these challenges? This session will provide an overview of modern software delivery practices, with a focus on DevOps. We will conclude with a case study of how we are doing this at Be The Match – the good, the bad, and the ugly. There will be time for Questions and Answers at the end of the session so please bring your toughest questions!

December 10, 2016

Who cares about DevOps practices?

Filed under: Uncategorized — David Allen @ 12:33 pm

I’m preparing for a talk in January on the benefits of DevOps. In preparing for a talk, I always start with the prime directive for presentations: “Know your audience.”  In this case, my target audience is a diverse group of IT professionals.  So I was wondering whether DevOps practices would be relevant to all of them. I asked myself the question “Who is directly affected by DevOps practices?”

Who is affected by DevOps? It depends on what your role is. DevOps is about improving the delivery of software and streamlining subsequent operations. The DevOps Handbook provides a tremendous overview of DevOps ideas and real-world case studies of companies implementing DevOps practices.

One of the underlying principles of DevOps is the lean concept of favoring global optimization over local optimization. In other words, we want to choose solutions whose total cost of ownership and total benefit are optimum over the entire life-cycle of the solution rather than just favoring one part of the life-cycle. For example you could build a software solution cheaply, but it might be very expensive to maintain. Or you might favor a SaaS solution because you can get started quickly, but it may be dramatically more expensive than a custom-built solution over its lifetime. Those are just two examples that illustrate how you can make a bad decision if you focus on only one aspect of the solutions costs or benefits in making a decision. You have to look at the big picture.  Those lean concepts of global optimization trace their roots to the theory of constraints, authoried by Dr. Eliyahu Goldratt, and other systems thinking approaches (see http://watersfoundation.org). You can research those topics if you want more depth.  For a more tactical answer, here is my list of people who are directly affected by DevOps.

Those who most benefit from studying DevOps practices are those who are responsible for designing, building, and delivering custom software.  These are people with titles like programmer, web developer, business analyst, QA tester, configuration management engineer, Scrum Master, project manager, and more.

For those who work with packaged solutions or SaaS solutions, if those packages or services routinely require customization and deployment of changes, then DevOps practices are also valuable. In fact, some SaaS solution providers like Salesforce.com have project management and deployment tooling built into their platform to support agile project management and automated delivery in the manner we aspire to with DevOps practices.

Even people who are responsible for delivering solutions like client workstations may find some benefit in a study of DevOps practices. Harkening back to our earlier philosophical remarks about global optimization, our ambition is more than simply finding solutions that are cheap to purchase. We want solutions that are cheap to purchase and install and operate over their entire life-cycle. For those who support client workstations like desktop or laptop computers, they are responsible for far more than simply buying the cheapest piece of equipment . The operational side of the workstation involves processes like patching the operating system, monitoring and protecting the system from malware, and deploying approved software. Again, one of the lessons of the DevOps movement is that we have done ourselves a disservice by working in silos and trying to optimize our individual areas. By failing to look at the big picture, and failing to consider the total cost and benefits of ownership over the lifecycle of the solution, we may not be providing the best solutions for our customers.

To reinforce this point, there has recently emerged an entire class of software development tools intended to help accelerate the development and delivery of software. These are called low-code platforms, and examples include Mendix and Outsystems among others. Their development platforms wrap a number of development and delivery capabilities into the solution and they aspire to the DevOps practices in order to streamline not just the creation of software but its ultimate delivery into subsequent environments and the testing and approval necessary to ensure that it gets into production safely and quickly.

So anyone who delivers software at any point in the life-cycle of a solution, where it is a software-only solution, or a solution with a software component, should understand at least the basics of modern DevOps theories.

 

April 18, 2016

The Pace of Change – How we Cope

Filed under: Uncategorized — David Allen @ 3:53 pm

New technologies arise so quickly that it is hard to achieve mastery in one before it is made obsolete.

So Knockout, Backbone, Angular, Aurelia?

And Azure released several new services into Preview in this month, while several that had been in preview were moved to General Availability. I can barely keep up with reading about the new services, let alone conduct experiments with the new features.

It has never been more true that if you are hiring purely to find someone who matches your checklist of technologies in use, you are missing something. As an experienced hiring manager, I suggest that candidates for advanced positions need experience in the core technology, and some version of front end/back end or whatever.

But you want people who are willing and able to learn new things. Their history is merely an indication of their aptitude and attitude.

Developers naturally get attached to technologies they’ve invested in. There is no good rule for when to stay with something and when to move on.

This is a fun field for someone who loves learning and relishes change. But it can be exhausting. And at some point, we must adopt a strategy to survive or we will all become shepherds and beekeepers.

 

 

 

March 27, 2016

Transient Fault Handling is easy with Polly

Filed under: Uncategorized — David Allen @ 1:07 pm

If you deal with real-world systems, and you value availability, you will want a strategy for handling transient faults. As we move to a greater reliance on services and microservices, we have a greater responsibility to consider such strategies to maintain adequate availability of our solutions.

There are several frameworks out there to help with this in .Net. But the one I like best is Polly.

https://github.com/App-vNext/Polly

Scott Hansleman did a great post on it.

I like it because the syntax is very clean and intentional.

You can choose another framework, or roll your own. But you can’t ignore this without leaving your users vulnerable to outages. If the outages are limited in time and occasional, why not just RETRY?

 

 

 

March 23, 2016

New Service Fabric Case Study

Filed under: Azure, Uncategorized — Tags: — David Allen @ 7:22 am

The Azure Service Fabric Team Blog has a new case study of a customer using Service Fabric: https://blogs.msdn.microsoft.com/azureservicefabric/2016/03/15/service-fabric-customer-profile-talktalk-tv/. It provides great detail on the application architecture and the advantages of Service Fabric that are leveraged, but it speaks less about the organizational transformation that was involved. (more…)

Older Posts »

Blog at WordPress.com.