Modelling Enterprise Architectures - Report Example

Modelling Enterprise Architectures Introduction Valentinos is a ‘Personal Information Agency’ which assists people to find suitable partners. It provides matching solutions for professional singles since, people are usually busy in their work and social life. Furthermore, with considerable number of personal preferences, it is quite difficult for an individual to find a perfect partner. Mission Statement At Valentinos, the mission is to provide a suitable match for singles. It is also committed to provide best value for money for its services. Business Benefits There are three business benefits provided by Valentinos namely: Value for Money: With respect to service and the number of people, Valentinos asserts to provide best value for money. The minimum value for membership in Valentinos is only £150 for one year. Proper information: There are several online dating services which use deceitful information in order to attract new members for taking membership. However, Valentinos evaluates the information provided by the users and judges its accurateness so that it can be ensured that every user is genuine. Enjoyable Services: Valentinos has strong communication system with several qualified employees who are always prepared to provide any kind of support regarding dating and matching. Furthermore, Valentinos also strives to recommend partners rapidly by reflecting their personal preferences. SWOT analysis The following figure represents the SWOT analysis of Valentinos. Fig 1: SWOT Analysis of Valentinos Over the years, Valentinos has attempted to make the services flexible. Furthermore, with the increasing number of users, the system operated by Valentinos also faces information overload. In order to be effective while providing dating services, Valentinos must effectively match on the basis of attributes selected by the registered users. The ranking attribute of users is quite problematic and usually requires users to allocate weight to each other of their necessities. Furthermore, since different users express things in different ways, in the end the users end up with large amount of irrelevant outcomes. Query proposition and query redrafting have been used in Valentinos for information recovery as well as to lessen the problem of providing proper suggestions to the customers. In order to fulfil the customer requirements, Valentinos necessitates a recommender system. However, with respect to the increasing number of multimedia profiles, it becomes quite difficult for Valentinos to provide quality services to the customers. Following is the PERT analysis of the recommender system. PERT Analysis Fig 2: PERT Analysis of the Recommender System Development of Project Initiation Products Vision Statement With this project, Valentinos will be capable of matching the partners effectively by considering their likings and dislikings. The system will be based on ‘collaborative filtering method’ which will help to recommend accurate match for different partners on the basis of the available information. Scope Diagram There are three broad scopes of implementing recommender system in Valentinos namely, component filtering, collaborative filtering and hybrid filtering (see fig 3). Fig 3: Scope Diagram of Recommender System Component Filtering: Recommender system is essentially a distinct kind of information sifting system which deals in proposing partners selected from large assortment which the users are expected to find exciting and valuable and also perceive as an arrangement job. In component based filtering model, recommender system selects the partners on the basis of the connection between different attributes and users’ preferences. Essentially, in this modelling system, recommendations are provided by comparing users’ profile with the component of every sort of information in the system database (Meteren & Someren, 1997). Collaborative Filtering: Collaborative filtering is also termed as social filtering. It has developed to recompense the boundaries of component filtering. The key thought of collaborative filtering is to choose and recommend people of interest for specific user orientation. This type of filtering is subjected to the belief of other users who have agreed in their assessment of certain attributes in the past and are likely to agree in the future as well. This method depends on simple assumption, which is a good way to find users with similar interests and afterwards to select or recommend people for dating (Brozovsky, 2006). Hybrid Filtering: Hybrid filtering system syndicates the two filtering techniques in order to obtain better performance with fewer problems. Hybrid filtering system can take advantage of both filtering system, i.e. representation of components and similarities among users in order to provide recommendations for dating partners. However, this method is quite costly and complex to implement (Burke, 2002). Potential Benefits and Costs The benefits of recommender system include the fact that it would minimise the searching cost for the organisation. With considerable number of registered users along with their huge provided information, this recommender system would be beneficial for Valentinos to match the extreme diversity of users. Nevertheless, in order to gain the desired benefits, Valentinos will be required to expend money on acquisition of software and hardware, installation charges and maintenance charges (Nooij, 2008). Requirements Catalogue Functional Requirements The recommender system will have ten functional requirements namely: Client Application: The client application should act as a link between the user and the server. Its task will be to collect information from the users and use them for matching. The user information is sent to server where it is saved and used for generating recommendation for dating. View Profile: The recommender system must deliver an interface that makes possible for users to view profile of others and see certain basic information. Observation: The new system is required to effectively observe the interaction between different users. As a result, it will help to identify the relationship between them. Evaluation: At the functional level, recommender system is required to evaluate every profile and send the evaluation report to the main servers. Store Evaluation Result: The system must be capable of storing the evaluation results for any future use. Request Recommendation: It is the primary functional requirement of the recommender system to take possible recommendations for partners. Recommendation through Filtering: The recommender system is required to provide recommendations by the evaluation of results. Furthermore, the system will also generate recommendations by understanding background information provided by the users. Security: The recommender system should also ensure that any kind of file or information provided to the user does not turn out to be spam and is free from any viruses. Choice: The system must enable the users to establish a basis for recommendation for their preferred partners. Control: The users should be able to properly control the privacy of their information provided to Valentinos. Furthermore, the system administrator will also be capable of monitoring the activities of users and controlling their profiles (Mortensen, 2007). Non-functional Requirements There are five non-functional requirements for the recommender system. Accurateness: The recommender system should generate accurate recommendations that match the requirements of the users. Intrusiveness: The recommender system should reduce the intrusiveness and simultaneously attract the users with adequate level of information. Accessibility: The recommender system must be accessible from several electronic devices without any geographical or time limitations. Reliability: There should be consistency regarding recommendations provided by the recommender system. Robustness: The recommender system must be robust enough to deal with the increased number of requests particularly during seasonal times. Evaluation: The system administrators are required to evaluate the performance of the recommender system on the basis of the feedbacks provided by the users (Javega, 2005) Use Case Model of the Required System Before developing the use case model, there is a need to identify the implementation procedure of the recommender system. The requirement for implementation process comprises recognition of use cases, specification of use cases, specification of requirements and class diagrams among others (Sessions, 2008). The actors recognised in the recommender system are partner seekers, system administrators and anonymous users. The partner seekers must be capable of creating account along with viewing the recommendations provided by the system. They should also be able to provide feedback to the recommender system through the way of rating the services, reviewing profiles and stipulating their particular interests. The partner seekers will get recommendations on the basis of profile information, search query information, relationship building opportunities and other background circumstances (Bennet et al., 2010). Fig 4: Case Model of Recommender System Concerning the system administrator, they should be capable of troubleshooting in case of any fault in the recommender system. Furthermore, the administrator also must be able to manage the information and evaluate the performance of the system. They will be able to adjust the recommender system in order to apply any new functionality and can implement different algorithms for better predication of dating partners as well. The following figure will show the use case for the system administrator. Fig 5: Case Diagram of System Administrator of Recommender System For the anonymous users, the system should be able to view similar users’ profile having comparable preferences. Furthermore, the anonymous users should also be able to obtain recommendations on relationship building opportunities. They would also able to read reviews given by the other users and provide feedbacks to the recommender system. The use case for anonymous users has been demonstrated in the following figure. Fig 6: Case Diagram for Anonymous Users of the Recommender system Class Model of the Required System The class diagram establishes relationship between different classes. A majority of the system punctualities has been represented in the class diagram of the recommender system. The key concepts involved in class diagram include index, objects, users, preferences and similarities. The information regarding users will be stored in the database and indexed appropriately. Information that is utilised regularly and modified often will be stored in disk as it will take less time to access information, reading file and querying database among others (Bennet et al., 2010). Index: Index signifies the list of likings for the recommender system. The application will provide users with different categories of likings for the users, through which similarities can be assessed. Objects: Objects represent the information items to be assessed and recommended by different users. This class contains preference vectors that represent the favourite objects of every registered user for the corresponding aspect. This vector will also contain binary values such as positive and negative preferences and integer values such as rating (Rojas et al., 2008). User: The user class represents registered users of Valentinos. They will receive recommendations for dating partner from the system. The user information will comprise user name, id, password and other personal information such as address, phone number and interests among others. Similarly, system administrator information will also comprise particular username and password along with other vital information such as registration number, website modification date, telephone number and nation among others (Rojas et al., 2008). Preference: Preference defines the explicit and implicit activities of marking any aspect as favoured by a registered user. For instance, preference enables to determine the rating of the service or visit of any particular profile or preference of any specific activity. It includes optional rating attribute, on behalf of the evaluation of aspects by associating the users. Similarity: Similarity demonstrates the resemblance between two users. The recommender system calculates on the basis of filtering algorithm, which compares the different vectors of two user profiles in order to obtain a similarity value (Rojas et al., 2008). Figure 7 demonstrates the class diagram by defining the structure of recommender system for Valentinos. Fig 7: Class Diagram for the Recommender System Modelling. There are several modelling methods that can be used in recommender system. However, for Valentinos, collaborative filtering modelling technique will be used in order to provide recommendations for dating partners. Collaborative filtering recommend for a specific user on the basis of the opinions of other users. It considers the agreed aspects and similar tastes of different users while recommending partners. The similarity of preferences of two users is planned on the basis of information provided and also historical activities of the users. Collaborative filtering model categorises the data on the basis of users’ belief, rather than information itself (Jones & Pu, 2009). Apart from collaborative filtering model, there are other alternative models that have been rejected namely content based filtering and hybrid filtering. The first reason for using this collaborative modelling is that the recommendations provided by this method is completely self-regulating and also it is conceivable to screen information from any source. The second reason is that in collaborative modelling, it is possible to filter and recommend users on the basis of profound and complex relationships. And, the third reason is that in this modelling, it is possible to obtain opportune recommendations for dating partners. The following figure demonstrates collaborative modelling technique for the recommender system. Fig 8: Collaborative Modelling Technique Human Stakeholder Aspects of the Project Factors of Accepting Recommender System The recommender system should be accepted by the key stakeholders, i.e. the users and the system administrators in order to be successful. The following factors could determine the acceptance of the key stakeholders. Perceived Usefulness: Perceived usefulness is defined by the level to which an individual believes that utilising a particular system can enhance the performance. Ease of Use: Ease of use is described as the level to which an individual considers that using a specific system is free from any effort. The recommender system must be simple to use, where users can find required information easily. Functionality: In order to be accepted by the users the recommender system must fulfil the key functional and non-functional requirements. Reliability: The recommender system should be reliable in case of any mistake or fault so that users can recover the valuable information easily and rapidly. Furthermore, the users must be capable of troubleshooting the system in order to fix any problem. Design: The interface of the recommender system should be attractive in order to be accepted by the key stakeholders. The system must provide information with clarity and the interface is required to be enjoyable for use. Learnability: The recommender system should be simple to learn. Adequate information must be provided with easy understandable language so that the administrators and other users can use the system without possessing any deep technical knowledge. Satisfaction: Finally, the recommender system must be capable of satisfying the key stakeholders. It should provide an enjoyable experience and fulfil the main objectives (Jones & Pu, 2009). Potential Problem Situation Arising From the Implementation of Recommender System There are several aspects which can generate problem for implementation of recommender system which has been defined in figure 9. Fig 9: Potential Problems of the Recommender System Implementation Compatibility: While implementing the recommender system, problem can arise due to compatibility of the system with the business process. In order to be successful, there is a need to transit the old procedure with the new system. In order to deal with the compatibility issue, proper planning must be done by including the role of people responsible for the changes in operations. Involvement: The other potential problem that might arise during implementation is low level of involvement. Thus, in order to make everyone with the business changes, there is a need to explain the project in details and how it will provide benefits to the organisation as well as the employees as a whole. Employee Resistance: In certain circumstances, employees might resist the changes as they are comfortable with the old business procedure. The implementation of new system might interrupt the acquaintance of conducting different activities and can make them distressed. Thus, in order to deal with such problem, the employees must be provided training so that they are able to understand their duties in the new system (Nikolaidou & Alexopoulou, 2008). Zachman Framework The Zachman’s framework provides a prescribed and organised mode of inspecting and defining a system. It delivers a mean of classifying enterprise architecture, comprising existing functions, components and procedures. As a result, this framework is helpful for managing changes in the usual process of the business. There are several benefits of using Zachman framework for the enterprise architecture namely, Improvement of professional communication within the new information system Recognition of risks of architectural illustration Positioning of extensive diversity of tools and methodologies Development of improved approaches to generate architectural representation and to rethink the characteristic of classic application improvement procedure (Nikolaidou & Alexopoulou, 2008; Raynard, 2008) Probably one of the key causes for the use of Zachman framework is the realisation that there is no sole architecture which meets the requirements of every stakeholder. Since different individuals have diverse requirements and complimentary viewpoints, a rich architecture is required for successful information system. The Zachman framework for Valentinos has been described below.   Data (What) Function (How) Network (Where) People (Who) Time (When) Motivation (Why) Objectives / Scope To enhance the recommendations of matching partner Providing dating services Identification and description of registered users in the UK Operational units, customer service units, financial units and marketing units New year, Valentine’s day, Christmas day and winter vacation Provide customers with proper matching solution with affordable price Business Model Semantic explanation of business procedures Conceptual model of dating service delivery Construction and interrelationship of users and system administrators Information system workflow Classification and timeline of services Personal benefits and quality services Model of the Information System Logical information model for user data Software architecture with functions and visions Connectivity architecture Information system interface architecture Various events Information system functional and non-functional requirements Technology Model Physical information model for user data Information system design, language and system description Comprehensive network architecture Information system interface architecture User information control architecture Information system operational requirements Detailed Representations Users databases Database management, filtering, finding similarities and recommendations Physical information network components, user addresses and other communication etiquettes Information system security architecture and business operational architecture Information system content, timing of services and description of facilities Technological requirements   (Working systems) Functioning Enterprise Database and knowledge base Collaborative filtering and comparison of user profiles Communication architecture Information system users description Matching schedules for dating Technical and functional requirements Table 1: Zachman Framework for Valentinos Conclusion The personal information agency business has gained much popularity in the present day context with increased business opportunities. With considerable number of registered users who seek to find their right partner, the analysis of users’ profile has become a challenging task for Valentinos. In this context, it can be stated that the recommender system will provide useful solution to vast amount of customers. It will effectively filter the different requirements of users and can make precise recommendations on the basis of diverse attributes. However, in order to be successful, the new information system is required to fulfil the functional and non-functional requirements along with considering the implementation issues. References Bennet, S., Farmer, R., & Mcrobb, S. (2010). Object-oriented systems analysis and design. India: McGraw Hill. Burke, R. (2002). Hybrid recommender systems: survey and experiments. Retrieved from http://josquin.cs.depaul.edu/~rburke/pubs/burke-umuai02.pdf Brozovsky, L. (2006). Recommender system for a dating service. Retrieved from http://www.occamslab.com/petricek/teaching/mt-onlinedating/colfi.pdf Javega, M. R. (2005). Content-based music recommender system. Retrieved from http://xavier.amatriain.net/PFC/mramirez-recommender.pdf Jones, N. P., & Pu, P. (2009). User acceptance issues in music recommender systems. Retrieved from http://infoscience.epfl.ch/record/142722/files/tr_accept_njones.pdf Meteren, R. V., & Someren, M. V. (1997). Using content-based filtering for recommendation. Retrieved from http://users.ics.forth.gr/~potamias/mlnia/paper_6.pdf Mortensen, M. (2007). Design and evaluation of a recommender system. Retrieved from http://munin.uit.no/bitstream/handle/10037/762/thesis.pdf?sequence=1 Nooij, G. J. D. (2008). Recommender systems: an overview. Retrieved from http://www.few.vu.nl/en/Images/werkstuk-nooij_tcm39-91406.pdf Nikolaidou, M., & Alexopoulou, N. (2008). Enterprise information system engineering: a model-based approach based on the Zachman Framework. Retrieved from http://galaxy.hua.gr/~mara/publications/HICSS08.pdf Rojas, G., Domınguez, F., & Salvatori, S. (2008). Recommender systems on the web: a model-driven approach. Retrieved from http://sol.inf.udec.cl/~adweb/docs/rojas.pdf Raynard, B. (2008). TOGAF the open group architecture framework 100 success secrets. United States: Lulu.com. Sessions, R. (2008). Simple architectures for complex enterprises: best practices. New Zealand: Roger Sessions. Read More