ALM, ADLM, EAP, SDLC & DevOps: Understanding Software Development Part 2

This blog post is part of blog post series covering common vernacular associated with software development, to read part one click the link below.

In the last blog post we covered ADLM and SDLC, their definitions, origins, their taxonomy and how they are connected. In this blog post we will cover ALM, DevOps and EAP(EAPT).

EAP (EAPT)

Let’s start off with concept of EAP first; Enterprise Agile Planning or Enterprise Agile Planning Tools (EAPT) is a market term coined by Gartner in recent years. It expands the concept of ADLM from using Agile at team/project level to implementing Agile philosophy at scale, in order to achieve enterprise class Agile development with the goal to deliver greater value across the enterprise and not just the team level.

A Team-centric approach to Agile promised the world when it came to management of software development and for the most part it did deliver. However, as the number of Agile teams grew within an organization it presented its own set of challenges. This is where EAP comes in, it aides in managing the development lifecycle when methodologies such as SAFe, LeSS, Disciplined Agile, etc. are implemented to manage enterprise scale Agile software development, using key capabilities such as: Project Portfolio Management, Service Desk Integration, (Enterprise class) Agile Planning, Agile Backlog Management, Release Management etc.

So where do we stand? And how does EAP fit into our overall context? Essentially EAP(EAPT) is to ADLM as ADLM is to SDLC. Now that’s a mouthful of acronyms. What do we mean by this? Simply put, EAP is the management of the development lifecycle, when Agile at scale methodologies such as SAFe or LeSS or Disciplined Agile are implemented within an organization.

Armed with this information let’s take a look at the taxonomy EAP and how it fits together in the overall grand scheme of things.

Looking at the overall taxonomy it is clear that EAP extends ALDM, while progressively focusing on Agile at scale methodologies. It does this through the inclusion of broad range Agile capabilities, and a defined focus on Agile Project Portfolio Management. Although EAP also includes Release Management and Service Desk Integration as critical capabilities, it falls short in fully integrating IT Operations merging the gap between development and operations. This is where DevOps comes in. The real questions are why do we need DevOps now? And what is it?

DevOps

Whereas SDLC, ADLM and EAP are mostly concerned with managing the process of developing software, DevOps aims to bridge the gap between software creation, its deployment and its use. Typically, activities such as continuous integration and deployment (CI/CD), and release management are generally considered to be a part of “DevOps”. Ultimately the idea behind DevOps is all about delivering value, like our previous concepts. However, the key difference between DevOps and our previous concepts is that it does this by putting the value of the development effort in the hands of those who can make best use of it, rather than inherently optimizing the developmental process. In that sense DevOps is agnostic to the developmental methodology being used.

Looking at the overall taxonomy, the lines between SDLC, ADLM and EAP vs DevOps blur a little in the middle of the process when talking about activities such as building, testing and releasing of software. However, concepts such as SDLC, ADLM and EAP generally apply to the preliminary parts of the lifecycle such as requirements gathering or creation of user stories in the case of Agile software development, the design/architecture of the application, and its overall development. Whereas when referring to DevOps, one tends to refer to later stage activities in the lifecycle such as deployment of software to production or product, its monitoring and operations.

The logical argument of this view is that the “Dev” in DevOps is all about development and writing of code, referring to the earlier parts of the lifecycle. However, when we think about DevOps and where it adds value and where it plays a greater role, it’s at the later stages of the lifecycle. As such for simplicity sake its best to think of DevOps as referring to later stage activities in the lifecycle.

ALM

Coming back to where we started our journey, we’ve covered SDLC, ADLM, EAP and DevOps, but what about ALM? Where does ALM fit in within this overall schema? What does ALM mean in modern software development? And why is it important?

Think of ALM as the overarching narrative that encompasses and includes the others. ALM is everything from birth or inception of an application to its end of life. As such, SDLC, ADLM, EAP and DevOps are all a part of, and subset of ALM, where SDLC, ADLM and EAP focus on managing the developmental side, DevOps focuses on managing the latter half of the lifecycle release, monitoring and maintenance. It is important to note although SDLC, ADLM, EAP and DevOps are subsets of ALM they don’t necessarily overlap or are subsets of one another. Activities such as portfolio management and the service desk integration are part of ALM but not automatically a part of the SDLC, ADLM or DevOps.

ALM also tends to focus on cross-functional collaboration, lifecycle traceability & compliance, advance asset reuse & variant management, application hazard & risk management, and application security management more so than others. The concept of ALM is even broader when it comes to cyber-physical systems, since they tend to deeply integrate physical and software components. ALM in this scenario supports not only the typical software specific activities but also supports integrations into PLM, MBSE, advance hardware software integration, architecture design and development, etc. to synchronize the software development processes with the hardware development ones.

At the end of the day, like the rest of the lifecycle management methodologies ALM, is all about adding value. However, unlike the rest, ALM doesn’t only focus on adding value to either developmental effort or operational effort. It takes a more holistic approach to an application’s lifecycle (i.e. from its inception to its end of life) and as such it adds value to the entirety of the lifecycle. ALM also aims to add value through cross functional collaboration, lifecycle traceability, advance reuse, compliance, etc. This is increasingly important in today’s fast paced software lifecycle, where software products need to be released more frequently, with greater complexity, increased variability and with better quality.

Returning to the start, now that we know “What is what?” in this space, the pertinent question is why is it important? Typically, vendors in this market use a select few combinations of terms such as ALM or DevOps or EAP, etc. in reference to an individual subset of processes or at times even the entire lifecycle, even though they aren’t direct replacements for one another. Hence, it is vital to know exactly what is being covered when these terminologies are being used. We here at Siemens and Polarion, focus on the entirety of lifecycle, we take a broader perspective for software development aim to add value to the entirety of the lifecycle, including not only the traditional activities associated with software development but expanding on them to include activities that are needed for the development of cyber-physical systems. In that sense Polarion has a holistic view of software development within a unified application lifecycle management platform.

Interested in more thought leadership topics about software development? Check out our white papers!