You are currently on IBM Systems Media’s archival website. Click here to view our new website.

Bookmark and Share

Recent Posts

Master Bath Meets IT Infrastructure–Fit for the Future

July 8, 2013

By David Bruce, Enterprise Systems Category Marketing Manager, IBM

I have a cracked master bath sink. What does that have to do with enterprise IT architecture you ask? When that epiphany occurred, the same question surfaced in my head. Interestingly, they have much in common. As I pondered the various solutions for my sink, it occurred to me that the process I was using had much in common with making IT infrastructure choices. They connect at the fit-for-purpose junction.

Apparently, the original homeowner’s requirements for the sink were that it should hold water, drain water and have a nice appearance. My requirements are a bit different. I expect it to do those things and tolerate water that is 140-150 °F without cracking. That never happens in IT does it? Market conditions cause a requirements change after implementation.

ANSI Z124 series standards call for vanities to handle a range of 50-150 °F but the manufacturer of my vanity states that water must be kept below the scald level (110-120 °F) to avoid cracking. So my cracked “sink” has many of the attributes of a sink but it is not fit-for-purpose as it fails to meet standards for its designated role. Had they originally chosen quartz (industrial strength, ranges from sub-freezing to several hundred °F tolerance) or a sink mounted to a countertop instead of a one-piece unit I wouldn’t be planning a master bath-remodeling project today. The failure here–if there was one–was in not thinking about versatility–fit-for-purpose and fit-for-future-purpose. Requirements change all of the time–and not just with a new owner. Failing to anticipate change just creates more work down the road than it would if handled at the beginning. Every DIYer reading this post has realized that at some time or another–usually on their way to the hardware store.

The same thing happens with our IT systems. We have a great order management application implemented; our call center personnel have all of the customer’s information and order information available to them when they are on the phone–and then the requirements change. Customers want to order products, check status, arrange shipping, return products, etc., all without talking to anyone. Great, we’ll just do a Web interface. However, they also want it on smartphones and tablets with a variety of operating systems, screen sizes, connection speeds and more. And they want it everywhere and without time restrictions and it should price check against their local store as well.

So much for the simple update.

Whether we’re trying to capture new customers through improved service or respond to a competitor, the result is the same–we need to modify the system. This takes us back to the original requirements and the original architecture choices. If we have infrastructure that can adapt to new requirements and easily expand to support the increased work, then meeting the new requirement will be straightforward. On the other hand, if versatility isn’t a feature of the existing architecture, then we will need to add on or replace. Neither is very attractive and both shift resources away from other projects.

Let’s jump back to the sink for a moment. Since I cannot update the vanity top with built in sinks to incorporate the new requirement of hot water, I have to replace it. Because I’m replacing it, it makes sense to build in some versatility and fit-for-future-purpose by switching to mounted sinks instead of a one-piece system. That change drives a new vanity top and cabinet base–one that no longer matches the tub surround. Why replace just a tub surround when you can update the tub as well? Why not modernize and future-proof a bunch of stuff?

Can you see where this goes? I just wanted hot water and to get it I am now going to get a new vanity top, sinks, cabinets, tub, tile, fixtures and floor. Wouldn’t it have been great if that first decision had included versatility–both fit-for-purpose and some level of fit-for-future-purpose? The same logic applies to our IT architecture. Does it offer support for today’s business objectives–and tomorrow’s? Was versatility built in or is everything an add-on or a replacement? What parts of your architecture most need to be fit-for-future-purpose? Are you facing issues today because of challenges like this? How are you tackling this in your business?

Posted July 8, 2013| Permalink