Addressing defined targets

The first target introduced in Chapter 2 were end users. This solution will potentially improve their lives in the way that they will gain more freedom in how they want to use all the software and hardware resources they happen to own. The proposed system gives them more control over devices, and a way to go with their creativity to implement various DIY customizations to their technology-enabled daily life.

Furthermore, satisfying their user experience with the solution-enabled devices and apps is also a goal, which can be reached if hardware vendors, software developers and system integrators see the business opportunity in building their own products and services on top of the proposed system.

65

The second target group is made of businesses. Where the improvement coming from the use of proposed system is considered for the existing product and services, it is much faster (and cheaper) to add RPC functionality to existing hardware and software products by using a 3^rd party middleware and linking pre-made libraries than by designing and implementing communication layers, protocols and parsers in house.

Although alternative middleware and libraries might be considered instead, but the proposed architecture is especially designed and dedicated to be integrated into the existing code and hardware with the minimal time and effort needed. Another competitive edge for businesses comes from lowering the costs of implementing future upgrades of already compliant products and services. The proposed architecture is especially designed to allow for adding more functionality to compatible products without the need of inside the box modifications. A product with a constant number of features that are exported to the be used over proposed system, can be upgraded to virtually infinite number of new features even without any modifications needed in the original hardware nor firmware, by just providing a new software independent from the product itself. Furthermore, the existing product can be integrated with features of other compliant products without the need of modification of neither one. This also makes a great added value to a product, as from the end user’s perspective, because even after there is a new successor to the product, or if the product support gets discontinued it is still possible to create updates for it or to dedicate it as a resource for the network. In this architecture there’s virtually no end of life for a product. Even if the original provider (a vendor, manufacturer, etc.) goes away from the market, or stops providing support, any 3^rd party can still provide updates, and the product can continue to be of use on and on. Lot of end users keep some of their old devices even after upgrading to newer ones. These old devices, even after not being used no more, are still fully

66

functional. Finally they too get thrown away, given away or recycled. But if only they could be dedicated as resources to newer generations of products, they would surely continue to serve their owners or would otherwise be valuable goods on the second-hand market.

If businesses create revenue on products upgrades (like Apple does), it might seem at the first glance as a threat to new sales if old product don’t go into the end of life stage.

Fortunately in the real life the advancement of technology will still push customers to purchase new products, while the old ones, instead of being thrown away, can continue to serve their users but in fulfilling different, lower level demands.

Third target group is the industry. Special consideration has already been given to the manufacturing industry (see Chapter 2). There are two primary ways how the proposed system can bring benefits to hardware manufacturers. Both are related to the OEM market. The first benefit is related to their current client base. Currently, where there are many OEM suppliers available, the brand owner will expect products rich in features ready to put their logo on and to market it right off. This is already how things are happening with lot of consumer electronics (CE) like Smartphones or tables as an example. Nowadays it is possible to order a fully functional tablet pc from a supplier, with requested logo printed on the product, paper documentation and boxing, that can be sold to end-users right off the shipment container. Still, lot of brands will create their own customizations. In tablets for example a vendor will by default make a custom ROM (and not only the brand company, but even a reseller can make customizations, like Telecom providers are often doing). Selling a product that is compatible with the proposed system would allow these brands to even more customizations. In fact, an OEM could start selling white boxes with sensors and peripherals only, while their customers would implement actual features for the end users outside of the box. The

67

second benefit is that OEMs can start selling directly to the end-user market (or through distributors) without any additional spending on things like branding, marketing etc.

Every single component from a current hardware spec can be sold separately to end-users as dedicated for DIY. A typical piece of electronics, if it is just a component, not a standalone product, has little value to an end-user, unless he is an electrical engineer or a hobbyist with some EE skills. However, if the single component is compatible with the proposed system it immediately becomes useful for any end-user regardless of his technical skills or their lack. A user who is not technically inclined, can bring the component home and create a self-made solution out of it in minutes.

Alternatively, the end user can use a 3^rd party software able to use newly added components as kind of Plug-n-Play resources. If a high level goal given by the user to the system cannot be realized because of some missing resources, the user can simply go to a nearby electronic store, grab few cheap, no-brand components that will just do, bring them home, and let the system to detect these added resources, configure them, and start using, to rich the given goal.

Finally, the 4^h target group are the developers. Apart of everything that has already been covered and that has already shown possible benefits to the developers in terms of exploring new market share, there is a set of benefits specific to the process of developing software. Targeting all the previous groups greatly depends on high involvement of developers working over the proposed architecture. What are benefits for them to choose working on this specific solution rather then implementing some high-level integration and communication solutions without it? Some most crucial benefits include:

- very easy integration of the system with existing code (linking a library and very few lines of code to export functions) in the Level 1 development (Ch. 3.2)

68

- Even without consideration to a wider problem of general inter-device and inter-application integration and communication, the proposed solution can still work great as easy way to implement RPC, network communication or CGI/Web services features to existing code for specific and limited use

- On the Level 2 development (Ch. 3.2) a native support for scripting programming language syntax – after all the communication, protocol and parsing has been provided, the further development on top if it does not increase complexity of code.

The added layers are transparent, and the RPC handling works seamlessly, so the code looks like if no remote communication was happening

- Adding further levels on top of the level 2 maintains the complexity of the source code, as each additional level transparently hides all the levels beneath. In fact an integration between different levels is possible