Bookmark :              

Every day I receive invitations to attend ALM webinars and download ALM white papers. I also see articles every week in publications of all kinds addressing ALM issues. The one place I don’t see much on ALM is on Lotus Notes-related publications or blogs.

ALM should:

• Help manage application complexity. Are Notes applications too simple for ALM to provide an advantage?
• Support the development process as a managed business process. Are Notes applications developed without a real or at least documented process?
• Provide a central management and governance framework. Is this frightening to Notes developers and admins?
• Provide transparency into the “black box” of the software delivery process. Would Notes developers rather keep that to themselves?
• Change the software delivery process from an unpredictable art form to a repeatable business process. Do Notes developers prefer art over science?

So why don’t I read more about ALM in a Notes world? I know there are lots of challenges implementing ALM (I hope to write a bit on that later), but I just don’t see it as a topic in our world.

Maybe it would help if we called ALM something else. Some of my thoughts include:
      Alienate Lotus Migrators
      Achieve Lotus Magnificence
      Applications in Lotus Matter
      Aim for Lotus Mastery

Posted by Scott Johnsen At 09:45:43 AM Location Beverly, MA | Permalink | Comments (5) | TrackBacks (0)

Bookmark :              

Its a quiet time here at UKLUG right now, most delegates are in one of the 2 sessions currently being held and that gives us sponsors a chance to see each others products, update notes on customer & prospect conversations, test technical queries or practice juggling.

I've only managed to attend 3 sessions so far due to commitments on the stand but to briefly summarise: Ed Brill's keynote was excellent. I am glad that Ed came over and supported UKLUG. He mentioned a commitment to release 8.5.1 & 8.5.2 next year, plus Notes 9 (or whatever its called) in 2010 - The future is bright in Notes Domino land.

Gurupalooza, facilitated by Bob Balaban, which was enlightening as the beer had come out by then, with one peach dropped in that can't be blogged about. Many questions were in Ed's direction as expected, but everyone else pitched in with juicy gems of their own.

(read more)

Posted by Grant Norman At 10:08:25 AM Location London, UK | Permalink | Comments (4) | TrackBacks (0)

Bookmark :              

On Ben Poole's recent post (Starting a New Project?) I commented that many people we speak to consider some of the things on Ben's list to be anti-RAD. They see RAD as being quick and flexible, yet too often this translates to sloppy and cutting corners in practice. This of course implies the things on Ben's list are a bad thing for Notes development, or at the very least, not suited to the way these devs work.

On first read of Ben's, it brought The Joel Test to mind even though Ben's is primarily looking at Domino. Both are sensible, sound lists of simple steps that can be undertaken by pretty much any team. Tips and suggestions like the contents on the list make you look better, make your life easier and help Domino utilise principles that apply to the majority of development platforms in use today. How can they be sacrificed to appease deadlines when they should be worshipped on the altar of the development gods?"

Which is the better guide list? Tough call. Domino development is not such a special case when it comes to the simple requirements of using source code control or simple, regular builds. If Notes pros & managers accepted this, I believe they would be able to increase the quality and robustness of their apps, delivering a more cost effective service to their organisation at the same time. After all, we all have a vested interest in making sure the Redmond monster doesn't creep in at Notes' expense.

Finally, if you are going to UKLUG this week, come over and say hello at the Teamstudio area.

Posted by Grant Norman At 09:32:30 AM Location Huntingdon, UK | Permalink | Comments (1) | TrackBacks (0)

Bookmark :              

That title was too good to pass up. So how do we go about 'subjugating', or taking control of, our Notes applications? So, I had a little fun, but here's my top ten list!

10 Reasons to Gain Control of Your Notes Applications

Without control:

1. IT can’t be aligned with the business. (This is somewhat important since the business usually pays for these projects.)
2. manual processes will continually lead to errors. (If you don’t believe me, just try typing “d space k space” 100 times in a row.)
3. you won’t be able to measure end user satisfaction. (If you can’t measure it, they probably aren’t satisfied.)
4. change requests take longer to implement. (This can result in the infamous change request to the change request.)
5. costly downtime will happen more often. (As it turns out, inexpensive downtime will happen more often too.)
6. development groups won’t be able to function as a development team. (Even development teams of one will have trouble agreeing on the version number and the source code version of the production code.)
7. regulatory audits become disruptive, time-consuming, costly and labor intensive. (I guess that’s redundant.)
8. risks become significantly greater. (And unlike gambling, that does not mean the payoff is bigger.)
9. IT will be misused, abused and confused. (Hopefully that’s not the usual case.)
10. business opportunities will be squandered. (I just wanted to say “squandered”.)

Posted by Scott Johnsen At 06:07:05 PM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

I was reading Scott’s post here and its associated thread (Notes New Threat – Salesforce.com with Google), and it got me thinking. I agree with the general view from the thread that actually there is not much of a threat from Salesforce.com and Google, largely because the costs associated with moving to this (unproven) platform would be prohibitive.

However, that is not to say that there are no threats to Domino’s long term future, and it seems to me that the biggest one is resourcing. Here in the UK at least, it is getting harder and harder to find experienced administrators and developers for Domino. I suspect that this is mostly down to new blood coming into the software industry being far more interested with what is perceived to be the cutting edge (Java, .NET, Web 2.0, etc). I say ‘perceived’ because we all know that Domino can provide a robust platform on which to build this stuff, but I think the prospect of using formula language and LotusScript strikes a lot of potential Domino professionals as a step backwards on the career development scale.

(read more)

Posted by Matthew Fyleman At 07:59:14 AM Location Huntingdon, UK | Permalink | Comments (6) | TrackBacks (0)

Bookmark :              

I was working with one of our customers, and I can tell this story because he was working on a third party application that someone else wrote. Do you know the JavaScript function navigator.appName? It is used to tell what type of browser is accessing your application. In Notes/Domino 7, this function was changed so that it now returns "IBM Lotus Notes" instead of just "Lotus Notes". So any application that tests for a Notes client needs to change to look for this new string. This person was trying to reduce the number of 'false' search results and was looking for the strings.

navigator.appName == "Lotus Notes"

and

navigator.appName <> "Lotus Notes"

Well, it turned out that this approach missed code like this:

variable = "Lotus Notes"
:
:
navigator.appName == variable

and several other instances, including one in the original code that was mis-typed as "LotusNotes" (no space) which never worked in the first place! The moral of the story is, you can be too smart for your own good. In this case, it is best to just find every occurrence of navigator.appName and look at it in context. Or, you could search for navigator.appName AND "Lotus Notes" and hope that the variable is not passed as a parameter, making it defined in a different sub or function from where it is used. But whatever you do, you need to look in every design element to make sure you find all occurrences because we can hide code in a lot of different places.

Posted by John Kingsley At 02:37:58 PM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

This afternoon I was looking at examples of other companies’ data sheets when I stumbled upon the SOA Infrastructure blog. I was surprised to see that they are also discussing governance, and how much is enough. A blog post by Dan Foody says “less governance is good governance”. I like that. It’s kind of catchy. And it doesn’t sound like a huge burden.

However, as much as I like the simplicity of this phrase, I can’t say it’s really right. In the end, I have to come back to the Teamstudio tag line, “just enough governance”. And in fairness, Dan does finish his post with the statement “as much governance as is absolutely necessary, but no more”. So clearly he gets it.

So why do I hear a lot of confusion around “just enough governance”? (This also came up a few weeks ago--see the blog post) Well I can say with 100% confidence that I’m not sure. It might be because “governance” carries with it the connotation of big, complex and expensive.

(read more)

Posted by Scott Johnsen At 08:21:20 AM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

Service Oriented Architecture has been a prominent theme in IT for a number of years. With Notes/Domino 8+ adding Composite Apps, Eclipse Contributions, Web Service consumers, and tools to integrate data from disparate sources into Domino applications ("on the glass" and otherwise), the promise of bringing the benefits of SOA to Domino applications is being realized.

Not surprisingly, SOA brings not only new opportunities, but also new challenges. One area of particular interest to me today is the complexity SOA can bring to managing applications through new dependencies on external services. IT organizations supporting applications taking advantage of SOA will need to put processes in place to handle changes to services.

We recently had an incident on this blog due to such a change: last week we discovered that comments on this blog were not being recorded.

We use an open-source, Domino-based blog who's contributors have put much effort into making it a first-class product; I won't speak to the strengths or weaknesses of the product because my focus here is on this problem of "coupling" that exists in integrating third-party services, which represents a much larger issue for SOA.

(read more)

Posted by Matt Vargish At 11:40:55 AM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

In an effort to provide solutions to Notes organizations who are attempting to gain control of their Notes infrastructures, we at Teamstudio have been investigating areas where Notes Administrators have stated that they have been experiencing the most frustration in getting the proper data to make critical environment control decisions. One of these areas is agents.

My first question is what exactly are the administrators looking for in and agent analysis? Is it enough to get an inventory of the agents that are deployed across the enterprise or do they also require an analysis of the settings on each agent or maybe the collection of data from each agents log?

(read more)

Posted by Mike Wetherbee At 05:18:54 PM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

I stumbled on this article (again) and it got me thinking about how most of us don’t really want to change, we just want change to happen to us because it is too hard to do the actual changing.

A lot of times people will come to us looking for help with issues they are having with implementing development policies for things like rolling apps out into production. They see a demo for Build Manager and think, “WOW! Perfect! Just what we need!". Almost every time they are right, Build Manager would be perfect and could solve quite a few of their problems. The trick is, development policies are more human related, than technology. Tools don’t work if the users are not committed to the practice of using them. It’s not until we go out and start helping them implement Build Manager, or CIAO! or anything else that we (and they) realize that to really get the most (or any) benefit from the tool, there needs to be some fundamental changes to the way they work. Build Manager for example really needs you to think about signer IDs, segregated environments like dev, test, and production, template strategies, etc., before it’s even possible to use it. This wasn’t what the customer was really after though. They were looking for the ‘Best Practices’ pill. Something they could just install and poof – all their problems are gone, the fact that a lot of their problems simply came down to how they operated didn’t occur to them.

Best Practices take work and discipline, tools can help ease the interruption and sometimes even allow you to do things you didn’t think was even possible before. Don’t go looking for a ‘Best Practices’ pill, ‘IT Governance’ pill, or any other type of quick fix like that, rather look for things that can help support a healthy lifestyle, or development practices.

Posted by Craig Schumann At 08:30:14 AM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)