Why does the chicken cross the road? To get to the other side. Now a little more difficult… Why do the English drive at the left side of the road? Personally I have no idea where this "left side" comes from, and, personally, I don't care. These Islanders just made an agreement once, and stuck to it, just to avoid running into each other.

Why does the software I want to buy for the company has to comply with J2EE standards, ISO standards, etc? First of all, I don't know what they mean, and second… why? If you go out eating, you don't care if they use a Siemens or a Philips microwave to nuke the food. However, you do want to keep your stomach at ease.

At companies, large and small, there will be some statements made about what your software should look like, and to which specifics it must comply. The Policies. They're annoying, they're anonymous and they're here to stay. "All information systems should have a 3-tier architecture." This is what a typical policy looks like. In case you will stumble across one, you will recognize the beast. It actually sounds like a requirement, doesn't it? No wonder, it actually is.

Policies are requirements too

Policies can be viewed as requirements made by the company itself. Following the argument of this book, the company should have stakes. I know, I argued in chapter "Intake" that only individuals have stakes, as it is a person who has fears and wishes. At the end of it all, I'm not taking that back. With company stakes it's only difficult to pinpoint exactly its original owner. Can be the board of directors, your boss or the "Policy Department" (those guys walking in toga's and stating the obvious as Nobel prize winning stuff). It also may be stakes that are inherent to operating a company, like "making a profit", so "we should earn more than we spend."

Back to the original question, why does the software I want to buy (or perhaps make) have to comply with certain policies? For the same reason it has to satisfy the stakes of the stakeholders; to make everyone a winner (including the company), so you have a happy and successful project. If the policies are the requirements, what are the stakes and can you change the policies? Now, that's worth some thinking.

Consider the situation where a toga from the Policy Department descends from his ivory tower to the mud of the software project. He has with him a paper role which content he shares with you in a loud voice: "Hear, fools, hear. Thou shall comply to these standards: J2EE, ISO and OSI. Thou shall use these techniques: UML, DPL and JBF." The crowd goes wild, sets fire to his paper role and kicks him back up into the tower. However, his glass tower is next to the quarters of Zeus, the Almighty Boss, who hears the whining of the toga and sends his thunder upon your little project. Thou shall comply.

You can ignore it, but you will get trampled upon. You can fully comply, and you have stuff that no one wants, no one with money to pay for it at least. So, you have to dive into the stakes that are behind the policies. And most of the time they are good ones, things that really benefit your project, and your company and, in the end, you.

Thou shall use The Big O

What are the stakes? I cannot be specific, there can be a lot of things. But perhaps some examples I experienced may help you on your way. "Every database should be Oracle." (or just pick a vendor you like). When buying a system, it can be simple. "Does it run Oracle? No? Sorry, we don't want it." But, normally you buy functionality and not technology. You buy a system for what it can do, and not because the bits and bytes are flipped in a certain way. For normal use, you buy a car to get you from point A to point B, and not because it has yellow spark plugs. You can ask the supplier to port its system to the desired database vendor, but you get a special version of the system (which is a nightmare in maintenance) and likely the supplier has limited knowledge about this particular database.

The stake here has to do with sharing database administrators among several systems. The company benefits from efficient use of employees. Especially concerning specialized people. Database administrators (DBAs) are a good example. Having more similar systems that these people can maintain, will make the costs of maintenance drop. Using a more mainstream database like Oracle, makes it also easier to get some outside people from the market to do the tasks when your own employees are overloaded or not available.

In this case it is not that the database should be Oracle, but that we should make efficient use of the current DBAs, and should have no problem finding outside people to handle the system. Now, that's a company stake!