It is Time to Bring Architecture to ALM

Posted by

In my role as Chief Product Officer at Tasktop I am lucky enough to visit lots of clients and talk to them about their ALM strategy. I get to sit in rooms with very smart people talking about their current tool stack, their challenges and where they think tools are going in the future. These talks are always enjoyable and give me the opportunity to observe at first hand the growing importance that software delivery tools have in delivering real business value.

Tool strategy motivations are often led with phrases like “we want to deliver software faster”, or “the business wants us to move into mobile”. It is a fact, software delivery is a key business process, and thus the tools that support it are crucial to the business as well. Every increase in velocity, quality or reduction in cost has a major impact on the bottom line, either delivering business value faster, keeping customers happier or freeing funds up that can be spent on other important things. Ok, I hear you say, get off your soap box Dave, we have heard it all before. But, bear with me for a moment because here is something you have not heard before. Frequently I have to admit these conversations are not as structured as they should be and I feel that I am missing something. As an analyst you would never have heard me say this – but yes, I feel that I am often poorly equipped to structure these discussions to a positive and effective outcome! I feel that we need to apply the practice of software architecture to the discipline of Application Lifecycle Management (ALM).

Now I have done a bit of Architecture work, even co-authored a book on the topic, so I have had some experience in architecture development, but frankly I never associated this work with ALM. Always thinking that ALM was just a strategy discussion, never an architecture problem – I was wrong. If you apply architectural thinking to ALM I believe that the resulting view of your ALM domain will be more insightful, better structured and the resulting strategy will be robust. So, what does an ALM architecture look like? Applying some standard architectural models you need to think about :


  • What are the objectives of ALM – Without a clear understanding of the reports you want to find, or the objectives those reports help you execute on, it is very hard to make any decisions about long term architecture.
  • The information / data model – A model that describes the key entities and their relationships. For example, how is a defect associated with a requirement, or how are requirements composed in terms of flow, functionality, behavior etc.? This can also be the model where ownership is described.
  • The process model – Not as detailed as a SDLC, but in general terms describe the major phases a project or release goes through. Now, this process model should be agnostic to particular process flavors such as Scrum or Waterfall, but instead concentrate on the major steps work goes through.
The states the key entities move through – Thinking about the entities and their life history. These state transitions can be mapped to the process model, allowing some level of validation and completeness.

Now, some of you will be thinking – Wow, another opportunity to build complex UML diagrams and spend weeks doing analysis and design and I am not proposing that. Instead I would encourage ALM process owners to instead focus on asking the questions these models ask, and then documenting the findings on the whiteboard. The act of architecture is often more interesting than the actual architecture itself. Once a high level understanding of the ALM architecture is achieved it is possible to then start overlaying tools, departments and then mapping that back to the objectives. This often highlights problems with the existing tools, or their implementation and encourages particular integrations or additional data storage.