In the last post we described DevOps and how it drive highly performant and reliable systems with openness and flexibility. In this post we complete the Open Network Integration domain by describing the Systems Integration practice.
What is Systems Integration
A classic definition of Systems Integration (SI) is:
Systems Integration (SI) covers the entire end-to-end solution implementation process across all components and processes. SI is about integrating multiple sub-systems and components into a cohesive whole that delivers the required overarching capabilities. The components are not only technology but also business and operational.
SI is almost always about integrating one or more vendor’s products with existing and potentially new internal systems. Given that vendors often operate in different geographies, this presents the problem of integrating multiple cultures and potentially multiple languages.
In a world in which enterprise business processes are increasingly outsourced to specialist providers, even dealing with entities within a single enterprise can involve transitioning multiple external service providers.
In summary: SI is about “multi-everything” – multi-technology, multi-component, multi-organisation, multi-process, multi-culture, etc.
We have Agile and DevOps. Why do we need Systems Integration too?
The typical Agile project is a single outcome software development project. As project scope grows, e.g. multiple vendors involved across multiple organisations, the limits to this approach become clear.
Although there are many branded methodologies that promote “agile at scale” (e.g. SaFE), they work best when there is a degree of process homogeneity across the multiple project stakeholders. This usually requires a major transformation before the project gets started.
At the scale at which Systems Integration becomes useful, we don’t see homogenous practices across the project scope. Typically we see a heterogenous mix of lifecycles and implementation approaches that have to be integrated together into a working project.
There are a number of factors that put significant stress on Agile practices and that require additional tools and practices, including:
- Existence of formal, complex and often stringent contracts between partners
- Much larger team sizes spread across different entities and often, geographic regions
- Need to manage significant decisions across internal and external organisational boundaries
- Multiple systems (internal and external to the organisation)
- Need for major organisational change management, which brings with it conflict and political power struggles in different departments, divisions, and regions
- Impracticality of a single Product Owner: we need to deal with multiple, even a large number of, “go to” people from both a knowledge and decision-making perspective across various organisational entities
- More stringent and complex compliance / governance processes, due to larger size and risk, which, can lead to
- Requirement for more detailed upfront specifications and estimates than most agile projects
- Up-front budget & timeline estimates that are typically locked into a fairly narrow range (+/- 10% is not uncommon, depending on the organisation)
In most Open Networking projects, it is not practical to run the necessary transformations that would enable fully agile approaches across organisations. We just have to play the ball where we find it.
How do we address these factors in Open Networking Projects?
Does this mean that for Open Networking projects we need revert to full “Waterfall” as our lifecycle model? The answer is no, not completely; but we have to recognise the reality of these factors and put in place mechanisms that allow us to manage them.
These mechanisms include:
- Stakeholder Management: using both formal and informal mechanisms
- Identify all the decision-makers and influencers and how to engage them
- Management of multiple “Product Owners”, actual or proxy, for requirements inputs and prioritisation
- Successful operation of cross-organisational escalation and conflict resolution processes
- Understanding and participation in formal governance processes
- Full-scope dependency management: between multiple points and multiple types (e.g. technical, process, governance)
- Precise but flexible models: of requirements, solution structure (components and interfaces), resource estimates (time, cost and people). These need to be precise, contextually rigorous, easily understood and flexible
- Appropriately Rapid Decision-making: decision timeframes need to be shorter than change cycles
Conclusion
Overall, SI means being immensely practical and solving specifically for each project’s unique and actual circumstances. This results in a highly tailored approach for each project: Systems Integrating is not a donut-making machine. The implication of this is that we need the skills to set this custom implementation plan up and obtain agreement from all the different stakeholders.
We need to be as flexible and agile as possible within the constraints imposed. Above all we need to carefully manage stakeholders to avoid the “culture wars” between agile and plan-based approaches or between different organisational perspectives; there is enough conflict in large projects as it is, without inventing new sources.
That brings us to the conclusion of our description of the Open Network Integration domain. Now we have covered all three domains, plus the Software Interlude. What’s next?
Next up we begin a series on Interoperability in the Real World, in which we examine the goal of Open Networking and how well (or not) that goal can be achieved.
Stay tuned.
