Computing and information technology

1 Introduction & Overview

1.1 Introduction

Computing and information technology has undergone fundamental changes over the last two decades. The World Wide Web has successfully evolved from a static web of one-way published media towards a new community-driven platform. Second generation websites are complex social systems of unprecedented growth and dynamics. On-line communities have emerged which interact in a self-organizing manner, supported by applications including bookmarking, tagging, blogging, and wikis.

Traditionally many organisations have deployed intranet services for internal communications and access to shared information for all of their staff. For organisations with distributed workforces such systems add significant value to the business. By connecting the workforce through the means of a centralized application, organisations have been able ensure all staff have the required means of communication and access to information as necessary. While intranets systems can add value to an organisation, the potential to enhance productivity and communication in this area is significant. Businesses and organizations are constantly trying to evolve in order to streamline business practices in an effort to reduce costs and improve efficiency. As global market competition increases, collaboration is becoming a more essential part of improving productivity and innovation at the personal, team, group and business coalition levels. Remaining competitive in the business environment is a key driver for many organizations; the ability of connecting information from various sources through the means of a single entity can be a very attractive prospect. [2]

With the recent success of many Web 2.0 technologies, the style and functionality of web technologies is moving forward at a remarkable pace. Gradually, enterprises are picking up on the trends and are starting to adopt these technologies to improve their business collaboration. Enterprise collaboration software enables organization to leverage desirable Web 2.0 attributes in the business environment; such software is commonly known as Enterprise 2.0. As a result Enterprise 2.0 platforms are more than an intranet or web conferencing system, they connect users and provides them with the necessary tools to find and exchange information in an easy manor whether they are working from an office of tethered from a remote location. The new Enterprise 2.0 model has helped to encourage the uses of tools which are common place among second generation websites into organizations. Forrester Research predicts that Enterprise 2.0 will become a $4.6 billion industry by 2013 and social networking software will gain the bulk of the market. [3] Both large and small-to-medium size enterprises are beginning to deploy Enterprise 2.0 platforms. When used in conjunction with a strategy which is unique to the business context, such platforms can offer a range of benefits to the business.

  • Increased Collaboration
  • Innovation
  • Increased Efficiency & Productivity
  • Improved Employee Relations
  • Increase in availability and sharing of information
  • Substantial growth in Business to Customer activity (B2C)
  • Business to Employee (B2E)
  • Business to Business (B2B)

1.2 Background & Context

During a 12 month period of works placement in a medium sized financial institution, it soon became apparent that there was an array of applications which needed to be maintained. It was also obvious to me that various channels of communication existed, different teams and departments developed their own methods of collaboration which ranged from email messages, 'Facebook' instant messaging to more traditional forms such as notice boards and post-it notes. Some such methods posed security issues and others left a lot to be desired, communication between certain departments appeared to be poor. After reviewing the internet usage records it became apparent 'Facebook' was the most visited site, since then 'Facebook' has been blocked by the IT dept in an effort to reduce in proper use of resources. Many enterprises have a wealth of knowledge and interests which is spread among employees, unfortunately due to constraints such as geo-graphical location and lack of infrastructure this information is not always shared effectively.

1.3 Scope & Objectives

The aim of this paper is to provide an enterprise system that is an alternative approach to communication and collaboration within an organisation. It is to be determined whether the use of second generation web based technologies which will help to reinforce the relationship between the business and the employee. In order to achieve this following objectives have been identified;

  1. Gain an understanding of enterprise collaboration systems and identify critical success factors and the risks and benefits associated.
  2. Research the current state of Web 2.0 collaborative technology and determine which components may be useful and can be adapted to the enterprise environment.
  3. Propose an Enterprise 2.0 model.
  4. Investigate various techniques and concepts in order to determine which design and development practices are best suited to solve the problem.
  5. Design and implement an experimental application to demonstrate the way in which value can be added.
  6. Identify areas of future research.

1.4 Research Methodology

In order to gather requirements and contextualise the proposed enterprise system implementation and associated success factors with second generation technologies, research has been conducted and data collected. Different sources of information have been considered ranging from whitepapers to a global survey. The collected data was analysed to identify the critical success factors which are associated with enterprise collaboration software implementation and to define requirements, in doing this a proposed model is specified.

1.5 Overview of Dissertation

This work consists of thirteen chapters, this introduction being the first one of them. This first chapter is introductory, giving a general overview of the context, problem and work conducted. Following this, the second chapter provides the foundation of research into the current state and trends in Web 2.0 technologies, whilst also discussing the adoption and use of such technologies by enterprises.

Chapter three outline the problem in which this project aims to solve, whilst providing justification and clarification on the suitability of the problem.

Chapter four considers different recognised development methods which are used in software development and provides justification over the method of choice. It also then goes on to discuss the overall lifecycle of the project from conception through to deployment.

Chapter five outlines considerations which should be made during the design element of the application.

Chapter six clarifies the project requirements.

Chapter seven is an investigation into suitable technological solutions

Chapter eight Design patterns - defines the architecture strategies and design patterns which are used to develop the application architecture during the construction phase.

Chapter nine - Design overview

Chapter ten, architecture

Chapter eleven provides a detailed treatment of project modelling. Use-case models are presented as a means by in which user requirements can be understood in terms of implementation. Use-cases represent how users envisage a system being used and the main actors involved.

Chapter twelve outlines the components and there functions.

Chapter thirteen - implementation

Chapter fourteen - conclusions

1.6 Acronyms, Abbreviations, Terms and Definitions

Please refer to Appendix A for a list of all acronyms and abbreviations.

2 Web 2.0 in the Enterprise

2.1 Introduction

This chapter presents the state of current Web 2.0 technologies, with a focus on the use in the Enterprise environment. It begins by reporting on the current and future trends in web development. Then goes on to exhibit which tools can be used or adapted specifically for aid with communication and collaboration within the enterprise environment. In order to achieve this various sources of information has been collected, including a global survey conducted by Mckinsey and Company on 'Building the Web 2.0 Enterprise.[3] This holds particular relevance to this project as it shows results from a global literal survey and unprecedented scale. By conducting such an analysis of information at this stage it possible to have a clear understanding of the potential benefits and risks which could affect the overall success or failure of the project. This in turn will provide a foundation which will drive requirements.

2.2 The Web

The Internet has become the most effective and widely used solution for accessing and sharing information, since its conception, social networks have evolved at a remarkably fast pace. The web has enhanced the possibility to create social networks; links and relationships are established not only on interests, but on friendships and other social ties.

"The web is more a social creation than a technical one. I designed it for a social effect - to help people work together and not as a technical toy. The ultimate goal of the Web is to support and improve our web like existence in the world." - Tim Berners-Lee

The Semantic Web, essentially a Web that understands its content, was part of Tim Berners-Lee's initial idea in creating the Web. He envisaged a globally distributed computer network that grants users access to stored information, but also understands the information well enough to interpret it. The Semantic Web continues to evolve, and when it is realized, the Web will again increase in significance. As the Web begins to understand the content we give it, it will be able to assist in routine procedures that are today only achieved through human work.

2.3 Web 2.0

Web 2.0 is a term which is rather undefined; it is used to describe new web applications or online services. In respect to this dissertation, it means any kind of online service which enhances web functionality in order to share and collaborate with others. This can be through the means of articles in a wiki, instant messaging, adding a friend, posting a blog, collaborating, tagging and more. In order to gain an understanding of the tools used thought the web a brief summary is provided below.

2.3.1 Social networking

2.3.2 Blogs

2.3.3 Wikis

2.3.4 RSS Feeds

2.4 Enterprise 2.0 Context

It is widely believed that the term Enterprise 2.0 translates into the use of publicly available Web 2.0 services such and 'Facebook' and 'Twitter' by organizations. However, the focus of Enterprise 2.0 is in terms of a specific product or service which is specifically designed for organizations. Major players in the software industry are all releasing, or have already done so, Enterprise 2.0 platforms which are designed specifically for use within organizations.

2.5 Specific Organization

The potential benefits and risks of introducing Web 2.0 style software solutions into the Enterprise environment vary depending on the organization in question. When assessing the risks and benefits of such an implementation, factors such as industry, organizational size, age profile, knowledge and culture should be carefully considered. Since the success of Web 2.0 technologies on the web, a number of issues have emerged which may affect the adaptation into the enterprise environment. Understanding such issues will help to clarify what needs to be done in order to successfully evolve existing models and technology.

2.5.1 Key factors in adopting Web 2.0

It is relevant to outline what issues organisations may face when considering the introduction of Web 2.0 style systems into the workplace. It is especially important as these factors will affect the choice technology, architecture and design of the system.

2.5.1.1 Scale

Web 2.0 technology successes relies on participation, the success can be measured by the amount of user actively contributing to the community. The web consists of millions of users which Web 2.0 organizations activity try to attract but in the enterprise environment there is a far smaller pool of users. Therefore to encourage participation in the proposed system, the user interface to be simple and pleasing to use, other strategies can also be used such a points of interest and internal publications. Web 2.0 tools and approaches can be used, but they should be adapted to ensure the suitability for use among small groups.

2.5.1.2 Security

There are different levels of security tolerance which exist varying between individuals, organizations and industries. Few additional security issues have been raised by Web 2.0 technologies compared with other internet technologies, although data protection and personal privacy does pose certain problems. These issues should be addressed by using existing IT security polices which exist in the organisation in hand. However any technology used needs to be assessed on security credentials.

2.5.1.3 Identity

As already touched upon, personal privacy issues do exist. Most Web 2.0 technologies allow a certain degree of anonymity. In the enterprise environment such anonymity is not always necessary, although a method of clear identification and authentication is required so that contributors are known and validated.

2.5.1.4 Information protection

It is important for many organizations to protect information for regulatory and competitive reasons. As enterprise systems are usually used by employees only, in many cases this is not a real issue. However, due to the nature of the system, organizations may want to have tools external visible to existing or potential customers, therefore appropriate boundaries should to be established to ensure internal and external information is kept entirely separate.

2.5.1.5 Audit ability

Many regulations are increasing forcing organization to keep an audit trail of communication; this is especially true in archiving email communications. However, other forms of communication which exist in Web 2.0 technology pose concerns regarding the traceability of messages.

2.6 Potential Benefits to Organizations

The potential benefits of Web 2.0 technology in organization can be categorized into four key benefits:

2.6.1 Greater Productivity & Efficiency

Increased productivity

Innovation and product development

Efficient project management

Improved team performance

2.6.2 Increased Staff Engagement

More efficient internal communications

Increased staff engagement

Greater collaborative engagement among employees

Possibility of more effective shared learning and development

2.6.3 Access to Knowledge

Centralized access point to knowledge and expertise

Enhanced document search

2.6.4 Improved Reputation

Greater attractiveness of young employees

Increased market promotion and visibility

Customer retention

2.7 Potential Risks to Organizations

The benefits of such Enterprise 2.0 technology are clear; however certain risks and concerns do apply to some organizations. It is important that all risks are fully understood and addressed to ensure that risk of failure is kept to a minimum and organizations would theoretically feel confident in adopting the final system. The potential risks can be categorized into six key risks;

2.7.1 Reduced Productivity

Reduced staff productivity

2.7.2 Loss of Control

Loss of control of information flows

Negative internal comments

2.7.3 Damage to Reputation

Inappropriate staff behaviors

2.7.4 Security

Information loss

Network Security

2.7.5 Reliability

Information unreliable or incorrect

2.7.6 Pressure on Resources

Bandwidth overheads

2.8 Summary of Findings

Enterprise 2.0 is not a technology but can be described as a business strategy which combines various techniques and technologies. The fundamental capabilities of an Enterprise 2.0 application required the combination of not just Web 2.0 tools but security and interaction with existing systems and infrastructure. None of the technologies involved in the strategy are new, as many of the concepts have derived from the prevalent Web2.0, but many organizations have been slow to adopt products mainly due to fact the concept is fairly immature and the benefits are not clearly understood.

User particplation

3 Problem Statement

3.1 Introduction

This chapter aims to clarify the purpose of this project and identify potential benefits and risks involved with the implementation of the project. This chapter also aims provide justification of the problem's uniqueness and a discussion of why the problem is worthwhile being solved.

3.2 Problem Description

As outlined in Chapters 1 and 2, there is a real need for a system which can be used to help improve productivity, communication and innovation in organisations. In the knowledge-intensive economy, business's have vast amounts of information and data which is not always shared effectively.

3.3 Product Perspective

Flexi Workspace is a new software application which aims to unify communication, collaboration and document management with an enterprise environment. The software aims to enable organizations to bring next generation of desktop and web application to present internal and external content, bringing social networking capabilities to the business end user, whilst maintain enterprise level security and control. As with all new systems there are significant potential benefits and pitfalls. Reaching the goal of a fully utilized online community within an organisation, would reap large benefits from a long-term point of view, with improved communication channels, staff engagement and greater access to knowledge. The plethora of models and tools being used throughout Web 2.0 sites is significant, and choosing the right tool, for the enterprise environment, to accomplish the task in hand is important when considering different options.

3.4 General Constraints

The major constraints of this project are limited design and construction time due to the length of period allocated by the University.

Other constraints include development environment & resources.

3.5 Assumptions and Dependencies

Flexi Workspace is dependant on the Adobe Air 2.0 runtime for desktop operation and Flash Player 9.0 and above for operation within a web browser

4 Software Development Lifecycle

The software development lifecycle refers to the process of software design and construction management from conception of the project through to deployment and maintenance. Software has been a key aspect of the modern world for over 5 decades, original methods of development were messy and often based on many short term decisions, sometimes referred to as the code and fix method. This unstructured approach to software development work well for many small systems, however when the systems inevitably grew it became more difficult to fix errors and new features. It soon became apparent that more structured of style of development was needed in order to reduce risk and unpredictability during the development of software. Traditional style methodologies imposed a more disciplined approach to software development with the aim of ensuring more predictable results. Various other methodologies have since been developed, each with its own recognized strengths and weaknesses.

All development methodologies are not necessarily suitable for use of all projects. [4] Therefore in order to ensure this projects structure it is important define the development model in which it will follow. To decide on the most appropriate model an analysis into both heavy-weight and lighter-weight methods will follow.

4.1 The Waterfall Model

As suggested by the name, the waterfall model is a sequential software development process which flows downwards, like a waterfall. As represented in Figure 1. The conventional, systematic waterfall approach to software development is said to be inherited from manufacturing and systems engineering practices. This development method was first adopted during the 1960's for building large scale applications for the U.S defence and space industry.

The waterfall model considers the best practice for software development is a linear or sequential series of phases which take the project from the initial high-level requirements right through to implementation and maintenance. This method requires the elicitation and documentation of requirements, architectural and high-level design, coding, and testing. The model relies heavily on consideration and review of each phase of development. As once the project moves on to the next phase in the process there is little room for changes to be made. Therefore the initial requirements and specification is crucial in the overall success of the project as once the system design and coding is underway there is little room for changes and iterations.

4.1.1 Characteristics

  • Predictive Approach
  • Comprehensive Documentation
  • Process and tool orientated
  • Unable to cope with change easily

4.2 The Agile Software Development Model

Developments methods are evolving into lighter weight, faster and more nimble models in order to meet the demands of the development community, mainly driven by the growing internet application sector. Agile development methods are a reaction to such traditional documentation driven software development processes, which were yielding poor results and low customer satisfaction levels.

The Agile Manifesto was first published in 2001 by 'The Agile Alliance' [8]. Four fundamental values were defined;

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

All agile development methods are based on these four values, to name a few: Adaptive Software Development, Dynamic System Development, Extreme Programming, SCRUM and Feature Driven Development.

Agile processes require more discipline on the part of the developers and project management. Change is seen as acceptable during a development.

4.3 Summary of Development Lifecycle

5 Application Attributes

This chapter outlines considerations which are to be taken into account during design and implementation of the proposed application. In outlining such attributes a foundation is provided, upon which the architecture of the system can be considered, in part by setting the standards and measures the software must satisfy. These in turn drive design principles that can be used to validate the design and ensure that future releases offer improvements and fixes. These system attributes have been complied following the research and analysis of the adaptation of Web 2.0 technology for use within organisations and general attributes required by software systems alike.

5.1 Framework

Although the proposed application is merely a prototype, it should not be developed is the same way as many prototypes are. It is a key aim to avoid spaghetti code during development to ensure that a structured architecture is created. Design patterns can assist in creating a separation between the presentation and application logic, generally known as one of the most difficult problems developers encounter when designing and constructing such applications. The emergence of third-party frameworks can present possible solutions to the problem, although it is important to evaluate each framework to ensure that is suits the application. Once a framework is adopted, generally it is not favourable to change to a different framework at any point in time, therefore it is advised the lifecycle of the application is also considered. The framework of the application should have the ability to facilitate future development, as more functionality may be need to be added further down the software lifecycle.

5.2 Distribution

5.3 Compatibility

Compatibility is the ability to operate on a range of operating systems and web browsers whilst also being backward compatible with previous releases where necessary.

5.4 Extensibility & Maintenance

Extensibility is the ability for new functionality and capabilities to be added without to the need for major changes to underlying architecture. A key factor for many enterprises whose business processes can be constantly evolving, therefore to ensure the application can be further developed and maintained it is essential that the architectural model has the ability to facilitate this.

5.5 Fault Tolerance

Fault Tolerance is a property of a system that gives it resistance from faults and the ability to recover in the event of component or service failure. Faults of different types are unavoidable when dealing with software; it is important that software/applications can recover from component or service failure and produce enough information about the possible cause. This application is no different, therefore fault handling is a key aspect which is to be further investigated to ensure that application has sufficient infrastructure in place to identify and cope with the problems it may encounter.

5.6 Integration

In the business environment many information streams and services exist, in order to present information from a centralized application, integration between existing systems should be possible. This should be considered during the architecture design to ensure services can be added during the lifecycle of the application.

5.7 Auditable

The ability to trace user activity, faults and errors within an enterprise application is a necessity. In certain industries, such as the financial sector, many regulations need to be met. Email archiving is a well established example of this, however many new forms of communication must also be addressed. Traceability is a key factor for such enterprises when developing or considering software, not only does it offer the ability to track user's activities but also gives maintainers the ability to easily locate errors and faults. This can be fundamental in the maintenance and further development of such applications or platforms.

5.8 Security

There are clearly different degrees of tolerance which exist between organisations and industries. However, to ensure information integrity, the application should have a level of security, which prevents unauthorized access to the application and tools. There are few other additional issues raised by this application which would not already have been addressed in existing IT security policies. However any technology should to be assessed on security.

5.9 Performance

Performance is a key attribute of any software system, the response time, utilization, and throughput behaviour of the system should be reasonable. Application profiling carried out to ensure the application operates as expected.

5.10 Data Validation

User input validation is an important aspect of this build, ensuring the integrity of the data is an important factor when dealing in business context. A method in which the application can handle the validation of user input is essential. Ideally the method of validation should be easily extendible and transferable to any aspect of the application.

5.11 Open Source

Where necessary this project should take advantage of free, open source, and community-supported software as an alternative to commercial solutions whenever possible. This will allow the application to build from work already done and negate any costs which are linked to other commercial solutions. It is not always possible to find an open source or free equivalents for a certain technology that also satisfies the requirements. Therefore licenses should be obtained where applicable.

5.12 Summary

This chapter has proposed attributes in which the project and technologies used should satisfy.

The design considerations outlined in this chapter provide the criteria in which should be take in account when analysing different technological options available.

6 Solution Study

6.1 Introduction

Defining the right technologies and solutions for the application is an essential part of the development lifecycle; the wrong choice can have detrimental effects on the whole project, such as lengthened speed of development, decreased performance, a steep learning curve during development and high levels of costs for stakeholders. Although the choice of technology is not an easy decision, many options exist and the supporters often claim that their technology is the best choice. With so many options available it is important to analysis each option in order to ensure that the requirements can be met within the allocated time allowed.

6.2 Client-Side

In a data intensive environment, businesses depend on the ability to be able to work with information efficiently. Businesses are constantly trying to provide a better customer experience than its competition; this includes improved user experience from a business to customer perspective and increased employee productivity. Users want quick and easy access to tools and their information regardless of the computer they are using. They also want a high level of reliability with native operating system features such as a fluid graphically experience, sound, video, dragging and dropping. Developers and software teams are expecting more and more from technology too. Time-to-market offers a high strategic value; therefore the ability to create and develop interoperable software quickly can be very advantageous. Not being able to guarantee that all users are on the same version at the same time introduces many problems for developers and maintainers, therefore pushing out updates need to be easy and fast. In effect a paradox is presented, users and customers are seeking a pleasant experience and businesses are trying to achieve market position and operational efficiency. It is in this context where traditional technologies divide and Rich internet applications capitalize.

6.3 The RIA Solution

RIA is an umbrella term used for describing web applications which look and behave more like a desktop application; key characteristics include interactivity, responsiveness and richness. They often also support elements of validation, error handling, drag and drop functionality and richer controls. RIA technologies help to provide rapid development and deployment through the means of a centralized internet model, whilst providing users with a desktop-like experience as shown in Figure 5. RIA frameworks enable developers to provide a compelling and fluid user experience that gives the impression of a live desktop application in contrast to traditional web applications which require refreshing on each interaction [5].Although the deployment and access model remains the same, users can operate these applications from any computer using a traditional web browser. Using a browser as the delivery mechanism in this way allows applications to have the same deploy ability that websites enjoy so much.

RIA frameworks can be divided into two categories: JavaScript/AJAX based frameworks and plug-in based frameworks. JavaScript based framework are browser based and usually considered more lightweight, while on the contrary plug-in based tend to be more heavy weight complied applications. Various technologies and frameworks exist in both categories; the following will explore the characteristics of the relevant options available in an effort to determine the most suitable option for the project.

6.4 Javascript / AJAX RIA's

AJAX is not a technology, but rather a term which is used to describe different techniques which can be used to enable more functionality within a web application. The biggest being asynchronous data transfer using a XMLHTTPRequest in JavaScript. The AJAX umbrella also consists of JavaScript, data formats such as JSON and XML for communication between client application and the server and HTML and CSS for interface design.

Developing rich application using AJAX can be very complex as many browsers interpret JavaScript in different ways. A possible solution to this problem is the use of JavaScript frameworks which can help to minimise crow-browser issues and also can provide ready to use components. The key benefit of using AJAX to develop RIAs is that there is no need for plug-ins to be installed on the client machine enabling greater accessibility to users. Below is a table containing a list of the most popular JavaScript frameworks and libraries available according to ajaxline.com [10].

6.5 Plug-in Based RIA's

RIA technologies provide the same look and feel regardless of environment. To achieve this they utilize a browser plug-in which acts as a client side runtime engine, with cross browser and operating system compatibility. As a result RIAs can offer true platform neutrality. Different RIA technology providers exist; the most mature and widely used is the Flex framework by Adobe, followed closely behind by the Silverlight framework by Microsoft. Sun Microsystems is also trying to define their place in the market with the recent release of JavaFX.

6.5.1 Flex by Adobe

Since the take over of Macromedia by Adobe, Adobe has inherited the Flex project and since made it open source. Easily the most mature RIA framework, flex offers the software development kit and optional integrated development environment and eclipse plug-in. Adobes product description is cited below:

"Adobe Flex is a highly productive, free, open source framework for building expressive web applications that deploy consistently across browsers, desktops, and operating systems by leveraging the Adobe Flash Player and Adobe AIR runtimes" (Adobe 2010)

Flex offers advantages to users and developers alike by leveraging Flash player which is a widely used plug-in across the internet. According to statowl.com it is thought nearly all computers have the flash player installed with browsers such as Google chrome now shipping with the plug-in installed, see Figure 5.

Flex offers tight integrations with other Adobe products from design software such as Photoshop and server-side technology such as Cold-Fusion.

6.5.2 Silverlight by Microsoft

Microsoft has jumped into the RIA market by investing large amounts capital into its Silverlight project. Microsoft's product description is cited below;

"Silverlight is a powerful development platform for creating engaging, interactive user experiences for Web, desktop, and mobile applications when online or offline." (Microsoft 2010)

Silverlight does not yet have the same integration with existing products as Flex, but design product Expression Studio can be used as a suitable IDE. From a platform perspective it now supports Windows and Apple operating systems, with plug-ins available for browsers such as Internet Explorer, Firefox and Safari. Silverlight is targeting Microsoft developers in order to gain market share by leveraging the existing .NET framework, components and language.

6.5.3 JavaFX by Sun Microsystems

JavaFX is a framework for creating Rich Internet Applications, developed by Sun Microsystems and first released in December 2008. Sun's description of the framework is cited below:

"JavaFX is an expressive rich client platform for creating and delivering rich Internet experiences across all the screens of your life." (Sun Microsystems 2010)

JavaFX is the most immature RIA on the market today; Sun Microsystems had the opportunity to seize the RIA market with its Java technology but failed to capitalize on its success. Existing technology provided by Sun Microsystems are generally very functional and are not well known for creativity and design. In order to catch up with Adobe and Microsoft measures need to be taken in order to compensate for the weaknesses which exist. Sun's main advantage is the sheer size of the Java development community; time will tell whether they can capitalize on this valuable attribute.

6.6 Acquainted with Flex

Following this brief evaluation of RIA frameworks Adobe Flex has been chosen to design and develop the software this project. This decision has been based on the following;

  • Maturity of the technology.
  • Experience with Flash, Action Script programming language and other Adobe software.
  • General acceptance of the Flash player browser plug-in.
  • Adobe Integrated Runtime - AIR
  • HTTP and AMF3 data transfer protocols
  • Event driven
  • Open Source

6.7 The Flex Framework

This programmatic approach uses Flex's core languages: the XML templating language (MXML) and Action Script.

Flex applications are event-driven. Events let a programmer know when the user interacts with the interface, and also when important changes happen in the appearance or life cycle of a component, such as the creation or destruction of a component.

6.8 Server-side Technology

Communications with back-end services is a key aspect of the application, choosing the most suitable server stack technologies and means of integrating the client with the server is essential. Figure 5 shows the available web 2.0 server technologies which are interoperable with Adobe Flex and therefore applicable to this project. Each of the stacks below are viable and worthy of consideration, therefore to make the right choice some further investigation is required.

6.8.1 J2EE / Spring-Hibernate

J2SE core language and set of libraries and their distinctions become clear on more detailed level of consideration.

There are two existing solutions to integrate a Flex client with a J2EE server environment, both solutions are provided by Adobe. Please see Appendix E for a functionality comparison of BlazeDS and LiveCycle Data Services ES2.

6.8.1.1 Blaze-DS

BlazeDS is an free and open source server based technology which enables Adobe Flex develops to integrate the client application with a J2EE backend environment.

6.8.1.2 Adobe LiveCycle Data Services ES2

LiveCycle Data Services ES2 is a commercial alternative to BlazeDS.

6.8.2 Coldfusion

Coldfusion is Adobe's solution to a servers-side

6.8.3 LAMP

Linux, Apache, MySQL and PHP is a well-known and proven solution,

The Apache HTTP Server Project is an open-source HTTP server for modern operating systems including UNIX and Windows. Apache HTTP has the ability to be a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards [6].

s but is still "young" and worth consideration as all three languages/frameworks are being actively developed and supported by large community.

6.8.3.1 AMFPHP

A database driven application needs a way to exchange data between database and front-end as efficiently as possible. AMFPHP is a technology written in PHP to emulate the capabilities of a software originally developed by Macromedia, called Flash Remoting. Flash Remoting, unveiled in 2001, is a proprietary, highly efficient technology to connect Flash applications to the server. The benefits when choosing Flash Remoting over other technologies are performance and seamless integration with Flash. It uses a binary message format, designed for the ActionScript object model, called Action Message Format.

AMFPHPis a free open-sourcePHPimplementation of theAction MessageFormat. AMF allows for binary serialization ofAction Scriptnative types and objects to be sent to server side services [8]. AMFPHPallows thin client applications built in languages such asFlash,Flex, andAIRto communicate directly withPHP class objectson the server.

6.10 Summary

During the development of the internet and the web applications that go with it, usability has been sacrificed for the need for rapid deployment and cross platform compatibility. The user experience has been the most effected by this, even though users have somewhat become accustomed to this it was just a matter of time until the disadvantages outweigh the benefits. The use of RIAs can help to demonstrate how we can achieve the best of both desktop and web technologies.

Adobe Flex leverages the cross-platform flash player by presenting a programmatic way to make a flash application. From design to deployment, Adobe offers the best environments and tools for each phase of application development. Now in its forth major version, Flex is maintaining its market share.

One of the primary goals of this project defined in the Chapter 1 is to take advantage of free, open source, and community-supported software as an alternative to commercial solutions whenever possible. The primary reason for this is the general lack of budget, the second reason is, to show what possibilities there are to build an enterprise system without the need for expensive, proprietary technologies, if choices are carefully considered. The available server side technologies which are interoperable with Adobe Flex are discussed below.

As previously stated, the aim of this study is to develop an enterprise rich internet application using the Adobe Flex 3.2 SDK.

However before undertaking this it is, three key questions must be answered:

What is meant by 'an enterprise rich internet application'

7 Requirements

7.1 Introduction

It is proposed that an experimental application is to be designed and developed in order to demonstrate the way in which web 2.0 tools can add value to a business. Although the application does not have scope to be implemented in any business context in the near future, the benefits of the system will be obvious. These requirements have been compiled following the analysis of data collected during the research phase of the project.

7.2 User Characteristics

This software applies to any employee within an enterprise environment. There is no limitation on who would be able to use Flexi Workspace from a technical viewpoint, although limitations regarding access to information and rights and permissions within the system would be applied depending on the usage scenario.

7.3 Usage Scenarios

  • Administrator
  • Manager
  • User
  • Public User

7.4 Use-Cases

7.4.1.1 Administrator

The user level will provide administrator functions such as user management.

7.4.1.2 Manager

This level of users will be able to insert new inspection details, facility information and generate letters. They will be also able to modify the entries they made in the past.

7.4.1.3 User

This level of users will be able to do all the record maintenance tasks. They will be able to modify any records created by any users.

7.4.1.4 Public User

This is the system administrative level which will be able to change any application settings, as well as maintaining user profiles.

7.5 Requirements Specification

The purpose of this section is to outline the functional and non-functional requirements of the system. The requirements have been developed specifically to meet the objectives defined in Chapter 1. The following requirements outlined presuppose the general structure and functionality of the system, although this is a definitive list of requirements other functionality may be added during development and revised iterations will follow. A requirements matrix has been complied and should be used to trace requirements throughout development and testing. Please see Appendix B.

8 Design Patterns

8.1 Introduction

This section discusses the use of design patterns, the methods and reasons for their use in software development. It will discuss which design patterns are applicable and how they can be utilized in order to meet specific architectural and design needs in order to control the behaviour of the application.

8.2 Purpose

Consideration of the application architecture is a fundamental part of this software design. It involves defining the interaction between each element of the application and its resources. By creating a conceptual model, it helps to identify any integration or functional problems, which translates into the system design. The rationale behind using design patterns in software design is that problems are given their own essential character by a sequence of events, or behaviours. Each pattern describes a problem which occurs over and over again in an environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice [6]. When faced with a particular problem, it is unusual to tackle it by inventing a completely new solution which is distinct from existing ones. It is common to recall similar problems that have already been solved and to adapt and reuse elements of them to solve a new problem. This type of thinking is common in many different domains such as architecture, economics and software development. Design patterns can be models or reusable object oriented code which helps developers cope with constant changes in software design and development. These patterns have been used successfully by developers before, and therefore, the pros and cons of the pattern are known beforehand.

8.3 N-Tier Model

Atieris alogicalpartitionof theseparationofconcernsin thesystem. Eachtieris assigned its own unique responsibility in thesystem. Eachtieris viewed as logically separated from one another. Eachtieris loosely coupled with the adjacenttier. [2] It is typical to design applications in this way. The application architecture is critical as it defines the interaction between various elements and components, thereby limiting the complexities of issues during constructing, deploying and maintaining the application. At a conceptual level each tier offers its own unique functionality. Traditionally, web deployed applications follow a three-tiered approach, as shown in Figure 9, for greater performance and scalability.

The three-tiered approach offers increased scalability as it introduces a separation between the logic, presentation and resource aspects of the application. Although the three-tiered approach does not offer true flexibility as it falls short in not separating the application into more specialized functional layers. These short comings are mainly because the business tier becomes too large and has too many functions contained within it. This is where the n-tiered approach provides a more suitable solution for complex applications, by introducing an additional tier a finer grained model is presented. It is preferable to separate the data access elements from the business tier thereby creating the additional tier. By decoupling the data access logic from the business logic in this way it is possible to make the application more flexible maintainable for future development. Figure 10 illustrates the n-tired architecture in which the application is based upon.

8.3.1 Presentation Tier

The presentation layer as the name suggests is the front-end layer that the end-user interacts with. The main responsibilities of this layer are application output display, handling input into the application and instantiating events. The user's desktop operating system is the primary client for this application, taking advantage of the Adobe Air Runtime. Although a standard Internet browser such as 'Internet Explorer' with Adobe Flash Player installed will be the secondary client for the application.

8.3.2 Business Tier

As the name signifies the business layer implements the business rules for the application. This layer contains components which are used to implement the business logic and defines the business entities that are used. The business components perform the core processing within the application; these components implement the following:

  • Requests to other business logic, data access layer or other services.
  • Interface between the user interface and the resource layer.
  • Business rules, such as calculations or conditional logic.
  • Implementation of validation such as authentication and authorization.
  • Data flow.

8.3.3 Data Access Tier

The data access layer provides the application with connectivity to local or remote services and resources. Persistent connectivity to such resources can be complex in large applications, neither the presentation nor business components need to be aware of this complexity. Moreover there are many forms of services and resources which exist from databases to flat files. Therefore by decoupling the data access logic from the business components allows for a more flexible and maintainable application. The data access layer manages the connection to the data source to obtain and store data. As a result this encapsulates all access to relevant data stores.

8.3.4 Resource Tier

The resource layer includes the underlying resources that the application utilizes to deliver the application service. This

These can include:

  • Databases (Directory, SQL, mySQL, etc)
  • File System
  • Exchange Services
  • Jabber (Real-time Communication)
  • Web Services

8.4 The Model-View-Controller Pattern

It is reasonable to propose that the given application is likely to change its interface as time goes by, or may have several interfaces at any one point in time. Therefore to build any particular user interface into the core application would have detrimental effects on the whole application, as it would result in making it less flexible, harder to migrate to newer releases and harder to debug. It makes more sense to keep the essence of the application separate from all and any of its user interfaces. As a result as the interfaces change the underlying application would remain relatively constant.

Although there are some development practices that in fact discourage such separation of user interface and logic. The principle objection of Rapid Application Prototyping is its inability to allow the developer to create a structure which is maintainable and scalable, its methods can assist in creating a slick user interfaces for prototyping purposes, although such development practices should be avoided as considerations that influence the design of a GUI should not be the same considerations made when designing the core application.

During the 1970's Prof. Trygve Reenskaug defined an architecture which addresses these software design issues, which was called Model-View-Controller (MVC) architecture. Since then, the MVC design pattern has become commonplace, especially in object-oriented systems. The Model-View-Controller is a compound pattern where many design patterns work in harmony to create applications. As suggested by the name the design pattern consists of three elements.

8.4.1.1 Model

The model is the essence of the application as it contains data and logic to manage the state of the application. From an object-orientated perspective this will consist of a set of classes and variables which support the underlying application. The model takes advantage of other design patterns which include the observer pattern to hold data and the singleton pattern to ensure only one instance is in use at any one time. The model should know nothing about any other interfaces or connections to other systems or the world.

8.4.1.2 View

The view presents the user interface and the state of the application, usually through the means of a screen. For any given version, in any given situation there will be one or more interfaces with the model, these are known as views. The view should not handle application logic just merely display output and instantiate events. In object-orientated terms, a view will consist of classes that give access to the model. Views are often GUI's, although they could be CLI view or API view. The view has knowledge of the model as often objects are bound to variables which are defined in the model. The view takes advantage of the composite pattern to represent the state of the application.

8.4.1.3 Controller

The term controller implies a user interface object of some sort, but the controller does not contain such elements. As pointed out previously user interface objects belong to the view element. Whilst the view handles the output, the controller is an object which handles the input in order to change the state of the application. The controller takes advantage of the strategy design pattern....

The controller pattern helps to implement a centralized point that controls and manages user requests. The controller manages the handling of requests, delegating business processing including security services such as authentication, authorization and access control, managing the views and handling errors or faults.

8.4.1.4 Communication between elements

Each element in the Model-View-Controller design pattern has unique and separate functions, although none of them operate in isolation. In order for the pattern to be successful, each element needs to communicate with one or more of the other elements. Communication between the elements is obligated by a sequence of events which are usually instantiated by an event or user interaction. Figure 7 is a simple representation of the channels of communication between elements. The arrows show the direction of communication.

8.5 Creational Patterns

Creational design patterns deal with the instantiation of objects. The basic method used for object creation could result design problems in certain situations, therefore creational design patterns can help solve this problem by controlling the instantiation of objects.

8.5.1.1 The Singleton Pattern

The singleton pattern is used to ensure that one and only one instance of a class can be instantiated at any one time, whilst providing a global point of access to the object instance. Multiple instances of certain types of objects within an application can cause issues. The model object is instantiated on the initialization of the application and is responsible for global variables and defining events. The singleton pattern should be applied to the model element of the application. This will provide a global access point to the model whilst ensuring there is only one possible instance. This design pattern can be used throughout the application on there classes where the number of instances need to be monitored, although it is not best practice to use this pattern for coding convenience where no deliberate architectural strategy exists.

8.6 Structural Patterns

A structural pattern refers to the use of classes and objects to build larger structures.

8.6.1 Composite Pattern

The composite pattern is used to provide solution to building software systems that are made up of several smaller components. An application is made up of these components, which may be single objects or containers that represent collections of objects. A composite object refers to the collection of components. By grouping objects in this way it is possible to treat the group in the same way as a single instance of an object. This can be useful as it can help to reduce the amount of coding required and therefore making the code more efficient.

8.7 Behavioral Patterns

Behavioural patterns focus on the communication between classes and objects. By using such design patterns a developer can increase flexibility in this communication.

8.7.1 The Observer Pattern

The observer patterns is used as a central point which sends information to subscribing receptors, it makes sense to have a single source of information broadcasting to receptors rather than having several different sources broadcasting the same information. The key feature of the observer pattern is that variables are all stored in one place and sent to all subscribing receptors. This one-to-many relationship allows a developer to create loosely coupled classes whilst yet maintaining information consistency. Maintaining information is this manner is not only efficient but also gives scope for evolution and expansion. The observer pattern should be used throughout the application where the need for components to subscribe to the model exists.

8.7.2 The State Pattern

The state pattern is used to represent and control state of an object. The state pattern is used when an application is required to change its behaviour type at runtime.

8.8 Summary

By using the tiered approach to application design, it is possible to separate the layers functionality, in doing the application becomes more readable and components more reusable. This style of application architecture will help to minimize the risk of spaghetti style code during in implementation.

Other benefits of structuring an application in tiers, becomes obvious when underlying technologies have to be changed.

For Example./ If the application needs to change its database, to a different server, which uses a different database vendor for instance. Many problems for application developers or maintainers could arise, as many different parts of the application may need to be adjusted. This process could be very costly and take valuable time to complete. By structuring the application in a tiered layout, the only adjustments required would be on the data access layer and/or possibly the business layer. No changes whatsoever would have to be done to the presentation layer as it is independent from the data access tier and communicates with it solely through the business tier.

9 Design Overview

9.1 Introduction

Software design is the creative process that needs to be guided and directed. To transform requirements into a functional system, a structured design process is to be followed in order to create a representation of the software system which can be assessed and used by developers as a template for the project there after. Design is considered as an iterative process of transforming the requirements specification into a design specification. Firstly, the conceptual design that defines exactly what the system will do. On approval, the conceptual design is translated into the much-more detailed design specification which allows the developers to understand the project presented. This section aims to give an overview of the solution and precisely how it will be implemented. In order further design the system, this section provides a bridge linking the gathering of requirements and the design specification by outlining the methods and concepts.

9.2 Design Method

A good software design strategy helps to ensure that the system is easy to develop and change. A structured approach provides assistance during the design and implementation to deal with large and complex software and demonstrates how the software and its components fit together. There are many ways to develop good designs, however, every design methods involves some kind of decomposition, starting with a high-level representation of key elements and creating lower-level definitions of how the system's features and functions will work together. It suggested that designs should be created by using one of the following methods;

  • Modular
  • Data - Oriented
  • Event - Oriented
  • Object - Oriented

All design methods share the same goal which is to transform outlined requirements into a software system. The decision has been made to follow an object-orientated approach to develop the requirements outlined into a functional software system. This approach is a recognised design method, although as with all design methods there is no proof of correctness due to the fact none are classed as a rigorous science. The object-orientated approach has been chosen for the following reasons;

9.3 Object-Orientated Analysis and Design

The object-orientated design approach provides a comprehensive solution of which has become the preferred approach to analysis and design of large scale software systems. This design method will be used to describe in detail processes and related workflows as well as people and artefacts relating to the system. The purpose of designing the system is this way is to provide a proof of concept to the solution which can be used to visualize and reduce complexity during the development phase. The method begins with an examination of the real world objects that relate to the problem in hand. These objects are identified and characterized individually in terms of their attributes and behaviour through the means. The object attributes and actions are discussed and the design explains how objects interact with each other. The focus is on creating explicit and traceable models, and extensible and reusable architecture using the industry standard Unified Modelling Language.

9.3.1 Methodology

9.4 Programming Techniques

This section provides a short insight into the different programming techniques and concepts which are to be used in the development of Flexi Workspace. Discussing all the details of the techniques mentioned here, would go beyond the scope of this paper. However, the following provides a short introduction to the main concepts and techniques used in the solution.

9.4.1 OOP: Object-Oriented-Programming

Due to the potential scale of this project, several problems may occur during development. A key problem may be as the system grows, components may become inherently dependant on other parts of the system, and therefore the flexibility of the system will decrease. This can in turn introduce more bugs and errors into the system making it harder to maintain and extend. Object-orientated programming is a well known and established concept which aims to provide a solution to such problems with high level programming languages. It is designed to help break down complex applications into to more self contained interacting modules of code. With out the use of such programming techniques the development may turn into a spaghetti of code and bare the characteristics of a rapidly developed prototype, this would have detrimental effects on the project and result in the failing of key objectives set out earlier in this paper, such as maintenance and extendibility. To ensure the proper use of the object-orientated programming it is important each element of the technique is fully understood.

9.4.1.1 Object

An object is a thing or concept. It can be a real-world thing or concept, or an abstraction of a thing or concept expressed as a software representation. An object has state (attributes) and behaviour (method) .Individual objects, also called instances, have identity and are distinct things, and can be distinguished from other objects.

9.4.1.2 Class

A class is a description of a collection of objects with common attributes and behaviour.

In practice, the definition or specification of a class includes the definitions of the attributes comprising the state, the methods implementing the behaviour, and how to handle creation and destruction of an object.

9.4.1.3 Attribute

9.4.1.4 Behaviour

9.4.1.5 Encapsulation

9.5 Refactoring

9.6 Conventions

9.7 Assumptions and dependencies

Contrary to web sites, RIA's requires a client to run on. Flexi Workspace web release utilizes Adobe Flash Player in order to enable browser operation and the desktop release uses the Adobe Integrated Runtime (AIR) 1.5 in order for desktop operation.

One of the goals I set myself is to build the application to be open to extension. This is achieved by a tier-, component- and object-oriented approach in the design of the application architecture.

Ldap NOT POSSIBLE RESOURCES

9.8 Goals and Constraints

9.9 Summary of Design

10 Architectural Design

The architecture of the application is defined by considering a combination of design patterns which were investigated in Chapter 9 & 10. The first of which is the N-tiered approach which defines each layer of the system, in order to achieve the advantages of this model a custom MVC design pattern will be used in combination with the N-tiered approach. Figure 12 shows a conceptual overview of this combination of models.

11 Modeling & Analysis

After defining the requirements of the system and investigating various technological solutions, it is important to model and describe the key elements of the system and the function it will provide. The section provides modelling and analysis in an effort to create a representation of the system.

11.1 Use-Case

Use-case analysis is used to identify objects within the system.

11.2 Authenticate User

The authentication of a user is a key requirement of the application. The user is prompted for login credentials. Once submitted an event is instantiated, the login controller listens for the event. The login controller then processes request and invokes the server handler to communicate with the Database. The result has two outcomes either false or user information as an array. The controller checks the returned data and either updates the model with user information and updates the view state or invokes a notification message to the user. This process is represented by an activity diagram and sequence diagram below.

11.2 Authenticate User

The authentication of a user is a key requirement of the application. The user is prompted for login credentials. Once submitted an event is instantiated, the login controller listens for the event. The login controller then processes request and invokes the server handler to communicate with the Database. The result has two outcomes either false or user information as an array. The controller checks the returned data and either updates the model with user information and updates the view state or invokes a notification message to the user. This process is represented by an activity diagram and sequence diagram below.

12 Implementation

13 Testing and Debugging

13.1 Introduction

This section defines the techniques used to test and debug the application during and after the implementation phase of this project.

13.2 Adobe Flex

In Flex's relatively short life, testing and debugging used to be weak points, but the ecosystem has come a long way in a short amount of time with a variety of tooling and advanced capabilities.

When it comes to debugging, you can do simple things to get insight into what's going on. In addition, the Flex Debugger is a robust tool that gives you tactile control over isolating issues.

13.3 Debugging

Flex Builder 3.2 Eclipse plug-in now is packaged with a fully functional debugger where it is possible to step through the code and watch the value of variables in real time.

13.3.1 Utilizing the trace() Function

trace () is a global function in the Flex 3.2 SDK which can be used throughout the application in order to write text to a log. This is an effective mechanism, which can be used to record variables.

13.3.2 Breakpoints

Once the debugging of the application is completed, it is advisable to test the application to ensure it is functioning as expected.

13.4 Testing

Software testing can be described as the process of validating and verifying an application. It is used to ensure the element/application works as expect and meets the requirements that guided the design and development. There are various types of testing which are relevant the application and technology used. The agile design methodology which is been followed throughout the design and implementation governs that testing should take place at the end of each iteration.

13.4.1 Types of Testing

There are three main types of testing which are applicable to this project;

  1. Profiling - is a process of testing to which assesses the resource utilization of an application, such testing can be used as a tool to identify memory leaks and unnecessary processing overheads and highlight areas in which the application could be optimized.
  2. Unit Testing - is a programmatic way of testing components, functions, and classes. It's considered a back-end type of testing.
  3. Functional Testing - is a process of testing which simulates an end-user running the application and verifies that behaviour or information is correct. It is possible to do conduct manually although the risk of human error and large time investment exists.

Different tools and techniques will be applied to each type of testing to ensure that issues can be identified and corrected. To identify appropriate tools brief research into various available products will follow.

13.4.2 Flex Profiling - Profiling

Adobe Flex builder now includes the ability to profile applications to identify performance issues. It is possible to isolate elements of the application in order to address problem which may be occurring. The tool works by taking periodic snapshots of the application, it is able to determine how many objects exist, memory usage, how many functions are called and the related response times.

13.4.3 FlexUnit - Unit

13.4.4 RIATest - Functional

13.5 Overview of Planned Tests

This section provides a high-level overview of the testing that will be performed. The outline in this section represents a high level overview of both the tests that will be performed and those that will not.

on the type of testing employed, different met testing is conducted during and/or after the coding process. The different types of testing use to validate this application are discussed below;

It's always a good idea as part of your Systems Development Life Cycle to do as much upfront testing as possible before you go live with the application. ASP, PHP, ColdFusion, and other such languages will tell you the line of code and filename when a crash occurs—this luxury doesn't exist in the land of Flex because of its compiled nature.

Testing is also an opportunity to fine-tune the application.

14 Conclusion

This chapter is a reflection on what has been accomplished during this project and indication to how the project could be furthered. Firstly, the benefits and risks involved in adapting Web 2.0 technologies for the enterprise environment is explained, then it goes on to discuss what contributions have been made in this area. An evaluation of the final product follows focusing on the future use of RIA's for application development.

14.1 Summary

This project has brought to light evidence which shows when businesses adopts social collaborations tools an increase in employee productivity is noticeable. Many companies find that specific enterprise 2.0 tools are invaluable for achieving true operational success and can play a vital role for collaboration with both internal and external parties. Critical success factors of enterprise 2.0 system adoption were investigated in order to gain an understanding of the issues which needed to be addressed. It emerged that most of the success factors were not technical but rather centered around user participation. However, the objectives of this study was not to address all critical success factors relating to enterprise 2.0, but merely to gain an understanding in order to minimize the element of risk during development of the application designed. After identifying the risks involved an investigation into existing web 2.0 technologies identified that there is a plethora of tools available, some holding more significance than others. The research conducted help to drive the requirements of the proposed application, and the eventually definition of the enterprise 2.0 model. Implementing the enterprise 2.0 system posed many technological uncertainties, in order to define the most suitable solution to the problem a study was carried out, which identified the characteristics of the most applicable technologies.

14.2 Evaluation

The development of this project has shown that enterprise software is moving forward in to a new paradigm of rapid and agile collaboration, information sharing and the emergence and integration of extended capabilities. The use of second generation web tools is set to continue in gain momentum within the enterprise environment. This project aimed to demonstrate how the use of an architectural framework can help to accommodate the accomplishment of specific business goals. Although due to certain constraints such a time and cost the measure of the success is hard to gauge, as currently there is no opportunity for deployment in an organizational environment. However, with that said, the delivery of an extendible application has been achieved to some level of satisfaction considering the constraints which exist. The project has come a long way since the initial conception with an end result of a responsive and intuitive application. It is apparent that the rich internet applications are increasingly becoming a viable substitute to more traditional desktop software. This style of application is beginning to offer real alternatives to IT departments, who are seeking improved flexibility and lower costs. Although, the research carried out has shown organizations should carefully consider the most appropriate solution based on the strategy, industry, organizational structure and culture.

14.3 Future Work

References

  1. Finney.S & Corbett.M, ERP Implementation: a compilation and analysis of critical success factors. Business Process Management Journal 2007 - Whitepaper pg 316-337
  2. E. Driver et al. Road Map to an Enterprise Collaboration Strategy. Forrester Research, August 2, 2004.
  3. Building the Web 2.0 Enterprise - McKinsey and Company - Global Survey Results 2008 https://www.mckinseyquarterly.com/High_Tech/Building_the_Web_20_Enterprise_McKinsey_Global_Survey_2174 - Accessed on 10/02/2010
  4. Centers for Medicare & Medicaid Services, Selecting a Development Approach Original Issuance: February 17, 2005 Revalidated: March 27, 2008 http://www.cms.gov/SystemLifecycleFramework - Access on 26/01/2010
  5. T.Ahmed, J.Hirschi & F,Abid, Flex 3 in Action First Edition, Manning Publications Co, 2009 pg 14-18
  6. IEEE 1990. IEEE standard glossary of software engineering terminology. Technical report, IEEE.
  7. D.Alur, J.Crupi and D.Malks Core J2EE Patterns - Best Practices and Design Strategies, First Edition, Prentice Hall / Sun Microsystems Press, 2001
  8. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. - Design Patterns: Elements of reusable object-oriented software. Boston: Addison-Wesley 1995.
  9. T.H. Davenport, J.G.Harris & S.Cantrel Enterprise Systems and ongoing change Business Process Management Journel 2004 pg 121-131
  10. 10 most popular JavaScript Frameworks - Access on 17/03/2010 http://www.ajaxline.com/10-most-popular-javascript-frameworks

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!