Enterprise is Dead, Long Live Agile!

Introduction

In corporations, the term “enterprise” often instills a sense of importance, complexity, cost and scale. Likewise high-budget, high-profile projects often result in tech departments responding with enterprise-ready software solutions and infrastructure.

What this means is extensive planning, evaluation, procurement, and timeframes often of several years to “get it right”. The cost of building an enterprise-level solution in this manner is usually in the millions. The risk from failure is extreme.

Of course, enterprise-level solutions shouldn’t mean high-cost, high-risk and long timeframes. Often, this is the result of a traditional mindset and organisational structure. It’s sometimes also an inability or unwillingness for businesses to transform and embrace change.

This article considers what is needed for traditional corporations to transform from that mindset and become agile.

What is Enterprise?

In the context of this article, enterprise means large-scale complex solutions delivered at scale. It often results in enterprise-ready software solutions, which consists of specialised applications that solve a particular business-need across an organisation.

The term “enterprise” also infers the scale, cost and complexity to solve a business need, and often drives a traditional approach to roll-out and planning for these reasons. It often means on-premise solutions or management of third-party applications.

A traditional enterprise project might consist of the following:

• Dedicated crack team
• Feasibility studies
• Risk assessment and mitigation strategies
• Identify all functional and non-functional requirements upfront
• Documentation and project planning
• Integration strategy with other systems and teams
• Migration strategy
• Estimations of costs
• Evaluation and procurement process
• Implementation
• Operational guides and checkpoints
• Disaster recovery planning
• Deployment and release planning
• Big-bang release
• An investigation into what went wrong

Why Enterprise?

Ironically, traditional enterprise approaches are aimed at reducing risk, ensuring longevity, maintainability and to provide maximum value across the business.

Decades ago, this made sense. Deploying software and maintaining servers was a complex process that required specialised teams and specialised applications. It required dedicated teams to guarantee uptime, availability and to provide 24/7 support. Deploying, monitoring, securing and managing these enterprise systems was a fulltime and complex challenge and required high lead times to realise new features. Corporations grew around these dependencies and their organisational structure formed to support it.

With the advancement of technology and modern practices, many of these challenges no longer exist and far more superior, scalable and performant solutions can simply be bought with ease through relatively low-cost subscription-based Cloud providers. This allows startups and companies embracing Lean principles the ability to quickly gain a competitive advantage. Although they face the same challenges in terms of product development, they are able to deliver faster, cheaper and at greater scale.

Challenger banks such as Monzo are a good example of this in practice, now competing with the giants at scale. This is no doubt an enterprise-level product offering, but the product is built on Agile principles and leverages modern architecture. It has the ability to roll-out features fast and adapt to the needs of its customers at pace.

In reality, corporations taking a traditional approach to enterprise are less able to compete in the market. Their aversion to risk and change increases actual risk and cost. Many projects fail and legacy systems get built on top of or integrated with the systems they are meant to replace.

This stems largely from the traditional organisational structures which result in an IT-first approach and detachment from the business. Once a business need is identified, IT builds vast enterprise solutions before any value can be realised to the business. In that time, the market or business needs may have changed, or the assumptions about what the customer needs could be wrong.

In traditional corporations, projects are sliced horizontally into siloed teams. The IT/operations team provide the enterprise software solutions to service the business. The result is large communication overheads and hand-off points throughout a project lifecycle.

Siloed teams drive a need for monolithic systems that support many requirements across the organisation. This creates complexity for deployments, upgrades and project management. It also prohibits change due to the large level of investment required in rolling out these systems.

What is Agile?

Agile is a methodology formed on a simple manifesto.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

It’s based on twelve principles which put the needs of the end user above all else, and this is an important and powerful strategy. It’s also about releasing often and driving architecture decisions from within self-organising teams, whilst collaborating closely with the business.

Agile methodologies are really frameworks and rituals to facilitate collaboration and communication within a team as well as self-improvement and learning. It aids rapid experimentation and iterative development.

Lean principles coupled with Test & Learn complement the Agile way of working and further drive the ability to validate user value and assumptions throughout the project at low cost. This focuses teams on doing the least work necessary to reach the business objective in satisfying the customer. This is the opposite to traditional enterprise which instead works to plan for and predict future requirements of the business.

Organising for Agile

In order for a company to transform and embrace Agile, it requires reorganisation away from siloed teams. To do this successfully, the horizontal slices across an organisation need to be broken down and reorganised into small vertically sliced Product Teams.

An Agile Product Team should be:

• Self-organising
• Delivering user value and validating that user value
• Composed of all skills needed to realise the product
• Autonomous in all decision making
• Responsible for product datasets and product infrastructure
• Able to deploy independently, rapidly and frequently
• Loosely coupled with other Product Teams through product services

For a traditional company transforming to Agile principles, these are often hard to achieve due to the high-coupling of legacy systems across products. Over time, these cross-dependencies should be removed and new systems migrated to the control of the single team that owns them.

Other challenges are of course with keeping the lights on throughout the transition, knowledge transfer and resistance to change.

Choosing the right dissection of Product Teams is important to ensure the right level of granularity of the products, and to minimise cross-dependencies and constraints. These teams should be focussed around specific business capabilities.

Architecting for Agile

What we really mean here is architect for Continuous Delivery in order to become more agile. This supports the Product Team in achieving its business goals. To deliver continuously is one of the 12 principles of Agile. Continuous Delivery is its own set of practices and principles to achieving this with minimal risk, cost and overhead.

A Product Team with full autonomy are free to adapt and improve the architecture of its products over time to meet its business objectives, and without the constraint and complexity of a siloed operations team. This in itself removes the need for enterprise software that touches multiple parts of the business. It allows each team to re-architect and simplify the path-to-production to meet the business needs.

Strangling the Enterprise

During transformation, the need to rearchitect and evolve is hampered by legacy systems and high-coupling between products. The Strangler Pattern is one solution to this problem and allows the business to continue functioning throughout the transition process.

With the Strangler Pattern, small slices of an existing system can be replaced in small incremental changes, and one piece at a time. It requires minimal upfront investment and risk. Each slice is re-built on a new architecture and allows the legacy counterpart to be slowly eaten away until it’s completely replaced. The new slice may contain new features and continue delivering value during the transition.

A reverse proxy is often used to make this process transparent to end users and keeps the user experience seamless.

This approach avoids the alternative which is a large-scale refactor, potential code freeze and large-scale migration of an existing system. Such a project would conflict with the Agile principles as it would not be providing direct value to users during the rewrite.

TSB bank in the UK very publicly failed with a large-scale big-bang migration project that back-fired and crippled its product range. This left customers without access to their accounts or money.

Summary

To stay competitive in an evolving market, traditional companies must embrace change across the organisation and break the enterprise traditions. It requires large-scale business transformation which starts with the organisation structure. This involves setting up dedicated cross-disciplined Product Teams and removing silos.

Product Teams must be given the autonomy and trust to fully manage the products they own, without external governance or architectural constraints.

To achieve the necessary transformation across an established product range, the Strangler Pattern can help teams evolve products whilst continuing to deliver value to customers. This is achieved through modern Cloud re-architecture and iteration within the newly formed Product Teams. It may require simplification and/or replacement of large-scale enterprise systems to refocus on business objectives.

The KPIs on which these teams should be measured include speed-to-market and customer satisfaction. A good team should be able to deploy multiple times a day. They should be continuously improving through rapid experimentation and user testing. This allows teams to quickly innovate, truly understand their customers and pivot where necessary.

History

• 7^th October, 2018: Initial version