cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Thinking Outside the Box for Collaboration...

6270
Views
0
Helpful
0
Comments
Contributor

IT consultant and Harvard professor Peter G.W. Keen developed a reach/range analysis in the 1990s that can be used to describe how distributed an application is (reach) and its degree of integration (range). Web technologies have become a user’s “single pane of glass” that reside in phones, badge readers, or anywhere network technologies can be used – making reach almost limitless.

Improving range has been more difficult as business applications remained stovepipes of isolated functionality. The forces of business opportunity and technological enablement have led to more loosely coupled architectures like SOA, while social networking has demonstrated that application components can form and reform more quickly and easily than conventionally programmed solutions. Composite applications called mashups now go beyond integrating data and text to incorporate maps, photos, music, and video-on-demand.

Application developers are faced with a daunting array of requirements. As SOA, composite and mash-up applications become the norm for collaboration, developers must not only integrate with applications from within their own enterprise, but they may also need to incorporate functionality from external applications hosted in the cloud.  It’s no longer as simple as updating a library and recompiling code to create compatibility with other applications. Web 2.0, social networking, and composite applications are redefining application integration requirements. Even senior application architects often fail to fully consider how an application will perform when rolling out from development and test environments to a production environment that integrates external applications.

What needs to be considered is how to address application complexity that affects reach and range over an application’s lifespan while still meeting user expectations.  Three factors are driving application complexity:

  • Applications are more distributed.  Employee and customer users may be anywhere in the world, yet providing a high quality of experience is critical to business. Virtualization compounds the challenge, with application servers that may reside in any data center across the globe.  These multiple moving parts make it difficult to meet user expectations for performance particularly for rich media.

  • Users have an ever-increasing choice of devices. They expect to use whatever device they want when they want, wherever they’re located.  Standardization is key, but the consumerization of IT makes end-to-end standardization exceedingly difficult to implement as the number of end-point types increase.

  • Integration requirements.  Applications need to integrate internally across silos, along with external applications that provide business services such as geo-coding, credit checks, mapping, etc.  Application developers need to integrate these different sources of information and present them in a single user interface.

Clearly, there is a looming capability gap between application complexity and existing architectural practice and development methods. Application architects must seek help in new places, one of which is surprisingly close by. Networks — the ubiquitous, transport infrastructure known for providing application “plumbing” — can now provide application-enhancing services that help meet the requirements of today’s exceedingly complex networked collaboratoin applications.

The need for concurrently longer reach and broader range is a fundamental principle for collaboration and has created an architectural and development logjam. As the performance burden on servers increase, the network is a natural resource for several scalability and performance responsibilities.

Network-based application services can change the face of application development, and here’s why they matter to you as an application architect and developer. From a development standpoint, it’s clearly more convoluted to have to code for each point you have to communicate with; but if you view the network as an operating system (OS) with available services, you can achieve “three E’s” for your applications: enablement, enhancement, and enrichment.

  • Fundamental enablement is the network plumbing and arbiter of QoS. For an application to be available for use, the network must be there. To best employ the services for fundamental enablement of networked applications, a well-developed enterprise architecture is a necessity.  This practice will ensure that the network is configured to support required protocols for applications and provide applications with requisite quality of service for data, voice and video.

  • Enhancement of applications using network-based services that are “transparent” to the application and don’t require direct interaction.  Examples of transparent services include application acceleration, transcoding/transrating, encryption, and filtering.  Transparent services are performed by the network automatically, but architects must specify configuration parameters and let developers know when the services are activated.  In some cases, developers may be able to request network configuration parameters to determine if a transparent service is available.

  • Application enrichment through application services that are “exposed” in the network is probably most important as composite applications continue to evolve.  These services employ a variety of API’s, but are shifting more and more toward web services using WSDL and REST to provide information and functionality the network is best in a position to offer. Examples include location and presence information, or voice and video services that enable integration of applications into call control and multimedia bridging services to add entirely new dimensions to an application’s functionality.

As reach and range continue to expand, the high-demand distributed applications of the future are going to require continuing innovation in architectural techniques, resources, and capabilities. New performance boosts will have to be found at every level of the system, from the lowest-level plumbing to the highest-level user interface. Enterprise architects and developers will be working far beyond the application server, getting involved with services from many sources.

At the network infrastructure level, networks have begun dealing in higher-level, application-related semantics in addition to their primary job of moving bits through the wire. They now offer capabilities such as data compression, caching, content distribution, metadata tagging, and protocol optimization — all at a point in the system that may be more efficient and less taxing than similar capabilities in the server. For the enterprise architect, this means expanded options and more flexibility.

Traditionally, application architecture and development is focused on the “boxes,” or servers, and the capabilities and resources they require.  However, the network or the lines between the boxes, provide services that merit the architect’s exploration and exploitation.  There are several advantages to using network-based application services, including:

  • Improved performance: Dedicated hardware can perform many tasks faster than software.

  • Shared effort: As the network assumes certain application responsibilities, numerous operations can now be performed “on the wire” instead of bogging down server compute cycles, freeing up the application server for the processing and functionality it’s meant to do.

  • Tuneability: Services locatedin the network can be tuned so that, for example, mission-critical applications receive a higher quality of service than other applications.

One challenge with network-based services is making developers aware of them. This is a layer of the technical architecture that application architects know little about and rarely venture into, and they may not realize what a properly provisioned network can provide. While architects are actively maintaining a catalog of the services that are the reusable building blocks of their enterprise systems, many services are going uncataloged (and thus unused) because they reside in the network where architects and developers are unaware of them. Furthermore, services may be available from the cloud in externally hosted environments.

I believe the network will increasingly become the source of standardization for many application features.  However, to truly be successful, enterprise architecture practices must connect application developers and network engineers to catalog and make aware these services.

****** Background Information about the Collaboration Architecture Blog Series ******

This blog is part of the Collaboration Architecture Blog series.  View all posts in this series.

Posts to the Collaboration Architecture Blog are made at least once a month.   Subscribe via RSS feed so you don't miss the next one.

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards