By Ajith Thampi, Ecetera ALM technician
ALM is a service that falls in the application development space. As such, it involves working with your technical teams – the developers, project managers and other engineers who all work at that critical stage where your application is being created – long before a working version is made customer facing.
With this in mind the tools I’m personally interested in are those that help manage issues commonly dominating the production environment – issues surrounding project management and development planning, for example.
But when we’re focusing on ALM it’s not just the production environment we need to be thinking about. The pre-production environment is just as critical and it needs to be managed and monitored in a particularly distinctive way because this environment is accessed and controlled by the engineering team and is often in a state of constant change. Changes resulting from issues that leak into the pre-production environment could destabilize the controlled production environment. And the implications of that can get very messy.
So it’s worth taking a close look at that pre-production environment and making sure you get your ALM strategy correct from the very beginning of your application’s development.
A different type of monitoring
Hopefully everybody monitors their production environment. But there’s a different kind of monitoring required when we’re looking at the pre-production space – and that is the monitoring of activities or tasks related to putting an application into production or service.
In that sense, effective ALM is about anticipating the bottlenecks and performance capabilities of the development environment and managing the activities surrounding the software development lifecycle. What you’re aiming to do is push those activities into the production environment quickly, efficiently and robustly.
And inevitably that involves automation – automating the right data to the right people so your organisation can act quickly and create a highly productive development environment. Equally, it’s about creating a collaborative, high performance working culture between the engineering teams and management within your organisation.
Getting back to the source
So let’s go back to the beginning. ALM is particularly active in the pre-production environment and runs throughout the whole production cycle. The process we’re talking about can be more rightfully called the SDLC (software development lifecycle) because it takes the application through design, development and testing and other sets of iterative activities. It’s at this birthplace of your application’s development that good processes and environments should be put in place.
So who is working for you at the early development stage? Usually it’s a team. A set of dedicated, sincere human beings working towards a common goal – at least, we hope so. Let’s examine this team closely. Do they have a workable environment? What are you providing so that they can work at optimum efficiency?
Perhaps I have a vested interest in saying this, but when you focus on the requirements of your service developers – providing them with the learning environment and tools they need, you get the best out of them – it’s as simple as that.
So what does focusing on their requirements actually mean? And why are so many organisations getting it wrong?
Firstly, a collaborative environment is instrumental in ensuring your engineers gain a sense of ownership, freedom and growth. In my opinion, this is what is missing today in most organisations – leadership loses focus on how to improve the working environment of its development resources.
Commonly, a lack of team collaboration is the result of a distributed team setup where one is in, say India and the other in Australia. It is often exacerbated by project specific training where you build singular experts in different tools.
Equally, organisations often treat each project under a different governance model whereby information may not be shared openly. There can be a restrictive air surrounding this information because of the creation of a separate team and management structure; or the use of tools familiar to that team but not to others, or because the team or knowledge is the result of a legacy process that has been handed over from previous iterations of the project.
When non-collaborative teams play an independent role within an organisation everybody loses. There is no sharing of information, no information re-use and it quickly becomes about re-inventing the wheel again and again. For many organisations with disjointed teams and distributed resources; it is unlikely that development teams are even aware of the resources and capabilities at their disposal – they work within their bubble.
Teams and tools – getting it right
For development teams to work at optimum efficiency they need the right tools. Procuring tools that don't integrate is a regular problem, as is a general ignorance about ‘right tools’ because regardless of the cost, the right tools for the job will always add benefit.
But it’s not just about having the right tools. It’s about having the vision and expertise to consolidate and integrate software assets into a single platform so that you achieve high performance for every application development throughout your organisation.
Great – so how do you achieve that?
See it in action
A team usually works on specific technologies - say Java for example. As part of a development process a certain set of artefacts is generated. These could include design documents, project plans, resource allocation plans, code control, code integration, testing and release.
You obviously need tools to do these activities and more often they are disparate tools from different vendors. Disparate tools might allow a limited integration where you could have a version control system to control code and documents, a project management tool to define tasks, and so on. But associating these artefacts across projects can be tricky, and creating ‘experts’ in singular disciplines or projects does little to breed collaboration or knowledge sharing – as we’ve discussed above.
This is where Integrated Tooling comes into its own. A version control code is associated to a project plan and in turn associated to a specific document. There is bi-level association generated between every tool in your application development – your tools start working as a team.
Integrated Tooling – the Holy Grail of ALM
In actual fact integrated tooling is the main component of ALM. That’s because ALM itself is about defining a platform to connect to any vendor application and creating a communication portal around it.
To explain this better in terms of application development, I’ll show you an example using just one each of the many available tools.
A project typically requires. - A source control tool
- A task management tool
- A build management tool
In a regular cycle of application development, all source code is pushed into a source control tool such as Subversion. Developers make changes and put those changes into Subversion for code control. This code is the source of the application and every change will have a plan or task associated to it.
To manage what sets of changes go into Subversion for any particular project, we need to assign tasks in a task management tool such as Bugzilla. Once all changes are in Subversion, developers need to generate a binary or running application, which is done via a build management tool such as Jenkins.
It’s all about building code and managing it and in this particular context, the true benefit of ALM is in the seamless interaction or even communication of these processes. When we can create a communication channel across these three tools we can track changes from the source control tool to the task management tools and to the build management tool. Equally, a user can access all of this information in one go rather search for them separately
Now, let’s assume we need to add a test cycle to all of this - and that this will be provided by a third party vendor – HP, for example.
An ALM solution will support the integration of this testing tool into the existing mix of tools and also create a communication channel there. This is automation in action – tools working together, building lines of communication and making sure your engineers have the technology to do their jobs well.
A final word
ALM is a platform that allows the integration of various tools regardless of their vendor status. Naturally there are conditions for this integration and expertise is required – and that’s where ALM specialists like Ecetera can add genuine value in providing a consultative role to organisation so you can achieve a scalable integrated solution.
Equally, before embarking on a successful ALM strategy you need to understand where your organization currently stands. As such it’s a good idea to invest in a formal assessment of your development processes and practices from all angles. That might include analysing your repository architecture, development processes, code branching and merging methodologies, continuous integration strategies, additional IP practices and platform optimisation.
My next blog will take you down the formal assessment path and explore the key benefits you should aim for with ALM – namely Centralization, Asset Re-use, Visibility, Automation, and deployment through Cloud. If you can’t wait that long, feel free to contact independent ALM specialists Ecetera for a complimentary ALM consultation.
Contact us at enquiries@ecetera.com.au
>>> | 