Connected Architecture for a Connected Planet

Or how to connect the architecture dots to support a smart connected planet.

Introduction

The notion of a connected planet is far from new.  However, the number of connections as illustrated in figure 1 is growing at an exponential rate, and it is fast becoming a reality in which many organizations must operate.

However, I doubt many organizations are preparing for this in a systematic way. More likely, experience suggests that dozens of connected ‘solutions’ will permeate the organization via myriad routes and just add to the complexity of the business and IT landscape, becoming yet more spaghetti that someone is left to untangle.

Architecture is key to dealing with this. However, architectural practices must evolve to themselves become more connected, and not a set of isolated disciplines as they are often practiced today.
Hence, in this note as well as considering the challenges and opportunities provided by the connected planet, I outline the role of connected architecture.

The Connected Planet

The looming challenge, or for some the opportunity, facing organizations is how they cope with the scenario shown in figure 1.

Figure 1 – The Connected Planet

Namely, that there will be

• Trillions of connected things, sometimes dumb but increasingly smart
• Used by billions of people, socializing and interacting to evaluate and rate you, your products, prices, and competitors.
• Generating quadrillions of messages representing quadrillions of events, some significant but many insignificant
• Connected to millions of APIs and services, hosted in the cloud
• Accessing and creating petabytes of information, both current and historical

This is a scenario I first documented back in a blog in 2009 [1].  IDC talk  about this as the “3rd platform, built on mobile devices and apps, cloud services, mobile broadband networks, big data analytics and social technologies” [2], and paint a scenario in their research that reads remarkably similar to the above.

Winners and Losers on the Connected Planet

The key issue for organizations will be

• How does the business cope with information overload, or derive value from it?
• How does IT deliver business solutions that manage the resulting transaction and information explosion, in a cost-effective manner?

The winners in this scenario will be those that exhibit the characteristics outlined in Table 1.

Table 1 – Winners and Losers on the Connected Planet

By implication, the losers will be those organizations that fail to exhibit these characteristics!

The Connected Architecture Solution

So, how does an organization make sense of trillions of connected things and billions of people accessing petabytes of information via millions of APIs and services?

Firstly, organizations and their IT solutions need to become increasingly,

• Autonomic, in the way they,
• respond to events, and how they correlate events and information
• discover new service providers and their APIs
• manage resources, adopting the principle of ‘management of services, by services’
• freeing up human resources to deal with exceptions and ‘special cases’
• Analytical, in the way they,
• make sense of events and information
• Decoupled, in the way they,
• participate in federated ecosystems, not tightly bound partnerships
• separate service provider from service consumer
• assemble solutions from services not implementations

Figure 2 – Connected Architecture

As stated earlier, architecture is key to dealing with this.  However, there is no one architectural ‘style’ that encompasses everything that is required to solve the problem. It would be tempting to say the answer is SOA, or the answer is WOA, or any other acronym that is or was flavor of the month, or for architects to believe that it all revolves around whatever is their ‘pet’ approach. While SOA principles of encapsulation and separation will inevitably be at the heart of the connected architecture, the practical reality of a collaboration between disparate organizations and capabilities will mean a federated architecture involving different technical solutions.

As illustrated in figure 2, what is required is an agile federated approach to architecture that assembles a Connected Architecture consisting of the following,

• Web 2.0 Architecture – enabling people to rapidly mash up user and community driven solutions, in turn assembled from millions of APIs and services, and generating quadrillions of events,
• leveraging Enterprise Mobility to connect employees, partners and customers, and their devices,  anytime, anywhere,
• requiring Event Driven Architecture (EDA) to determine the autonomic response required to sensors and changes in state, and correlate events,
• that are also placed into context by agile Business Process Architecture (BPA/BPM) and Information Architecture (IA), with Real-time Business Analytics (BA) to make sense of what is happening,
• using capabilities provisioned through APIs and services in a Service Oriented Architecture (SOA) that provides a formal basis for the decoupling of Provider and Consumers resources,
• combined with a Web Oriented, or Resource Oriented Architecture (WOA/ROA) exchanging information between those trillions of devices in an efficient manner that will likely be done in a more lightweight manner than full blown Web Service-based SOA, with their implementations defined in a Component Based Software Architecture (CBSA) - with the focus on right-grained software units enabling agile, federated software delivery, that is hosted anywhere, anytime on a Cloud Based Architecture (CBA) that describes the virtualized, federated infrastructure providing scalability, reliability.

No one of these styles covers the problem space by itself. Rather, the problem space needs to be decomposed and the appropriate architecture approach applied to each domain.

Connected Platform

Another key enabler will be the increasing use of ‘Connected Platforms’. Cloud ‘platforms’ such as Salesforce, Facebook or Amazon are in wide use and are already dominant in their respective domains because their platforms provide a considerable benefit by way of platform capabilities in comparison to building their own, and more importantly to business perhaps, provide a gateway to a ready-made ecosystem that use the platform.

Expect Connected Platforms to emerge that act as a ‘hub’ or focal point around which industry ecosystems evolve, and it is likely that every industry will come to be dominated by a few key platform providers.

Many organizations will therefore have little choice of which Connected Platform they use as they will be forced upon them by participants in their industry – either by the 400lb gorillas who already dominate their industry, or by the platforms to which their ecosystem and end customers have gravitated, forcing them to adopt.

As illustrated by figure 3, the challenge for each enterprise will be to determine,

• what their role is in the ecosystem, as provider and /or consumer, or possibly platform operator
• hence, which services they should be expected to provide, and which they should consume
• what services the Connected Platform is or should be providing, and who should providing them
• their willingness to depend on the Connected Platform and the extent to which they allow the platform to dominate
• the extent to which architects design their service architecture around the Connected Platform, or to what extent  they should design their own platform independent architecture, especially for large organizations who may participate in multiple overlapping ecosystems, with multiple Connected Platforms.

Figure 3 – The Connected Platform

The Architect’s Challenge

The key challenge for architects is that they cannot treat the various elements of the Connected Architecture as they often do today – as architectural silos [3] in ivory towers. Instead, as discussed earlier the elements must work seamlessly together.  But this isn’t solved by Enterprise Architecture – which may contain elements of all these – at least not alone, as this is about working at the detailed level to deliver solutions, not just a high-level view of the enterprise.

Hence it is important that architects develop a consistent framework for collaboration within the Connected Architecture.  This is an area in which Everware-CBDI is well placed to assist.

References

[1] Architecture for the Smarter Planet. http://lwsoa.blogspot.co.uk/2009/10/architecture-for-smarter-planet.html 
[2] IDC Predictions 2013. November 2012, IDC #238044, Volume: 1 http://www.idc.com/research/Predictions13/index.jsp#.UR4HSmf-unI
[3] Beware the new silos! http://everware-cbdi.com/index.php?cID=118&cType=document