« Where in the World is ALM? | Main| Cutting IT Costs »

What do you call a Best Practice when a better practice comes along?


Bookmark : del.icio.us  Technorati  Digg This  Add To Furl  Add To YahooMyWeb  Add To Reddit  Add To NewsVine 

Was the best practice just a mistake? How could you get better than best?

I was talking with Rocky Oliver the other day and we were discussing signing agents. In the old days, we didn't pay too much attention to who signed the agents. We developers had full access to production, with full permissions to run any agent on the server, and all the end users trusted us. We now know that some developers are not to be trusted. So the practice became to sign the agents with another ID. The problem was the Admin client gave us the choice of current user ID or the server ID. Well, that's easy. It's too hard to create a new ID for signing because you would have to switch to that ID, so let's just sign the database with the server ID.

Once again, that has turned out to be a bad idea, because you have given the agent all the permissions the server has - no data is safe anymore. So the practice became to sign the database with a special ID, like 'Lotus NotesTemplate Development' or 'Teamstudio Template Development'. The bad part of this was giving that ID permission to run unrestricted methods and operations (which means that they can perform operations that are restricted, such as accessing the file system on the server).

So the 'Best Practice' has evolved so that agents should be signed by a special ID, and that ID should not be in the group that can run unrestricted methods. Agents that need to perform restricted operations need to be justified, reviewed, and signed with an even more special ID. And that's the Best Practice. At least for today...

Comments

Gravatar Image1 - How about "Best Known Practice"? Wait, scratch that... sounds too much like Windows' "Last Known Good Configuration".

Gravatar Image2 - Maybe that's why Gartner and others started using "good practice" instead of best practice. At least this term indicates it's a good practice instead of just the best one I know of. Emoticon

Gravatar Image3 - In my view the agents should be signed by an ID belonging to a real person who is trusted to read the code and sign off its suitability for use in the production environment and can be held acountable for doing so. That might be the developer, it might be an administrator, it might be a power user, but just like signing a contract, the signer should read what they are signing, or understand that they are accountable for not having read it.
Shared ID files are evil.

Gravatar Image4 - Sounds like we need a deprecated best practices list - where you introduce the new best practice and reference the old :)

Shouldn't the agent be done with some shared id that has limited visibility and then be tied to a "sign off" or deployment process?

I will give you an example. At Lotus there is a template signing process and you have to submit your database to that process. You database will be returned and sign by Lotus Development. The developer has no rights or way to sign it using that Id, they don't have any access to it.

Gravatar Image5 - @3 I can't agree on not using shared IDs. What happens when your trusted dev or admin is off sick or on holiday, or worse? User dependence is certainly not Best/Good Practice when it comes to a controlled process and can be disastrous.

Of course, your point is about having accountability so with a shared ID there would need to be a system or process in the background to be able to see who has used the faceless ID for any given bit of code.

@2 Indeed, though Good Practice I think is almost too generic as a term. I prefer Known Best Practice but I do like being awkward. Emoticon
@1 Though I'm now filled with self-loathing.Emoticon

Gravatar Image6 - This is pretty common as things change. For example, it was considered best practice to use Delete when looping through a NotesDocumentCollection. This was changed somewhere in the Notes 6.x codestream, but plenty of sources still list it.

@4 - Not everyone is in an environment with things that separate. In my environment I'm the admin, the developer, and the server admin. I do sign databases with a separate ID after users sign off on an application running on a test server, but I can't realistically give that to anyone else and have them do it.

Gravatar Image7 - @2 - The pharma industry has this thing called GXP, meaning Good fill-in-the-blank Practice. Such as Good Laboratory Practice where you have the proper way to handle chemicals without contamination, etc. Maybe we could use Good Development Practice, except some economist has co-opted the TLA of GDP Emoticon

Gravatar Image8 - @5
"What happens when your trusted dev or admin is off sick or on holiday"

Well it doesn't get done. Unless you are advocating that it should be done by an UNtrusted dev or admin?

I am not advocating having a single trusted person to sign off everything. Just all those with authority to sign off stuff should do so under their own name.
Just imagine a form authorising captial expenditure of lots of money. Would you have one of those where the signoff procedure was to use a rubber stamp to mark it "approved" with no indictation as to who did it, you just know that the stamp is normally kept in the accounts office so someone on that team probably approved it? More likely is that people have to put their own name to it, and if there is nobody with authority to sign then the form waits until there is.

Gravatar Image9 - I think you might reach your "best/good practice" with a tool called signEZ. You can sign design elements without having a direct access to "signer's ID".

Everything is audited and you can limit access to several databases, users etc.
Emoticon

Gravatar Image10 - I like a good conversation!

@9 - While having a tool to automate a task is a good thing, I think we all agree with @8 about a trusted role to sign databases. Whether the ID used is an individuals or a separate signing ID is the question. So what happens when the individual ID used to sign the databases leaves the organization (it could happen)? Do you have to resign all your agents (I know, a tool would help)? I think the audit trail is important to show that the agents were signed with a signing ID by the trusted user.

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)