Welcome!

Web 2.0 Authors: Roger Strukhoff, Liz McMillan, Kevin Benedict, Pat Romanski, Elizabeth White

Related Topics: SOA & WOA, Java, Web 2.0, Cloud Expo, Big Data Journal, SDN Journal

SOA & WOA: Blog Feed Post

Connected Architecture for a Connected Planet

Or how to connect the architecture dots to support a smart 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

  • Trillionsof connected things, sometimes dumb but increasingly smart
  • Used by billionsof people, socializing and interacting to evaluate and rate you, your products, prices, and competitors.
  • Generating quadrillionsof 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 in2009 [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.

Winners are:
Constantly Connected With their Customers. Anywhere, Anytime, Anyhow
Constantly Engaged To help customers (and themselves) make informed decisions
Agile Responsive to change Creating new opportunities
Decoupled Provider from Consumer Solution from Technology Application from Process from Capability
Responsive Sensing and predicting events Correlating events Autonomic response
Excellent Six-Sigma products and processes
Efficient Automated and Autonomic Low operational cost per event response (e.g. business transaction) Optimized processes
Federated Driving multi-party ecosystems (internal and external)
Focused On core capabilities Best sourcing and collaborative sourcing of non-core capabilities

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.

IASA UK Architecture Summit

My colleague David Sprott and I will be running a one day workshop on these and other related ideas at the IASA UK Architecture Summit.

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

Read the original blog entry...

More Stories By Lawrence Wilkes

Lawrence Wilkes is a consultant, author and researcher developing best practices in Service Oriented Architecture (SOA), Enterprise Architecture (EA), Application Modernization (AM), and Cloud Computing. As well as consulting to clients, Lawrence has developed education and certification programmes used by organizations and individuals the world over, as well as a knowledgebase of best practices licenced by major corporations. See the education and products pages on http://www.everware-cbdi.com