Tuesday, 16 July 2013

6 IT Trends & 15 New Habits for CIOs & Their Teams

The CIO/ITD In Crisis.

Harvard Business Review blogger, Jim Stikeleather, posted recently  The CIO in Crisis: What You Told Us - a few particular points caught my attention:

"The best executives I have met have had a great understanding of how to use technology to gain competitive advantage and improve operations. They also worked with the CIO to help them to understand the business. They worked together to identify the technologies that could improve the company's competitive advantage versus technologies that were needed to support the business. Once this was done, the executive leadership and CIO focused on implementing technologies that improve the company's competitive advantage".

"All the parts of the organization have to come together and build a common language to discuss their markets and their enterprise. They need to have a common appreciation of each other's purpose. The CIO must step up and mentor the C-suite on the potentials, possibilities, threats and opportunities of information technology..".

"If IT and the CIO come to the party talking like engineers, only offer convergent lines of thought (analytical, rational, quantitative, sequential, constraint driven, objective and detailed focus) and don't offer a more holistic, shaded divergent thinking point of view (creative, intuitive, qualitative, subjective, possibility driven, holistic with conceptual abstractions), then they have missed the point".

"The CEOs were actively aware, concerned, looking at alternatives such as chief digital officers, or creating "not-so-shadow" IT organizations under the CMO".

"For existing CIOs, ask yourself a few questions. Are you generating customer value? Are you (or do you have the potential to be) the best in the world at what you are doing? Are you required to do what you are doing? Using the answers to those questions, what do you need to stop doing, start doing or do differently?..". [see 15 ways to change the ITD's habits table later in this post].

In a similar vein, according to a recent CIO event run by Forrester Research: "The IT department of 2020 could disappear as a separate entity and become embedded in departments throughout the entire organization".

This article posits that the need for change is now undeniable, and that CIOs are looking for practical steps for creating new habits in their teams. These new habits, developed now, will help prove the continuing need for a central Enterprise IT Department.


History & Trends.

The demise of the IT Department is not a new  prediction, it was first suggested in 2004 by Nicolas Carr in his book 'Does IT Matter?' and again in 2007 when Chris Anderson published his ‘Black Wire – White Wire’ article. This post talked about how corporate IT was being over-taken by consumer-IT. Later, in January 2008,  Nicholas Carr famously pronounced “The IT department is dead” referring to the up-take of utility computing since his 2004 prediction. 

Since then, others made further observations about emerging IT trends that appear to strengthen those predictions. Today, around six hard trends are well established. They sit within an umbrella trend we described as ‘Externalization’ back in 2007. Later, in 'Flash Foresight' Daniel Burrus explains how he identified many of the established technology trends and why they are 'Hard' trends rather than passing fads. More recently,  in his book 'Agile Architecture Revolution', Jason Bloomberg talks about understanding the enterprise as a Complex System - a System-of-Systems. His book is architectural guide to help IT Departments respond to the Externalization trend and, at the same time, it highlights the need for a change in mindset within the IT community.

In parallel, John R. Rymer of Forrester Research coined the phrase 'Business Technology' (BT) to describe the ever-increasing reliance on information technology by businesses of all types to handle and optimize their business processes  and the need for a more integrated & holistic approach to the use of business-embedded information technology.  Here's what Wikipedia says about BT

"The increasing use of the term business technology in IT forums and publications is due to an emerging school of thought that the potential of information technology, its industries and experts, has now moved beyond the meaning of the term. Specifically information is seen by some as a descriptor not broad enough to cover the contribution that technology can make to the success of a business or organization".


Focus on Externalization and BT.


Acceptance of the Externalization trend, and a deep appreciation of 'Business Technology' theme, provide the canvas, on which, we can sketch-out the ways in which the IT Department must change to survive. Probably most importantly, the CIO needs to find the time to think strategically: from 'Whac-A-Mole-IT-Management'  to strategic, Business-Technology leadership. Thinking strategically means the CIO needs to develop a deep appreciation of  the various ‘markets’ his/her team serve, as both a supplier, and a broker of services, to those markets. Such markets exists within and outside the enterprise and are made up of customers, suppliers, intermediaries and other stakeholders. All with differing values and requiring different sensitivities to protect and enhance trust relationships.

How to prepare for the inevitable change.

At my current company, we use the 'BT' label help position our five-year vision & strategy. It helps frame the discussion about the many areas of change required: cultural, technological, procedural, organizational & regulatory. BT is not, however, a new name-tag for the IT department - it represents the new thinking required across the whole business. It might seem ironic, given the predictions, that it was our CIO who initiated the discussion - I suspect, however, this will often be the case: the CIO is frequently the only C-level executive who has a holistic understanding of both the breadth and depth of the business.

Back in May this year, I posted about the work we were doing to establish a BT Vision. This has since been developing gradually and is gaining acceptance across the IT senior leadership team, but more importantly, with C-Level executives.

Recently, I was invited to share, with a large multinational conglomerate, some of the more tangible changes we're implementing  Our vision & journey towards 'BT', and our response to the the 'Externalization' trend set the context for the discussion. Here's the list of 'contrasting behaviors' I shared: 

15 ways to change the IT Department's habits

Old Habits
 New Habits
1.The department of ‘No’
2.Products focus
3.Internal SLAs
4.IT Strategy
5.Cyber security tooling
6.CAPEX-first mentality
7.Solution-focused technology architecture
8.Product standardized IT portfolio management
9.Governance of large IT projects
10.IT Cost Centre management
11.Internal procedures & methods
12.'Family’ of IT vendors
13.Gadget-focused innovation
14.Periodic, internally-focused, measurement
15.Technology focus
1.The department of qualified ‘Yes’
2.Services focus
3.Services internal/external ecosystem –SLA-chains
4.Integrated BT strategy
5.Cyber security culture
6.Balanced, outcome-focused, investment
7.Adaptive, value-focused,  Enterprise Architecture
8.Principle-led architecture & standards-based integration
9.Company-wide, joined-up,  BT-governance
10.BT services broker, innovation-lead and advisory
11.Internal & external engagement
12.Consumer-driven, ecosystem of suppliers
13.Customer-story-based innovation
14.Constant, external & internal, feedback-loops
15.Focus on information value & risk

We've made good progress on many of the 15 points, but I'd say the most compelling for the business are: 1) The department of qualified 'Yes',  4) Integrated BT strategy, 5) Cyber security culture, and 13) Customer-story-based-innovation. I'm pleased to see these seem resonate with the observations made in the HBR article mentioned above.

Monday, 17 June 2013

VPEC-T: What Works & What Doesn't?

It's been over 5 years since Carl and I stumbled upon VPEC-T thinking, whilst working with the UK's Criminal Justice organisation. We've both enjoyed numerous conversations with people who tell us that they've found it useful,  in a wide range of circumstances.   I'm interested, however,  in hearing more about how VPEC-T has been applied,  and in sharing these scenarios publicly, so that others might find their own way to apply the framework. I'm particularly interested in the circumstances which led to its use, the method used to start the VPEC-T conversation, other models/canvasses that helped frame the conversation, insights that emerged and, last but not least, what worked and, more importantly to me, what didn't.  Feedback on the use/usefulness of VPEC-T has always been difficult: the nature of a framework that examines sensitive issues, like Values and Trust, becomes a barrier to public feedback. In the spirit, however,  of openness and sharing, but recognising such sensitivities,  I'm not asking anyone to disclose specifics, instead, Im asking for more general,  anonymised, observations. 

Here's the top 6 questions I'd like to ask:
  1. What were the general circumstances that led to a VPEC-T analysis?
  2. How did you bound the conversation - did you use a model or canvas to help focus-in?
  3. How did you conduct the VPEC-T analysis - a workshop (how many participants?), 1-on-1, or other?
  4. Which dimension (i.e. V-P-E-C-T) did you start with and which dimension(s) stimulated the most insights? 
  5. What were the main barriers to getting the conversation going or issues that became a stumbling-block? How did you overcome?
  6. What was the nature of the output/insights from the session and where/how did VPEC-T add the most value in surfacing them?
Not surprisingly, I've used VPEC-T in many different scenarios, sometimes explicitly, and sometimes  as a, non-disclosed, mental model, for analysing  at a problem or opportunity.  The most valuable feedback to me, however, has always come from others - their unimagined (by me!) challenges and circumstances. Ever since my original blog post in 2007, I've been keen to share and develop the thinking publicly (despite pressures to do otherwise!). Can I encourage others to do the same?  I guess I'll see.  Any better ideas on soliciting feedback always welcome! (thought to self: I wonder if I could find a way to use Dave Snowden's Sensemaker tool?).

For the latest developments in 2017 please take a look at the VPEC-T Metro Map.

Monday, 27 May 2013

What Happened to the Fine Art of Business Analysis? - Revisited 2013

Back in 2008, I wrote a paper on Business Analysis. Recently, I've been revisiting this subject in my day-job and this made me realise how little things had changed and inspired me to write this post, which is, basically, the original article re-written, with additional thoughts (in italics).

Wednesday, 22 May 2013

Searching for Agility and Industrial Strength? - Part II

This is Part 2 of a discussion started in my last post. The discussion is around the need for Agile, Resilient and Robust systems within an Enterprise Architecture. This post is a detailed response to Adrian Apthorp's  comments and, more generally, comments from Chris Bird and Tom Graves (Thanks all).

Adrian said:  At the recent Integrated EA conference Tom Graves spoke about the notion of backbone and edge. The backbone being where the core robust and resilient elements sit and edge is the playground that enables agility. This division in itself implies / demands different 'engineering' practices to deliver backbone vs edge elements - may be one clue for the organisation of IT to deliver against these different demands.

I like Adrian's words: "edge is the playground that enables agility" and would add: "edge is also the playground that nurtures innovation". This is probably, in part, due to my frustration with trying to explain the true nature of innovation and to get people to understand that new IT gadgets do not bring about innovation on their own. Innovation is not something bought, it is something grown within the business by allowing people to experiment in a 'Safe-Fail' environment.

Adrian said:  The key question of course is how do you determine what sits in the edge and what in the backbone? This partitioning is of course down to architecture, but how do you go about it?

It's interesting that you should use the airplane example, certain aircraft (e.g. 747) are a good example of an architecture that has persisted over time, but virtually every part has changed. This illustrates the fact that even the robust and resilient elements change within the context of the whole. Don't forget the architecture of the aircraft goes beyond the airframe to include the design of airports etc.

Adrian also said:  The overall architecture of your system of systems provides the basis of the backbone and is populated by elements that don't change or have low rate of change. Chris Bird talks about shearing layers, I like to think about pivot points I.e. the stable parts of the architecture that change can be managed around. 

To put it in business terms these are the elements that define our business and if we change them we're in a different business or at least have major upheaval? 

In reply to Adrian's point that everything can change, even the more stable aspects of a system over time, I agree that entropy applies to everything but how we deal with change can differ significantly based on business needs: response to market, customer safety,  brand  et al. But, the context of 'the whole' in question must not be lost or confused. To this point, I wouldn't say that the architecture of the Complex System called  'aircraft' includes the design of airports, per se, rather, that the system 'aircraft' exists in a environments that include 'airports', 'weather', 'tourism' etc. Of course, one can see these as an infinite Russian-doll-like of Systems-of-Systems, but this rapidly becomes unhelpful. 

I believe the most fruitful to define the boundary between a 'System-of-the-Business' its environment by a current and planned view of the business. That is, the 'System-of-System' that is defined by the Business Operating Model, its Enduring Purpose (relates to the 'pivot-points' described by Adrian) and the current Centre-of-Gravity of the executive board (the strategic things they currently care about the most). This way, the boundary for the architecture can flex to encompass those aspects most germane - so if, in the analogy, understanding the deeper relationship between the system of 'aircraft' and the system of 'airport' is important to the future architecture, it's included.  Under different  circumstances, however,  it may be more important to understand the system of 'aircraft' in the context of the system of 'tourism', in which case, the system of 'airport' much just be recognized as a set of environmental constraints, with greater emphasis on the system of 'tourism'. End of analogy!

I find it useful to explore the Agility, Resilience and Robustness as potential 'Design Principles' for different aspects of the architecture. For example, it may be  that Agility is a core principle for mobile apps and SaaS. In contrast, however, Robustness might the most important characteristic of a system that has life-impacting consequences in the case of failure. 

It seems that the need to design Resilient systems rarely understood today but will become increasingly important. I believe that such systems require a meta-architecture (as described in Jason Bloomberg's book): an architecture that is specifically designed to cope with multiple business purposes that cannot be fully described at design time but should not be regarded as be designed/developed in a 'agile', experimental fashion.  An example of this was DHL's Track & Trace architecture designed in the1990s. This was designed as a set of simple services with flex and adaptability - this was the key to adoption through local adaption and extensibility and, ultimately gave way to local 'agile' innovation. While  a core set of 'Global' tracking checkpoints were defined the meta-architecture allowed for 'Local' extension without corrupting the core standards. This also had the effect of 'protecting' other core 'backbone' systems that produced, consumed and transported shipment status information.

Using Tom's definition of 'Edge vs Backbone', it seems to me that Resilient systems sit in the land between the two. They are the 'elastic surface' that allows for 'edge' agility and that acts as a membrane that helps protect the 'backbone'. The need for Resilience, in my opinion, was always a key objective of Service Oriented Architecture.




Saturday, 18 May 2013

Searching for Agility and Industrial Strength?

Many organizations are looking for ways to improve business agility and innovation enabled by information technology. Moreover, they are concerned about the increasing Cyber Threat, to core business systems, that comes with new technologies.

The challenge for the CIO and his/her team is to find a way to strike a balance that preserves the integrity of 'mission-critical' systems, but at the same time, allows for agility, flexibility and creates the conditions for business process innovation.  In short, they need to create an ecosystem that, on one hand, provides an environment that is inherently adaptive, one that allows for emergent behavior, and on the other, protects the business operation. Such an ecosystem is described in the latest book from Jason Bloomberg: "The Agile Architecture Revolution". In it, he refers to concepts from Complexity Science and suggests that organizations are best understood as a Complex System of both technology and people. The System of the Organization is, in fact, a System-of-Systems which interact to deliver business outcomes in the form of products or services.

An analogy with a commercial aircraft as a 'Complex System' or 'System-of-Systems': the many sub-systems, each have a  well-defined purpose and expected outcome, and together, work in concert to deliver a safe and commercially competitive experience to the passengers. However, one sub-system can have very different core characteristics from another. It is clear, for example, that a core characteristic of the undercarriage with be strength - it is therefore a 'Robust System', a system that is design to be 'Fail-Safe'. In contrast, the defining characteristic of the wing will be it's ability to flex (else it would snap off!), hence the wing is a "Resilient System', but it is also designed to be 'Fail-Safe'. Contrast, those two sub-systems with the 'Seating-and-Entertainment' system: an important feature of this system is the ability to change it quickly to keep up with competitive in-flight experience demands and allow for re-configurability of the cabin space. 

The need for 'Business Agility' in this area was demonstrated, when Cathay Pacific introduced new seats in the economy class cabin. They received overwhelming  feedback that their new seats were uncomfortable and many passengers complained of back problems after long-haul flights. Passengers started to vote with their feet. While this was clearly and expensive lesson in 'User Experience'  testing, commercial disaster was averted by their ability to react quickly. This was only possible because the sub-system in question had been specifically designed to be easily swapped-out - it is an inherently agile system that can be described as having a 'Safe-Fail' quality.

Going back to the organization as a Complex System, identifying the fundamental characteristics of the sub-systems of people interacting with technology within an organization is critical to understanding how the correct balance of agility, robustness and resilience is achieved across the whole the enterprise. As has been said many times before, one-size-doesn't-fit-all! (i.e. we're an 'SAP shop' so let's use their products wall-to-wall!). Understanding that starts with knowing the outcomes to be delivered by each sub-system and how they work together to deliver safe, secure, and at the same time, flexible systems.. In the context of Business-Technology, this understanding can only be gained through insightful and informed, whole-business design, that understands the behavior of the business as a combination of people, process and technology. This, in my opinion, should be a primary focus of Enterprise Architecture. Critical design patterns are often overlooked when the notion of Analysis and Design is limited to project-led solutions, that at best, describe the desired features and functions of a narrow 'User' community. This has not been helped by the IT industry's constant ability to misappropriate such terms as Agility, Service Orientation and spin-off into, often faddish, ill defined concepts like Cloud computing and BYOD.

Like Mr. Bloomberg, I believe it's now time to re-think what a Business-Technology Architecture needs to deliver. Many of the original concepts of the thought-leaders in Enterprise Architecture are still very relevant -  Jason makes that point the the original idea behind SOA (Component-Based Architecture) are even more relevant today and he airs his frustration with IT software vendors' re-badging of middleware as 'SOA' - all but destroying the original concept. There are many other examples. However, he and are are not alone in our belief that understanding organization as a 'Complex System' is vital today. Others  like Tom Graves, Richard Veryard, Chris Bird, Darrach Ennis, Simon Wardley and Sally Bean have been banging this drum for many years!  

This is a big subject  and I recognize that this is a very 'What' rather than 'How' focused post. I'd be happy to take the discussion further and share ideas on how I'm starting to make-sense of the Business-Technology challenges I'm facing in my day-job - ranging from core SCADA systems to Consumer-led IT and the 'Cloud'.  As always, I'd be delighted to hear your views, builds and challenges to this post!

A much earlier related post here

Update:
This discussion continues here based on comments below.


Thursday, 9 May 2013

One Picture For All: Visualising Business-Technology Strategy



In the process of developing a Business-Technology Strategy, I wanted to create Gamestorming-like approach to help position business drivers, technology trends and IT responses. I've been reading 'The Agile Architecture Revolution' by Jason Bloomberg (highly recommended!) - I particularly was inspired by the Zapthink Poster therein. But given the different audience, I need a more Business-focused that might eventually  evolve into a info-gram poster ( I recognise it's more Mindmap than info-gram in this version!). The aim is to create a tool that will help frame and stimulate discussion with business people and technologists that becomes the core of a Business-Technology strategy. Subsequently, the developed artwork (or simplified versions) might become a commonly understood reference model for communicating the strategy - maybe even a piece of office wall-art!

Hopefully, the diagram I've developed is self explanatory, however,  a few words of explanation might be helpful:
  1. The star at the centre should be the "headline" of CEO's strategic direction over the period (e.g. to 2018) or similar agreed at the C-level.
  2. The items in blue circle are the specific business drivers - the things C-level care most about!
  3. The six labelled outer sections are general technology trends that the CIO/IT team believe are most pertinent to the business.
  4. The items red circle are the IT responses to both the inner business direction & drivers in the context of the technology trends.
  5. In this example, the buff coloured encircling arrow represents the importance of "Big Data" overall and how data-driven decision-making will be fueled by other technology trends (I guess this might vary from business to business).
  6. The orange "explosions' are specific predicted events within a trend, the yellow "post-its" are  aspects/observations and the green "scrolls' represent particular milestones or goals.

I'd welcome any thoughts, builds or alternative ideas - maybe you have a better approach or can offer something to augment?

Oh, and one more ask, if anyone knows of a low-cost way to make the poster less "PowerPointy" and more "Infogramy", please Tweet me (@taotwit) with suggestions - thanks!

You can download a more readable .pdf version below. Let me know if you'd like an editable .ppt version via email.

Thursday, 21 March 2013

TOGAF Good or Bad? - Definitely Ugly!


I'm struggling with the value of TOGAF on my current assignment.

Background:


·        We have a need to develop architectural thinking up the 'food-chain' to the C-level to help inform business strategy.


·        The IT Leadership want to focus on: agility & resilience (fast response and ability to thrive under constant change), security, value-for-money and continuously improving User Experience.

·        Unusually for a private company, we are not currently focused on competition (we are a monopoly) nor inefficiency (labour cost - we rarely 'let people go').


·        We have established business-engaged governance mechanisms around Cyber Threat, however, there's cultural resistance to Western-style Governance practices and methods in other areas.


·        The IT department is mostly seen as a Cost Centre, although we are making some progress here.


·        English is the second language for the vast majority of our employees.


·        Experienced Enterprise Architects are rarer than hen's teeth in Hong Kong.


·        A few on my team have been trained and 'Certified' in TOGAF (mostly before I joined) but they have not actually practiced EA (for a wide variety of reasons) since attending the course.


Observations:


·        TOGAF is hard to comprehend for those whose 1st language is English, so it's an even greater challenge for my team.


·        TOGAF just tries too hard and ends up failing on a few counts; it's too comprehensive to be a usable framework and not specific enough to be a methodology. It's almost a philosophy, but a very incomplete and, at times, dangerously misleading one. This is very hard for my team to make sense of and I find myself having very long conversations with them where we end up agreeing that we reduce or focus on one or two of the TOGAF concepts (usually around a deliverable).

·        TOGAF doesn't seem to help very much when it comes to the challenges we face around Consumer-led IT.



·        TOGAF does encourage SOA, that would help our agility & resilience goal eventually, but we're quite a way from developing a genuine component-based, shared-services architecture due to the business organisation, culture and funding mechanisms. And we can't wait for those to change to be able meet our agility & resilience needs.


·        It’s fair to say, TOGAF training does help introduce newbies to some important EA perspectives and does help with common terms and concepts, but it requires a lot of additional buddy-work with an experienced architect to become useful and, what's worse, it conveys the wrong message; 'Enterprise Architecture is complicated and requires a high intellectual capacity to understand'. The latter being the absolute opposite of what I need to convey across IT and the business; 'Enterprise Architecture is about joining-the-dots and making things simpler to understand'.


I do continue to put my team through TOGAF Certification. Why? It's the only credible option here getting newbies up-to-speed on the basics of EA/SA and it helps my staff build their CVs (which is important). I just wish there was a better option that was both less and more:



and


  • more - on the basic mentality required of of an EA (e.g ability to abstract) and why all organizations take a different approach to architecture based on culture, maturity and business priorities.


I sometimes wonder if the authors of TOGAF are motivated to make it more understandable, or, as seems to be the case, keep it obscure and arcane. It certainly felt that way when I was exposed to IAF (Capgemini's Framework) and its zealots for the first time.

An aside here: in a recent chat with the Chief Architect in a well-known travel company, I said I needed the 80 page version of TOGAF - he laughed and responded that he'd implemented an 8 page version! BTW: all his architects are native-English speakers hired in from abroad.

Sunday, 10 March 2013

Enterprise Architecture: Charting the Journey to Business Value

Enterprise Architecture: Charting the Journey to Business Value by Nigel Green

VPEC-T Pesentation to SCiO

VPEC-T A thinking framework as presented to ScIO by Nigel Green

2013: The year the Internet-of-Things takes-off?

I’ve been reading a lot about M2M/’The Internet of Things’, many pundits believe 2013 will be the year the concept finally goes mainstream – it’s been a while since its inception in the late ‘90s!

I have to say I’m among those believers, but I can see a lot of dust in the air before we get to anything that might resemble a ubiquitous eco-system for all-things-Smart.  Here are a few reasons why:
  1. Open standards for connectivity and data interchange will take a while to agree. Having said that, I don’t think Businesses and Consumers will want to see proprietary platforms (the nightmarish vision of an ‘ITunes-for-M2M’)!
  2. Object Identity standards: Everyone seems to be talking about IP v6 for this purpose, very few in the ‘new wave’ of M2M seem to be aware of the Electronic Product Code(EPC)  from GS1/EPCGlobal. I’ve not been close to EPC developments since 2004, but a lot of good thinking was done that tackled many of the issues yet to be resolved in the M2M world – not the least of which, delineation between the identity of the object and the identity of an object’s interface(s) - a debate that continues around the use of IPv6 for identity.
  3. Who will lead the M2M market? Or should it be markets? Will it be consumers leading with ‘Home & Personal’ gadgets , as Alex Hawkinson, founder/CEO of http://smartthings.com/  believes. Or could it be led by large Energy providers with their Smart Grid projects – often subsidized and encouraged by governments? Or will the Telco’s and Network equipment guys to fight back?  Many telcos (mostly outside the US) have been dabbling in this space for ten years or more – I worked with BT on an early Auto ID service back in 2003. Some Telcos have continued to invest, for example; Telefonica recently announced their proprietary ‘Smart M2M’ solution and clearly have global ambitions in M2M services. Meanwhile, the likes of Alcatel-Lucent, Ericsson, HP, Juniper Networks, Motorola Mobility, Qualcomm, Samsung and Texas Instruments are rallying around the OneM2M movement (http://www.onem2m.org). Not to forget Cisco’s long standing ambitions in this space.
  4. Who will lead Enterprise-quality data integration? This would probably include correlation, aggregation and other, signal-based & enterprise app generated data. Think multi-source, data ‘mash-up’ services. This feels to me that this could be the sweet-spot for the more ‘application-and-data-as-a-service’ focused Cloud vendors. Or could be a SI or large software vendor play (SAP or Oracle spring to mind).
  5. Which roles will the Complex Event Processing (CEP) platform vendors adopt in the M2M eco-system? How far can we expect the likes of TIBCO, Oracle and IBM to push M2M/CEP/Big Data combinations within the Enterprise?
But despite the above challenges and battles yet to be won, I do believe we will see far greater deployment of ‘Smart’ things over the next 12-24 months than at any time since those early days of Auto-ID. My bet is that both Smart Grid and consumer-led lifestyle solutions will lead the early adopters.  Don’t, however, hold your breath for pan-industry standards at anything above low-level communications protocols!