1 2 3 Previous Next


166 Posts
Share: |

Chef is hosting #ChefConf 2014, their third annual user conference, and BMC is proud to be a part. The three-day event will take place April 15-17 at the Hyatt Regency Embarcadero, located on the beautiful San Francisco waterfront. This year’s conference will host three days of technical training and sessions focused on Enterprise Chef. Experts from across the industry will be speaking on a variety of topics.

1. ChefConf Keynote speakers include:

Justin Arbuckle, Chief Architect at GE Capital
Jeff Einhorn, Group Manager Infrastructure Strategy & Architecture at Target
Jez Humble, Principal at ThoughtWorks
Rachel Chalmers, Principal at Ignition


BMC will be on hand with the latest for BladeLogic Server Automation and Release Process Management.


2. Manage and Control your Data Center with Integrated Server Automation:

Streamline your data center with next-gen management from BladeLogic Server Automation. Integrated configuration and compliance, plus policy-based automation add up to comprehensive capabilities across any environment - physical, cloud, and everything in between.

3. Deploy Application Changes Faster, At Lower Cost and With Fewer Errors with Release Management:

DevOps KPIs include radically increased deployment frequency, faster deployment speeds with dramatically lower failure rates and overall massively improved MTTR. And BMC lets you adopt this incrementally as you're comfortable and as you need to.

4. Come Visit Us During Exhibit Hours:

Tuesday April 15: 6-7pm

Wednesday April 16: 10am-7pm

Thursday, April 17: 10am-4:30pm


Also, be sure to join us for a great presentation.


5. Orchestration in Meatspace: Orchestration vs. Autonomy


You've gotten comfortable using Chef to build a decentralized, agile platform for configuring your infrastructure and deploying your code.  Many traditional enterprises, though, have release processes that are all about centralized management with strictly-defined rules, an imperative approach that is dependent on some central coordinator. To make things worse, many organizations have dedicated teams for security, operations, and application release that may not be hooked into Chef, want you to participate in 100+ step high-ceremony release plans, or have their own rules and policies they want you to live within.

Join DevOps Consultant to BMC Software, Niek Bartholomeus at 3:15-3:55 pm on Thursday, April 17.


Niek Bartholomeus (@niekbartho) is a DevOps and Continuous Delivery evangelist who has implemented a Continuous Delivery pipeline during his most recent mission at ReQtest, a small agile company. Before that he was a technical architect at a large financial institution where he was responsible for bringing together the dev and ops teams, on a cultural as well as a tooling level. He currently works as a DevOps consultant for BMC. He has a background as a software architect and developer and is fascinated by finding the big picture out of the smaller pieces.


Pink Speakers.png

6. Join us on Facebook and Google+

Finally, join our events on Facebook and Google+ to get involved in the conversation around #ChefConf.


What are you looking forward to learning at #ChefConf? Let us know in the comments below.

Share: |



This is an interesting angle of insight on the public/private/hybrid cloud discussions that I haven't seen much. AWS is clearly above and beyond the leading option and that market dominance -- and the duration of that dominance for years now -- brings to the Amazon offering a number of advantages we might not normally think about.


Jason raises a big one IMO: security.


Fact is, AWS may be more hardened in more ways and more times than what you're going to consider (or be able to afford) for your private cloud. So, if security is a big consideration, you may have just made the decision for yourself in the public-vs-private cloud debate.



Jason Bloomberg:  Well, there was a great article that quoted me as saying that private clouds are less secure than public clouds, when that's not precisely what I was saying.  It's more that there's no reason to believe that private clouds are inherently more secure than public clouds, and it's expensive and difficult to make them as secure as public clouds.  So it's not that it's impossible or that it's always the case, but it's more difficult than you might think.


So, if you compare an enterprise's private cloud to what Amazon is doing […], well, Amazon has very well-hardened infrastructure.  People have been attacking it for years,  so they see all of the attacks.


Well, what penetration testing can you do?  Well, you'll run your pen test and you'll try a bunch of things, but no – you're going to get nowhere near the level of penetration testing that Amazon does simply by being a leader in the marketplace for so many years.


You're going to try to hire the best security people to secure your cloud, so where are you going to find these people?  Well, the really good ones are already working at Amazon.  And they're not going to work for you; they love working at Amazon.  So it's really hard to hire the best security people.


Now you're going to have to go buy the best security gear.  So you shop for best security gear, you buy a bunch of security gear, and a couple of years later,  your infrastructure manager comes to you and says – comes to the CIO and says, we should replace all the security gear with the latest and greatest.  Well,  maybe, maybe not.  I don't know.  Can we keep it for another year?  You want to save money.  You're not going to have the economies of scale of one of the big cloud providers, so you're not going to have the same sort of cost efficiencies and get the very best equipment.



So you have a skills gap, you have a technology gap, you lack the economies of scale that you need to provide cost-competitive level of security.  So it can be done, but it's difficult and expensive.


Jason Bloomberg's Summary page is here.

Share: |

I've been tracking financial activity in the "DevOps market space" since BMC acquired StreamStep at the end of 2011 for its lightweight planning and coordination software called SmartRelease (now known as BMC Release Process Management and still an awesome product, if I say so myself


Anyway, 2011 had very little activity (basically the only one I heard about I just mentioned), 2012 had about the same and then 2013 came along and blew the doors off. Here's a table of the highlight (assuming none get announced between now and year-end). And these are public investments, so the real number is higher.


FebBig Switch$6.5M


That's over a quarter of a BILLION dollars in $ heading DevOps way. And in the case of the acquisitions, it represents the minimum spend, because a company like CA or IBM still has to invest in the on-going run and upgrade of the acquired companies...


I suspect 2014 is going to be a rip-roaring year for DevOps!

Share: |



I sometimes find myself in conversations where people are confused by the relationship between what they believe about cloud and what is real. People believe what they want to believe (or, in all too many cases, what the company paycheck they believe apparently pays them to say is real). It usually turns out that most of the people who seem to me most confused have never used cloud… yet they have strong "cloud use" opinions.  Those conversations I try to keep short.


Jason really lays it out here. A few weeks ago I listened to Adrain Cockcroft say Amazon is the only real deal and then saw the stats myself: Amazon is larger in this than all of the other vendors combined. All. And it's by a lot (some 70%+, if I recall correctly).


So this excerpt started with talking about a vendor-neutral architecture, because that's a big open source trend. But is it real? A lot of vendors and people are committed to saying yes… And now here are some really helpful insights from Jason. Once again, if you're looking for sweet, sugar-coated answers, don't ask Jason Bloomberg any questions.



Jason Bloomberg:  A cloud vendor neutral architecture.  Well, at this point, the market really hasn't figured out an answer to that question.  Cloud computing is still too new.  It's still too much of an emerging market to really have a clear understanding of what it would mean to be cloud vendor neutral, because there isn't enough understanding or enough agreement on how everybody should be providing cloud capabilities.


So we have in the cloud computing marketplace today, especially in the IaaS, infrastructure-as-a-service marketplace in particular, we have an interesting –  I guess, an interesting way that the market is developing.  And it's characterized by the fact that Amazon, with their Amazon Web services IaaS offering, essentially defined what IaaS was supposed to be and got it to work as they brought it to market, which is different from the way traditional vendors do things.


A traditional vendor will throw together some crap, integrate it at the PowerPoint level, try to sell it, and if customers buy it, then by version 3.0 or 4.0, they'll finally get it to work, hopefully.


So you sort of fill in the blanks, and eventually the product matures.  Amazon doesn't think of itself as a software vendor.  It thinks of itself as the Wal-Mart of the markets they're in, so they're the Wal-Mart of the cloud.  They're the low-priced leader.  They are rolling out these capabilities, defining what IaaS means, and continually lowering their prices as they achieve greater economies of scale, which – what does it mean to everybody else?  Well, they're all scrambling to put together something that works at least partly like Amazon, in a way that will make them at least a little bit of money, but they are struggling to achieve economies of scale and actually get their stuff to work, which, by and large, they're not.


So this is the deep, dark secret of the cloud computing marketplace.  With the exception of Amazon, virtually nobody else is getting this stuff to work.  They're getting bits and pieces to work, but they're not getting the whole thing to work, the automated, dynamic provisioning,  the seamless virtualization, the automated – the measurement,  all of the –  only Amazon –  they're miles ahead of everybody else...


Everybody else is scrambling. […  Amazon] started pretty early, because they figured out how to do this stuff.  They figured, well, there's money to be made here, and they were right.


So what we have is, is we have all these other players who are all just practicing different levels of cloud washing.  They have something that isn't really cloud or is partly cloud or is kind of cloud, and they're doing some sort of hand-waving to convince customers they really should buy it.  But there's a lot of hand-waving going on, a lot of that cloud washing going on.


So it's happening for the service providers.  It's happening for the open source world.  It's happening for the commercial vendors.  There's all different levels of cloud watching.  So you can go to an open stack – go to OpenStack,  Rackspace and those guys, well, that's only half-baked.  A lot of pieces are missing.


So […] does OpenStack compete with Amazon?  Well, kind of ... eventually, but not really, because it's only half-baked.  And if you look at what Oracle is doing, well, Oracle is basically trying to convince their customers what they're doing is cloud, but it's managed hosting.  There's no cloud.  Oracle has no cloud of any kind, but you talk to Oracle [and they'll say] "it's all cloud", but it's cloud washing.


You talk to SAP, same story.  You talk to IBM, well, IBM is piecing things together, but it's [got] a lot of stuff missing.  And the story goes on and on and on.  All of these vendors, as well as the service providers, are trying to figure out how to do something that is really cloud, and they're piecing it together, and there's a lot of pieces missing.



Jason Bloomberg's Summary page is here.

Share: |



So there's a train wreck coming. It will be another blow against Ops. It's where the cloud self-service availability for Dev/Test train arrives at the traditional IT Ops station and its historical role of provisioning and configuring. And it's IT Ops that will be most impacted: what does self-service on-demand cloud mean for the traditional command&control corporate IT structure?


What happens now that you can do formerly complex or difficult things, or things that required cooperation from the branch of IT controlling the hardware -- things now replaced with spinning up what you need in the cloud immediately.

In other words, your wait time has become radically shorter because standing a server up is automated and easy to do right now, but your pre-existing policies for the provisioning and configuring still take a long time? What do you do when your policy has become a jokingly bad speed bump because the time it requires has become the heavyweight burden in the process? When it no longer enables but almost disables agility and responsiveness?


Welcome to a new Meta-world where global change has collided head on with local policies about changes. Where self-service instantiation has become on-demand easy, but governing existence of said instantiation throws a whole bunch of previously settled notions into question. It was one thing when standing up a set of servers took 6 weeks but now that it takes 6 minutes, there's a problem with the old ruleset.


This self-service standing cloud in Dev -- often without even worrying anymore about Ops, more than making sure whatever gets spun up looks like what production requires -- is a part of the change that DevOps is bringing to making a business more agile. It should be not just a good thing but an awesome thing.


Is Ops ready for it? I don't know, but I do know the literal provision and configure dominion once held by Ops is no longer competitively realistic. Those companies that do not adapt and evolve will join the ranks of those companies that insist on retaining use of typewriters.




Jason Bloomberg:  If you look at cloud computing, we have automated providing and automated configuration and management that pushes the responsibility for operations to essentially the IT end user.  Any developer, any techie can provision instances.  That shifts the whole challenge from a technical challenge to now a governance challenge.  What are the policies and processes for understanding how the organization wants to leverage cloud computing?


We saw the same thing with SOA.  SOA governance became a key challenge. […So,] publishing all of these services, and now the services are available, they're discoverable, and now anybody can come along and compose them and consume them to build anything.  But without proper governance, it can just go off the rails.


So we have this automated approach for representing policies and enforcing policies in an automated way, and that enables us to achieve – to basically approach governance from a different approach – [a] different perspective. 


So governance – that word governance, it sort of has some baggage, because it's traditionally been something your compliance department handles and they think about making sure people follow rules and it becomes very sort of onerous and heavy-handed. 


But we're reinventing governance, because we're automating the ability to create, communicate and enforce policies, and so we have this automated aspect of governance that is by no means all policies, but there's a whole core set of policies that we can now deal with in an automated way.


So we represent policies in a metadata format.  In the SOA world, it started off being,  Web services-based, XML-formatted.  In the cloud computing world, it's increasingly JSON-based policies.  But it doesn't really matter. 


What matters is that we have a standard way of representing a policy in a machine-readable way, and that brings the governance story up a level, so – where it's not just about creating the policies, but now governance becomes a set of policies for how we deal with policies.  That's what we call meta policies, and we sort of raise the whole discussion up to this meta level, where it's not about the policies, it's about, 'what are our policies for dealing with policies?'


And that becomes a new way of looking at governance, where it's a more – essentially architected approach to governance.  And that pattern repeats itself.  It repeats itself with how we do development and it repeats itself, how we do operations.  So it becomes the whole agile architecture story is based at that meta level.



Jason Bloomberg's Summary page is here.


Share: |



It's rare that I have a free-standing excerpt that doesn't need any help or elaboration. Jason's crisp that way. I love the analogy.




Jason Bloomberg:  Yeah, when I brought up the tin woodman analogy, that was – I don't know, several years ago, 2006, 2007, somewhere in there – I was really talking about the software vendors who are struggling to bring a SOA story to their customers, because the vendors can't sell architecture.  Architecture is a set of best practices.  It's something you do; it's not something you buy.


So all these vendors wanted to sell SOA, because SOA was the hot topic back in those days, but they couldn't, because it was something you do.  So what did they sell?  Well, they sold Web services support and they sold middleware and they sold this and they sold that, but none of those were architecture.


So it's the same as the story of the Wizard of Oz.  You have these four people.  They go to the wizard.  And each one of them thinks they want something, but it's not really what they want at all.  The tin woodman thinks he wants a heart, but in reality, of course, he was the –  the most loving of the four. 


So each of the four, if you think about it, didn't need what they thought they wanted.  Dorothy was always at home.  She was dreaming.  She never left home.  The lion was the most courageous of the four.  He just didn't realize it.  Tin woodman was the most loving, and the scarecrow was the smartest. 


And so – but they were all missing,  the heart or the whatever.  And so the tin woodman, what did he get from the wizard?  Well, he got a clock, and it ticked like a heart, and that was good enough for him, because he really had all along what he was looking for.


And so the moral is that you can't get best practices from a piece of technology.  That's something you have to bring to the technology.  It's something that people have to have, because it's something you do with technology.  And this is an important part of the DevOps story.  The reason that we're talking about DevOps today is because our technology has matured to the point that we can automate much of our operational environment.


So we don't need to have people provisioning servers manually anymore.  We don't have to have people setting up networks manual anymore and reconfiguring – we don't have to – we don't have to have that.  We can automate that, so now we can move those ops people and put them in a different role in working with the developers and focusing on the life cycle.


[…] The technology is the enabler, but if you don't understand the organizational and architectural best practices, you're not going to get it.  You're not going to get the value out of DevOps.  And I actually wrote a blog post on this […] called the DevOps paradox, where all these organizations want to do DevOps, and what they're doing is they're setting up separate DevOps teams who are now separate from dev and ops.


And it sort of defeats the whole purpose, because the idea of DevOps is to sort of cut across the teams, to be less siloed, rather than more siloed.  So setting up a DevOps silo defeats the whole purpose of DevOps.  And people are scratching their head and saying, "well, why am I not getting the value that I read about in all these great podcasts about DevOps, saying all this wonderful stuff, and I'm not getting this value?" 


Because they're missing the organizational, the human side of the story.  And that becomes the most important part.


The technology is an enabler.  We couldn't do DevOps if we didn't have automated operations, but automated operations alone doesn't give us any organizational benefits, unless we get the architecture right.




Jason Bloomberg's Summary page is here.

Share: |


In our interview with Gene Kim, we noted that COOs used to really know their business. Similar to how the Captain of a nuclear submarine in the US Navy by design and career path comes up and has to know every system in the ship he commands. (That's still the case with the US Navy.)


Gene went so far as to say -- and I strongly agree with him -- any COO without an IT background in 10 years will be largely unemployable.  Jason takes it one step further… 


I've been warning for several years now: every business is in the IT business.


So what's the future for other executives getting IT?


Jason Bloomberg:  I think Gene is right on track with that.  It's not just COOs, either.  I mean, it's really any executive.


If you look at most industries today – and it's not every single industry, but if you look at most industries – let's say banking, for example.  Well, what is banking – what are their widgets on their shelf?  It's not the currency in the drawers.  It's bits on the wire. 

Money is bits on the wire. Everything they're doing is moving information and dealing with information.


And so the entire business, everything that banking involves is completely permeated by technology.  You can't subtract the technology out.  It is a technology business. 

And so you have all these bankers who think of technology as just tools they can use and are missing the bigger picture of how technology is really what their business is all about.  When customers interact with their bank, they're interacting with technology.  And they're missing that point.


So you go from one – one industry to another, and it's the same pattern.  […] We work a lot with the government, and the government – U.S. government has technology across the board.  Every single agency, what they're trying to accomplish depends upon technology

The government is increasingly seeing itself as being in the role of collecting and disseminating information for citizens, and that becomes now the primary goal of government. 


It just depends on what information you're talking about.


And the story keeps going.  So interesting to industry, it's about information and how we deal with information and how the technology becomes the supporting – information technology is the supporting capability that makes 21st century business work.




Jason Bloomberg's Summary page is here.

Share: |

JasonBloomberg.pngJason defines agility in the context of a traffic jam analogy. It's brilliant IMO. The observation that business agility is an emergent property of complex system is a huge one and the traffic jam really sums it up well. It's the best encapsulation of it I've heard of. Another reason to get his book, after you finish this excerpt.



Jason Bloomberg:  Well, when we define business agility, we define it as enabling an organization to deal efficiently with a change in the business environment and to leverage change for competitive advantage.  So it's a business concept at the organizational level, right?  How can an organization achieve it’s business goals [such as] making money, improving customer relationships, dealing with competition and changing regulatory pressures? 


So it becomes an organizational set of priorities that drive down throughout the organization, including the IT organization.


So traditionally, the IT organization hasn't been as flexible as the business really requires.  And IT now is a money sink.  It limits flexibility, now the business wants to find ways around IT, and that becomes a big source of pain within large organizations.


So what we're trying to achieve, both with the agile architecture story, as well as the DevOps story and some of these other pieces is, is how can IT rise to this challenge?  How can IT provide the business with powerful, flexible, capable tools so that the business can now achieve increasing levels of agility at that business level?


So it's tying the IT benefits to the business priorities, which has always been, you know, the challenge – you know, the business IT alignment challenge of enterprise architecture and IT broadly speaking.



[The traffic jam metaphor from the book] is really to understand the nature of the organization as a complex system or a complex adaptive system.  So if you look at the organization as a whole, so the enterprise as a whole, you want to achieve business agility.  But business agility is not in any piece of the organization.  No individual or particular system exhibits business agility.  You want the organization as a whole to exhibit business agility.


So a property of a system as a whole – it's not a property of any part of a system – is called an emergent property.  And only systems that are complex systems exhibit emerging properties.  So what we have here is we have – we're treating the organization as a system, a system made up of component systems, that are – that consist of both people, as well as technology.


And you have to architect both.  You can't just focus on the technology.  You have to take a best practice approach for architecting the human parts of the organization, as well, which is part of the mission of enterprise architecture.  It's not just about the technology.


So when I talk about the traffic jam analogy, I point out that traffic is itself a complex system.  And if you think about the behavior of traffic, you have speed-ups and slowdowns, right, you have the rubbernecking, somebody on the other side of the road slows down, has an accident, so your side slows down, but nobody wants that to happen.  That's a property of the system as a whole, not a property of any individual car or driver.


But if you look at traffic, we have this combination human technology system of systems – right, cars plus drivers – and that makes up the complex system we call traffic – but if we subtract the people, right, if you take traffic jam and subtract the people, you don't have traffic at all.  You have a parking lot.


And a parking lot isn't a complex system at all.  It has very simple behavior.  It just sits there, right?  Cars don't do anything until you add the people. They just sit there.


So if you take the organization and say, well, I'm not going to worry about the human side, I'm just going to architect a technology, you're looking at the wrong system altogether, because it's not going to exhibit emerging properties like agility.


You know, the word complex is sort of – it's sort of unfortunate, because complex systems can be very simple.  So the question really is, is it a complicated concept?  In some ways, it is.  What really makes it complicated is that there are so many moving parts.


[…] We have a SOA course, and so we talk about SOA, and that's fine, but we have a cloud course, we talk about cloud, and that's fine.  But each of those trends is just a part of a story.  All of these things fit together.


Same thing with DevOps.  You can talk about DevOps in isolation and think about, Okay, who goes on a DevOps team?  What are they doing?  And, you know, what tools do they use?  But that misses the bigger picture.  And you have to fit these things together to get an understanding of how to achieve the strategic business goals that you're looking to achieve.


And techies – you know, pick on techies.  Everybody does this, but techies in particular have that techie tunnel vision.  It's all about just that piece of technology you're working on and that's what you're focusing on and you lose sight of the bigger picture.  Of course, businesspeople, they lose sight of the technology, so they're supporting what they're doing, as well, so tunnel vision happens at all levels.


But what we're really trying to do with the book is help people understand that you can't just have that tunnel vision focusing on just your area.  And this is part of the DevOps story.  Part of the DevOps story is that developers can't just think about development.  Operations people can't just think about operations.  You have to think horizontally across the lifecycle, and that's part of raising your eyes above this tunnel vision focus and having a broader sense as to what the business is trying to accomplish and how the technology can help the business achieve it’s goals.




Jason Bloomberg's Summary page is here.

Share: |

DevOps isn't just for unicorns anymore.


We ran a 3 part webinar with our own Carrie Alston on BMC IT's use of Agile and Rally and BMC Release Process Management (the original Streamstep product designed for collaborative planning, team coordination and execution of automation tooling) last fall. Recently, the folks in the BMC IT group under the guidance of 3-time award winning CIO Mark Settle published a great brochure on the details of use of DevOps in the group.

I wanted to share the digital version of that brochure because it's great and eye-opening.


So, no, DevOps isn't just for unicorns anymore. The brochure is available attached to this post (below). Here is a image of the first page from that brochure -- get a copy for yourself, it's well worth reading.


DevOps image.png

Share: |



At the heart of DevOps, Agile and other things is the focus on making business more adaptable, more agile, more immediately productive. Really, folks, if your business isn't adaptive, it cannot last (cue the oft-quoted Deming: survival is not mandatory).


Patrick Debois, the Godfather of DevOps, once said he originally considered calling it "agile infrastructure" but, after testing the wording out in community meetings and not getting many takers, well, you know, it just doesn't sound as catchy as "DevOps". . . history has proven him correct.


Jason's recent book is about the agile architecture revolution (probably guess that from the title, huh). In addition to being in the heart of DevOps topics, Jason also brings a very refreshing quirky, confident and engaging perspective on it all.

This was particularly refreshing to me as 2013 has definitely become the year of sparkly "Now with DevOps!" buttons and banners as company after company buys technology or re-labels existing stuff to be, in the minds of their marketing folk, DevOps-y.

But remember: marketing folks wishing for something doesn't make it so. Jason's a great guy to remind us all of that truth and more.




Jason Bloomberg:  Agile Architecture is about how the changing approaches to enterprise IT enabled organizations as a whole to be more agile.  And what you need to do in the context of all of the different trans-enterprise IT today – cloud computing and agile approaches to software architecture and mobile computing and all of the other organizational trends, including DevOps, and how do you leverage all of these and put them together to achieve greater agility in your organization?


[I'd been with a start-up that had] been focused on service-oriented architecture for a number of years now.  We were very early to the SOA game, you know, with our book, "XML and Web Services Unleashed" came out back in 2001, wrote the chapter on architecture for that.


Middle of last decade, we really focused on helping vendors understand how to put SOA in their marketing, judged our focus to be the enterprise architect, enterprise practitioner, helping architects and large organizations understand SOA and how it can provide benefits to their organization.


But the challenge with SOA – you know, here it is, the mid-2010s now – is it's had a rather mixed success story.  On the one hand, a lot of organizations were able to implement SOA and achieve more flexible IT capabilities, but, on the other hand, a lot of them spent a whole lot of money on middleware and got lost in some of the organizational challenges, the governance challenges, and didn't really get the value they were looking for.


So what's happening now in the 2010s is organizations are looking to take that to the next level.  Can we learn the lessons of the 2000s?  You know, what did work with SOA, building loosely coupled services, but move beyond the heavyweight, middleware-centric, centralized Web services-based approach to more lighter-weight approach.  And that leads to the notion of agile architecture, right?  What are the best parts of SOA?  And how can we incorporate those with cloud computing and mobile technologies to provide greater agility?


Basically, the promise – how can we realize the promise of SOA, where in the 2000s we only were able to do that in part.  Now we want to take that to the next level.


[It's important to realize] SOA all along was really more of an architectural approach than a technology approach, but the big vendors basically jumped onboard and, you know, repositioned SOA as an excuse to sell middleware.  They took all this old middleware they had and slapped Web services on it, called it an ESB, and then you end up with all these different ESBs in the market.  Companies would buy those.  They wouldn't have the architecture properly worked out, and they wouldn't achieve the benefits they were looking for.  They ended up with traditional integration with Web services and no SOA to be found.  And a lot of organizations sort of got steered the wrong way by – you know, by the big vendors in the – you know, the big analyst firms who said buy the big middleware.


So the missing part are really the organizational and best practice part of the architecture.  What do we need to do in order to achieve greater agility in terms of governance, in terms of organizational change, right?  Having technology alone doesn't give you the agility.  It's having powerful tools – if you don't know how to use them or they're just dangerous, it's like giving power tools to children -- you don't want to do that, right?


So what we have today: we have increasingly powerful tools, right?  Our phones are more powerful.  Our servers are more powerful. Cloud computing gives us IT capabilities at our fingertips.  And people aren't using them properly, don't know how to use them, and, as a result, organizations are running into a whole new set of issues that are more governance and organizational and less about the technology.



Jason Bloomberg's Summary page is here.

Share: |



It's hard to predict the future. When I "got" DevOps, I knew it would be the future, whether or not the word for it, DevOps, made it. The need was too great, the issues too substantial. It was simply too obvious for anyone who has lived with modern infrastructure.


DAD is a much more designed thing than the DevOps movement, so we asked Scott what he thought might be in its future.



   My hope is that Disciplined Agile Delivery will take off.  I think there’s a lot of organizations that are really sort of struggling that understand how to do Agile within an Enterprise environment.

   I think Agile has done very well with these smaller, simpler situations but when companies start to roll that out across their organization and start trying to scale it to a more complex environment, you know some of the, the Scrum rhetoric starts to really fall apart.  And I think people have pretty much figured that out now, or are in the process of realizing that, “you know, we can really be doing better than how we are”.


    And I think, Disciplined Agile Delivery is going to be one of the better options. Of course, Disciplined Agile Delivery and Kanban and maybe one or two others.  But, I think Disciplined Agile Delivery’s going to do pretty well in the Enterprise space, which is as you know is fairly large.  So, I think there’s a pretty good, healthy future.


    We’re also doing things like trying to spin off the certificate of identification. We actually have to earn the certification. So I think that’s a healthy change for the Agile community, there’s been some very questionable certification efforts over the last few years.  There’s been some good ones, but also  some not so respectable ones.  We’ve just done a lot of damage.  But, anyway I think it’s got a healthy future.




Scott Ambler Leadership Series Summary is Here.

Share: |

Musing on whether the DevOps ideas you’ve been reading about could be the way to a happier, more productive working life — but not sure how to make the case, or how you’ll demonstrate results? People using DevOps practices rely on several key performance indicators (KPIs) to judge the success of their DevOps efforts.

Of the 4,000-odd people in 90-plus countries who responded to our 2013 State of DevOps survey, more than 63 percent “doing DevOps.” These respondents told us their most important measures of improvement are:


  1. Deployment frequency
  2. Speed of deployment
  3. Deployment success rate
  4. How quickly service can be restored after a failed deployment
  5. Culture, which actually can’t be measured. See below.

Combining survey results with what some DevOps companies have said publicly about their experiences can help you decide which KPIs to measure if you’re just starting to implement DevOps in your workplace—or thinking about starting.

1. Deployment frequency

Boosting deployment frequency has been a powerful motivator for shifts in development practices. The ability to make code changes quickly and easily is a key competitive advantage for any company that needs to deliver new features quickly to customers, and respond to their behavior.

People responding to our survey told us they were able to deploy much faster after implementing DevOps in their organizations. Teams that had been following DevOps practices the longest were shipping code up to 30 times faster — and completing deployments up to 8,000 times faster — than their lower-performing peers.

These numbers may sound exaggerated, until you hear real stories of companies that used to deploy once or twice a year, and now deploy multiple times per day. Some companies deploy changes as often as every few minutes.

One great example is AOL, which implemented a simple change that took deploy time from 6 hours to 45 minutes. (Disclosure: Because our survey was anonymous, we don’t know the actual companies where respondents work. All anecdotes come from other reporting we’ve done.)

2. Deployment speed

Frequent code deployment depends in large part on being able to move quickly from committed code to that code running successfully in the production environment.

More than 25 percent of our respondents reported that their teams had were able to accelerate time to deployment to less than a day. Just under half of these said it took less than one hour. That puts these teams in good company: PayPal has said publicly that it has improved lead time to the point that new code makes it from a developer’s desktop to production in an hour or less.

3. Failure rate

It’s great to deploy more frequently and quickly, but if changes fail just as frequently, you’ve gained nothing. Failed deployments can take services down, resulting in lost revenue and frustrated customers.

DevOps practices can make a big difference in failure rate. The survey respondents whose organizations are performing well reported 50 percent fewer failures from code changes.

Some high-performing technology teams have taken service reliability to dramatic heights. Amazon Web Services says just 0.001 percent of its deployments cause outages. During President Barack Obama’s most recent campaign, his technology team processed more than 180 terabytes of data over 18 months, and experienced just 30 minutes of downtime.

4. Time to recovery

When service does go out, the ability to recover quickly can make a huge difference to business results. It’s not surprising, then, that large web companies like Google, Etsy, Netflix and Amazon push the envelope in their efforts to improve time to recovery, regularly breaking their applications and infrastructure to discover - and provision against - anything that can go wrong.

The best-performing organizations represented in our survey were able to restore service 12 times faster than their peers. Most of our respondents - almost 75 percent - reported being able to restore service in less than an hour. A much smaller group - about 28 percent - can restore services within a few minutes.

The fifth KPI: Happier lives for sysadmins and developers

The business benefits of DevOps practices are clear. Companies that can deploy changes quickly and reliably are able to introduce new features and improvements in response to the market, and ahead of competitors. Their revenue streams are more dependable, and they can plan better for the future.

All that is great — and quantifiable — but the human benefits of DevOps practices matter just as much to the people who adopt them. More than half our survey respondents said that cultural change within their organization — more collaboration and cooperation between developers and IT operations — was one of the top benefits of changing over to DevOps practices.

The stories we hear from customers and community members confirm that human benefit: the IT ops people who no longer get the 3:00 AM call to fix a broken deployment, and the developers who now see the IT team as allies and friends, instead of obstacles.

Learn more:


A version of this post originally appeared on the Puppet Labs blog.

Share: |



Scott addresses what he views as the shortfall of DevOps -- mostly he seems concerned by what might be viewed as a lack of rigor. Having known the community for a few years now and followed it closely, what appears to be lack of rigor is, however, often a reflection of very smart geeks not needing training wheels when they go biking.


Also, DAD's primary approach is around development. We've already had some fantastic discussions with the Poppendeicks on Lean Software Development earlier and Ryan Martens, founder of Rally, on Agile methodologies.


That said, Scott smartly identifies the fuller cycle that DevOps truly represents. When I was at StreamStep, we focused really on the "DevOps gap" that occurred when Developers, having adopted Agile Methodology and Cloud and CD, etc., started dramatically increasing the cadence of app delivery for release to production to Operations, who had a much stronger incentive in keeping things stable and available than changing and updated. But DevOps is bigger than that -- its a return to a more integrated team.

DevOps is really a cycle, with feedback and monitoring and iterations inherent in a lifecycle. As Jez Humble wrote memorably in his interview in this very same series -- this is what some folks would call "a money quote":

"DevOps extends right past engineering into requirements management and back to your customers (which is also where you end up if you keep going in the other direction). It's a mistake to think of DevOps as a linear thing - you need to think of it as a cycle which starts and ends with your customers, where changes are the inventory that moves through the cycle."

Jez Humble



Scott:  What I find in the DevOps community is that there’s a lot of great discussions, but in a lot of them everybody focuses on their thing.  Some people will have some very good discussions about this – how the cultural change is the primary machine and very clearly that’s important to us and you’ve got some people who will be focused on the certain kind of tools or some people will be focused on a certain set of practices. 


  You really need to take a look at the whole picture. 


And I think this, this is what we’re trying get at with Disciplined Agile Delivery. And to be fair, Disciplined Agile Delivery really does still focus on the development side of the house, we respect the operations side; we try to do our best to make things as easy as possible.  But, I think there’s a small opportunity for somebody to really get going on the operations side. 


And maybe that’s evolving ITIL into something a little bit more flexible, there’s more work to be done here, but I think taking a look at the full picture, trying to look at the full lifecycle is critical, and don’t get distracted by some of these side discussions where they’re only looking at part of the overall DevOps picture.


DevOps [is] fairly complex and really encompassing, and I think we often don’t appreciate that.



Scott Ambler's DevOps Leadership Page is Here.

Share: |




Colocation vs outsourcing discussion is a trend in supply chain management ... and in software development. I've had discussions with folks like Gene Kim about whether or not DevOps is even possible with outsourced teams, or long distances.


I think they are. A lot of people I respect a lot are not so sure. It's one of the things I love about this community: smart people discussing things and not finding complete agreement, but enough basis to start a real discussion and not accept the first conclusion you stub your toe on.


I wanted Scott's take on it because at the heart of the idea of outsourced is not just that its outside entities but physical separation of internal teams, too. It's a big deal for today's IT.





          Scott:  [You] get people telling you what you can’t do Agile if you’re not co-located.  That is complete rubbish.  But, maybe you don’t know how to do Agile if you are not co-located but people certainly are succeeding with Agile and they’re not being co-located.  So, let’s have a coherent discussion about that.

         [...]The majority of [many] teams are geographically distributed in some ways.  This is one of those dirty little secrets that the Agile community often doesn’t want to discuss.


And one of the things I do, I run the industry level surveys to find out what people are actually doing as opposed to telling them what they’re doing.  And as a result you get very different things. Most Agile teams actually look what you – if you spread across the floor of a building, or they are all working in cubes or on different floors. Some people work from home, or might totally spread it across the globe.


Only the minority are actually co-located together.  And it is actually interesting, there’s so much discussion out there about how difficult it is to be co-located, yet the Ops that had the discussion of, well, actually most of those aren’t co-located, so what are we going to do about that?




Scott Ambler's DevOps Leadership Page is Here.

Share: |



I think DevOps is misunderstood and underestimated. There's more to the moniker "DevOps" than just "Dev" + "Ops" (that is, Cloud, CD, CI, Lean Software Development, Lean, etc.).


Fact is, Patrick Debois' rolling drumbeat for DevOps is a model for viral movements. Starting with small meet-ups all over after inventing the word and founding DevOps Days and taking it global, patiently talking, guiding, blogging, he was also nurturing a profoundly talented and smart group of independent people to add their own drumbeats. CD, Agile, TDD, CI, and other methods and practices accrued to a movement about getting to the business of strong, fast, robust app delivery.


But no Official Manifesto.

Lack of canonical definition is IMO brilliant -- I realize there's contention on this with people who need canonical Source that defines exactly how to behave  -- because it forces everyone back to the table to talk. Some cynics and a lot of media took this to mean that DevOps doesn't "mean" anything, or they use the Wikipedia definition (which is nice and loose and emergent). We have had many seminal thinkers and leaders in the field provide definitions and they all converge. If you require canon, you're out of luck. Think about it, talk about it, get involved.


So, in context, what is DAD for DevOps?


Scott:  Disciplined Agile Development is fairly new, it’s in the early stages, I guess. 


  [… Whereas DevOps has] sort of grown out of the Agile movement several years ago now, so it’s been around longer.


  I think it’s been in a way, a more obvious issue for a lot of organizations whereas becoming a little more disciplined and more mature in your Agile approach is just starting to catch on.


  Disciplined Agile Development will catch up in a few years I hope.



  So, Disciplined Agile Delivery sort of combines everything. It’s a process that we call our process decision framework.


What we mean by that is, we observed that a lot of teams are making some very important kind of decisions.  Like what practices should they follow? How does it all fit together?   When should they do what?  How much documentation should they write in? And a bunch of other important things.


As well as the important organization questions: what roles should they play?  And how are they going to interact with each other?  And how are we going to coordinate sub teams? And so on. And the challenge is, is that they often have the expertise to make these decisions well. 


And there’s a lot of organizations and a lot of teams that are really into struggling with doing Agile effectively. They often don’t understand, they don’t even know what they don’t know, which could be a really serious problem because there’s a lot of opportunities for improvement, for working together better that they just don’t get. 


So, Disciplined Agile Delivery is based on an umbrella for techniques such as Scrum, and Agile modeling, and Xtreme Programming, and all of the sub practices of those methodologies. The basis is, here’s what all fits together, and we adopt ideas from Lean.  We adopt strategies from DevOps. 


So, it’s basically a very lightweight description of here’s how it all fits together.  Here are these decisions that you’re making and here’s the trade-off.  So should you have a Agile life cycle?  Should you be having more of a Lean life cycle? These are important decisions that people often don’t understand the implications of, and one of the challenges we get – one of the mysteries is they called these religious battles.


[…] And the trade offs. And what happens is these teams are in different situations, and they’re going to work in different ways.  And this is something that’s often not discussed well enough.  The Lean community is pretty good about this.  But, certainly the Agile community, I think, struggles a bit to give coherent advice, or when to do what, and what the trade-offs are.


There’s far too much religious rhetoric out there.


Scott Ambler Leadership Series Summary is Here.

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.