What if Enterprise IT Built Race Cars?
What if Enterprise IT Built Race Cars?
Join the DZone community and get the full member experience.Join For Free
Don’t let inefficiencies in software testing lead to delayed deployments and poor quality products. Get the 90 Days to Better QA Guide by Rainforest QA for best practices to avoid these common pitfalls.
(Original article: https://www.scriptrock.com/blog/it-systems-cars-environment-configuration/)
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.
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.
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.
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.
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.
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.
Opinions expressed by DZone contributors are their own.