Transforming IT: From a solution-driven model to a capability-driven model

[tl;dr Moving from a solution-oriented to a capability-oriented model for software development is necessary to enable enterprises to achieve agility, but has substantial impacts on how enterprises organise themselves to support this transition.]

Most organisations which manage software change as part of their overall change portfolio take a project-oriented approach to delivery: the project goals are set up front, and a solution architecture and delivery plan are created in order to achieve the project goals.

Most organisations also fix project portfolios on a yearly basis, and deviating from this plan can often very difficult for organisations to cope with – at least partly because such plans are intrinsically tied into financial planning and cost-saving techniques such as capitalisation of expenses, etc, which reduce bottom-line cost to the firm of the investment (even if it says nothing about the value added).

As the portfolio of change projects rise every year, due to many extraneous factors (business opportunities, revenue protection, regulatory demand, maintenance, exploration, digital initiatives,  etc), cross-project dependency management becomes increasingly difficult. It becomes even more complex to manage solution architecture dependencies within that overall dependency framework.

What results is a massive set of compromises that ends up with building solutions that are sub-optimal for pretty much every project, and an investment in technology that is so enterprise-specific, that no other organisation could possibly derive any significant value from it.

While it is possible that even that sub-optimal technology can yield significant value to the organisation as a whole, this benefit may be short lived, as the cost-effective ability to change the architecture must inevitably decrease over time, reducing agility and therefore the ability to compete.

So a balance needs to be struck, between delivering enterprise value (even at the expense of individual projects) while maintaining relative technical and business agility. By relative I mean relative to peers in the same competitive sector…sectors which are themselves being disrupted by innovative technology firms which are very specialist and agile within their domain.

The concept of ‘capabilities’ realised through technology ‘products’, in addition to the traditional project/program management approach, is key to this. In particular, it recognises the following key trends:

  • Infrastructure- and platform-as-a-service
  • Increasingly tech-savvy work-force
  • Increasing controls on IT by regulators, auditors, etc
  • Closer integration of business functions led by ‘digital’ initiatives
  • The replacement of the desktop by mobile & IoT (Internet of Things)
  • The tension between innovation and standards in large organisations

Enterprises are adapting to all the above by recognising that the IT function cannot be responsible for both technical delivery and ensuring that all technology-dependent initiatives realise the value they were intended to realise.

As a result, many aspects of IT project and programme management are no longer driven out of the ‘core’ IT function, but by domain-specific change management functions. IT itself must consolidate its activities to focus on those activities that can only be performed by highly qualified and expert technologists.

The inevitable consequence of this transformation is that IT becomes more product driven, where a given product may support many projects. As such, IT needs to be clear on how to govern change for that product, to lead it in a direction that is most appropriate for the enterprise as a whole, and not just for any particular project or business line.

A product must provide capabilities to the stakeholders or users of that product. In the past, those capabilities were entirely decided by whatever IT built and delivered: if IT delivered something that in practice wasn’t entirely fit for purpose, then business functions had no alternative but to find ways to work around the system deficiencies – usually creating more complexity (through end-user-developed applications in tools like Excel etc) and more expense (through having to hire more people).

By taking a capability-based approach to product development, however, IT can give business functions more options and ways to work around inevitable IT shortfalls without compromising controls or data integrity – e.g., through controlled APIs and services, etc.

So, while solutions may explode in number and complexity, the number of products can be controlled – with individual businesses being more directly accountable for the complexity they create, rather than ‘IT’.

This approach requires a step-change in how traditional IT organisations manage change. Techniques from enterprise architecture, scaled agile, and DevOps are all key enablers for this new model of structuring the IT organisation.

In particular, except for product-strategy (where IT must be the leader), IT must get out of the business of deciding the relative value/importance of individual product changes requested by projects, which historically IT has been required to do. By imposing a governance structure to control the ‘epics’ and ‘stories’ that drive product evolution, projects and stakeholders have some transparency into when the work they need will be done, and demand can be balanced fairly across stakeholders in accordance with their ability to pay.

If changes implemented by IT do not end up delivering value, it should not be because IT delivered the wrong thing, but rather the right thing was delivered for the wrong reason. As long as IT maintains its product roadmap and vision, such mis-steps can be tolerated. But they cannot be tolerated if every change weakens the ability of the product platform to change.

Firms which successfully balance between the project and product view of their technology landscape will find that productivity increases, complexity is reduced and agility increases massively. This model also lends itself nicely to bounded domain development, microservices, use of container technologies and automated build/deployment – all of which will likely feature strongly in the enterprise technology platform of the future.

The changes required to support this are significant..in terms of financial governance, delivery oversight, team collaborations, and the roles of senior managers and leaders. But organisations must be prepared to do this transition, as historical approaches to enterprise IT software development are clearly unsustainable.

Transforming IT: From a solution-driven model to a capability-driven model

The true scope of enterprise architecture

This article addresses what is, or should be, the true scope of enterprise architecture.

To date, most enterprise architecture efforts have been focused on supporting IT’s role as the ‘owner’ of all applications and infrastructure used by an organisation to deliver its core value proposition. (Note: in this article, ‘IT’ refers to the IT organisation within a firm, rather than ‘technology’ as a general theme.)

The view of the ‘enterprise’ was therefore heavily influenced by IT’s view of the enterprise.

There has been an increasing awareness in recent times that enterprise architects should look beyond IT and its role in the enterprise – notably led by Tom Graves and his view on concepts such as the business model canvas.

But while in principle this perspective correct, in practice it is hard for most organisations to swallow. So most enterprise architects are still focused on IT-centric activities, which most corporate folks are comfortable for them to do – and, indeed, for which there is still a considerable need.

But the world is changing, and this IT-centric view of the enterprise is becoming less useful, for two principle (ironically) technology-led reasons:

  • The rise of Everything-as-a-Service, and
  • Decentralised applications

Let’s cover the above two major technology trends in turn.

The rise of Everything-as-a-Service

This is a reflection that more and more technology and technology-enabled capability is being delivered as a service – i.e., on-tap, pay-as-you-go and there when you need it.

This starts with basic infrastructure (so called IaaS), and rises up to Platform-as-a-Service (PaaS), then up to Software-as-a-Service (SaaS) and finally  Business Process-as-a Service (BPaaS) and its ilk.

The implications of this are far-reaching, as this research from Horses for Sources indicates.

This trend puts the provision and management of IT capability squarely outside of the ‘traditional’ IT organisation. While IT as an organisation must still exist, it’s role will focus increasingly on the ‘digital’ agenda, namely, focusing on client-centricity (bespoke optimised client experience), data as an asset (and related governance/compliance issues), and managing complexity (of service utilisation, service integration, and legacy application evolution/retirement).

Of particular note is that many firms may be willing to write-down their legacy IT investments in the face of newer, more innovative, agile and cheaper solutions available via the ‘as-a-Service’ route.

Decentralised Applications

Decentralised applications are applications which are built on so-called ‘blockchain’ technology – i.e., applications where transactions between two or more mutually distrusting and legally distinct parties can be reliably and irrefutably recorded without the need for an intermediate 3rd party.

Bitcoin is the first and most visible decentralised application: it acts as a distributed ledger. ‘bitcoin’ the currency is built upon the Bitcoin protocol, and its focus is on being a reliable store of value. But there are many other protocols and technologies (such as Ethereum, Ripple, MasterCoin, Namecoin, etc).

Decentralised applications will enable many new and innovative distributed processes and services. Where previously many processes were retained in-house for maximum control, processes can in future be performed by one or more external parties, with decentralised application technology ensuring all parties are meeting their obligations within the overall process.

Summary

In the short term, many EA’s will be focused on helping optimise change within their respective organisation’s, and will remain accountable to IT while supporting a particular business area.

As IT’s role changes to accommodate the new reality of ‘everything-as-a-service’ and decentralised applications, EA’s should be given a broader remit to look beyond traditional IT-centric solutions.

In the meantime, businesses are investing heavily in innovation accelerators and incubators – most of which are dominated by ‘as-a-service’ solutions.

It will take some time for the ‘everything-as-a-service’ model to play itself out, as there are many issues concerning privacy, security, performance, etc that will need to be addressed in practice and in law. But the direction is clear, and firms that start to take a service-oriented view of the capabilities they need will have a competitive advantage over those that do not.

 

 

 

 

 

The true scope of enterprise architecture