The Internet of Things

The Internet is, of course, now universal, with over 625 million hosts currently registered according to the Jan 09 ISC Domain Survey. Even with the advent of Internet enabled end devices such as 2.5/3G mobile phones, the majority of these connections will be computers of some kind.

But, what if you could connect almost any device to the Internet, medical devices, cars, toys, weather stations your home even? The possibilities for opening up new classes of applications are mind bloggling. Since the early days of the Internet there have always been people connecting 'odd ball' devices to the Internet, the Internet fridge is just one example.

Pretty much any electronics hobby enthusiast can rustle up a circuit with some form of sensor board and wire it to an Internet connected PC. Also, numerous companies have manufactured data loggers and instrumentation devices for years, and most of these can connect to PCs. The key to enabling this vision is standards and interoperability. Sun's approach does just that, focusing on bringing together Open Source standards and hardware, Java, ad-hoc networking and the Internet.

This is where Sun Microsystems is heading with its Sun SPOT vision. Sun SPOT is a SunLabs research project that kicked off in 2003. This work has led to Sun selling a Sun SPOT Developer Kit to the public, mainly to drive interest in potential applications. The video below outlines Sun's vision.

The key innovation is not only have Sun made the SDK Open Source, but the OS (Squawk) and, believe or not, the hardware. This means that anyone's free to download the SunSPOT bill of materials, circuit designs, schematics and drawings, send them to an outsource electronics fabricator (of which there are loads who will build you small batch runs) and you can have your very own custom device.

One of the major advantages of the platform is the fact all development is done in Java. Anyone who's had experience of developing for embedded systems knows that specific architecture, software engineering and programming skills are required. Sun have put effort into ensuring that any skilled Java Developer can pick up a Sun SPOT device and get going straight away without any embedded systems background. It's important to note that Sun SPOTS are much more that your typical data logger device, they're a computing platform in their own right. The ability to create ad-hoc mesh networks of these devices, coupled with Agent-Based software architectures is what makes these devices so unique.

So what are the potential applications. I work in the Defence industry and I can see applications in military and security. For example, imagine parachuting dozens of these devices across a theatre of operations, each fitted with an array of sensors. They would also have the ability to network with each and other military systems when they are in range, for example warning a squad of troops of potential suspicious activity in an area.

Applications that require remote data acquisition and logging are also obvious candidates. SunLabs have an experimental environmental monitoring solution called Canopee deployed to Kalakad Mundanthurai Tiger Reserve (KMTR) in India.

Sun are hoping to repeat their successfully strategy of getting Java onto just about any device you can think of, from mobile phones to digital tv set-top boxes. Their goal is to open up and accelerate the market for wireless sensor based applications by standardizing the hardware and reducing software implementation effort. It will also be interesting to see how this technology starts to converge with RFID.

Currently, most applications are in Universities and Research Labs, but given the momentum behind Java and the Open Source nature of the whole platform, I believe we could soon be seeing SunSPOT applications opening up in the near future.

Scaling Software Design Patterns to the Enterprise

Much has been written on Architecture Styles and Software Design Patterns. Concepts such as coupling, cohesion, abstraction, modularity and information hiding are all well understood by Developers and Architects when designing software systems. There are volumes of best practice and guidance widely available to solve most software engineering problems.

Where there's less established guidelines and practice is in large scale Enterprise Architecture design. In particular the eternal problem of partitioning business services and functionality and allocating them to systems. Most Enterprises are complex, processes vary by business unit and function and all have a legacy systems landscape that has grown over time. Also, the the biggest issue is change, organisations change to meet new customer needs and markets, or when acquiring and disposing of operations. Enterprise Architectures struggle to keep up with these changes, no sooner have you finished a major ERP implementation programme, re-engineered numerous business processes, than the Enterprise reorganises, divests operations and places new demands on systems.

What I have noticed in my experience of large Enterprises is although reorganisations and business change occurs, there usually is a minimal cohesive business capability below which cannot be reorganised. For example, take a capability such as purchasing, managing customer orders, demands, purchased orders and the purchase-to-pay cycle does not make sense to split apart as the business service loses it cohesion. The capability would become inefficient as it far too frequently communicated with another separately managed function to fulfil it's service requirements.

In a lot of ways optimum organisational services or functions are designed in a similar way to a good OO design following class responsibility collaborator (CRC) principles. CRC seeks to ensure that responsibilities of any given class are the most appropriate given the other classes it collaborates with to achieve a use case or scenario. The goal of CRC is to analyse a class and it's adjacent classes, understand what they each need to know about themselves (responsibilities) and how scenarios drive different collaborations between then. In a complex domain, it may not be obvious what methods belong to what classes and allocating a method to the wrong class can often mean an overall sub optimum design. Also, knowing the frequency and nature of collaboration between classes reveals the cohesion between them and ensures they are deployed into the same components. The goal is to achieve high levels of cohesion of classes within components while maintaining low coupling between components.

Example CRC Cards for the classic Model, View Controller Pattern

If you scale this up to business and system components you essentially have the same problem, So to maximise the flexibility of the Enterprise Architecture, the goal is to align the business process and service cohesion and coupling to the systems cohesion and coupling, with the aim to create self contained highly cohesive autonomous business and system services. In a sense you can draw analogies between system classes & components and business processes and functions.

To provide a real life example I was involved in a project to implement a supply chain solution which was to roll out across multiple business programmes. When we came to one particular programme it had an existing supply chain system, but because the particular COTS application they had been using had engineering parts and document management functionality, they had started to embed these capabilities into their supply chain processes. These processes had become engrained and stakeholders were reluctant to re-engineer and move the document management and engineering parts functionality to other Enterprise wide systems. Essentially, if you examined the business responsibilities and collaborations between purchasing and engineering, they had unknowingly created a very low cohesion supply chain services that had tight coupling to an external capability. Hence 'breaking apart' the process and systems proved extremely difficult.

When an examining an overall Enterprise Architecture, the goal should be to create a set of as autonomous and cohesive business and system services as is feasible. This is difficult to do and requires strong IS governance and stakeholder support. This is also challenging when dealing with COTS applications. I often see COTS applications in Enterprises as a set of overlapping functional components that could be visualised in a venn diagram. The battle is to gain agreement what COTS component should be used for what capability. For example, most ERP solutions have a Document Management module that tends to tightly integrate with the other ERP modules, allowing associations between business objects and documents. Most organisations, though, produce more documents outside of core processes being support by the ERP, therefore Document Management should be regarded as an cohesive Enterprise capability in its own right that communicates with many other parts of the organisation. Attempting to mandate the ERP as the Document Management system would exclude numerous people in the organisation who needed document management yet never touched the ERP system in the course of their role. Result, probably the vast majority of documents being managed outside of a formal system or the Enterprises document management capability distributed across multiple systems.

If you can get the Enterprise Architecture 'assembled' from these highly cohesive components, I believe there's a greater chance of being able to provide flexibility, agility and responsiveness to change, and that is what all CEO's what from their IT.

For further reading, I recommend an excellent article by Alistar Cockburn on Reponsibility-Based Modeling. I'd also recommend you read the classic OO book by Rebecca Wirfs-Brock Object Orientated Design: a Responsibility Driven Approach.