In case you missed them, here are the best articles from The DevOps Zone from the past week, as chosen by the curator of the DevOps Zone. This week: 3 things to expect from a software architect, why slacking off is important for innovation, some thoughts on the friction DevOps, what exactly is continuous testing? and managing change in DevOps.
A software architect is a key person in a software project, which I explained in my What Does a Software Architect Do? post a few months ago. The architect is personally responsible for the technical quality of the product we're developing. No matter how good the team is, how complex the technology is, how messy the requirements are, or how chaotic the project sponsor is, we blame the architect and noone else. Of course, we also reward the architect if we succeed. Here is what I, as project manager, expect from a good architect.
There’s a strange dichotomy in place in many of our organizations. It seems that most appear openly supportive of innovation and all of the fruits that it brings, yet many are also striving to get as much productivity out of employees as possible.
If a developer is spending time with DevOps (and TechOps) trying to get stuff deployed, who's developing the Next Big Thing?
An effective Continuous Testing strategy incorporates all of these elements and forces an organization-wide cultural change to synchronize Dev, Ops and QA/Testing as part of the true DevOps philosophy.
A couple of years ago I wrote a blog post titled “The Many Layers of DevOps.” Lately I have been asked to revise this post and expand upon other areas of change.