Signs You Need Better Middleware

• You are doing a great deal of custom sockets, TLI, CPI-C, IPX or NetBIOS coding. These protocol interfaces are very low level, so a fair amount of custom programming is required to make them useful to a particular application. This is accompanied by difficult debugging, both during development and after systems are deployed. Also, how will you monitor performance and/or manage and administer the deployed applications? Sounds like more code than you bargained for, I bet.
• You are coding elaborate error handling and recovery, failover, load balancing, resource location, security or distributed transaction algorithms. This really follows from the previous point. Getting two processes to communicate is only the beginning. In a production environment, there many requirements layered on top of this. Are you ready to do all this development in house? Would your job be in jeopardy if executives understood that you are coordinating multiple, distributed transactions in your own code when there is a mature market of products (including CICS) that can do this for you?
• Your programs communicate by reading and writing a large number of small (or empty!) files that you move across machines with, say, FTP. Is this an efficient use of your file systems and network bandwidth? And, continuing the "services" theme, how do you do administration, performance monitoring, status checking, failover, etc.?
• Your database tables are full of "status flags" and "last updated" columns to pass information about events between programs. Is that an RDBMS or a workflow engine? Is this an efficient use of an RDBMS? Also, when your database schema changes with every program release, you've doubled your configuration management problems.
• You have multiple daemons running on every platform. This is usually related to the previous two points. When you write to files or a database to indicate events, you have to have something checking for changes. Sometimes this is done daily, which isn't much of a burden. But what about those events you want to check every minute?
• Your WAN has much lower bandwidth or greater latency than your LAN. The network implementations of most (all?) client/server RDBMS engines are not particularly streamlined or efficient. After all, they have to be able to serve a wide range of clients, from programs you've written with hard-coded SELECT statements or remote procedure calls, to ad hoc query tools. The latter needs metadata, but the former doesn't. Plus, your network administrator doesn't want huge result sets clogging the WAN, nor do your users want to wait a variable amount of time for a list box to populate.
• You support disconnected users. It's hard to avoid middleware for these folks.
• You use e-mail to communicate program-to-program. Yes, SMTP is a reasonably robust transport protocol. But while e-mail is great for person-to-person and program-to-person, it is a dubious replacement for message-oriented middleware. The APIs are weak to non-existent, and you probably will lack performance monitoring, message prioritization and automatically generated progress messages.