Copyright perhapstoopink (Creative Commons)
I get calls all the time at home from “investment planners” and “retirement planners” and all sorts of other people who believe that I need to plan for the future. Well, their not wrong, but planning needs to occur in other areas of your life as well.
Taking on my mantle of IT Philosopher I’m here to talk to you about planning. Future planning for your applications.
I understand that being able to write “Developed and implemented web services” looks good on a resume, but if your application does not need a web service don’t give it one. Sorry for the emphasis, but it’s needed. Quite often I see application architectures that don’t make a lot of sense, other than the fact that it will look good on a resume.
Let’s take a look at a fictitious travel agency “Jessop Fantasy Tours” (hey, my story, my travel agency). One thing that probably makes good sense to spin off into a web service is “RetrieveTravelItinerary”. Based on the name you would assume that this web service would retrieve the Itinerary based on a key being passed in. In order to determine if it meets the criteria for a web service see if it satisfies these points:
- There is a need for this information in multiple locations in one or more applications.
OK, there was originally going to be a list of five or six points, but, for the most part, it really comes down to the above question. Even then I could spend another couple of thousand words just talking about the permutations and combinations of items that make up the little phrase “multiple locations”.
For instance, I don’t mean two different places on the same screen. I don’t mean in two different functions, but in two different application functions. (“List of Itineraries” and “Itinerary Details”). If you plan on commercializing the usage of the function then that would qualify as multiple locations. By commercializing the usage I don’t necessarily mean external to the organization. You could have a function, used strictly internally, that you need to promote, maintain and elicit usage within the organization. Let’s say that my travel agency provides clients with a list of restaurants near a location that they pick. They can do this from within the pages where they book the travel or, because I am a nice guy and I want to drive traffic to my site, I also put this on the main page. The email system also needs it because it will generate the itinerary and associated restaurants and send that information to an email address.
There are valid reasons for creating web services (same function, different places) and poor reasons for creating web services (resume padding, bored). Know which one is which and make sure that the reasons are valid.