Why IoT is changing Enterprise Architecture

[tl;dr The discipline of enterprise architecture as an aid to business strategy execution has failed for most organizations, but is finding a new lease of life in the Internet of Things.]

The strategic benefits of having an enterprise-architecture based approach to organizational change – at least in terms of business models and shared capabilities needed to support those models – have been the subject of much discussion in recent years.

However, enterprise architecture as a practice (as espoused by The Open Group and others) has never managed to break beyond it’s role as an IT-focused endeavor.

In the meantime, less technology-minded folks are beginning to discuss business strategy using terms like ‘modularity’, which is a first step towards bridging the gap between the business folks and the technology folks. And technology-minded folks are looking at disruptive business strategy through the lens of the ‘Internet of Things‘.

Business Model Capability Decomposition

Just like manufacturing-based industries decomposed their supply-chains over the past 30+ years (driving an increasingly modular view of manufacturing), knowledge-based industries are going through a similar transformation.

Fundamentally, knowledge based industries are based on the transfer and management of human knowledge or understanding. So, for example, you pay for something, there is an understanding on both sides that that payment has happened. Technology allows such information to be captured and managed at scale.

But the ‘units’ of knowledge have only slowly been standardized, and knowledge-based organizations are incentivized to ensure they are the only ones to be able to act on the information they have gathered – to often disastrous social and economic consequences (e.g., the financial crisis of 2008).

Hence, regulators are stepping into to ensure that at least some of this ‘knowledge’ is available in a form that allows governments to ensure such situations do not arise again.

In the FinTech world, every service provided by big banks is being attacked by nimble competitors able to take advantage of new, more meaningful technology-enabled means of engaging with customers, and who are willing to make at least some of this information more accessible so that they can participate in a more flexible, dynamic ecosystem.

For these upstart FinTech firms, they often have a stark choice to make in order to succeed. Assuming they have cleared the first hurdle of actually having a product people want, at some point, they must decide whether they are competing directly with the big banks, or if they are providing a key part of the electronic financial knowledge ecosystem that big banks must (eventually) be part of.

In the end, what matters is their approach to data: how they capture it (i.e., ‘UX’), what they do with it, how they manage it, and how it is leveraged for competitive and commercial advantage (without falling foul of privacy laws etc). Much of the rest is noise from businesses trying to get attention in an increasingly crowded space.

Historically, many ‘enterprise architecture’ or strategy departments fail to have impact because firms do not treat data (or information, or knowledge) as an asset, but rather as something to be freely and easily created and shunted around, leaving a trail of complexity and lost opportunity cost wherever it goes. So this attitude must change before ‘enterprise architecture’ as a concept will have a role in boardroom discussions, and firms change how they position IT in their business strategy. (Regulators are certainly driving this for certain sectors like finance and health.)

Internet of Things

Why does the Internet Of Things (IoT) matter, and where does IoT fit into all this?

At one level, IoT presents a large opportunity for firms which see the potential implied by the technologies underpinning IoT; the technology can provide a significant level of convenience and safety to many aspects of a modern, digitally enabled life.

But fundamentally, IoT is about having a large number of autonomous actors collaborating in some way to deliver a particular service, which is of value to some set of interested stakeholders.

But this sounds a lot like what a ‘company’ is. So IoT is, in effect, a company where the actors are technology actors rather than human actors. They need some level of orchestration. They need a common language for communication. And they need laws/protocols that govern what’s permitted and what is not.

If enterprise architecture is all about establishing the functional, data and protocol boundaries between discrete capabilities within an organization, then EA for IoT is the same thing but for technical components, such as sensors or driverless cars, etc.

So IoT seems a much more natural fit for EA thinking than traditional organizations, especially as, unlike departments in traditional ‘human’ companies, technical components like standards: they like fixed protocols, fixed functional boundaries and well-defined data sets. And while the ‘things’ themselves may not be organic, their behavior in such an environment could exhibit ‘organic’ characteristics.

So, IoT and and the benefits of an enterprise architecture-oriented approach to business strategy do seem like a match made in heaven.

The Converged Enterprise

For information-based industries in particular, there appears to be an inevitable convergence: as IoT and the standards, protocols and governance underpinning it mature, so too will the ‘modular’ aspects of existing firms operating models, and the eco-system of technology-enabled platforms will mature along with it. Firms will be challenged to deliver value by picking the most capable components in the eco-system around which to deliver unique service propositions – and the most successful of those solutions will themselves become the basis for future eco-systems (a Darwinian view of software evolution, if you will).

The converged enterprise will consist of a combination of human and technical capabilities collaborating in well-defined ways. Some capabilities will be highly human, others highly technical, some will be in-house, some will be part of a wider platform eco-system.

In such an organization, enterprise architects will find a natural home. In the meantime, enterprise architects must choose their starting point, behavioral or structural: focusing first on decomposed business capabilities and finishing with IoT (behavioral->structural), or focusing first on IoT and finishing with business capabilities (structural->behavioral).

Technical Footnote

I am somewhat intrigued at how the OSGi Alliance has over the years shifted its focus from basic Java applications, to discrete embedded systems, to enterprise systems and now to IoT. OSGi, (disappointingly, IMO), has had a patchy record changing how firms build enterprise software – much of this is to do with a culture of undisciplined dependency management in the software industry which is very, very hard to break.

IoT raises the bar on dependency management: you simply cannot comprehensively test software updates to potentially hundreds of thousands or millions of components running that software. The ability to reliably change modules without forcing a test of all dependent instantiated components is a necessity. As enterprises get more complex and digitally interdependent, standards such as OSGi will become more critical to the plumbing of enabling technologies. But as evidenced above, for folks who have tried and failed to change how enterprises treat their technology-enabled business strategy, it’s a case of FIETIOT – Failed in Enterprise, Trying IoT. And this, indeed, seems a far more rational use of an enterprise architect’s time, as things currently stand.

 

 

 

 

 

 

Why IoT is changing Enterprise Architecture

The 3 pillars of a ‘digital’ strategy

The ‘term’ digital is bandied around quite a lot, so it is useful to be quite precise about what is meant by it.

I believe a ‘digital’ strategy for a business must formally address all of the following 3 pillars if it is to be considered a true ‘digital’ strategy and to achieve the goals of the business:

  • Customer- or client-centricity
  • Data is an asset
  • Achieve and maintain business agility

Customer- or client-centricity – this is about understanding the client’s needs, and in effect providing the whole capability of the organisation to meet the client’s needs effectively and efficiently. The client is assumed to be the primary source of revenue, and the balance between meeting the firm’s wants (i.e., to get clients and to make as much money as possible from them) and the client’s needs (i.e., to get the service they need) will very much shape any client-centricity programme.

Many ‘digital’ efforts tend to focus exclusively on this space, as this involves big data, social, mobile, etc, etc. It is about building (mobile or traditional desktop) applications to meet client needs, it is about providing clients a richer user experience, it is about clients being able to interact with the firm through a single portal tuned for their needs, and not the firm’s own wants. It is about joining processes and functions which historically have acted as islands.

Client-centricity efforts are usually led by the CEO and/or the COO.

Data is an asset

Data is an asset implies you ‘know what you got’ in terms of knowing what data the firm has and where.

This is becoming a bigger priority for more and more firms, as they realise that key strategic goals such as knowing your client’s needs, meeting demanding regulatory obligations or improving operational excellence are all but impossible to achieve without some stewardship of the vast amounts of data that the organisation captures every day.

Stewardship means putting in place principles, practices and tools to allow data to be discovered and accessed when and where it is needed, and to avoid the creation of redundant or duplicative processes or systems.

Data stewardship needs to be led at the level of COO at least, and potentially CEO.

Achieve and maintain business agility

Business agility is the ability to rapidly and sustainably respond to change. Many businesses have been agile in the past, in the sense that they see market opportunities and do the work needed to take advantage of it, usually within a 1 year timeframe and often much less.

However, as the complexity in an organisation grows, the ability to respond rapidly to change decreases, until eventually sclerotic processes and systems force a massive re-investment in technology with the corresponding high cost and high risk.

So maintaining business agility is a complexity management activity: first to control the complexity and then to manage it.

As with the others, business agility needs to be led at the level of COO at least, and potentially CEO. It should not be the responsibility of the CIO on their own.

Summary

At a minimum, all three of the above threads need to be in place to achieve a successful digital transformation effort. The need for first two threads are generally widely understood at the board- and ‘CXO’ level of firms.

But here’s the question: what are they doing about business agility and complexity management? The answer is buried in the murky world of ‘enterprise architecture’, a discipline which has never quite settled down into a steady-state agreement of what it is or what it should focus on, or who should be accountable for doing it.

In a digital context Enterprise Architecture should be first and foremost about complexity management in the context of business agility – especially when viewed in light of the other two executive areas of focus. (This also applies in other non-digital business contexts, such as Mergers & Acquisitions, or Regulatory Compliance.)

Business agility requires agility in its technology. The way to achieve and maintain agility is through managing complexity *continuously* – the complexity of business processes, and complexity of the supporting IT.

A proven way to address complexity is to partition or modularise activities, from the enterprise all the way down, and to establish principles for identifying partitions and for governing change within and across partitions.

This requires new practices and skills which are specifically focused on these principles. These may be skills more mature IT organisations may have, but the practice is a business-technology endeavour: in the end, in the same way the CEO demands focus on customers and data, they must also demand business agility and hold their business and IT to account for achieving that.

An excellent book on this topic is Roger Sessions ‘Simple Architectures for Complex Systems‘, some of which ideas will feature strongly in future posts. A related enabler is the ‘Scaled Agile Framework (SAFe)‘, which drives business agility goals into execution of projects and programs.

The 3 pillars of a ‘digital’ strategy

The path to successful digital transformation

A recent article on TechCrunch suggested that the path to digital transformation for large organisations starts with small pockets of innovation.

It talks about the ‘bi-modal’ approach to doing IT (popularised by Gartner):

  • Mode 1 is traditional, waterfall, risk-averse approach
  • Mode 2 is new, agile, digital, innovative with a higher appetite for risk

In principle, I agree that IT has to be bi-modal, but the rationale and execution as explained in this article is, I believe, flawed or incomplete.

Mode 1 and Mode 2 are not about different ways of building and managing software as such, but about the scope and interest of the users, with which there are strong parallels. Mode 1 inherently supports many stakeholders using a least-common-denominator approach. Mode 2 supports a narrow set of stakeholders very, very well.

Historically, Mode 1 has mainly been comprised of systems focused on ERP for financial planning and management, accounting systems, HR systems, critical payments infrastructure, etc. Almost everything else is Mode 2 by default – i.e., where the benefit to the local users usually outweigh any need/benefit to the wider firm or business line.

The problem is, as organisations mature, Mode 2 systems inevitably become more Mode 1 in nature, as the data they capture, process and control gets dispersed to other systems and processes, and as they in turn depend on more data and processes from other systems.

And this is when complexity becomes an issue. The Mode 2 way of working becomes subject to Mode 1 constraints because of the sheer complexity of dependency management, and as a consequence, projects take longer, cost more and clients get increasingly dissatisfied with their IT service.

So part of the challenge re digital transformation is how to get (legacy) Mode 2 applications that have become Mode 1 back to Mode 2 again.

Perhaps part of the answer is to recognise that parts of the legacy Mode 2 applications are actually Mode 1 (enterprise), and to carve out the remaining parts of the legacy Mode 2 applications that are truly unique to specific users or localised use cases.

The key characteristic of Mode 1 applications must be ‘planning’ – they by definition will take time to get right, and while agile practices and architecture can certainly be applied, the sheer number of stakeholders involved will limit its agility. In the future, firms will compete on how agile their ‘Mode 1’ applications are, but today this is less of an issue as almost all firms in a given industry/sector face the same legacy challenges.

Innovation today is driven by Mode 2 applications; these indirectly generate requirements into the Mode 1 solutions. For example, as soon as another application requires data from a Mode 2 application, this implies that data is Mode 1, and should be a hint that the Mode 1 ‘service’ should now accommodate that data.

The basic premise is to keep Mode 2 applications as simple (in enterprise terms) as possible, to continually drive enterprise-relevant functionality into the Mode 1 enterprise-wide eco-system, and to continually prune such functionality from the Mode 2 application implementation.

The Mode 1 applications then become enterprise services, and can adapt agile practices appropriate for their domain. Mode 2 applications remain highly agile, with a high degree of risk and a high degree of innovation.

But how can we identify these candidate  ‘Mode 1’ services from legacy ‘Mode 2’ applications, and how can these evolve into enterprise solutions in their own right?

That is the subject of another post…

 

The path to successful digital transformation

Digital Evolution Architecture

[tl;dr The Digital Evolution Architect drives incremental technology portfolio investment towards achievable digital objectives.]

Enterprise architecture (EA) has been around for quite a few years. It has mostly been discovered by firms which recognised the rising cost of technology and the need to optimise their technology footprint. They recognised that unfettered technology innovation across departments and teams may serve individual fiefdoms in the short term, but does the whole firm no good in the medium and long term.

But those were in the days when (arguably) the biggest competitive concern of organisations was their peers: as long as you did technology better, and more cost effectively, than your peers, then you were golden. So the smarter organisations improved their investment management processes through the introduction of enterprise architecture. Portfolio construction and investment management was not only based on what the firm wanted to do, but how it did it.

All well and good. For those industries that managed to get by so far without enterprise architecture, the drivers for change today are much more insidious. It is no longer your peers that are challenging your status quo: it is smaller, nimbler businesses; it is more demanding user expectations; it is enterprise-grade technology at pay-as-you-go prices; it is digital business processes that massively compress the time it takes to transact; it is regulators that want to know you are in control of those same processes; it is data as a strategic asset, to be protected and used as such.

These digital drivers require firms to adopt a formal digital agenda. This in turn will require firms to rethink how they manage their technology investments, and how they drive those investments through to successful execution.

One thing is clear: firms cannot go digital overnight. Firms have built up substantial value over the last 20 years in their post-mainframe technology portfolios. They support tried-and-tested processes. Now those processes are under stress, and it is not clear which (or any) of these systems (or firms) will have a place in the highly digital environment we can expect to have in the next 5-10 years.

Firms that recognise the challenges have multiple efforts underway within their IT function – including, but not limited to:

  • Reducing the cost of infrastructure through virtualisation and cloud adoption
  • Consolidation & modernisation of application portfolios
  • Investment in mobile development capabilities
  • Investment in ‘big data’ initiatives
  • Increased focus on security management
  • Improved SDLC and operational processes (DevOps)
  • etc

The problem is, all these initiatives tend to take place in their own silos, and end up being disconnected from the ‘big picture’ – if, that is, there is in fact a ‘big picture’ in the first place. Bringing all these disparate efforts together into a cohesive set of capabilities that allow a firm to thrive in a highly digital environment is non-trivial, but must be an explicit goal of any firm that has established a formal digital agenda.

To do this requires the bringing together of some well-established skills and disciplines that most firms do not have, or are still developing capabilities in:

  • strategy development,
  • investment governance,
  • enterprise architecture,
  • (scaled) agile development, and
  • ‘true’ service-oriented architecture.

(‘True’ service-oriented architecture means designing reusable services from the ground-up, rather than just putting a service interface on top of legacy, monolithic, non-cloud architectures. ‘Micro services’ may be an acceptable term for this form of SOA.)

It also requires a recognition that a multi-tiered IT organisation is a necessity – i.e., that the traditional IT organisation cannot retain control over the entire technology spend of a firm, but instead should focus on those capabilities of cross-business significance (beyond obvious functions like HR, Finance, etc), and enable business (revenue)-aligned IT folks to build on top of these capabilities.

A digital architecture cannot be built over-night: the key skill is in understanding what the business needs to do now (i.e., in the timeframe of the next budgeting period), and in continually evolving the architecture to where it needs to be in order to be ‘digital’ through the projects that are commissioned and executed, even as specific business needs will be constantly changing and adapting.

This means that strategies for cloud adoption, application portfolio consolidation and modernisation, mobile app development, big data, security, ‘devops’ etc all need to be implemented incrementally as part of this over-arching digital evolution approach.

The digital evolution architect (DEA) is the role or function that supports the transition, putting legacy applications on a clear evolutionary path, ensuring that progress does not leave its own legacy, and that the overall cost of change is on a fixed downward trend, even in the face of continuous innovation in technology. It is the role described in the ‘Opportunities and Solutions” part of the TOGAF method for enterprise architecture, albeit with a very explicit digital mandate. As such, it requires close collaboration with folks involved in business & data architecture, solution (information systems) architecture and technology architecture. But the DEA is primarily concerned about evolution towards coherent goals, not about deciding what the optimal target state is, and hence cares as much about portfolio management as about architecture.

For larger firms, the enterprise architecture function must identify which DEA’s are needed where, and how they should collaborate. But DEA’s should be accountable to the head of Digital Transformation, if a firm has one. (If a firm doesn’t have or plan to have such a function, then don’t expect it to be competitive or even around in 10 years, regardless of how big it is today.)

This blog will elaborate more on the skills and capabilities of the digital evolution architecture concept over the coming weeks.

 

 

 

 

 

Digital Evolution Architecture