Share This Page

ShareShareShareShare

Share This Page

ShareShareShareShare

Silos inevitably arise within every organisation. It’s time to stop trying to prevent them, rather let’s get them under governance, and start thinking today about why we want them.

What is a Silo?

Any standalone functional capability is a silo. Silos usually indicate a lack of information flow between interfacing systems. Silos can be technology systems or business systems. Here, I am discussing technology silos, which happen by enabling business capability with technology - either by solving business problems or by automating business processes.

Why do we have silos?

Sometimes silos are simply indicative of some protectionist mentality. Let’s put that to one side in this briefing. We are more interested in why silos are created when there is a willingness to engage with the local IT and architecture function, yet facilitation of technology to meet business needs cannot be accommodated in a timely fashion, within existing enterprise capabilities.

Our problem is founded upon the universally known enterprise speed conflict between ‘Technology’, ‘Business Needs’ and ‘IT Services’. Simply put, each operates in different speed lanes, and enterprise architecture thinking can never resolve this.

Technology moves at a rapid pace, much faster than most organisations can readily keep up with.

Business users have a good idea of what they want to achieve and how they are performing against competitors. They would like to keep up with the latest and greatest, but local technology and skill vacuums usually prevent this.

IT Services usually cannot bypass enterprise processes to adopt new technology fast enough to satisfy business expectations. Project funding does not actually properly budget for industrialisation (productionisation is not the same as industrialisation), and complexities around service and maintenance models, product lifecycle and improvement programmes may be perceived as inconvenient necessities.

Technology Moves

Our challenge is to enable the business to achieve its immediate requirements, without technology obstacles, while enterprise services iteratively converge towards technology harmony.

Resolving the speed lane problem

Ideally, we want to defend our existing IT estate from external pollution, while maintaining flexible access to any technology solutions that best serve our business requirements.

  • How do we ensure that business needs can be met rapidly and efficiently, delivering value at the earliest possible opportunity?
  • How do we implement enterprise-wide strong governance and best practices, ensuring efficient reusability of our existing capabilities?

Re-thinking traditional principles

A more contemporary interpretation of the abstraction principle is useful. If we were to baseline platform level capabilities, and provide these using interfaceable services, abstracting these from re-invention, we can implement contained products (read healthy silos), to accelerate business value (product delivery), and enable (even encourage) freedom to innovate, without breaking enterprise principles, as core features of a modern platform architecture.

Data Publication Platform

Of course, this conveniently aligns with a cloud-first strategy, where security and monitoring, product boundaries, and costs controls can be efficiently enforced.

Healthy silos

If a silo ringfences a business value proposition implemented as a technology solution, a pattern for healthy contained silos also follows the following ruleset:

  1. Use anything within the Platform Product suite that is available to you
  2. Extend capabilities into your silo only to meet business needs. Innovation is encouraged, but this is not a place for R&D
  3. Plan to maintain any non-platform functionality as part of your product lifecycle. Anything non-platform provisioned is the responsibility of the product owner – not the platform owner
  4. Observe platform protocols and standards wherever possible; designing your improvements so that they are promotable into the platform layer (but don’t bank on when that might be)
  5. When (if) platform capabilities and local functionality become convergent, plan to switch dependencies to the platform level feature, as part of your normal, iterative, product improvement cycle
  6. All products should aspire to be fulfilled by platform capabilities as a target state, but never assume when that may realistically become possible

Product IT operating model

Most modern organisations no longer centralise their IT spend. Each business team generally has a budget to invest in IT projects that achieve strategically aligned value propositions. The boundaries between IT and business are not at all clearly defined, and a continuous trade-off exists between speed and agility, functionality, efficiency, and reusability.

Adopting a Product focus, over an Enterprise focus avoids obstacles that constrain rapid value achievement, without removing the expectation of reusability and enterprise conformance. In fact, these enterprise capabilities accelerate product delivery by providing critical universal functions to the benefit of all.

However, from ideation, design, and construction through to the industrialisation of a Product, the model expects domain-based technical and business alignment, end-to-end delivery by the Product team, and ownership at the Product level.

In this model, a Product inevitably represents a Silo, but critically it’s a Healthy Silo; we understand the division of responsibilities between the Product and Enterprise teams, and both have committed to (eventual) convergence where product innovation may represent some improvement to enterprise services.

Culture adjustment

There is a culture adjustment required in most organisations to cope with the powershift towards a product focus, and a strong reliance upon adoption of modern principals around agile, continuous integration and deployment, and test automation. All these usually require some technical upskilling and a full-stack mindset.

Additionally, at the enterprise level, platform components must move towards adaptive capabilities for intelligent data ingest, data quality management, security and monitoring, with micro-services and other flexible interfaces ready to support product construction through an efficient delivery pipeline. Not forgetting the process, or blueprint, to enable promotion of product-level service to the platform-level … when appropriate.

Culture shift and skills refresh does not need to arrive with a ‘big-bang’. You can start small and carefully shift over time, gently fostering confidence in the organisation. Adoption will grow as benefits are realised.

What are the benefits?

Understanding why silos are inevitable and how to keep them healthy enables us to achieve business outcomes faster.

We can resolve technology and skill vacuums to meet immediate needs, while enabling the possibility to improve our platform capabilities and upskill our local teams according to a comfortable roadmap.

We encourage an environment that fosters innovation, and we get to apply a standard of governance, that we previously only aspired to; establishing an IT eco-system that can easily adopt new technology, without breaking the enterprise model.

And finally, we now have a business organisation that can be happy with their IT services, and lines of responsibility that are clear, transparent, and enforceable.

Worth a chat?

Get in touch with me at:

antony.panteli@mindtree.com
linkedin.com/in/antonypanteli

image

About the Author

Antony Panteli
Global Technology Partner - Consulting

Antony Panteli is a global technology partner within Mindtree Consulting. An evangelist for architecture led modernisation and transformation, Antony is a senior strategic technology leader, with 20 years’ experience in complex system architecture and delivery across multiple verticals.

Other Stories by the Author

Let's Talk About Your Needs

Thank you for your submission. We'll be in touch.