If you’ve raised children, particularly if you’re old enough to have gotten any kids from cradle-to-college, you may have felt a sense of dij` vu as you’ve worked with distributed application systems. Distributed applications are nothing like stand-alone apps.
They have behaviors all their own, and can be more frustrating than an obstinate child at times.
The comparison is more than just a vague metaphor. There are serious parallels between distributed apps and growing children that should inspire thoughtful planning on the part of even the most seasoned project manager. See if these characteristics don’t ring true …
Every one is unique. A distributed application often begins its existence as an amalgamation of components from different sources, which may have originally had different purposes. There is an inevitable supporting infrastructure that has to exist to accommodate a distributed app, and the components in that infrastructure are often recycled.
And if that isn’t enough to put a unique stamp on the new app, it will certainly exist in an unique environment: no two companies deploying distributed apps have the same internal needs or the same patterns of interactions with partner companies. That unique environment will leave its mark on the app itself, which will constantly change and grow in order to interact productively with that environment.
The biggest consequence of this uniqueness is that no matter how much documentation or support there may be for individual components of your distributed app, there is no complete, comprehensive book of answers for a home-grown distributed app.
Like parenting, you learn about to look after this new creation by the seat-of-your-pants as you go. But even that will only happen if you resolve to invest seriously in learning its strengths, weaknesses and idiosyncrasies, and surrender to the discipline of giving it regular attention.
They will have needs you haven’t anticipated. It’s the nature of distributed apps to be more dynamic than other conventional ones. They have many more connections to their local environment and to the outside world than conventional database apps and simple client-server apps.
It is inevitable that forces both internal and external will require a much higher degree of accommodation from a distributed system. It’s just as inevitable that the distributed system’s greater number of interfaces, broad scope and offering of increased data access potential will inspire change among its users within and without, and in those systems with which it interacts.
The result? It is difficult if not impossible to plan accurately for the growth and expansion of such a system.
You know that it will grow and expand, but you’ll find yourself surprised at when and where this growth occurs, and what needs you’ll have to accommodate. You can only vaguely predict the shifts in patterns of data usage within your organization when a distributed system is deployed. And it’s even less likely you’ll be able to accurately guess what opportunities will be exploited by your partner companies when you offer a more dynamic application to external users.
The bottom line is be prepared to move quickly to support the app and ensure healthy and steady support.
They will require increasing levels of discipline as they grow. Distributed apps — especially if they’re deployed on the web — can grow almost without limit, since the paths by which they tap supporting resources can be many.
As more users avail themselves of such an application and as its modes of presentation increase, it can become unwieldy and even burdensome to users. The only cure for this is to handle the expansion of supporting resources carefully; with a thoughtful hand rather than an attitude of convenience. Not all growth is healthy. Carefully channel new resources into an expanding app.
They will sometimes display behaviors you don’t expect. Stretching an application across servers, through various network connections and out multiple interfaces is bound to lead to glitches, either in the app itself or in the supporting infrastructure.
The very nature of distributed apps is such that some of a distributed app’s resources are re-channeled into its deployment; it must expend cycles communicating with itself, so to speak. Because of this, a distributed app may sometimes exhibit inexplicable behaviors, either internally or in interaction with users.
Just be aware of it, and don’t be surprised.
They will sometimes go in directions of their own. It’s not always easy to know the future of a distributed app. Spreading an app across multiple servers and giving it more than one face can open up new possibilities to users, and make an app far more powerful, with a broader ranger of features, than it ever could have had as a local app.
When increased server resources, unanticipated user demand, and opportunities for enhanced functionality come along, they may enable possibilities you never imagined. Don’t have a fixed idea about where a distributed app goes from here. Remain open to these new possibilities and you’ll wind up applauded by your user community, for providing ever-broadening quality resources that more or less fall into your lap.
Scott Robinson is an enterprise software and systems consultant with Quantumetrics, Inc., a consultant’s collaborative. Robinson is presently working in distributed healthcare information systems with HCHB/Allegro IT and has worked with such well-known organizations as the Dept. of Defense (DOD), Dept. of Energy (DOE), Wal-Mart, and Roche Pharmaceuticals.
As well as CIO Update, he is also a regular contributor to TechRepublic and can be reached by email at [email protected] or by phone at (812) 989-8173.