DIY software faults are expensive, says survey

This article started a series of thoughts in my head around why problems like these exist. The thoughts and issues started coming up like an eruption - this posting is quite long.If you work in one IT department long enough (which most of us do not) you will see the entire lifecycle of this problem. If you are more transient you probably only see part of the story, the genesis; the perfect custom coded solution - everyone loves you and things are great - or the demise; some jerk created this custom coded band-aid and now we are stuck trying to fix it.At the inception the deployment make sense for everyone, doing the work in house seems like the best choice based on your needs and gives you a competitive advantage over taking an out-of-the-box solutions.As time passes something goes wrong the people who created the custom code have moved on to another job, position, etc and you are stuck trying to fix something that no one else really knows everything about - there is no product support number to call.Custom coding is great, it gives you strong advantages over your competition and allows your organization to act according to your business logic instead of the lest common denominator of your industry an out-of-the-box solution usually gives you.Don't look at the application level first, the key is in your infrastructure. Don't custom code something that should be handled by your infrastructure. Beef up your infrastructure capabilities, so that it is able to adapt to new business needs and able to be supported by professionals (who know the product inside and out) if there is a problem. Don't go this part alone!Keep custom coding to how you USE the data, not how it is delivered. If your infrastructure is flexible and adaptive you will lose nothing and gain reliability, serviceability and the ability to deploy new initiatives in a fraction of the time of your competitors.Your infrastructure needs to support flexibility in some key areas:1) Data publishing - can you represent data from multiple sources as a single source?If you can't get the data you need in one location you will find yourself replicating data from multiple silos into a plethora of new repositories at every turn, re-assembling the data it into a view that is optimal for your new service or application. This creates unnecessary complexity.ORYou start to change the structure of your existing data silos. BAD IDEA - there is a reason these silos exist, its like messing with your DNA, there is a reason these silos evolved the way they did. It is almost like cutting off one of your arms so that you could fit through a new door.Changing the structure or existing integration points of your data silos can have repercussions that are not easily apparent. Often legacy systems are black boxes, you dont' know what is really going on inside. Do you really want to start messing around with something you don't totally understand the nature of?This is where data virtualization can help. Virtualize access to disparate data silos and recompose the data into a view that you can use for your client (data modeling).2) Data access - can you access the data by multiple industry standards?If your new piece of infrastructure is a directory, then you are stuck with LDAP. Sure most applications are LDAP compliant for say Authentication, but what about other applications that would benefit from SQL access, or web services that leverage SAML? Don't get pigeon-holed into one protocol, again its about flexibility.3) Data availability - can you get to the data when you need it?Again, custom coding doesn't usually allow for growth. Your infrastructure needs to be scalable and have features that can be added for increased performance as your needs grow. The best indicator of a useful tool is how often it is used... same thing here, if you build something useful to your organization, people will find more uses for it. The better your solution is the more demands will be made on it. You may be the hero this year, but next year if your solution can't keep up - you will be the next picture in the break room pinned to the dart board.4) Data integration - can you match disparate data objects accurately?Integration... sigh... there is a lot to be said here, the problems look simple at first look, and when its time for the IT department to implement it - gentile Dr. Jeckel turns into Mr. Hyde. Data is never as clean as you think it is... Make sure you plan ahead and your infrastructure can support your needs to examine data and integrate it accurately.If you can't aggregate, correlate and integrate data then you can't leverage existing data. Your efforts will be for naught. This is where virtualization plays a key role again. You have to be able to compare apples to apples, not apples to lawnmowers. Things have to be comparable to be able to compare them! Sounds dumb, but you would be surprised how often this is forgotten, managers think since its data in our network, we can just use it anyway we want, its not true. Computers are still dumb, they don't know TimothyPaul and TimPaul are the same person how can you expect them to recognize uid=9898A in a directory and user=TPaul in a database as the same person? If you can make this correlation between profiles I can use my user list in SunOne and extend the entries with groups in Active Directory, or even authenticate against AD as if it was a single SunOne directory for web access control applications like TAM or SiteMinder.5) Synchronization - can you propagate data across disparate data sources?Here is another painful part of data delivery, synchronization. You have to be able to rely on data when you retrieve it. If solutions are not flexible (as most custom in-house solutions) then each time a system requirement changes, everything breaks down.Make sure you have a synchronization component in your infrastructure. If you can incorporate it into your other components all the better, just make sure you can change your topology and add attributes into the system easily.This is a bit long, but this topic is huge - custom in-house solutions are the cause of large problems across organizations as it ages. Its time to look at the future, build the solution at the infrastructure level - not try to fit new applications into a rigid enterprise by custom coding around the problem. You don't have to.

read more | digg story