Bookreview: OpenAM

In January Packt publishing published the first book on OpenAM.
I've been reading on it the last couple of weeks, and it's now time to give it a score.

The book is quite thorough with its 292 pages, you can get a lot of good info from it; especially if you're a rookie.
Because most of the info is on the basic level, it will give you an insight on the functionality in OpenAM.
What you don't get, is tips on which functionality you should use, or which functionality that will be trickier and perhaps should be avoided.


Indira Thangasamy has clearly a lot of knowledge about OpenAM, and must have used it in many different occasions. Throughout the book he uses the commandline tools to perform the different configurations, this is very good, and is perhaps the number 1 tip from his book. It is too many that uses the console, and writes installation and configuration guides based on the console. Please pick up on Indira's use of the commandline tools. He even takes in to consideration the move from test to production in chapter 10.

 Do I miss something in the book?
I understand that the purpose of the book is to cover all the functional aspects of OpenAM, so perhaps what I miss is a new book. I would love a book covering all the small details that you always learn the hard way.

Examples of things to write about in a new book:

• Scaling of OpenAM, what do you need to do to OpenAM to get a setup that actually will scale to a large system? (moving the Berkeley database out of the same application server)
• When build custom authentication modules you should always avoid using JATO. Because you should try to make authentication modules that actually is possible to unit test.
• There is some hidden, less known, admin jsps in OpenAM that in the standard setup is available to customer. How should you avoid deploying these? This could actually be a book in its self, hardening OpenAM. Hope somebody will take their time to write this one.

Conclusion
I will recommend the book; it's a good book to have lying around. But the book is NOT the answer to ALL your OpenAM questions. So if you have an OpenAM installation you also should have a copy of OpenAM.

Enough quality - what's that?

This week we experience a big IT scandal in Norway. The central system Altinn went down because of the big load that came because of the Tax return for wage earners. Several hundred thousand users tried to check there tax return, this was too much for the system, it went down and it took several days to get it fully functional again.

Why did this happen?

• Of course there is no simple answer to that, but I would like to focus on one thing:

QUALITY

• How do you measure that a system has the correct Quality? 
• How do plan for the correct quality?

This has something to do with the complete project process. It's not possible to ensure the correct quality through testing alone or through requirment's alone. You need a focus on quality from start to finish.

The last year as a project manager/scrum master for the software development in the Norwegian national eID program has given me the possibility to learn a lot about quality.
We have spent a lot of time, resources and money on this subject and it's now not an exclusive focus on delivering functionality on time.
We strive to make the process, product and deliveries better for each iteration. We strive to deliver quality in every sprint. We strive to make sure that the product owner, architects, developers and testers has the same understanding on what's the correct quality.

I've always learn that as a project manager your responsible to deliver the correct functionality on time within the budget. But I'm not agreeing any more.
I proclaim that as a project manager you should be responsible for:

Delivering the correct quality on time within budget.

• It's better to lose out some of the functionality than to deliver a bad product.
• It's easier to add functionality later, then to improve and fix a product that lacks quality.

Experience report: GTD - Getting Things Done

This is my experience with GTD after 9 months.
I have read the book, and used the Microsoft Outlook plugin as my tool.

The results are not perfect, my life is still more or less a mess, but it is more like a organized mess.
It is difficult to live by the rules and tips that is given in the book, because all day's is'nt the same and some days just brings changes that will turn everything up side down for a while.

I have 2 major problems that I need to solve before I can manage to follow the principles of GTD.
That is:
- ALLWAYS make time for the weekly review
    - I tend to prioritze this down from time to time, and it ALWAYS hits my later. A broomed and perfect task list and inbox is important for me.

- My mobile version of the tasklist/buckets is not good enough
  - I need  a mobile solution that will give me the same categories that I have in Outlook now.


I will not give up GTD, but what I have learned at this time is:
- GTD dosn't solve my problems,
- GTD does require a weekly review of the buckets
- GTD dosn't come free but requires it's time.
- Remember to analyze your work situation, you WILL need to change your buckets/catgories from time to time.

My hope for the future is that more people read the GTD book and start using this method. It's no silver bullit, but a good practical tool.