Fragile to Agile Defined

We chose our name as it encapsulates our value proposition – transforming organisations from a fragile to an agile one.

So what do we mean by a fragile organisation and an agile organisation?

It is perhaps a controversial assertion that almost all organisations today are inherently fragile. Our primary argument for this assertion is that the vast majority of organisations exhibit one or more of the following characteristics:

• Business processes are embedded in code, fragmented, difficult to change and lack visibility

Over years, poor solution design and short term fixes have embedded business rules and processes into software, rendering them slow, difficult and expensive to change thereby preventing timely responses to market conditions. Given that business processes must be inherently flexible and change frequently, this can be an insidious conflict. Individual applications provide a limited piece of enterprise functionality. Therefore, implementing end to end business processes requires the linking together of the applications that contain parts of the process. This often requires rekeying of data between applications and/or manual processes and procedures to address the fragmentation. Business processes are either embedded in individual applications or require users to move from each application via manual procedures to execute the process. Alternatively, they are hidden by application-to-application interfaces. In both cases, this results in:

  • A lack of visibility of the end to end process;
  • No technology support for ensuring that processes are followed;
  • No way of identifying incomplete open processes;
  • No systemic way of measuring process performance and improvement.

• Solutions do not match business intent or fail

Solutions are delivered that do not meet business objectives or fail completely. The lack of a common language and shared understanding of business intent often results in execution missteps, resource wastage, functionality that does not serve business need and an organisation under equipped to meet its challenges.

• The interface between business and IT is broken

IT is often separated from its business partners by culture, language, perspective and objectives. Without a shared language and understanding of business needs and priorities, resources are wasted by good intentions poorly directed. Solution requirements are inadequately identified and the results delivered infrequently fit the desired business purpose. This is, in many cases, the root cause of the previous characteristic.

• Increasing cost and time to market

Business change to drive new or enhanced products and services is slow to develop, costly or cannot be adequately supported by IT systems. Consequently, market opportunities are missed or better exploited by Fragile Inc.’s competitors.

• Enterprise architecture is considered an information technology responsibility only

If Enterprise Architecture exists, it is assumed to be about information technology only and aimed at efficiency rather than effectiveness; cost reduction rather than value enhancement. Based on the Fragile to Agile definition of Enterprise Architecture, it cannot support the successful execution of business strategy and maximise agility without a deep understanding of business intent, or desired business outcomes, and business architecture.

• Architecture governance is almost non existent

Solution designs lack guiding principles and reference architectures or their enforcement and design deviations are not captured or risk assessed which increases system complexity, integration costs and ongoing maintenance overheads. There is no mechanism to maintain the currency, integrity and relevancy of architecture artefacts and their alignment with business need. Enterprise Architecture has become ‘shelf ware’ so far detached from the real needs of the business it fails to function effectively.

• Unnecessarily complex staff training requirements

Staff members interact directly with one or more applications to execute their job function that requires them to be trained in the specifics of each application, many of which have a very different look and feel. This is further compounded when one of these applications is replaced and a significant retraining exercise is required. Furthermore, the need for staff to continually transition between different applications has, in itself, a materially negative impact on productivity, staff performance, job satisfaction and the ability to attract the desired skills.

• Multiple solutions exist for the same business capability but there is no clear understanding if this is problematic or not

A frequent misalignment between IT and business units occurs when IT attempts to impose a single, standardised solution across the whole business, often citing cost and ease of support as justification. Conversely, some business units desire functionality that fits their business needs specifically. Fragile Inc. does not know whether different solutions are required for a business capability in different business units or if one solution is adequate.

• An inability to exploit sourcing opportunities or fully realise the benefits and synergies of M&A activity

There is an inability to easily insource or outsource capabilities to exploit specialist service providers and/or react effectively to a disaggregation of the business model. Consequently, the organisation cannot dynamically augment internal capacity for a capability to absorb peaks in demand. There is no systematic mechanism to determine, in advance, the integration effort required for potential acquisition targets therefore realising synergies promised for mergers and acquisitions is often elusive.

• Data integrity issues and no single source of the truth

Data is fragmented, inaccurate or missing; not readily available or in the form required by the executive; multiple conflicting copies exist; and it is difficult to determine what data is required to make informed decisions and operate effectively. Although much data exists, its origin is unknown and little insight can be gained from it. Therefore, Fragile Inc. does not know everything it knows; does not know what it does not know and is not certain that it knows what it thinks it knows.

• Lack of clarity where the boundaries between business processes and services lie

Due to an inability to determine where top-down processes and bottom-up service initiatives meet to support business process reengineering, there is no systematic way of identifying where process design ends (business process orchestration) and the service layer begins (service orchestration).

• Not achieving an acceptable level of reuse of services

There is no systemic way to determine the appropriate service granularity for business capabilities to exploit and fully realise service-based initiatives. Some of the services are too coarse grained and no reuse is being achieved and some are too fine grained to be effectively managed.

• Intertwined systems with inflexible interfaces and the need for the manual rekeying of data

Without a properly designed architecture, Fragile Inc. has an accidental architecture, characterised by inflexible point to point integrations between disparate systems. These interfaces are vulnerable whenever change is made to one or more of the attached systems. Where no automation exists, data is moved between systems by manual data entry that is a slow, error prone process.

Even if your organisation is one of the few that does not exhibit any of the above characteristics we would still contend that it is inherently fragile simply because it is now possible to design and build Agile Inc. Unless your organisation is already well on the way to this transformation, you are exposed to the significant risk that someone else in your industry will execute this transformation successfully before you. The major competitive advantage their agility and significantly reduced cost base will provide will automatically render your organisation fragile by comparison.

The passion for Fragile to Agile is to realise the seemingly elusive promise of a truly agile organisation. So what does a truly agile organisation look like? In our view it is one that exhibits the following characteristics:

• Changes to business processes can be made in materially less time

Processes have been extracted from system code and are implemented on a separate specialised platform designed to facilitate rapid change and continuous improvement. Depending on its nature, changes to business processes are made in real time without IT involvement. When IT is required for more complex process changes, or a change to the service layer is required, they are also delivered much more quickly than Fragile Inc.

• Management has real time visibility of the performance of the business

All of the information within the organisation is available to management in a useable form and is a maximum of 24 hours old and, in most cases, up to the minute. Management can manipulate this information dynamically to meet their needs and initiate ad hoc reports on the fly. All levels of management can observe the execution of critical business processes in real time. The predictive and real time analytics capability of the business process management platform provides advance warnings of potential issues, which enables timely pre-emptive action. Processes are automated with staff only required to manage exceptions, and processes are continuously tuned to reduce the number of exceptions requiring intervention.

• Can easily switch between internal and external capability delivery

Agile Inc. operates as a services-based business. Business capabilities are loosely connected to each other via clearly defined manual or automated service interfaces with appropriately defined service levels. As a consequence, when it desires to change sourcing options i.e. insource or outsource any given capability, it can do so with ease.

• Capability delivery capacity can be flexed dynamically to absorb peaks in demand

Agile Inc. is not constrained to a binary choice between wholly insourcing or outsourcing a capability. By identifying common patterns in its business operations, peaks and troughs in the organisation’s process load are detected. The agility of a services-based business enables it to prepare for these loads and dynamically outsource excess work to external service providers whilst maintaining an optimal staff head count.

• Business capability solutions are specialised and standardised, as required

Agile Inc. has a clear understanding of which capabilities require different solutions to meet the needs of different business units and which can share a single solution to enforce standardisation. IT solutions fully support this; where business processes span capabilities that are specialised and those that are standardised the process seamlessly switches between them. This design clarity and execution alignment ensures that the total cost of ownership of IT is minimised whilst still delivering the flexibility required for the organisation to compete.

• Can independently optimise specific business capabilities

Agile Inc. understands its business as an engineered system and can optimise it with confidence. Individual business capabilities are optimised in the same way the engine of a car is tuned. By ensuring that the impact of change is minimised to only those capabilities that must change, there is no cumulative effect due to the nature of its IT systems. Therefore, Agile Inc. confidently adapts to rapid change in its industry through tailored optimisation of specific capabilities.

• Communication channels are added without requiring major system changes

All solutions at Agile Inc. are channel independent, characterised by the separation of the user interface layer from other layers within the solution. As a result, the business logic in the layers below the user interface layer is shared by multiple and different interfaces. This not only reduces costs but adding new channels is simpler and, irrespective of the channel used, the outcome is identical as the same business logic is executed.

• Role clarity, accountability and performance measurement

Everyone understands their role and has clear accountability against which they are measured and non-performers are easily identified. By capturing business process metrics, Agile Inc. has assigned KPIs based on process efficiency and easily identifies where processes are failing. Well defined end to end business processes give clarity, direction and distinct boundaries to individual roles.

• Single view of the customer and other key stakeholders

Staff members have access to a single view of the customer, updated in real time, together with all of the information they require to perform their role. Similar views of other stakeholders, such as partners, are provided if necessary.

• Single source of truth for enterprise data

At Agile Inc. all data has been assigned to a business capability and it is clear which capability is responsible for which data throughout the organisation. As the quality of the data for which the capability owner is responsible directly impacts the ability to meet the capability’s service levels, they are motivated to improve that quality. This is in marked contrast to Fragile Inc. where data stewards are somewhat arbitrarily defined and improving the quality of the data does not directly impact their ‘day job’. With the exception of a read only copy for the integrated reporting solution, data is not replicated across different capability solutions and only updated by the services of its owning capability. Consequently, there is minimal data duplication and the quality of the data is greatly enhanced.

• IT solutions that support true business agility

IT solutions are based on the synergistic Business Process Management (BPM) and Service Oriented Architecture (SOA) paradigms. As both have been designed and adopted in unison, Agile Inc. has achieved greater organisational agility and a marked reduction in cost and time to market.

• Materially lower risk in change execution

As business logic is universally available for reuse via services, when a new requirement emerges that requires the same business logic, it no longer needs to be duplicated. Through its reuse of existing pretested components rather than the development of new ones, Agile Inc. has materially reduced its testing effort and the risk of introducing errors.

• Enhanced staff satisfaction and reduced training requirements

Whilst some staff members still interact directly with applications where only one application is required to perform their role, most staff members now operate entirely via a portal designed specifically for their role. The portal aggregates the functionality required in a single environment with a consistent look and feel that has been tailored to maximise their efficiency. When an underlying application that provides some services to the portal is changed, staff members are unaware it has happened. Key external partners are also provided similar portals and experience the same benefits.

All of the above characteristics render Agile Inc. significantly better positioned than Fragile Inc. when implementing business change. Its cost and time to market are far superior than more fragile organisations and the realisation of other tangible business benefits is guaranteed.

We contend that an agile business is built on a foundation of dynamic business processes underpinned by flexible services. Achieving the former is the remit of the Business Process Management (BPM) and Lean Manufacturing disciplines; achieving the latter is the domain of Services-Based Business Design and Service Oriented Architecture (SOA). It is our belief that adopting either a BPM or SOA strategy without the other will only achieve incremental improvement and certainly not deliver a truly agile organisation.

It is a commonly held belief that neither BPM nor SOA can be delivered without an architectural approach to design and implementation. The Fragile to Agile Integrated Architecture Framework has been specifically designed with this in mind and is uniquely suited to supporting a BPM/SOA strategy. More importantly, our approach to Business Capability Modelling is fundamental in designing a truly agile organisation.

Finally, it is important to have a clearly articulated strategy and that the design of the organisation’s architecture, process and services design which is inclusive of the business, people and technology design domains, is aligned with that strategy for the promise of a truly agile organisation to be realised.

This is encapsulated in the following diagram which is the Fragile to Agile Agility Pyramid.

However, a fragmented approach to change with gaps between levels of design and/or domains of design will prevent a successful transition to this materially more agile organisation. Therefore, it is imperative to have a seamless end to end approach to change delivery.

To summarise and based on the Agility Pyramid, the following are the key shifts required at each layer of the pyramid to transform an organisation from fragile to agile:

Fragile Inc to Agile Inc v1.0

“Adaptive architectures are pointless outside agile organisations” – Ron Bennett