Why standards is important
Posted July 10, 2007on:
It’s been a long time since I want to write about this because I’ve seen too many people are ignorant with standards. The standards that I’m talking about here is the JCP components standards.
Some people I know give me this kind of feedback everytime I stand out saying that adhering to standards is important:
Why should I care about standards? My apps are working fine and my client is happy
Here are my reasons from my perspective as a developer on why you should care about standards:
- Your client do care about standards
- Non-standards will usually lock your client in
- Not all opensource components are long-lived and able to give you support
- This component will most likely not supported across the industry
- Your client don’t like this spesific vendor
If you are in this kind of situation and unless you have a solid reason not to use standards then you have no other choice other than to follow your client’s request. Recently I’m involved in a project where the client asked us to use EJB2 eventhough they might have noticed that there is far more better solution that are available nowadays other than EJB2. But because it is a standards, they stick to it.
When and why would this kind of situation occur? Because your client want to handle the application/code maintenance after the project is finished or they want to outsource the project’s maintenance to another vendor.
What kind of client/product owner that is like this? Client’s that invested large amount of money for a stable technology environment to make a longterm investment on the project such as banking, telco, oil company, airlines company simply because this apps is a mission critical type apps.
If your client don’t care about standards, then congratulation, but you’re still faced with another problem.
Ok let’s say that your client’s do not care about whether or not you use standards. So you will start building apps that uses non-standards component, it works fine and your client is happy. But what if your client/not-going-to-be-your-client-anymore chooses that they will use other vendors to maintain the apps?
It’s either the other vendor will not understand your code and this will spend their time and automatically their money too or you will get the maintenance project again
Good for you if you can win the maintenance project again but for me it’s not good because you don’t leave any room for others to join in. I know some people think that business is all about competition so if they can win the maintenance phase project again, they will bring the money back in again to their cash deposit. But if it turns out that you think that way, then you are so selfish because you just think about your self and how to make yourself rich, you don’t think about other’s that will maintain the project in the future.
Ok enough with the life’s philosophy. Another example is if your client chose to use more than one vendor to build his apps. Vendor B already adhere to standards, but you chose not to adhere with standards. Have you realized how much time it will take for you and client B to blend in just because you chose not to use standards based components?
Ok then you’ll throw me another question:
What about opensource components? That won’t lock me in to a specific vendor won’t it? Since their code is available on the web, and any other vendor could have known it wouldn’t they?
Good question. I know alot of vendors that uses only opensource components to avoid vendor lock in. But still you are faced with another problem.
That’s right. Because it is opensource, (eventhough not all of it) they don’t have any responsibility to keep the project alive longer than their life😀. Several opensource projects are still going and alive even though the original creator chose not to continue the project anymore. And that’s good if you use that component. But what if the it’s the other way around? What if you just don’t have any idea whether that project will continue forever? What if the developers of that opensource project chose to leave the project in the middle of your development phase because there’s something better to do than creating an opensource project?
Ok, then you ask me another question:
What if I choose to use a component that is created by a vendor?
That is good, but you are still faced with another problem.
Because this opensource component is not a standard, that means only one vendor that holds it. To use an opensource component that is held by a vendor still will cause vendor lock in, only that the one’s that is locked now is you.
But it is still save from another perspective, because it is opensource: so there’s more chance other people (like other vendor that I mentioned in previous point, your client’s IT department team or newly recruited employee) will know and able to learn this components. And also because it is held by a vendor which you can rely on when there’s something bad happens (although we don’t expect it) or when you need their support to patch certain bugs that creeps in their component.
But there is still another problem and if you can manage to co-operate with this last problem, then you are really save.
Then you would give me another question:
Why would my client don’t like a specific vendor?
There are many reasons, even subjective reasons like your client don’t like the owner because out there he is known as a snob. Or there’s been rumour that this vendor’s service is not reliable or good enough for your client’s satisfaction.
And then you would ask me another question:
So if I choose a vendor that builds standards based component, will this be able to give choice for my client?
Of course. Let’s say if you build your apps, using standards based components. At development phase you use an opensource appserver. But when you go for presentation to your client, your client seems not to like/trust this opensource appserver. No problem, you just switch to a proprietary appserver that your client wants. But after several years, your client changed their mind again because simply subscribing to this vendor’s support is far too expensive so they decide to have their own IT team to maintain the appserver and the apps. No problem, you just switch back to your client’s appserver of choice. But in the middle of somewhere this opensource appserver is abandoned. No problem, now that your client’s IT department team is gaining stronger knowledge, they just switch back to another appserver.
Well, you get the idea.
Overall, the point of using standards is to prevent vendor lock in. By being able to prevent vendor lock in as I have pointed out gives several benefits:
- Give a wide array of choices for your clients, so they won’t be locked in either with you or the vendor that creates the component that you use.
- Give spaces for other competitor/vendor to join in, either because they will maintain the project you have developed or if it turns out that you will be doing the project with other vendor.
- Ease other’s that will maintain the project you have developed, either your client’s IT department team or other vendor
- Standards based components will help you minimize the risk of investing in R&D
So whether you are an ISV, or a product owner, or a freelance progammer I hope my thoughts can give you another perspective why choosing a standards based component is important for yourself and for others.