The Next Big Thing
Posts about next generation technologies and their effect on business.

IoT model update from the one I used 4 years back...

Back about four years ago, I used a model to think about machine-to-machine (M2) from a holistic perspective. Today, this would be viewed more through an Internet of Things (IoT) lens. In talking with some others last week, it seemed that the simple progressing from sensors all the way through action is still valid but may need to be expanded a bit.

Internet of things model.png

 

In really starts with the ‘thing’ that has been tagged (and its sensors and controllers). There is also a supporting device management layer that adds security, power management and other fleet management features. I didn't really show that the first time.

 

Data collection continues to have integration capabilities but the analytics layer needs to add more context and pattern recognition than just traditional analytics. There is an automation layer that rides on top that performs a number of the action oriented features.

 

I didn’t really think about the management layer that is inherent in the approach, even though some functions may only be useful for a subset of the environment. A pluggable set of standards is needed to minimize the complexity.

 

The Internet of Things will require a significant degree of autonomous control. It can’t be as needy as the tools we’re using today – crying out for our attention all the time.

 

IoT standards war begins

tug of war.pngI seem to have done quite a number of blog posts in the last month related to the Internet of Things. I just noticed that there have been numerous announcements about standards efforts. This may have spurred me on. 

 

There are a number of them, but the three I’ve seen the most about are:

  • AllSeen Alliance that supports the open source project AllJoyn that provides “a universal software framework and core set of system services that enable interoperability among connected products and software applications across manufacturers to create dynamic proximal networks.”
  • The Open Interconnect Consortium with “the goal of defining the connectivity requirements and ensuring interoperability of the billions of devices that will make up the emerging Internet of Things. “
  • And Google (not to be left out) has defined Thread. Its goal is: “To create the very best way to connect and control products in the home. “ These devices all run over IEEE 802.15.4.

The IEEE has its own set of IoT standards efforts, but those haven’t been getting the press as the recently announced ones above.

 

It is clear that IoT needs standards, but if it is too fragmented there will be no standard at all.

 

Hopefully this will shake out soon, since standards will help make the services and the software needed that actually provide the value for the end consumer.

 

Is an Agile Architecture in your future?

agile architecture.pngA few weeks back I did a post on agile development and that got me thinking about the future of architecture and the need for agile architecture.

 

The same pressures of shifting needs are present at the macro level and should affect the creation and use of architecture work products – although since it is architecture it will be a bit different than agile development.

 

Some of the same principles apply:

  •          People – Architecture lives at the intersection of business and technology. People are at the focus of that intersection, not technology. Architectural efforts should focus on the effect upon the people involved. What needs to happen? How will it be measured? These factors can be used to make course corrections along the way – once you realize that an architecture is never finished. If it doesn’t deliver as expected, change it. Make the whole activity transparent, so that people can buy in, instead of throw stones.
  •          Continuous change – When you begin to think of the business as dynamic and not static, the relationship with the real world becomes clear. In nature those species that are flexible and adjust to meet the needs of the environment can thrive – those that can’t adjust die off.
    Architectures need to have standards, but it also needs to understand where compromises can be made. When talking with CIOs the other day, it became clear that ignoring Shadow IT efforts doesn’t mean you will never need to support them. It is better to understand and facilitate their effective use (through architecture), rather than try and stand in the way.
    In a similar way, the link between the agile projects and the overall architecture need to be recursive. Building upon the understanding that develops. The architecture does not stand alone.
    Architecture development can also have short sprints of understanding, documenting and standardizing the technical innovations that take place, while minimizing technical debt.
  •          Focus on business goal based deliverables – Over the years, I’ve seen too many architectural efforts end up as shelf-ware. In the case of architecture, just-in-time is probably the most effective and accurate approach.
    If the architecture work products can be automated or at least integrated with the tooling used in the enterprise, it will be more accurate and useful. The concept of machine and human readable work products should be part of any agile architecture approach.
    From a goal-based perspective, the architecture needs to understand at a fundamental level what is scarce for the organization and what is abundant and then maximize the value generated from what is scarce – or at least unique to the organization.
  •          Good enough – Don’t let the perfect architecture stand in the way of one that is good enough for today. All too often I’ve seen architecture analysis go down to 2 or 3 levels of detail. Then people say “if 2 is good, let’s go to 5 levels of depth.” Unfortunately, with each level of detail the cost to develop and maintain goes up by an order of magnitude – know when to stop. I’ve never seen a single instance of where these highly detailed architecture definitions where maintained more than 2 or 3 years.
    The goal should be functional use, not a focus on perfection. Architecting the simplest solution what works today is generally best. If you architect the solution for something that will be needed 5 years out, either the underlying business need or the technical capabilities will change before it will actually be used.

None of this is really revolutionary. Good architects have been taking approaches like this for years. It is just easy to interpret some of the architecture process materials from an ivory tower perspective.

Rethinking future services and the application portfolio

applications.pngAreas changing within business and IT include the movement away from dedicated hardware for applications, as well as the concept of dedicated applications themselves. In order for these changes to be truly successful there are a number of factors to be addressed.

 

Today there are a wealth of software providers that supply intellectual property to address business problems (e.g., ERP solutions). Although some support more flexible access methods (e.g., SaaS), they are still rigid in what they make available to the business itself. The problems are viewed as IT and not what the business needs. In order for these service providers to address the specific needs of an organization, greater service integration flexibility is required. This allows for real integration of business processes, meeting the businesses unique needs. IT that supports those business processes may come from many different sources.

 

This flexibility will require greater data transport capabilities and analytics, turning generic processing into business differentiation. This movement of data outside the control of a service provider is the bane of most as-a-service solutions, yet when you think about it – whose data is it??

 

To meet the needs of the system users, greater platform independent support is required. This will allow the integration of generic business processes into a context specific solution that can be used by the various business roles to make better business decisions. Since the mobile interface is the enterprise interface going forward, placing the information in the context of the user is critical, on the device the user is actually using. Or if the response is well understood facilitating the systems of action needed to predict and respond to business events.

 

This also means that custom application configuration capabilities will be critical. Rather than having 3rd generation programmers handcrafting new behaviors into the system, standards and tools for customization will be required. Application configuration capabilities will improve the time to market and reduce the maintenance costs -- relying on business-oriented graphical modeling to aggregate functionality from across the portfolio of capabilities. Social capabilities and gamification support will be built into these customization capabilities. This mass-customized contextual portfolio approach is the antithesis of what leveraged service providers enable today.

 

One of the biggest detriments (at least from my perspective) of the dot com era was the view that everyone can code. These coders can do that in a 3rd generation language like Java (or JavaScript for that matter). And finally, that coders actually understand user interface and business process automation design (and security). I don’t think we can afford to put up with these views any longer. The changes in how computing works and is delivered as well the complex possibilities enabled by the abundance of IT capabilities don’t allow it. There has been work to leverage experts and hide complexity over the years, yet most organizations take advantage of very little of this work. It’s time that we move on.

Start thinking about HTTP 2.0 early

http.pngOne of the changes on the horizon that I’ve not paid too much attention to but will impact the services space is: HTTP 2.0. Most organizations today are using HTTP 1.1 and since that dates back to 1999, it is getting rather long in the tooth.

 

Some of the areas trying to be addressed in this update are performance and security.  There are efforts underway today (like SPDY) to improve the existing HTTP, and these are only recently being supported by some of the mainstream browsers. The foundation they defined is being used though to move forward.

 

If the standards effort progresses as defined, HTTP 2.0 will be faster, safer, and be more efficient than HTTP 1.1. Most of these changes will actually take place behind the scenes, so for the user they will upgrade their browser and have HTTP 2.0 capabilities and have to wait for the servers to provide the improved functionality.

For companies though capabilities like server push, enabling HTTP servers to send multiple responses (in parallel) for a single client request -- significant improvements are possible.

 

 

“An average page requires dozens of additional assets, such as JavaScript, CSS, and images, and references to all of these assets are embedded in the very HTML that the server is producing!”

 

So for HTTP interfaces, instead of waiting for the client to discover references to needed resources, the server could sent all of them immediately as soon as you know they’ll be needed. Server push can eliminate entire roundtrips of unnecessary network latency. With user interface responsiveness being an important satisfaction criteria for users this could be a differentiator for a service, especially if it is turned to the network bandwidth available.

 

For businesses, there is a bit of work to do, since porting environments between HTTP servers requires a great deal of testing, even if you have not yet architected a solution to newer functionality. Microsoft and others have put out new server software so organizations can get their feet wet now, while the standards are still solidifying.

Search
Showing results for 
Search instead for 
Do you mean 
Follow Us
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation