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

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

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.