How did ALM become Agile?

One of my managers and I attended separate ALM related conferences recently and it was interesting how we both came away wondering how the ALM discussion morphed into an Agile discussion.

For those new to this area, ALM is Application Lifecycle Management, while Agile refers to a development methodology based on the Agile manifesto.  Both relate to how software is made and includes workflows and tools needed to manage the process.  But to me, ALM is bigger because it includes all the processes, methodologies and dimensions of the software lifecyle, while Agile is just one methodology for developing software.

When my group thinks of ALM, we take a three-dimensional look at how we build applications and use those dimensions to determine the workflow and tooling needs to help manage the application's lifecycle.  To me, that is the crux of the difference between ALM and Agile, because different methodologies than Agile, lend to different workflows or tooling.  

The three dimensions or criteria we look at are; the development methodology, the technology used and the maturity level of the organization (see pic below).  Depending on what option in which dimension is selected, we will determine the management level and tooling needs when making software.

1. Development Methodology - Agile is just one of the development methodologies we use, which also includes Waterfall and WaterScrumFall (waterfall requirements gathering, iterative construction, and then waterfall testing).  There are others like Extreme Programming (XP), but we don't use them, so we don't list them.  Depending on what development methodology is used, will determine the workflow needs or specific info needed during the lifecycle (i.e. waterfall has requirements while Agile has user-stories).

2. Technology Stack - because we provide tools, the technology stack is important to us and we broke it out into Microsoft technologies, the Java/Web 2.0 technologies and then the legacy technologies.  These could add more sub-dimensions, but this works for us because we found tools fit these technology stacks (i.e. Microsoft TFS for the .Net developers) and we didn't need other stacks.

3. Maturity - because we are healthcare services company, we have different levels of maturity based on if our application is regulated by the FDA or used for non-patient care use or just used for internal use (i.e. our intranet or employee portal page).  Depending on the maturity level will determine the application management needs, like an extended workflow that includes electronic signature.

There may be a fourth dimension which is how the application is deployed: internal use, external use (by customers) or for sale.  Sometimes this is covered by the maturity level, so it is debatable if it needs to be included. The main reason to include it is when groups need to account for deployment and operations into the ALM and they are including monitoring and defect reporting into their workflow decisions.

I'm thinking Agile is becoming such a hot topic that it is starting to take over discussion about the other parts of ALM.  But if you look at managing the application lifecycle, you will see there is more than just how to build the software, and just talking about Agile short changes the larger ALM discussion.

How Windows Server is like the Dallas Cowboys

Without going into too much detail, a question came up about how our users access our tools.  Most of our centralized tool infrastructure is based on a web/app or app server on Windows Server 2008 R2 machines and our databases are on either Windows Server/SQL Server or AIX/Oracle configurations.  A question came up about licensing and we usually license by processor for any of the 3rd party tools because we have a variable number of users hitting our applications and it is usually in the thousands.

During the conversation, the topic of Windows Server Client Access License (CAL) came up.  I told them I didn't think my users needed them (even though we have them) because my users don't access the server, just the app through either JBoss or IIS.  Oh, but I was wrong.  According to the Microsoft license specialist (I deleted the references to our company and bolding is mine):

• If the Windows Server is a server for internal use, every user/device that accesses the server directly or indirectly needs a Windows CAL.
• If the Windows Servers are used by external users, you need External Connectors.  External users are defined as users who are not employees or onsite contractors.
• If the Windows Server is hosted by someone else, the server needs to be properly licensed by the Hoster 

So how is Windows Server like the Dallas Cowboys or New York Yankees/ Mets /Giants /Jets or any other sports franchise trying to invent ways to get more money out of their stadium?  Because according to the stipulations above, Windows Server is the equivalent of a Personal Seat License (PSL) to house your application.

A computer is useless unless it has an operating system (well not totally useless, you could use it as a door stop), so you pay to put an OS like Windows Server on your web/app or database box and then install your app or database on top of that.  But according to the stipulations above, the end-users has to pay for a CAL (or ticket) to access the application even if they don't access the web/app or database box itself.  So even though we bought a server license (PSL), we still need a CAL (ticket) to use our application because the user is indirectly accessing the OS.

So why would I buy a Personal Seat (or Server OS) that I couldn't use unless I bought a ticket (or CAL)?  Because people like Jerry Jones think of these things (I hope you don't win another game Cowboys!)