How it would turn out if Enterprise IT departments were to make race cars (with no DevOps)

1. What if Enterprise IT Built Race Cars?
Designing and building a race car using the typical lifecycle process used within an
Enterprise IT department. Sounds like a good idea, no? No. It’s a terrible idea, but it’s
fun to paint a picture of how it may work out to illustrate what goes wrong today in so
many Enterprises. For this exercise I’m going to assume that there are four main groups.
The design team (analogous to IT Architects), the manufacturing team (development),
the safety team (security) and the mechanics (operations). Here is how things may turn
out.
1. Design
A request has come in for a new race car and, after approval, goes straight to the design
team. The design team gets to work on a design for the greatest race car that the
company has ever produced. They work diligently, applying industry best practices and
current design philosophies. Whilst most, if not all, worked in manufacturing or safety
and even as mechanics, for the most part, they eschew more pragmatic concerns in
the favor of ensuring that their design is a vision of perfection. They review amongst
themselves and package the design for manufacturing in what they feel is the most

2. appropriate format, Word and Visio. Their job done, the design team moves on to the
next project the second that this design leaves their outbox.
2. Manufacturing
The manufacturing team, barely functioning after shipping the last car a couple of nights
prior comes in to work to find the pristine new design in their email. The cursing begins
before anyone has even opened the file. Things only get worse once it’s opened.
“Fantasy”, “optimistic”, “detached from reality” are some of the descriptions being kicked
around. “Crap” is the most common. Undeterred they begin digesting it, tearing it down
and putting it back together so they can actually get things done in the ludicrously short
timeframe that they’ve been lumped with.
Functional concerns and high level performance benchmarks are their focus. The main
characteristics of the car that they know management will be focused on: the car’s top
speed, its acceleration and the headline grabbers. Other elements get less attention.
Safety and maintainability are two of the critical ones as they aren’t as visible at the
completion of the manufacturing process. Remember, we’re running this like an IT
project.
3. Safety
OK. The car is built. It doesn’t look much like the one originally designed but
manufacturing hit their deadline. With the car poised to be used in anger though the
safety team finally gets a chance to give their input. The result isn’t pretty. The list of
safety issues is long and the budget and time constraints mean that mitigation, rather
than resolution, is the order of the day. Whilst a car can’t be released until all major
safety issues are resolved, the word gets around that some issues were downgraded
with questionable justification.
4. Mechanics
OK,by this stage of the development, the car is somewhat of a joke. Everyone is
laughing. Well, besides the mechanics and drivers of course. The car is turned over to
them and the rosy picture that’s been painted publicly soon fades. It handles like a dog.
It breaks down constantly. The drivers nickname it the flying coffin. As scandalous at it

3. all seems though, it’s really par for the course. Management has already declared
success and moved on. No one who counts will notice unless someone really dies. The
mechanics have a list of recommendations they’d love implemented but they are told to
shelve it and make do with workarounds.
Conclusion
OK, as gross a simplification as the above was the lessons remain. Collaboration
between teams within Enterprise IT is still a major problem. Agile is making
progress but, its success is usually restricted to functional requirements. The attention
that the DevOps movement has garnered means that improvements are being made in
relations between developers and operations staff. Does this extend to improved
collaboration with other areas such as architecture and security? Not so much.
You can’t always get teams to play nicely together. You can get them to document their
requirements though. One element of IT that spans all these areas is configuration.
When non-functional requirements such as security and performance can be captured in
the form of configurations, you have something to work with. When these requirements
are made executable, they become portable and enforceable so you can ensure a
development process that can be constantly validated against other team’s
requirements. Not one that is hit by them retrospectively when, in many cases, it is too
late to make changes.