Introduction

No two systems integration projects are the same, given the large number of applications, platforms and component subsystems that can be brought together to function as an integrated system, and the wide range of business requirements and business outcomes that are typically pursued.

This article describes several practices and approaches that Project/Iteration Managers on integration projects with multiple vendor teams can look out for and adopt to facilitate success.

This is especially the case where multiple vendor systems, which on their own perform specific functions are integration targets, and where multiple vendor teams are expected to work closely together to develop software components that provide for integration capabilities between systems.

As integration experts that are trusted and engaged to perform systems integration work, Mexia developers, analysts and project managers strive to fully understand the context in which they operate, and how to deliver customer outcomes in cooperation with other vendor teams, under a customer umbrella.

It’s the way we work

Some vendor teams adopt Agile ways of working that emphasise teamwork, accountability and an iterative process leading towards a well-defined goal, and embrace SCRUM as a project management framework and software development lifecycle (SDLC). However, the teams of other vendors may be invested in a more traditional Waterfall method that is characterised by sequential stages of delivery, and a fixed plan of work.

Cooperation with other vendor teams in a mixed-methodology context can quickly expose the limits of established ways of team working. Delivering working software will be tested and challenged. When Agile ways of working like SCRUM clashes with Waterfall (and vice versa), conflicts and tensions inevitably arise. They need to be considered and managed carefully.

Both the Agile and Waterfall methodologies have their strengths and weaknesses. Considering them in turn is a worthwhile and necessary effort, but beyond the scope of this article.

To complicate matters, vendor teams on a project may also be expected to adopt the project management framework and SDLC stipulated by the customer, which in turn may be a mixture of different frameworks and methodologies such as Agile or Waterfall, and which may not provide the automated tools, templates, and re-usable objects linked to specific SDLC steps that vendor teams typically take.

In a mixed-methodology context, understanding the ways in which other vendor teams work - including customer teams - and adapting practises and techniques to deliver working software in close collaboration with them can go a long way towards ensuring project success.

For example, where one vendor team delivers on a fixed plan of work with set dates, in a predictive fashion, Mexia can estimate the effort required to deliver integration components by a certain date, adjust resourcing accordingly and flexibly, and deliver in an adaptive fashion. Similarly, Mexia delivery teams pragmatically embrace aspects of both methodologies where necessary and combine them to make the best possible software development process for an integration project.

A SDLC and project management framework that is embraced and used effectively by all vendor teams will promote high-quality software development, prevent and locate defects early in the development lifecycle and help the project come in on-time, on-schedule and on-target.

Don’t wait, escalate!

Teams that adopt and fully embrace Agile principles and working practices are typically empowered to take decisions that directly affect their ability to deliver work, and resolve issues head-on. Team members are given the environment and support they need, and are trusted to get the job done.

When faced with technical obstacles, Agile teams are empowered to take decisions on how to resolve issues without necessarily having to seek approval from line managers in each instance. Empowered teams are therefore often able to respond faster to resolve technical issues, because they are trusted and provided with the mandate to do so. They are nimble.

But this may not be the case with other vendor teams, where decision-making is strictly hierarchical, takes time, is based on scheduling resources and the mandate to address issues may be constrained.

Where empowered teams working alongside constrained teams need to address urgent technical issues, it is imperative to escalate issues with the Project/Iteration Manager as well as the right person on the vendor partner team fast, and follow up often.

This is no reflection on the ability of constrained vendor teams to deliver, their technical competence, or the willingness of individuals to go the extra mile to address issues. It is a reflection on the need to assist constrained teams by communicating issues and challenges “up the chain” to the individuals in their own organisation who are empowered to take decisions at the earliest opportunity.

On large integration projects, this supports the Project/Iteration Manager, and where daily stand-up meetings with representatives of all vendors teams do not take place, facilitates the flow of important information, and prevents bottle-necks.

And it goes back to the point above:

Understanding the way vendor teams work, and the role individuals play in them. If you know who to escalate to on vendor partner teams on issues that affect your team’s ability to deliver, you should not have to wait.

Get early visibility of schemas and contracts

No two system data schemas are the same in terms of structure, elements and attributes. Similarly, no two interface and service contracts are the same. The earlier that technical analysis can proceed, the higher the chance that integration challenges on a data and system contract level can be addressed and resolved in good time.

For this to happen, requests for system documentation, contracts and data schemas should be sought from other vendors as early as possible. Conversely - and equally - Mexia provides early visibility to other vendors of data schemas and mapping specifications for services and operations that reside on the integration layer.

As systems integrators, Mexia teams play a crucial role in “bringing systems together” and delivering integration. Team members therefore need to understand vendor systems and technologies to the degree that is required to deliver working integration components, which in turn allow data to flow from system to system, and ultimately deliver expected business outcomes.

Where other vendors’ priorities may be to deliver functional software within the boundaries of their own system(s), and do not necessarily prioritise work on the integration layer, Mexia is solely focussed on delivering the integration solution. Having access to vendor technical documentation and schemas at an early stage supports successful integration outcomes.

Are the right people in the room?

Part of getting to understand how other vendor teams operate is to establish whether and when team members are available to participate in regular meetings as software components are delivered through the lower test environments and into production. This is particularly important for defect triage sessions, during which a first attempt is made at defect root cause analysis.

It is almost inevitable on complex integration projects that defects and issues arise. Knowing that the right people are available at short notice to contribute to resolving such defects in the higher environments, as the project nears its end, is crucial to meet schedules, maintain momentum and deliver working software.

This is particularly the case where team members with specialist skills work remotely and/or are in a different time zone, and where several vendor teams collaborate on problem resolution. The knowledge that access to the right people, at the right time, in the right place is possible builds team and customer confidence, helps to reduce the risk that some defects pose and allows timely defect resolution.

Although not always possible for commercial and scheduling reasons, spending some time during the initiation phase of the project on ensuring that the right people are in the room and available during the defect triage phase is vitally important. It is also a sign of good planning.

Iteration 0 lays the foundation

Software management tools and applications that make the underlying network and data layer visible are essential on any software integration project, as they would be on any other software development project.

Obtaining early access to these software applications and tools - along with the relevant access permissions - supports requirements gathering and elicitation. It allows Systems Analysts and Business Analysts in different vendor teams to have a conversation about specific, highly technical integration requirements and challenges.

It also supports efficient software development and testing. Iteration 0 is typically used in Agile projects to set up servers and infrastructure, come up with a release plan and more generally assure that the project is ready to go. It is the duration between the initial “Discovery” and “Evolve Phase” of a software project, and it is typically neglected, often at a later cost.

For example, where a vendor system utilises SQL database technology, the ability to access a query tool allows analysts and developers to understand database structures, and support the flow of data. Similarly, and where available, SoapUI or PostMan projects that can be used to test service endpoints of vendor systems will support a productive SDLC. Access to these tools and applications is essential to any successful integration project and should be sought as part of Iteration 0.

Information will flow freely

Building strong relationships with individuals on other vendor teams fosters a spirit of openness and transparency, which is vital to ensure successful project outcomes. Mexia delivery teams will encourage daily stand-up meetings and invite key representatives from other vendor teams to participate actively.

Daily stand-up meetings that focus on updating all vendor teams about progress achieved, current effort and finding solutions to obstacles builds trust and confidence in the ability of all parties to deliver for the customer.

Similarly, organising impromptu huddles with vendor experts using a whiteboard to discuss integration challenges creates the space to discuss ideas about possible ways to address and resolve technical blockers.

Instead of scheduling the next formal meeting, making time for a five or ten-minute huddle will often progress vital work substantially, especially where there is an open, pragmatic and collective approach to finding solutions.

In this context Conway’s Law comes to mind, an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It was first dubbed Conway's law by participants at the 1968 National Symposium on Modular Programming. It states that:

“Organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations.”

— M. Conway

The law is based on the reasoning that for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organisations that produced it, across which communication is more difficult.

To break down boundaries on an integration project requires efficient and effective methods of conveying information to and within multiple vendor teams, primarily face-to-face conversations, followed-up with written, formalised communication.

In a practical sense, this is a call to daily action throughout the project to “get up and walk over”, to have that conversation. It is almost too obvious to state, and it is a vital professional skill that all project team members should demonstrate: the willingness to communicate frequently and openly.

We’re all in the same boat

Just as the free and efficient flow of information between vendor teams and an understanding of how other vendor teams work improves the chance of successful project outcomes, so does a shared commitment between vendor teams to delivering good outcomes for the customer.

It is often not enough to use a known, established way of working - whether Agile or Waterfall or any other framework or methodology - as a defence. “That’s just the way we work” will often not suffice. In this sense, all vendors are partners on an integration project, and must act as such in the customer’s interest.

The attitude that “it’s not my problem, the hole is on the other side of the boat” falls short of what is ultimately required. All vendor teams on an integration project sit in the same boat, and if any party knocks a hole in it, all better start bailing water. All parties sink if the integration software fails, not only the customer. When data does not flow across systems, it is not even possible to determine whether it is a case of GIGO, or garbage-in, garbage-out. Data simply does not flow across and into systems.

Summary

To ensure successful outcomes, Project/Iteration managers on software integration projects that engage multiple vendor teams and have multiple system integration targets should be on the lookout for vendor teams to:

• have a good understanding of the way other vendor teams work and demonstrate a willingness to adapt working practices where necessary to the customer’s project management framework and SDLC.
• show a willingness and ability to communicate often and openly, join stand-up meetings, have face-to-face conversations and spontaneous huddles throughout the project with other vendor teams.
• be prepared to provide system documentation, data schemas and contracts as early as Iteration 0 to other vendor teams.
• ensure the right people are in the room during critical phases of the project.
• foster a shared commitment with other vendor teams to project success.

Customers expect no less, and the highest priority for vendors is to satisfy the customer through early and continuous delivery of valuable software.

Picture sources: Burst, Unsplash, Pexels