Enterprise Architecture is pretty well understood as to what it means in respect of IT application integration, and even has some industry wide methodologies like TOGAF. Talk about Architecture and the Web and there are more variations, but there are some strong underlying principles that are respected. Now reflect on IoT, supposedly a ‘any to any’ Internet environment of event driven connections and insightful outcomes. So where is the commonly stood architecture to support this?
The IoT problem is not a lack of standards, even for Architectural approaches, its too many ‘standards’, as the ubiquitous nature of IoT has led to all standards bodies believing that they must extend their existing work to include IoT.
The result is the proverbial story of the person asking directions to a specific destination. Each successive person states that they don’t know the way from where they are both currently standing, and can only provide directions from another starting point. Currently with IoT standards generally and Architecture in particular each standards body is defining their new standard from the direction of their non-IoT existing focus. There is little, if anything that connects these efforts, currently.
The IEEE started well with an excellent definition of the requirement for an industry wide Architecture rather than the fragmentation of industry sector focus activities. The resulting working group contains many important players such as the Industrial Internet Consortium, security experts Kaspersky, as well as significant Enterprises such as Schneider Electric. Undoubtedly in time this will prove an important contribution, but reading the report from the last Working Parties meeting suggests there will be little to help those planning deployments in the next year.
Fortunately there are some more practical short-term reference definitions of the technology stacks being suggested, and that includes two presentations on Slideshare. A November 2014 presentation by the API solution director of the MuleSoft Open Source API project has some excellent technology stack diagrams that help to grasp conceptual level principles. The proposal there should be a ‘hub of hubs’ connecting everything makes sense to MuleSoft as an API hub provider. For immediate deployments API centric integration is necessary, but it will introduce longer term scaling questions.
As a side comment; It’s necessary to check dates on any paper, blog, or presentation, as the rapid development of IoT technology and products is quickly making anything over a year old potentially out of date.
An alternative, and frankly a thought provoking approach, as it focuses on an IoT architecture for services and distribution by invoking the BSS model popular in the telecoms industry comes from Charles Gibbon in December 2014. However the question that this presentation raises is should IoT be a Server side driven architecture? Certainly in the context of Mobility and Mobile phones this makes sense, but that assume all IoT devices are firmly ‘owned’ and ‘managed’ centrally.
Public service IoT devices as an example may need to be both promiscuous and allow ‘operational management’ by the event process. This suggests that the Event Service will be more important as the focal point in the architectural model.
There are plenty of initiatives working on Industry sector architectures that could be included in a general list of architectural developments. Oddly the focus always seems to be either the Network, or the Protocol, but not on the overall architecture. Any mention of integration architecture is always referred to as needing a Gateway or an API Hub.
Reading through the various Working Groups leaves the impression that every current approach to IoT architecture starts with a proposed technology answer and works backwards to define the necessary architecture. Strangely absence is any reference to the business requirement definition. What has happened to Enterprise Architecture methods such as TOGAF that start with a conceptual architecture related to the business requirements?
The basic challenge for IoT Architecture arises from its loose coupled, stateless and decentralized nature as befits an Internet based technology. Enterprise Architecture as used in the client-server IT environment reverses these statements being; close coupled, state-full and centralized. The two environments simply don’t resemble each other enough for any easy transfer of methods as the last few years of arguments about REST alone testify.
If you are currently contemplating a significant IoT deployment then none of the above offers very much help so just adopting a good basic architectural approach to work methodically seems best. The Bredemeyer ‘Visual Architecting Process’ for Software Architecting defines the stages of Architecting a solution with no dogma about technology or products. Populating the stage one Bredemeyer Meta Architecture with the technology stacks mentioned above from the SlideShare is a useful start.
Now comes the question of the Business Requirement and that’s the difficult part! Does the conceptual architecture work from an event or from the resulting insight service outcome? This hits the real question of IOT – defining what is a beneficial outcome!
The notion that future Enterprise architects will focus on outcomes was current this last summer, but unfortunately its not so easy to take this statement into reality.
The nearest approach to this was Service Oriented Architecture not new, but those who were most involved in SOA seem to be least involved in IoT. Back in 2007 Stefan Tilkov wrote a much-applauded article entitled ‘The Ten Principles of SOA’ in which he stressed the principles of Loose Coupled Services. Some eight years later and facing the challenges of a loose-coupled IoT architecture there are some strong similarities.
There is also one big difference that hits almost anything that was said before 2010 and lies right at the heart of the IoT architecture problem. IoT is about ‘Interactions’ more than Transactions, and most Architectural principles concentrate on Transactional data.
That’s a challenging statement and really should provoke some comment! Yes, the value from IoT comes from a Business valuable outcome, but no that’s doesn’t make it a Transaction. But what changed around 2010 that makes this a turning point? The answer was arrival of Social Customer Relationship Management as the new Internet based Social Tools arrived supporting interactions with customers. Before this Customer Relationship Management was/is a traditional IT Enterprise Application focused on Transactional Data. The difference is hugely important and in 2010 the rise of Social CRM was causing similar challenges to those of IOT today.
Read the following from an article published in August 2010 entitled Interactions with Transactions; Understanding Social CRM and try substituting Enterprise IT for CRM and IoT for Social CRM.
CRM was focused on transactions; social CRM is focused on interactions with transactions oftentimes being a byproduct. Social CRM didn't come about because of technology, but as a result of cultural and behavioral shifts, technology simply allowed customers to have a much louder voice
Social CRM was as radical a change five years ago as IoT is today in it’s competitive impact on business models and of course technology. The result was the rise of Salesforce based on completely different principles and products. As Internet/Cloud based capabilities have become well established for a wider range of ‘new’ business valuable activities Salesforce has become a well recognized Enterprise enabler.
There are very strong similarities between deploying and operating Social CRM for Business Value, and at this stage of the development, deploying IoT for its Business Value.
Social CRM provided enterprises with an external visibility into their markets via actual and perspective customers using the ubiquitous connectivity and technologies of the Internet. IoT is in effect completing the external visibility of an enterprise by adding machine and event inputs to complete the view.
At this point the conclusion of this article must be obvious, if you use Salesforce for your Social CRM and other Internet/cloud based initiatives then use Salesforce for your IoT initiatives too. That’s a pretty major statement to make so the importance of this blog was to highlight exactly why this is the conclusion. In time standards will undoubtedly arrive, but it’s going to take a long time, and a large market presence of a defacto approach usually results in a role in the resulting standard.
Right now in some sectors there isn’t time to wait, a decision needs to be made as to the deployment approach in more than a few enterprises. Understanding the similarities as well as the ‘smart’ integration possibilities between Social CRM and IoT clarifies the options. Quietly, and effectively, Salesforce have been building a strong set of IoT capabilities complete with integration with their ‘action’ suites. It’s a good time to take advantage and quick business value from IoT.
A further article in this series on understanding and using IOT will introduce the topic of Business Requirement capture and definition for IoT Business value.
