Looking back now, I can see that I was one of the blind men with the elephant when it came to knowing what software lifecycle integration was about. I’m now realizing that back then I only saw bits and pieces of the bigger picture. And I definitely had no clue how the small piece that I saw and understood fit into the overall landscape. On top of that, I am learning that integration has matured as a discipline significantly and how we think and talk about connected application lifecycle has advanced, allowing new, exciting integration patterns to emerge.
Back then everything started and ended with artifacts (i.e. story, defect, requirement, etc). You took defects found by QA teams and pushed them to Dev teams.. done.
You gathered up a list of user stories from BAs and flowed them to the Development team. and that’s that. So on the surface, the integration was fairly simple.
As things progressed, new more advanced concepts have evolved. For instance, ARM (artifact relationship management) gave much more structure and context to the information synchronized. With more information came more expectations.. Integration desires covered more artifact types and a much wider span of information that was expected to be shared across the ecosystem. At this point, we not only knew information about the requirements and its delivery status, but also how many of them are covered by tests and what the level of coverage for each is. Talk about a big leap forward!!! (Read more about ARM and how it benefits the integration world in in Trevor’s blog “Synchronizing Your Artifacts Is Good, But Organizing Them Is Better“)
But now, my most recent “ah ha moment” of how far integration has come involves “the death of the project”. First, let’s make sure we are on the same page with the definitions:
- Container: Basic Grouping- project, folder, collection, release, etc.
- Work Item: Primary goal is to hold information about work to be done – story, defect, requirement, etc.
Until recently, almost every integration happened within projects. Projects were defined as containers and did not participate in integrations as artifacts. The goal of the project container was quite clear – to organize, aggregate, and manage other artifacts that are meant to represent a single application or a defined set of features, a version maybe… But what we have realized is that actually, the line between containers and artifacts is sometimes blurred – and, we could no longer pretend that that wasn’t the case – we absolutely had to start considering project not just as a container, but as an artifact itself in certain situations. Probably the most fascinating scenario involves project becoming a representation of work to be kicked off by a team, therefore, representing a work item participating in an integration as an artifact, not as a container. There are a couple possible reasons why we are seeing this trend:
- Projects contain certain metadata (not just it’s name) that needs to be communicated to “the other side” which leads us to viewing a project as a typical artifact/attribute entity
- It is more important to be able to communicate progress and health of the project not at the individual task level, but a complex multi-level structure, starting at the top and drilling down to even the sub-task level, if necessary
- Organizations lean towards overall automation to reduce manual overhead, therefore, we are seeing more and more push for automating creation of higher level entities.
Let’s explore this scenario a little more. This is quite common in the “PMO to Development” integration pattern where an organization uses a PPM tool for project and portfolio, high level planning, and a more Agile work management tool for development work scheduling. This is clearly starting to blur the line between an actionable work item and a container project. Going back to my point of maturing integration as a discipline – the PMO office expects that all the information that they need should be visible in their tool of choice to better prioritize, manage, and deliver customer requirements faster. They not only need the updates of the detailed task statuses, but also the link between high-level feature planning, project definition and work item assignments. 
So yet again, because the complexity of integration that we can handle has increased, the integration use cases increase in complexity as well. In the particular sample scenario, we could have an organization that integrates a PPM tool with an Agile Dev tool. Projects are proposed and approved in the high level PPM tool and once a project is approved on the PPM side, it would create a high level work item (Feature) on the Dev side that would serve as a workflow step to represent start of the development process. Once this Project is represented as a feature on the dev side, it can be further broken down into stories and sub-tasks to accommodate day to day development work.
But where does that leave the all so high level “project”? This evolution has turned project into just another work item that can be planned, scheduled and pushed to the dev organization for execution. So the truth is, we can’t delineate between projects and work items as easily anymore. Now, when doing integrations, we have to carefully evaluate the business goal that we are trying to achieve and decide which route to take and how to look at the project item. The good news is, however, the integration building blocks that we have put in place let us be smart about this and seamlessly accommodate for both scenarios, depending on the customer use case on hand. So today we can not only talk about being able to communicate the progress and status updates of the very detailed project work items back to your PMO organization, but also communicate the overall progress of the whole project.
Overall, this is another step into the direction of breaking down silos within your organization, improving communication, and eliminating manual overhead… another step towards the holy grail of software lifecycle integration!
