Connected Architecture for the Creative Economy

Steve Denning’s insightful blog post ‘Leadership In The Three-Speed Economy’ has me pondering on the correlation with IT. Does ‘IT in the Three-Speed Economy’ follow a similar pattern?

I am not sure it is cut and dried. My experience suggests that IT can be like the example of GE that Steve provides, where all three economies can exist in the same organization and where pockets of creative IT thinking exist within the morass of traditionalism.  That said, IT in most Traditional Economy organizations will probably follow the pattern in the table below.

Developing Reference 'Things' - Reference Architectures, Reference Models, Reference Frameworks

I have spent a lot of time in recent years developing various reference 'things' for clients and as part of our own research. Whether it has been SOA, Enterprise Architecture, Cloud Computing or more recently Enterprise Mobility, one thing has been clear - that organizations often lack a framework that should form the basis for consistency in these domains.

It is tempting, and common practice, for organizations to respond by acquiring such a framework 'off the shelf'. TOGAF in the EA domain would be a prime example. However, in our experience such 'off the shelf' solutions rarely provide a 100% match to requirements and must be customized and extended to be effective, especially if you want them to be easily assimilated by the organization and not become divisive. Nothing is worse for example than EA becoming just another silo because people don't agree with the framework foisted upon them.

Everware-CBDI plays key role in developing ACT-IAC white paper on Enterprise Architecture and Cloud Computing

Under the auspices of ACT-IAC’s Enterprise Architecture SIG, my colleague Dave Mayo, the President of Everware-CBDI, has led a team in the development of a white paper explaining the role of EA in Cloud Computing.  The paper explores architectural issues, management issues and tools for decision making regarding cloud deployments.  The fundamental finding is that the prerequisite to success with cloud computing is the establishment of a Service Oriented Architecture that identifies the services deployed to the cloud and how they may be accessed.

Click to access the White Paper on the ACT-IAC website. (Word)
or view as HTML on the Semantic Community

Architecture for the Smarter Planet

You are probably aware by now that IBM’s current ‘theme’ is the Smarter Planet.Their basic message is that organizations (both businesses and governments) should take advantage the fact that we live in a world that is,

• Instrumented – 30 billion RFID tags in supply chains
• Interconnected –Trillions of connected devices, and two billion people on the web
• Intelligent – 15 petabytes of new information created everyday

And to do something ‘smart’ with these resources.

This seems in part a reinvention of the ‘Pervasive Computing’ vision. I authored a lengthy report on this some time ago in 2002. I still don’t think we are fully there yet, but you can sense that we are another step closer to it becoming reality, and IBM provide some good real world examples via the link above.

Architecture Scope

Attending the IBM Rational Software Conference recently at which the smarter planet was the theme of the keynote, it prompted me to think about what sort of business and IT architecture was needed.

One thing that is clear is that architects need to think very carefully about scope in this scenario. You cannot take a narrow inward looking project or even enterprise-wide view when the smartness you seek comes from the interconnectivity and behavior of the ecosystem. My colleague David Sprott has coined the term Smart Ecosystem Architecture (SEA) in reference to this.

I believe the key thing here in relation to SEA vs EA (Enterprise Architecture) is for organizations to understand

• what activities are going to be performed by the ecosystem (or the other participants in it), and what activities they need to perform themselves.
• and consequently, what they have to do – e.g. in terms of service provision – to participate in the ecosystem, and hence what capabilities and resources they need to provide their services, and handle the events that require their response

It also seems critical to me to that it is necessary to understand which capabilities are core vs context, but from an ecosystem perspective. (I need to ponder on that further…)

Architecture Patterns

That addresses scope, but what about the architectural patterns that applies?
I am tempted to say it’s all about Service Oriented Architecture (SOA) – in that federated, interconnected ecosystems are inherently service-based. But smart behavior is in a large part about sensing events and responding to them, so we need to add Event Driven Architecture (EDA) into the mix.

Before long I recognized we need several other architectural patterns in support of the Smarter Planet. I started off trying to draw a layered architecture to support of this, but that seemed inappropriate, so for now I will try to sum it up in a simple textual list.
OK, so the architecture for the Smarter Planet involves

• trillions of connected objects and billions of people accessing petabytes of information via millions of solutions, based on an agile,
• Web 2.0 Architecture – enabling billions of people to mash up rapid, user and community driven solutions, in turn assembled from millions of services, and generating trillions of events,
• requiring Event Driven Architecture (EDA) to determine the autonomic response required to sensors and changes in state,
• that are also placed into context by Business Process Architecture (BPA/BPM) and Information Architecture (IA)
• supported by services in a Service Oriented Architecture (SOA) that provides a formal basis for the decoupling of Provider and Consumers resource,
• as well as a Web Oriented, or Resource Oriented Architecture (WOA/ROA) as exchanging information between those trillions of devices in an efficient manner will likely be done in a more lightweight manner than full blown Web Service-based SOA
• with the implementations defined in a Component Based Software Architecture (CBSA) - with the focus on right-grained software enabling federated software delivery, that is running anywhere, anytime on a
• Cloud Based Architecture (CBA) that details the virtualized, federated infrastructure providing scalability, reliability. Which brings us back to SOA, as cloud computing is inherently service-based.

Anything I missed? My point is that architecting for the Smarter Planet is not about choosing one architectural pattern in preference to another – SOA or EDA or WOA or Web 2.0. One of those can't possibly address all the requirements. But rather how to use SOA+EDA+WOA+Web 2.0+xyz together, and understanding how they relate, not compete.

Enterprise Architects will argue these are all just components of EA, and to some extent that is correct. However, the scope now needs to be broadened to SEA.

What we need to avoid is any sense that things just got more complicated thanks to the Smarter Planet. With the application of sound architecture, it ought to get a whole lot simpler.

Some of CBDI Forum's Architecture mashups,

• Extending SOA with Web 2.0 (free access on registration)
• Web 2.0 and Enterprise Architecture (subscription required)
• Event Driven Service Architecture (subscription required)

Microsoft Visio – Suitable for Modeling SOA and EA?

Over the last month, I have been looking at Microsoft Visio as a possible tool for modelling Service Architecture and other SOA deliverables and as a place to capture the Enterprise Architecture. This was prompted in part by a product report I have just completed on Orbus Software’s iServer product, which adds a multi-user repository to Visio.

Given the number of specialist modeling tools there are on the market, it is surprising how many enterprises we encounter that use Microsoft Office as their prime vehicle for capturing various items of metadata and producing the documentation and diagrams required to support their IT architecture and delivery projects. Requirements and specification deliverables are routinely documented using Microsoft Word, while metadata is captured as columns and rows in Microsoft Excel spreadsheets, and diagrams are constructed using Microsoft Visio (or even just Microsoft PowerPoint). However, there are many shortcomings to this approach in an enterprise context, and that is primarily what iServer sets out to address and I have examined in my report.

Until now, I had only been a casual Visio user. For simple diagrams we publish in reports, PowerPoint is sufficient, and also the format we provide to our customers. For more rigorous work – with our clients for example, or to produce our SAE Meta Model, then we use other UML modelling tools.

Once I started investigating though, I was impressed how simple it is to create your own stencils and templates, but moreover how straightforward it is then to connect instances of the shapes to items in a Microsoft SharePoint list. In the example below, I created a simple template for the Service Specification Architecture diagram we use in CBDI-SAE, and then linked it to a SharePoint list containing a catalog of Information System Services (TOGAF) which are classified by Service Architecture Layer.

Hence it would be straightforward to create a Service Catalog in SharePoint, and then visualise the architecture for the services in Visio. My product report looks at how to do this in iServer. Clearly that is a more robust solution than my simple SharePoint example. However, for anyone with SharePoint and Visio already at their disposal, all it takes is some effort on their part.

Hopefully I will find some time to work on a Visio Template and corresponding SharePoint Template for CBDI-SAE and make these available in the same way we have done with our UML Profile.

Let me know if that would be useful.

In the meantime, I am interested to know just how many folk are using Microsoft Office and Visio as their prime tools for capturing EA and SOA deliverables, and what your experiences are.