In my previous article, Building Is Only the Beginning: Why Application Lifecycle Management Matters in Microsoft Dynamics 365, i explored the importance of having a structured approach to managing applications throughout their lifecycle.
But understanding the value of ALM and successfully implementing it are two very different things.
Organisations are increasingly building complex solutions across Dynamics 365 and Power Platform, introducing new integrations, automation and AI capabilities; yet the processes needed to manage those solutions don’t always receive the same attention as the technology itself.
And that’s where challenges can begin.
What happens when organisations haven’t established the right environments?
When changes are introduced without sufficient testing?
Or when ALM is only considered after an implementation has already gone live?
To explore these challenges, I’ve caught up with TTEC Digital's FastTrack Solution Architect Kieran Mackison-Brown to share their experience of helping organisations navigate Application Lifecycle Management within the Microsoft ecosystem.
From common implementation mistakes to governance, automation and long-term scalability, we’re exploring what businesses need to get right before they begin building.
Where do you most commonly see organisations going wrong when it comes to ALM?
Kelly : Is there a tendency to focus on delivering functionality and meeting project deadlines while overlooking the processes needed to manage change? What mistakes do you see organisation have encounterd, and what impact can they have further down the line?
Kieran :
“I think one of the biggest mistakes organisations make is focusing almost entirely on delivering functionality and meeting project deadlines, without giving enough thought to how they’re going to manage that functionality once it’s been built. There’s often a mindset of, “Let’s get the application working, and we’ll sort out the deployment process later.” The problem is that later tends to arrive when the solution is already quite complex, there are multiple developers involved, and the business is relying on it.
Some common issues I see are unmanaged solutions being moved into production, development taking place directly in shared environments, no proper source control, and deployments relying on manual steps or individual knowledge. There can also be a lack of clarity around solution ownership, dependencies and who is responsible for approving changes.
Individually, these might seem like small compromises, particularly when a project is under pressure, but over time, they create a fragile delivery model. Changes become harder to track, deployments become less predictable, and teams can struggle to understand what has changed or why something that worked in development has broken in production.
Ultimately, the cost isn't just technical. It affects business confidence, slows down future delivery and increases the risk of issues and disruption. You can end up spending more time fixing deployments and managing incidents than delivering new value.
For me, good ALM is about recognising that delivering the initial solution is only part of the job. You also need a reliable way to maintain, enhance and support it throughout its lifecycle.”
Kelly : Agreed, treating ALM as part of the investment, rather than an optional extra, is often what separates a platform that keeps delivering return from one that slowly becomes expensive to own.
What should organisations have in place before a Dynamics 365 or Power Platform project even begins?
Kelly : How important is it to establish an ALM strategy from day one? What should businesses be considering around environment strategy, solution architecture, source control, ownership and governance before development starts?
Kieran :
“Ideally, ALM, Solution, and Environment Strategy should be part of the project conversation from day one, rather than something introduced once development is underway. You don't need to design an incredibly complex enterprise delivery framework before writing the first line of code, but you do need to make some deliberate decisions early on.
The first is environment strategy.
Organisations should understand what environments they need for development, testing, user acceptance and production, who will have access to them, and how changes will move between them. That also means thinking about environment security, data management and how environments will be maintained over time.
The second is solution architecture.
You need to agree how solutions will be structured, how components and dependencies will be managed, and how you’ll separate configuration from customisation where appropriate. In Dynamics 365 and Power Platform, decisions around managed versus unmanaged solutions, environment variables, connection references and solution ownership can have a significant impact later. The golden rule here is to try and keep any related functionality in 1 solution if it’s practical. A single solution may take longer to deploy, but it will save a lot of headache compared to the number of dependency issues etc. that can happen with multiple solutions.
I'd also establish source control and a deployment approach early. Ideally, the team should have a clear way to capture changes, track versions, collaborate safely and promote tested solutions through the environments. Azure DevOps or GitHub can support a more advanced engineering approach, while Power Platform Pipelines and native Git integration can provide a more accessible starting point for governed deployments.
Finally, don't overlook ownership and governance.
Who approves releases? Who manages service accounts and connections? Who owns the platform, the applications and the ongoing support model? Those responsibilities need to be clear.
The important thing is to make ALM proportionate to the organisation. A small project doesn't need the same level of process as a large, multi-team programme, but every project benefits from having a defined and repeatable way of managing change, and ensuring that the package you are deploying is the same package you have spent 2 weeks testing!”
Kelly : For business leaders, these early decisions are really about protecting the business case. An environment strategy, a solution structure and clear ownership feel technical, but they determine how quickly the organisation can respond when priorities change, a new region comes on board or a regulation shifts.
What are the risks of introducing ALM too late in a project?
Kelly : Some organisations only recognise the need for structured lifecycle management once they encounter deployment issues or operational challenges. How difficult can it be to introduce ALM retrospectively, and what technical debt or additional costs might this create?
Kieran :
“Introducing ALM late is absolutely possible, but it can be much more difficult and expensive than putting the foundations in place at the beginning.
By that stage, the team may already have built a large solution in a shared development environment, with dependencies between components, environment-specific configuration and undocumented deployment steps. Developers may have made changes directly in the same environment, so it isn't always obvious who changed what or which version of a component should be treated as the source of truth.
When you introduce ALM retrospectively, you're not simply setting up a pipeline. You may need to restructure solutions, establish source control, identify dependencies, separate configuration, resolve naming inconsistencies and work out how to reproduce the existing application reliably in another environment.
There can also be some difficult conversations about technical debt. Decisions that helped the team move quickly at the beginning might now be preventing safe deployments or making future changes harder. Fixing those issues can take time away from planned features, and the business may need to accept a period of stabilisation before the team can move forward confidently.
The biggest risk is trying to retrofit everything while continuing to deliver at full speed, without allowing time for remediation and testing. That can introduce further disruption.
My advice would be to introduce the essential ALM practices as early as possible, even if you start with something relatively simple. If you're already well into a project, take a phased approach: understand the current state, establish a baseline, prioritise the highest-risk issues and progressively introduce source control, structured deployments and appropriate testing.
You don't have to fix everything overnight, but you do need a clear path towards a controlled and repeatable delivery process.!”
Kelly : From a commercial perspective, retrofitting ALM is a cost that rarely appears in the original budget. It often lands at the point where the business expects to accelerate. That creates a difficult message for sponsors who have already celebrated go-live. Raising this early is not about adding scope for its own sake. It is about making sure customers aren’t paying twice: once to build the solution, and again to make it safe to change.
How important is automation in establishing an effective ALM process?
Kelly : Microsoft provides capabilities such as Power Platform Pipelines and integration with Azure DevOps. Where should organisations be looking to automate their testing and deployment processes, and how do they strike the right balance between automation, control and human oversight?
Kieran :
“Automation is a really important part of effective ALM because it helps make deployments repeatable, reduces manual error and removes some of the dependency on individual people knowing exactly which steps to follow.
Microsoft provides a number of options here. Power Platform Pipelines can help teams establish a governed deployment process without having to build everything themselves. For organisations with more complex requirements, Azure DevOps or GitHub can support source control, automated solution exports and imports, validation, testing and release orchestration. For an example of a more customised/complicated ADO Pipeline, TTEC Digital’s Rob Wood has put together a repository called ALM4Dataverse, which is a stripped down version of what we use on our projects, and we try and keep this up to date and fix issues as we notice them!
I'd generally look at automating the repeatable and error-prone activities first. That includes solution packaging, dependency and solution checks, deployment between environments, configuration validation, config data deployment, and post-deployment verification. Where appropriate, I'd also introduce automated tests for critical business logic, integrations and critical user journeys, alongside static analysis and solution checker rules.
However, I don't think automation should mean removing human oversight altogether. A successful pipeline should have clear controls around approvals, security, testing and production releases. Higher-risk changes may require explicit business or technical sign-off, while lower-risk changes can often move through a more automated process.
It's also important to distinguish between automating deployment and automating quality. A pipeline can move a broken solution into production very efficiently if the right validation and testing aren't in place.
So, I'd start by standardising the deployment process, then progressively introduce automated quality gates and testing as the team's maturity increases. The aim isn't to automate everything for the sake of it. It's to make the safe path the easiest path, while retaining the right level of control for the business.”
Kelly : The value of automation is easy to frame in efficiency terms, but the bigger win for customers is confidence. When releases are predictable, the business stops treating every update as a risk event and starts asking for more improvements, more often. That shift from cautious change to continuous improvement is where organisations begin to see the full return on their Microsoft investment.
How can organisations make sure their ALM processes continue to work as their Microsoft environment grows?
Kelly : As businesses introduce more applications, integrations, development teams and AI-driven capabilities, what additional challenges can arise? How should organisations approach governance, collaboration and change management to ensure their ALM processes remain scalable rather than becoming a bottleneck?
Kieran :
“I think the key is to treat ALM as an evolving capability rather than a one-off project deliverable.
When an organisation starts with one or two Power Platform applications, a relatively straightforward process might be perfectly adequate. But as more applications, teams, integrations and environments are introduced, the complexity increases. You start seeing shared components, dependencies between solutions, competing release schedules, different development standards and potentially several teams making changes to the same business processes.
AI-driven capabilities add another dimension, too. Organisations need to consider how they manage changes to AI-enabled solutions, prompts, agents, connectors and their associated permissions, data access and governance controls. The exact lifecycle approach will depend on the technology involved, but the same principle applies: changes need to be traceable, testable and governed appropriately.
To scale successfully, I'd focus on establishing a set of common standards without making every team follow an unnecessarily rigid process. That means having agreed conventions for solutions, publisher, environments, source control, naming, security, deployment and documentation, supported by reusable pipeline templates and shared components where appropriate.
Governance is particularly important. Organisations should define who owns the platform, who is responsible for individual applications, and how decisions are made when teams have competing requirements. A centre of excellence or platform team can help establish standards, provide guidance and monitor the overall health of the environment, while still allowing delivery teams to work at an appropriate pace.
I'd also regularly review the process itself. Look at deployment failures, lead times, incidents, manual work and the time it takes to get a change into production. If the process is becoming a bottleneck, understand why rather than simply adding more approval steps.
Ultimately, scalable ALM comes from combining consistent engineering practices with clear ownership, collaboration and proportionate governance. You want enough standardisation to protect the platform, but enough flexibility for teams to keep delivering value.”
Kelly : I completely agree, most customers start with one use case, but the ambition is usually much bigger: more departments, more automation and, increasingly, AI agents working across their data and processes. Scalable ALM is what makes that ambition achievable without the platform becoming a constraint. It is also a key part of AI readiness. Organisations that can govern and trace change today are far better placed to adopt Copilot and agentic capabilities safely tomorrow.
If you could give one piece of advice to an organisation preparing to implement Dynamics 365 or Power Platform, what would it be?
Kelly : What’s the one thing you’d encourage business and technology leaders to prioritise from the outset to avoid unnecessary complexity and establish a foundation for long-term success?
Kieran :
“My one piece of advice would be to treat the ability to manage change as a core part of the solution, not as something you'll come back to once the application has been delivered.
It's very easy to get caught up in requirements, functionality, user experience and delivery deadlines, because those are the things people can see. But the decisions you make around environments, solution architecture, source control, deployment and ownership will have a huge influence on how easy that solution is to maintain and evolve over the next few years.
You don't need to build a hugely complicated ALM framework from the outset. Start with the right fundamentals: clear environments, properly structured solutions, source control where appropriate, a repeatable deployment process, and clear accountability for changes.
Most importantly, get the business and technical teams aligned on this early. ALM isn't just an IT concern. It directly affects business continuity, release confidence, the speed at which improvements can be delivered and the long-term cost of ownership.
If you establish those foundations from day one, you're giving the organisation the flexibility to grow without having to continually revisit the basics. And that's what good architecture should do: not just solve today's problem, but make tomorrow's changes easier to deliver.”
Kelly : This is really interesting. I wonder if there is a difference when ALM is positioned purely as an IT concern, whether internally it competes with features for budget (and usually loses. ?) If it is understood as the mechanism that protects business continuity and keeps future change affordable, it becomes an easier internal decision.
Closing Thoughts
There’s a tendency to measure the success of technology projects by whether they go live on time, meet initial requirements and deliver the functionality originally promised.
But perhaps we should be looking further ahead.
Can the solution adapt as the business evolves? Can teams introduce changes confidently? And are the processes in place to manage innovation without compromising stability?
ALM might not always be the most visible part of a digital transformation programme, but its influence can be felt long after the initial implementation is complete.
Because ultimately, building a successful solution is only the beginning. Managing its evolution is what helps make that success sustainable.
