What if Enterprise IT Built Race Cars?Designing and building a race car using the typical lifecycle process used within anEnterprise IT department. Sounds like a good idea, no? No. It’s a terrible idea, but it’sfun to paint a picture of how it may work out to illustrate what goes wrong today in somany 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 turnout.1. DesignA request has come in for a new race car and, after approval, goes straight to the designteam. The design team gets to work on a design for the greatest race car that thecompany has ever produced. They work diligently, applying industry best practices andcurrent design philosophies. Whilst most, if not all, worked in manufacturing or safetyand even as mechanics, for the most part, they eschew more pragmatic concerns inthe favor of ensuring that their design is a vision of perfection. They review amongstthemselves 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 thenext project the second that this design leaves their outbox.2. ManufacturingThe manufacturing team, barely functioning after shipping the last car a couple of nightsprior comes in to work to find the pristine new design in their email. The cursing beginsbefore 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 kickedaround. “Crap” is the most common. Undeterred they begin digesting it, tearing it downand putting it back together so they can actually get things done in the ludicrously shorttimeframe that they’ve been lumped with.Functional concerns and high level performance benchmarks are their focus. The maincharacteristics of the car that they know management will be focused on: the car’s topspeed, 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 thecompletion of the manufacturing process. Remember, we’re running this like an ITproject.3. SafetyOK. The car is built. It doesn’t look much like the one originally designed butmanufacturing hit their deadline. With the car poised to be used in anger though thesafety team finally gets a chance to give their input. The result isn’t pretty. The list ofsafety issues is long and the budget and time constraints mean that mitigation, ratherthan resolution, is the order of the day. Whilst a car can’t be released until all majorsafety issues are resolved, the word gets around that some issues were downgradedwith questionable justification.4. MechanicsOK,by this stage of the development, the car is somewhat of a joke. Everyone islaughing. Well, besides the mechanics and drivers of course. The car is turned over tothem 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 declaredsuccess and moved on. No one who counts will notice unless someone really dies. Themechanics have a list of recommendations they’d love implemented but they are told toshelve it and make do with workarounds.ConclusionOK, as gross a simplification as the above was the lessons remain. Collaborationbetween teams within Enterprise IT is still a major problem. Agile is makingprogress but, its success is usually restricted to functional requirements. The attentionthat the DevOps movement has garnered means that improvements are being made inrelations between developers and operations staff. Does this extend to improvedcollaboration 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 theirrequirements though. One element of IT that spans all these areas is configuration.When non-functional requirements such as security and performance can be captured inthe form of configurations, you have something to work with. When these requirementsare made executable, they become portable and enforceable so you can ensure adevelopment process that can be constantly validated against other team’srequirements. Not one that is hit by them retrospectively when, in many cases, it is toolate to make changes.