You may have thought I had something to say about the global economic malaise (which I do) but this is not the forum! Of course I am talking about creating information systems that survive in the chaos we call IT. Well, let's just say it's "managed chaos".
Why does IT tend toward chaos? My personal opinion - because it can. Software is a very volatile material, easily changed, difficult to understand and manage. Sort of like trying to shovel fog out of the driveway. In the midst of this fog we have boxes of steel and wires. Lots of wires.
If you live in this fog, here are a few tips for dealing with it.
Probably the first thing to do when you can't see anything is to feel around in the dark for solid things that don't move. Partly this is because they hurt when you run into them, partly because you can count on them being there next time. In my hazy metaphor these are business services. They still move, but not so fast that you can't find them the next time you walk in the fog. You can build interfaces around these things that last longer that way. The simpler the interface, the more durable it is. So keep things simple.
Design for uncertainty
This is a hard thing to do, which will lead to my next tip. Even though you may create very stable systems and well defined simple interfaces, others may not play by the same rules. So your system should tolerate unexpected changes. You may be talking to "Harry" one day and "Harriet" the next, but if you still speak the same language you can still communicate. If not, try adding to your vocabulary. I have seen a lot of cases where communications broke down because of very petty differences. (I'm talking about integrated systems here. Just because an interface is missing a parameter, or the format of one parameter changes, does that mean you should just throw an error and refuse to talk? How about throwing a warning and trying to get along.)
Set a little aside for a foggy day
Tolerating change can be a bit more expensive than just creating monolithic hard-wired systems. If you manage a project budget, I suggest you invest a little more in a service-oriented design because it will pay dividends in reduced cost of ownership. Those dividends can be reinvested in the future, so instead of fixing yesterday's interoperability problems you are adapting to tomorrow's business requirements. If I were developing software again, I would definitely think about spending an extra hour or two on interface design and error handling to save those all-night phone calls later.
Bees can fly because parts of them are stable and other parts move so fast you can't see them. The parts that need to move in an IT system are the business rules and processes. So these should be adaptable to fit your business needs. Some parts need to move very fast; others don't. Things that are not designed to move when they need to move tend to break. I once made a belt out of wood (and lots of hinges - a college exercise in creativity). I once wrote code to simulate a bug because another system was expecting that bug and didn't work without it. Browsers tolerate a lot of HTML errors. It's better to adapt than to wait for everybody else to change.
Identify and manage changes
You don't have to work at the Service Desk for long before you recognize the value of Change Management. Those constants you identified earlier better stay constant, or a lot of processes will break. When those things move, everybody in the fog needs to know about it. Lighthouses prevent shipwrecks. Sonar prevents shipwrecks even bettter. Configuration and Change Management can help you steer through the fog.
The postings in this blog are my own and don't necessarily represent BMC's opinion or position.