.:justwerks software:.

I spent waaaay too much time figuring out this one and the web is full of half-answers to this problem.

To configure a Tomcat 5.5 server realm to work with Active Directory you can crib from the following setup.

Make the following changes to the %CATALINA_HOME%/conf/server.xml file.

<Realm className="org.apache.catalina.realm.JNDIRealm" debug="0"
connectionURL="ldap://<AD SERVER ONE HOST NAME:PORT>"
alternateURL="ldap://<AD SERVER TWO HOST NAME:PORT>"
connectionName="<"DOMAIN"\"USER NAME TO BIND TO AD">" <!-- e.g. internal\serviceacct -->
connectionPassword="<YOUR PASSWORD FOR THE ABOVE ACCOUNT>"
userBase="<DN TO YOUR USERS IN AD>" <!-- e.g. OU=Users, dc=foo, dc=baz -->
userSearch="sAMAccountName={0}"
userSubtree="true"
roleBase="<DN TO YOUR GROUPS IN AD>" <!-- e.g. OU=Groups, dc=foo, dc=baz -->
roleName="CN"
roleSearch="member={0}"
roleSubtree="true"
/>


Then make the required security changes to your web.xml file for your application and you will be able to authenticate against your AD installation.

I have been leading a SEPG group for the past year or so at my day job. Our goal is to improve the software development practices and the resultant quality of our software projects using CMMI v1.2 as our model. I have been remiss in not posting more about our steps, stumbles and lessons learned. I hope to improve on this.

With that introduction done - on with the story!
I was in Pittsburgh to take an introduction course at the Software Engineering Institute at Carnegie Mellon University last week. It was a lot of fun for myself as I am quite passionate about software process, and process in general, and it's implementation at organizations big and small. We were introduced to the CMMI-DEV model.

A quick detour here for a definition of CMMI and I can discuss the pros and cons of the experience.

The course focussed on walking through the 22 process areas as well as helping us determine which pieces of the model are required to achieve a particular maturity level. We also talked about the interactions of the various process areas and how they affect each other. They also cleared up a bit of confusion I had over what the two representations of the model - Staged and Continuous - mean from an adoption perspective.
The instructors placed a lot of emphasis on the fact that this model only provides the practices that need to be implemented - not how they are implemented. In fact, a repeated statement was that implementation is organization specific and should be mapped onto business objectives - you do what makes sense for the business.
The class was comprised of a broad spectrum of organizations with insurance companies, banks and Department of Defense contracts making up the majority of the participants. Happily there was a broad level of maturity in the room (from Staged Level 1 to Level 3'ish) but sadly there was no organization in the High level category (4 or 5) - it does make sense that a high level maturity organization would not have to send students to an introductory course! There was decent participation in the group exercises and some good conversations with a diverse group.

The course itself was fairly well paced but at times I felt like we were going through the content for the sake of covering the content. The instructors seemed aware of this and moved quickly when the pace started to sag.
The class remained fairly engaged but one question that refused to be answered was that of appraisal requirements. I have to admit that even I am not totally satisfied with the answers given and I will write more on this later as I digest the message. The quick synopsis is that you cannot really compare a CMMI Level 3 company to another CMMI Level 3 company as being an "apples to apples" comparison.

Another "a-ha" moment for myself was hearing why the Staged representation of process improvement is created as it is. Essentially, the first Stage is about having project management/requirements management processes in place before starting to work on improving software development processes. The old mantra of fixing things earlier in process, when they are much cheaper, is evident here.

We had a very good presentation by Michael Phillips - Head Practitioner at the SEI regarding the worldwide adoption of CMMI. There is high participation from companies in the US but the interesting growth areas are Japan, China and India. He stated that China is an area of strong growth as the government is encouraging companies to achieve particular maturity levels.

I would recommend this course to anyone that is interested in software engineering and in how to effectively and efficiently run a company, no matter the size.
They even answered one question I had regarding adoption - the model doesn't tell you how to do something, you can implement it in any fashion, as long as you are meeting the intent of the specific practices and generic practices you can scale you process to any kind of company: innovative, legacy, or start-up.

The process is yours to create!

In the world of software engineering there is an underlying assumption that people can, and do, talk to each other. Mostly, we do.

The world of complex software requires that many individuals from many groups have fully functional N-way communication processes in place. These processes can utilize many tools, email is frequently at the top of the list, but why?