CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

Phase 4 Individual Project Consultants Analysis Report on Enterprise Systems Shell David Haskins IT401-1202A-03 Professor Matthew Wilhite Colorado Technical University Online May 15, 2012

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

Table of Contents
Table of Contents....................................................................................................... 2 Introduction................................................................................................................ 3 System Requirements................................................................................................ 4 Basic Functions Category........................................................................................ 4 Account Services Category...................................................................................... 4 Transfers and Payments Category...........................................................................4 User Profile Category............................................................................................... 4 Nonfunctional Requirements................................................................................... 4 Architecture Selection................................................................................................ 5 Distributed Event Based Systems (DEBSs)..............................................................5 Java Enterprise Edition (JEE) Web Application Architecture.....................................8 Service Oriented Architecture...............................................................................11 Resources and Timeline............................................................................................ 19 Timeline for the Project with Milestone and Completion Times (expected time to deployment 16 weeks)........................................................................................... 20 Security.................................................................................................................... 23 Final Analysis and Recommendations......................................................................26 References................................................................................................................ 27 Brandon, D. (2008). Software engineering for modern web applications methodologies and technologies. Hershey, PA: Information Science Reference (an imprint of IGI Global)....................................................................................27 Cade, M. & Sheil, H. (2010). Sun certified enterprise architect for Java EE study guide, second edition. [Electronic Version]. Boston, MA: Pearson Education, Inc. Retrieved from Safari Books Online at http://proquestcombo.safaribooksonline.com/book/certification/java/978013136 3021/what-is-architecture/ch01.........................................................................27 Top Online Banking Threats to Financial Service Providers in 2010. (n. d.). Retrieved from http://www2.safenet-inc.com/email/2010/MITB2010/WhitePaper_Top-Threat-to-Financial-Service-Providers-in-2010_FINAL.pdf ........................................................................................................................... 27

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

Introduction
Enterprise architecture (EA) provides the supporting framework for a business applications and systems, the hardware infrastructure they are housed on, and the strategies used to manage the lifecycle of the entire arrangement (Godinez, Hechler, Koenig, Lockwood, Oberhofer, & Schroek, 2010). Enterprise architecture aligns the business and IT strategies and their implementation, resulting in a closely integrated system that sustains business functions. The overall system is used as a tool that links the business and IT strategies in support of the corporate mission. The design of the overall system, with the documentation detailing its components, their interactions, and the information that drives them, is also referred to as the enterprise architecture (Sessions, 2007). In this report the author details the creation of the enterprise architecture for Wells Fargo Bank, which has campuses across the United States. The project begins with the design of basic Web functionalities supporting online account creation, adding and removing of online accounts, the creation and maintenance of user profile information, checking and savings account activities and monitoring, viewing of online statements, bill pay operations, and system maintenance. The EA will be accessed by customers through the Web and ATM machines, by tellers and other banking professionals through the company intranet, and as needed by administrators and developers during construction and maintenance throughout the lifecycle of the system. The EA will be developed with the knowledge that, as project time permits, further functionalities will be added, such as the setup/personalization of mobile banking, financial planning programs, and other features previously only available at local bank branches. Applications used in departments such as marketing, sales, finance, and human resources will be integrated into the system concurrently to the implementation of the online banking is implemented. Actors include various users of the enterprise system. Bank management and various employees will access the system from the company intranet within campus facilities. System administrators and developers will access the system directly through computer terminals set up in the server room of each facility and through the ATM, intranet, and Internet portals for development and maintenance purposes. Customers will access the system through ATMs and over the Internet. The majority of customers that use the system will be of intermediate computer skill level. The public-facing Web site will be designed to target users with little or no computer experience, with shortcuts and other advanced functionalities implemented at every opportunity to cater to intermediate and advanced users. Wells Fargo, headquartered in San Francisco, California, has a reputation as a technological innovator (Wells Fargo, 2011). One in three households in the US does business with the bank. The Web site must handle loads accordingly, with the added burden of sending all pages using Secure Sockets Layer (SSL) for security. Compliance issues related to various government regulations will be a top priority.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

System Requirements
The following is a tentative list of use cases by category that will be supported by the new system (Higher One, Inc. 2012; Wells Fargo, 2012):

Basic Functions Category

Create Online Account Log In/View Accounts Summary Log Out

Account Services Category

View Account Activity View Statement Add Account Remove Account

Transfers and Payments Category

Transfer Money View Transfer History Pay a Bill with Bill Pay View billing and payments History

User Profile Category

Update Contact Info Change Username Change Password

Nonfunctional Requirements
The following nonfunctional requirements will be addressed by the system: Performance will be measured in response times. No transaction should take the system more than 3 seconds to respond to. Availability means the system will not go off line except for during planned maintenance activities for an hour each night. Other downtime due to maintenance activities must be scheduled in advance. Reliability is a system feature that supports availability. Clustering, failover, and other techniques will be implemented as explained later in this report. Security is of critical importance. Downtime must be investigated for data breaches, which would set off a chain of unfortunate circumstances such as audits and public disclosures, claims, apologies to customers, etc. Security will be implemented based on a system risk assessment. Details are given later in the report. Scalability will be a major concern and will be implemented horizontally with the addition of hardware and server instances as necessary.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

Extensibility is a major concern as more and more system functionality will be implemented iteratively. The system should remain extensible throughout its lifecycle so new functionalities can be implemented as business requirements evolve. Maintainability will be achieved so in house IT staff can take over operation and maintenance of the system at the appropriate time.

Architecture Selection
Application development is done by the composition of units of code that build functionality (Hinze, Cuchman, 2010). The units of code are called components and also go by the names classes, modules, or programs. Other components within a distributed architecture include JSPs, EJBs, and any other software component. Hardware architectural components include clients, servers, and the network infrastructure such as switches, routers, and cabling. Functionality provided by the interaction of components can be structured through procedural abstraction and implicit invocation. Procedural abstraction, or explicit invocation, is a form of communication between components where the name of the called service is known at compile time and is statically bound to the calling function. An example is when a process uses a remote procedure call (RPC) to invoke the functionality of a process located on a different machine. Implicit invocation involves the announcement of an event which will trigger another process to provide some type of functionality. The calling function may or may not know the function being called. In this report the author presents overviews of distributed event-based systems (DEBS), JEE ntiered Web applications, and Service Oriented Architecture (SOA), which are three distributed system architectures. Advantages and disadvantages of the distributed architectures are presented. Finally, the architecture for the Wells Fargo online banking system will be chosen.

Distributed Event Based Systems (DEBSs)

Distributed Event Based Systems (DEBSs) are composed of separate processes that interact through events announced implicitly. DEBSs are implicit invocation systems (IIS). Publishers are components that generate events. Subscribers are those components that are interested in the generated events. A system event model looks at the way event data is structured, how events are announced, how components show interest in particular events, and how the events are delivered to interested components. DEBSs use a publish/subscribe communication scheme and have the following characteristics: The system does not predetermine the types of events introduced to the system. New events can be added and those already present can be removed at run time. Event binding is how the system knows which components to notify in the case of an event. The bindings can be dynamically established or terminated. Events are announced when publishers invoke a publish operation. The publisher then goes about its business. Subscribers must register for the types of events they wish to be notified about. The system makes an attempt to notify all subscribers when an event occurs. Considerations for designing a DEBS include the format of the event declaration, when it is defined, and whether the language is extensible. Event parameters must be decided upon, which are descriptive attributes that are associated with the event. Designers must decide how bindings are created and how events are announced. If events are explicitly invoked then procedures must be created for publishing. A delivery policy will dictate which if not all subscribers are notified. Concurrency is an issue as with the design of any system.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

Event models are classified as peer to peer, mediator, and implicit (Hinze, Cuchman, 2010, p23). Publishers and subscribers communicate directly in the peer to peer model. In the Observer peer to peer pattern subscribers must know and register with the publishers of events they are interested in. Publishers maintain subscriber lists and send events directly to subscribers. Unlike the peer to peer Observer pattern, publishers and subscribers do not need to know about each other in DEBSs, and this is a characteristic of loose coupling in the system. Low coupling favors autonomous and heterogeneous components. The mediator event model uses a broker to deliver messages. In the Event Channel pattern components called mediators deliver events. A mediator delivers only one type of event and is called an event channel. There are a number of event channels so publishers and subscribers of a particular event type must be able to communicate with the appropriate mediator. The system is the broker in the implicit event model and must maintain information about subscribers and publishers of all types of events. The systems event vocabulary contains the list of event types that are announced over the system. The collection is considered either static or dynamic and if dynamic whether new event types need to be declared before publishing them. A system that predetermines the event types a component may publish has a fixed event vocabulary. A system that allows events to be added as needed has a variable event vocabulary. When new events can be added to the system but they must be registered before the system is operational then the system has a static event vocabulary. Systems with a dynamic event vocabulary can add new types of events at run time. The declaration of new events will be done at some central location or at multiple locations implemented as a distributed event declaration. For the events to be published they first must be declared to the system in most IISs. Once the broker has the event declaration subscribers must register as being interested in the event. The Java Event-Based Distribution Architecture (JEDI) is a DEBS with a dynamic event vocabulary. JEDI events are strings that include the event name and any attributes. JEDI event subscriptions specify names and any filtering arguments. IISs may permit attributes to be associated with events. Event attributes are also called parameters. If attributes are not supported then information describing an event must be deduced by the subscriber from the event name or retrieved using global variables, shared memory or fields in a database table, explicit invocation, or some other way. Java Message Service (JMS) is an example of an IIS that associates a fixed attribute list to each event. Messages can be codified in the body of a message as a string that translates to an XML document. Information about the event is coded as strings, a list of attribute/value pairs, a serialized object, a stream of bytes, or a stream of Java primitive data types (Hinze, Cuchman, 2010, p26). Subscribers must know how to decode the message. CORBA Event Service (CORBA ES) features a Generic Event Communication where the body of the event determines the type. With event-based aspectoriented programming (EAOP) the system has a fixed vocabulary with 4 event types: method calls, method returns, constructor calls, and constructor returns. Examples of attributes for a method call include the method name and values for the arguments passed to the method. The attribute values are decided statically or at the time the method call is made. Each event has a fixed attribute list in JMS. One of the attributes is used to map the event to relevant application data. JINI is a DEBS designed by Sun Microsystems. Each event has 4 parameters in JINI: event type, a reference to the publisher, the event instance number, and a hand back object, which is the java object the subscriber specified when registering as a listener to the event. As can be observed in object-oriented programming techniques such as inheritance and method overloading, methods and object calls can provide different services for the same call depending on the attributes. Event types are defined in an Interface Definition Language (IDL).

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

Event binding controls which subscribers are informed of an event in an IIS. DEBSs can establish or terminate binding dynamically. Attribute binding controls the value of attributes sent when an event is published. Roles can be used as an access control measure, limiting who can subscribe to an event. Implicit invocation systems (IISs) have a procedure that is executed when an event is published. Each method or constructor call as well as return values are events that happen at preordained times in a program. Database triggers cause events by calling a process as a result of views or modifications of data. Publishers may block until the event is delivered or processed by subscribers or they may continue execution. IISs that are centralized generally block until subscribers process events. In distributed IISs publishers do not block after sending an event. Most databases block when a trigger is set off until the process being called by the trigger finishes processing. Transaction management in distributed computing is performed in this way as all or none of the database transaction is executed. In UNIX any process generating events has a unique numeric process identifier and groups of processes are identified by a group identifier. Events can be addressed to a particular process or a process group. Addressing changes the degree of coupling between publishers and subscribers. There are IISs that do not use addressing when publishing events, instead relying the system to deliver the message to registered subscribers. Processes in DEBs explicitly publish events, do not block, and addressing is not used. If subscribers are not required to register for the events they are interested in the event will need to be broadcast throughout the system or sent to a shared memory location where subscribers can inquire if the event has been published. The IIS Linda is a system where subscriber registration is not required and a shared tuple in a database is used to collect events. Processes publish an event, which is delivered to the database, where it fills the record of a table. Other processes monitor the table and can read and/or remove events from the database. There are single events and composite events. Topic based subscription involves subscribers to feeds which are also categorized by types. A subscriber accepts an event based on the filtering of attributes values in content-based filtering. Filtering takes place at the component, at a centralized location, or at specialized servers. Contextual information such as the location of the publisher can be used to filter an event. Subscribers in a DEBS must register for events. The system supports single event notification, full notification, and content-based filtering of events. In single delivery of events only one subscriber is notified when an event takes place. Single delivery of requests works in server clustering. In full event delivery the event is delivered to all subscribers. Many DEBSs support full delivery of events and employ components called subscription brokers to rout events from publishers to registered subscribers. For reliable delivery of events the system needs a DBMS or some other way to reliably store the events. If one event is generated as a result of another the first event will be delivered before the second to any component subscribed to both events. When a subscriber is not available to receive an event the IIS can either persist the event for delivery at a later time or terminate the event. When the system supports event persistence, the event can be saved until all subscribers receive the event or the event can be given a time to live after which the message is dropped by the system. Most IISs only deliver events to available processes. Linda saves messages until either subscribers or publishers remove them. Oracle's Advanced Queuing stores events in a relational database. Each event can be given an expiration date. If there is no expiration date a process must explicitly remove the message. The system supports best effort delivery of messages so persistence is the only way to guarantee delivery. In the DEBS Rebeca local brokers manage client access to the system. The local brokers link to

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

router brokers, who deliver the message to its subscriber. History clients are special components that save event information that a client is subscribed to. When a process subscribes to the system it can request past events stored on history clients. The NaradaBrokering system saves messages and replays them upon request, while Rebeca only replays messages during the execution of the subscriber process. Notifications can be sent to subscribers by a call-back routine it is registered for.
Notification of published events can be immediate or deferred. Messages are pushed in immediate notification. Components that are processing one event when another subscribed event arrives can utilize a wait loop so they can continue processing the previous request. The process can then pull any events that have built up. DEBSs support pushing messages to subscribers. If not available subscribers can later pull any events that have been saved. Advantages of DEBSs include interoperability between processes and the encapsulation of the implementation. A disadvantage is the extra processing overhead required to connect different applications.

Java Enterprise Edition (JEE) Web Application Architecture

Where a designer is concerned with what happens when a user pushes a button, an architect is concerned about what happens when a thousand users hit the button (Cade, & Sheil, 2010). Artifacts that will be helpful when building Web architectures include: 1. System class diagram labeled with any public methods that appear in other diagrams such as sequence diagrams 2. Component diagrams showing interactions between subsystems-system components include EJBs, JSPs, and POJOs 3. A proposed deployment diagram depicting the physical tiers of the system 4. Use case diagrams with accompanying sequence diagrams and collaboration diagrams 5. Simple risk assessment for the top three risks to successful system implementation with risk mitigating alternatives It is critical the architect understands the nonfunctional requirements of the system such as performance, scalability, reliability, security, and availability (Cade, & Sheil, 2010, p10). The goal of architecture in a complex system is to break the system down into components that can be worked on in separate groups. Traditionally, architectural tiers include the Client, Web, Business, Integration, and Resource tiers. The client tier includes a system managing user display and interaction. The Web tier includes personalization and aggregation services for user interfaces. Assembling content for view, formatting, and other presentation activities are performed in the Web tier. The business tier houses the business logic of the system such as authentication and transaction management services, the delivery of mail, order entry, customer, payment, and inventory management processes, etc. The integration tier connects the system to information resources. Software called middleware implements queuing, publish/subscribe schemes, and synchronous and asynchronous communications are supported in the integration tier. The resource tier includes databases and external data feeds that provide data to the system. A layer is a hardware/software combination that hosts the services within a specific tier. Layers provide well-defined borders and interfaces similarly to the way tiers do. The chains of processing that make up tiers span components. Layers map components to containers. Typical layers include the application layer, which brings together user functionality with business logic. The application layer is the most visible to the user and is unique in every system. The virtual platform layer is made up of component APIs that provide interfaces to the middleware of the application infrastructure layer. Java EE APIs including EJBs make up this layer, on top of

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

which is built the application. The application infrastructure layer provides containers that house the middleware. Glassfish is an example of an application infrastructure container. The enterprise services layer is the operating system with any virtual machines that run over the compute and storage layer. The compute and storage layer includes the hardware of the system architecture. The networking infrastructure layer encompasses the networking components including network interfaces, routers, switches, load balancers, connectivity cabling or fiber, and other networking elements. The system architecture must address requirements for performance, scalability, reliability, availability, extensibility, maintainability, manageability, and security (Cade, & Sheil, 2010, p20). Redundant system components will support many of these requirements. Load balancing will address throughput and scalability as the system will direct requests to one of a cluster of servers based on a predetermined algorithm. Smaller machines clustered together give more processing power for handling large numbers of concurrent requests. Load balancing can be implemented at the network switches or as management software much closer to the server cluster, which allows more flexibility and manageability. Failover provides redundant hardware that will automatically pick up the load in case of a server failure, assuming the identity of the failed system. Failover can be implemented by designing for extra capacity or providing a standby server. Either way extra processing power is added to the equation as insurance against failure. Server clustering uses support software to manage requests for a server group. Clustering provides high availability and fault tolerance. With two-node clusters the configuration can be set symmetrically with both servers running or asymmetrically with the stand-by server. The clustered pair configuration places the 2 servers in a cluster, then combining two pairs under a single cluster. Each sever pair is configured in failover mode. The ring cluster will allow a node to replace either of its neighbors in the event of a failure within the cluster. The star cluster provides a single standby server that can replace any server that fails within the group. A scalable cluster allows each machine equal access to the data, which will be required to handle all the requests. Factors that affect performance are processing time and blocking time. Processing time includes the time it takes for data computation, data marshaling/unmarshaling, buffering and travel over the network. Blocking can be caused by resource contention or dependencies on other processes. Performance improvements can be made by adding processing power and writing more efficient code, locating nearby copies of data, and limiting the number of concurrent requests. Availability is affected by system downtime and long response times where the user thinks the system is down. Replication employs redundant hardware and software components to improve availability. In active replication a request is sent to all copy locations, synchronizing the entire system in one parallel step. In passive replication only the primary component responds to requests. Secondary components are synchronized after the primary component. Extensibility refers to the flexibility of a system to accept change. Extensible systems are a result of working with a clearly defined scope. Anticipation of change will make the changes easier to implement. Writing quality code using object-oriented techniques will improve extensibility. Scalability can be configured vertically by adding processors or disks to existing devices to increase the processing power. Adding servers will increase processing and memory by increasing the horizontal scale of the system. Horizontal scaling requires clustering software. The physical tiers of the system include the client, web server, application server, and database server. Multi-tier systems employ a web tier, business logic tier, an integration tier, and a data tier. Advantages of this type of configuration include scalability and availability as

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

10

clustering and failover techniques are utilized. Extensibility and maintainability are increased as functions are isolated in the tiers. Security becomes more complicated due to an increased number of vulnerability points. Performance is increased unless large amounts of data must be sent between servers. The formative design pattern in the JEE platform is the Mode View Controller (MVC) model. Views are realized by JSP pages that implement action handlers to collect user interactions with the application. A Servlet acts as controller and calls the action handler before the page is sent, possibly with data from the model, which maintains flow of control and business logic. A web container is a server side component that supports the controller and view by providing JSPs, servlets, filters, event listeners, and plain old Java objects (POJOs). Concurrency, transaction control, and configuration and security management are among the services provided by the web container framework. The JEE architecture is platform-independent and based on interactive components that are reusable. JEE provides a container for every component type. The container interfaces the component with low level support implementations that provide management of state, multithreading capabilities, and resource pooling, among other services. A servlet is a software component located on the server that handles inbound messages from remote clients and sends them to the appropriate event handler. Hosted by the web container, multiple threads can access the servlet concurrently. Filters are software components on the server side that are housed in the web container. Filters are the first to receive incoming messages and do preprocessing on the message such as security checks and logging of the event. Listeners are components that reside in the server side web container. When a message is received announcing a specific event the appropriate listener takes control of the thread and sends it to the associated process within the application. Java Server pages (JSPs) are HTML pages embedded with markup read by the web container at run time. Any processing is done to fill out the page and it is sent to the client to be viewed in their browser. The use of JSPs enforces separation of concerns by keeping the presentation and business logic separate. The Java Standard Tag Library (JSTL) is a collection of tag libraries included in the JSP specification. The tag libraries allow for control of page content and improve the functionality of the presentation layer. The Unified Expression Language (EL) is the answer to the need to banish scripting on the JSP page, which violates the separation of concerns principle. EL commands within JSTL tags allow the JSP to communicate with server side processes. JSPs deal with the presentation of data to the client and should not have business logic unless it is contained within JSTL tags and written in EL. Web centric applications deploy only the web container and no Enterprise Java Beans (EJBs). Web-centric applications should only be deployed where an existing application is already web-centric, ease of development is critical, or where transactions are not important to the business processes. EJB-centric applications should be built for scenarios with strong requirements for security, messaging, or transaction management. EJBs are server side software components that are used to encapsulate a particular portion of business logic. There are many types of EJBs, but they all represent information that has its own container and can be accessed regardless of location through a well-defined interface. EJBs are configured by adding metadata annotations to the source code with parameters assigned to variables provided by the container. The following presents the major types of EJBs. Session beans are considered server side proxies that keep track of where the client is within a process. Stateful session beans maintain information about conversations with clients through many client requests. Applications that employ stateful session beans incur significantly more overhead than

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

11

those that use stateless session beans. Stateless session beans are the simplest of the EJBs and do not save any information about the client between messages. Entity beans are used to persist data. They are still supported but their functionality has been updated and replaced by the Java Persistence API entity classes. Container Managed Persistence (CMP) entity beans delegate to the container the tasks involved in persisting their state information. Code is generated that accomplishes the mapping of class variables to the database and include SQL commands. Developers should inspect generated code, especially during performance testing. Bean Managed Persistence (BMP) entity beans necessitate the developer hand code the SQL required to persist the data held in the class variables. CMP should be used over BMP to save time unless there are performance problems with the generated code. Entity classes are a new technology that combines plain old Java objects (POJOs) with annotations that tie in Java Persistence API functionality. Entity classes were designed for ease of use in development and this technique is simpler to use than CMP or BMP. An EntityManager class is the container that is called when persisting class variables with entity classes. When persisting data there are two general alternatives: utilize EJB containers or Object Relational Mapping (ORM) tools to auto generate code or write the code by hand. Generating code by hand allows more control but at the price of creating something that has already been coded. Either way a persistence pier needs coding out. Asynchronous messaging processing capabilities are provided by message-driven beans (MDB). An MDB can be used to process messages received from a JMS destination such as a queue or topic. MDBs require the implementation of only a single method so it is possibly the simplest of the EJBs. EJBs promote scalability through the pooling of EJBs for the control of concurrency. The exception is in the case of stateful session beans, which handle less concurrent users than stateless session beans. Security, transaction management, and concurrency control are the core features of the EJB suite. Persistency functionality can be provided with less development work through the use of Object Relational Mapping (ORM) utilities, Java Persistence APIs (JPA), or Container Managed Persistence (CMP) entity beans. There may be a price to pay in terms of overhead depending on the situation. Hand coded SQL executed over a JDBC connection will take longer to develop and while tight control over code may (or may not) produce the best performance. Prototyping, benchmarking, and testing can help find the right solution. Where changes must be made to the underlying data no advantage exists between using utilities and hand coding. Either way the persistence tier must be upgraded. Using EJBs shortens the development process. Hand coding is done in hopes of cleaner, more efficient code. Advantages of Developing with JEE technology include the ease of development using Integrated Development Environments to build Web applications. While IDE development tools manage much of the complexity, the main disadvantage of JEE Web applications are still their complexity and the required skill to design them properly.

Service Oriented Architecture

Service Oriented Architecture (SOA) allows a corporation to achieve agility in business through the utilization of decoupling (Jellema, 2010). Companies such as Wells Fargo Bank can be better equipped to adapt to opportunities and threats in a timely manner. IT departments that can allow their organizations the flexibility to adjust their strategies based on changing business requirements, regulations, or advances in technology. Corporations have a competitive advantage when they can make improvements to business processes more quickly and at a lower cost.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

12

Information management supports business processes, strategies, and financial management and requires the strong alignment of business and IT strategies. Enterprise architecture can provide a framework of IT solutions that access business information during the execution of business processes. Three basic views of the enterprise architecture are 1. The business architecture view defines the business processes of the bank system. Models for the strategy, role-based hierarchy, and key performance indicators (KPIs) are developed in the business architectural view. Primary processes including management and support processes are modeled. A high level approach is taken and the problem is broken down as more information becomes available. 2. The informational architecture view provides models of the data and the applications. Because applications from different domains and even organizations may interact with the data it is important that the data remain application independent. Canonical data models will facilitate interoperability, which will be discussed later. 3. The technical architecture view describes the network topology of the bank network. The model accounts for everything from hardware, software, and middleware and should be present in diagrams. Business architecture view describes relationships between departments within an organization and between the company and its partners. Strategies that have been put together by the bank are documented, with success factors for reaching goals. The system must meet these goals according to the success factors to achieve business objectives. Key performance indicators (KPIs) are identified to help measure the success of attaining identified goals. The bank board of directors is responsible for the strategy and several departments report to them. 1. Marketing department communicates both internally and externally to the business. Employees, customers and business partners may communicate to people in the marketing department through the internet. The bank Web site has different components including general information content and personalized account access. 2. Human resources department manages recruiting, employee assessments, and career planning. Goals are minimizing employee sick days and turnover and increasing efficiency by hiring good people. Bonuses can be awarded based on performance. 3. Information management is responsible for IT and how it aligns with business. Technology-oriented employees will work with business-oriented employees to talk about changes and new requirements. 4. Legal services deals with all legal issues in the bank from compliance issues to firing employees that do not work out. 5. Accounting, planning, and control budgets the strategy from the board of directors. Overhead and personnel costs, training budget, and active projects are tracked. Key performance indicators are metrics for the success of the system, such as those that measure customer satisfaction, income, costs, assets, investment, interest, and risk. The objectives in these categories will provide input for process improvements as the bank strives to be an industry leader. Information architectural view integrates the system after undergoing a major merge. Currently local bank transactions are processed and the results sent to the system at headquarters to update a master table every night. The local branches work with their own local data in the form of fragments, or partial copies taken from a master table. The exchange of information within and without the organization should be governed by universal standards.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

13

The responsibility of the IT department involves meeting business requirements with innovative functionalities based on technological advances that will provide a competitive edge. The goal is to provide a system that improves operations by reducing human errors, completing business processes faster, and providing useful metrics that can show where processes can be improved. IT can provide services that have business value and should try to achieve short release times, high quality, and low cost. SOA provides the agility to react to changing business requirements through the use of existing units of business functionality called services. SOA assembles new functionalities using existing building blocks as a base, adding new capabilities in increments, and exposing them as services that have well-defined interfaces and an implementation that is encapsulated. Business Process Management (BPM) is the administration of the ongoing business process optimization activities that include designing, executing, and monitoring business processes. Business processes entail human tasks mingled with automated tasks implemented through Web services. BPM integration with SOA attempts to provide high quality and tight control of the process flow, facilitating the low cost of change. Event driven architecture (EDA) is a pattern that encourages low coupling between communicating systems using asynchronous communications that are driven by events. A generic mediator connects producers and consumers. Executing services in response to events allows for the change of components without an impact on processes outside of the component.
Service oriented architecture (SOA) provides a framework for organizing the functionalities of a system based on fundamental components called services. The services can interact with minimal dependencies. Services can be changed, relocated, or combined without impacting the system while providing rich, complex functions. SOA should be implemented in environments where increased competition, changes in regulations, and changes in business processes demand frequent and rapid changes to business processes. Organizational processes that reach across departmental boundaries and technical platforms require functional components that can be accessed where needed. External communications can be standardized and encapsulated in services. Proven assets of known quality can be reused for lower cost development.

A service is a set of capabilities or operations that are encapsulated and accessible through a well-defined, standardized interface. In this context services are Web services that are implemented using industry standards that are interoperable. Business services offer dedicated, possibly complex capabilities that support business process tasks. The services can be exposed to a department, enterprise, or a much wider audience. Elementary services have limited scope and are used as a base from which more complex services are built. CRUD operations within a particular department are examples of elementary services. These fine-grained services are not independently useful and are only locally exposed within composite services. Technical services include logging and exception handling that is required to support other services across domains. Business services for a bank would include a service that retrieves customer account information for a teller. Another example would be the functionality required for an account holder over the Internet to order checks and track the order. The bank may have partners in the insurance industry. Services in support of this relationship include formatting contracts sold to bank customers and sending them to the insurance company. Many internal services control, manage, and update customer bank accounts. A service can provide a group of related

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

14

functionalities such as those that make up a bill pay or a funds transfer. Customer relationship management services would have a birds-eye view of all this information in order to mine for useful data. Centralized services available across departments include email or letter printing and mailing. Service composition works like a mini application and it is a arrangement of elementary and utility services. A business process will be sequenced as a combination of human and automated processes that follow a flow of logic. A modification to an existing business process or the creation of new one becomes a simplified task of reworking the process flow by changing or adding calls to services. Because elementary services are reused, changes to implementation such as the structure of a database table would be implemented only once and correctly propagated to calling services. IT gets on the same page concerning the business domain during the development of changes, providing experience for the further evolvement of the system. In order to reuse code the company has invested in legacy applications, those functionalities must be exposed as services that can interoperate with other services. These sometimes large, monolithic applications that service functions across domains may combine user interface, business, and data logic where it can be difficult to decipher the separation of concerns. Changes to these types of systems often propagate to other areas, negatively affecting functionality. SOA is an architecture that must be well thought out as existing applications are to be service-enabled with considerations for a middleware infrastructure. The initial cost makes SOA an investment for the future with present benefits. Immediate benefits include a highly functional, highly componentized, low coupled system that can respond to change requests with higher quality and lower time to market and cost as the development process becomes more predictable. Components that have low coupling are relatively autonomous and make up a federation of identifiable stand-alone modules that can be deployed on various servers for optimal distribution of load. The components must be interoperable across applications and be able to connect across domains and technology platforms. System architecture looks at how the components of a system are organized and how they interact with each other and their environment. It is described with the principles followed by its design and evolution. SOA organizes the system in terms of services, which consist of a standards-based interface with the name, parameters, and return values of operations whose implementations do the work. The service contract is the definition of the terms of use of the service. Details concerning access control, fees charged, levels of service, and performance characteristics such as response times, availability requirements, and load capabilities are documented in the service contract. Service contracts promote reuse of services by providing for their discovery and understanding. The building of composite services automates interactions between the services, so they must be described in a standard way. The service contract contains the technical interface description, detailing operations, parameters, return values, and exceptions thrown. Supporting descriptions are given for parameters and return values. QoS details regarding the security, the concurrency load, required authorization, and reliability of the messaging is presented. The service level agreement (SLA) provides information about response times, availability, and costs of the service. Functional descriptions, intended users, future plans, and user satisfaction metrics are included in the service contract. Standards include Web service Definition Language (WSDL) and XML Schema Definition (XSD) for the service contract. Service interfaces are described using WSDL but the implementation can be written in almost any language. The service contract details quality attributes including and plans for the services

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

15

evolution. Tools such as WS-Policy, WS SecurityPolicy, and WS-ReliableMessaging can be used to standardize the QoS aspects of the service. Coupling is a very important concept in enterprise architecture. Technical coupling is the protocol used when sending messages and the format of the messages, such as XML, JSON, etc. Open standards of interaction reduce the level of coupling. Synchronous communications require a higher degree of coupling as both parties must be available for communication. Loose coupling makes the use of services in different sequences possible and allows services to be changed on an individual basis without causing change outside the component. Details of the service implementation, including location, are encapsulated. The service registry is an intermediary that facilitates discovery of services between publishers and subscribers. The registry publishes services using a standard that allows for dynamic lookup. Subscribers are given enough information about the functional interface, service contract, and SLA to know how to use the service. The granularity of the service can be described as fine grained, or of generic functionality that has little value of itself, to coarsegrained, providing a very high valued, specific use. Services must be atomic whether they are stand alone or composite. Highly concurrent services that are long running and require state should be transferred to machines that are optimized for handling stateful transactions. Sending data across the infrastructure should be done only when absolutely required. Layering the enterprise architecture separates the architecture into components based on specific characteristics such as responsibilities and dependencies. Each layer has its own standardization requirements: The application service components layer encompasses the implementation of the service. In the case of accounts management, the component that allows a user to perform activities against their account is the implementation of the accounts management service. The services and events layer includes the definition of the service contracts and interfaces. Hours of operation, authorized users, as well as descriptions of operations, parameters, and events published by the service are in the services and events layer. This layer forms a taxonomy which must be organized, as it helps structure all of the enterprise services. Services should be organized as elementary services, or those specific to a domain, technical services such as email and instant messaging, and enterprise services, which are business services that are exposed outside of their domain. Enterprise services reach across departments and even to partners and customers. A service repository governs the organization of this taxonomy of services. The business process layer controls business processes during the process analysis, execution, and monitoring stages utilizing Business Process Management (BPM). The analysis and documentation of business processes allows for solutions that include service reuse and parallel processing so unrelated services do not wait for each other. The GUI layer encapsulates the user interface logic. The GUI layer connects to the business processes and services layer to retrieve data and perform operations. An example would be a JSP page with an accounts summary. Clicking on an account number brings up another page with details about the particular account such as recent transactions. The GUI is the front end of tasks that are done to complete business processes. Web services have the potential to provide complex programs involving user interaction, business logic, and data components that may cross domains. The various user interfaces and the programs they interact with can be accessed by a form of the enterprise service bus. The enterprise service bus (ESB) addresses the challenge of providing loose coupling between services and consumers. Features of the ESB include:

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

16

Endpoint virtualization provides for location transparency as consumers call on the ESB and not the services directly. Service providers become interchangeable and consumers and services do not have to know about each other as the ESB manages the details. Services can be selected based on the request with content-based routing. Service providers do not always speak the same language as consumers. The ESB translates messages to a standardized format called the canonical data model (CDM) before delivering them. The ESB validates messages before delivery and can provide monitoring and logging functions. The ESB can provide guaranteed delivery of messages using various persistence techniques. The ESB can advertise services using an asynchronous or a synchronous interface. Queuing and store and forward techniques are employed to permit message delivery to unavailable processes. The ESB can compose the results from the execution of several services and deliver them as a single message. An ESB can also enable communication between processes utilizing different security protocols. For example a consumer utilizing an SAML token can send a request to a service provider that is using basic HTTP authentication. The ESB can also help improve: performance by caching results, availability by the facilitation of clustering, reliability of data through the management of transactions, authorization rule enforcement, control message loads, and monitoring of SLAs. Composing applications with services requires standardization in order to be interoperable. This is done by basing all service interfaces on the canonical data model (CDM). The CDM provides definitions for business objects described in XML Schema Definition (XSD). The CDM closely aligns to the domain language and should be managed by architects, analysts, and developers. Utility data definitions standardize the format of parameters, exceptions, and transaction reports. Translations are required between canonical messages and those that are noncanonical. Different domains may be required to have different CDMs so translation will be needed when crossing the boundaries. The enterprise-wide canonical model is a collection of data structure definitions for business objects with business rules are kept in a library of domain standards. It is best to translate data from foreign applications to the CDM as close to the application as possible using the ESB. Service governance includes aspects related to the ownership of service assets as this issue will appear during maintenance and development of composite services. The application of sound architectural principles is a cornerstone of governance to guarantee quality and ensure proper tracking of ongoing changes to architecture, design, and implementation. Governance defines proper change management processes. An event signals a change in the state of a business object (process) such as a database trigger being set off because of a transaction resulting in an account overdraft. These events may set off other events. A bounced check would set off a database trigger that sends a message to a service that will mail a letter to the account holder so they can address the issue. Other database triggers send messages to queues or logs when changes are made to the database. Processes send messages from events such as method and constructor calls at various points within a program. Events need enough information to serve their purpose: a login would require a username and password. The publish/subscribe pattern is the most common type of event-based architecture. The provider publishes the event and consumers that are interested in an event subscribe to it. The event can be signaled using different message standards such as text, XML, or Java objects. Events that should be published during business processes can be defined and used to monitor business activities using business activity monitoring (BAM). BAM presents real time data about process status and results. Events can be used to set off alarms. Missed loan payments send a message to a loan officer. Event patterns can lead to the creation of complex events.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

17

The following are considerations for building an architecture using SOA: Services, processes, and events characteristic of SOA require infrastructure such as an ESB and security tools. Introduced middleware will require administration and developers and administrators will need to know web service technologies. Since services are loosely coupled components, well-defined groups of services can be deployed on separate servers. Deployments will be numerous but more simplified than a single large application. Oracle SOA Suite 11g is components based and standards based. JDeveloper 11g can be used to develop Web services and other artifacts. Companies utilizing SOA continuously carry out small, incremental changes to the system based on the reorganization of business processes or the improvement of existing functionalities. Focus will be directed towards change management, automated testing, and deployment efficiency. Web services standardize interoperations between applications running on different platforms and/or frameworks. Interoperability and extensibility allow Web services to be combined to create complex operations as programs interact with the services. SOAP Web Services adhere to formal specifications for message formatting. Utilizing SOAP and WSDL operations, services, and data are specified for the exchange of data sent between services. SOAP provides support for multiple protocols and has features that include WS-Addressing, WSSecurity, and basic Profile. The disadvantage of SOAP is developers shy away from this formal, contract-based approach because of the extra overhead of the XML. Representational state transfer (REST) is more lightweight than SOAP. RESTful web services use HTTP-based APIs and send and receive relatively simple messages. REST is not often used for SOA. An enterprise needs a place to store and to publish information about Web services such as which services are available and where they can be accessed. Universal Description, Discovery, and Integration (UDDI) is a standard defining the publishing and discovery of SOA software components. The directory is formatted for browsing services. Many implementations of UDDI service registries are utilized for runtime discovery of service locations. Applications like Oracle Enterprise Repository provide an asset manager that defines the service inventory with the accompanying metadata for search operations and allows for view of service descriptions, status, and other information. Artifacts that will help simplify collaboration and reuse, including descriptions of canonical data models and service level agreements, are documented. Knowledge about the documentation structure should be provided to link artifacts according to dependencies in order to keep up with changes. Service registries are connected to the service repository. Industries use particular standards of message formatting and structure used to expedite the exchange, integration, and sharing of documents. One such standard is XBRL that defines financial reporting. Service Component Architecture (SCA) is a modern standard that models using SOA to build applications and systems. SCA is the framework upon which Oracle SOA 11g is built. Service Oriented Architecture will help Wells Fargo Bank build an enterprise system that will automate business processes for employees and accountholders alike. Elementary services are designed first that are fine grained and supported by a shared canonical data model for message passing. These lower level services are reused and combined in the building of more specialized business functionalities. Legacy processes can be wrapped and exposed as services. Standardized interfaces promote low coupled interoperability between processes and enable service reuse. Business agility results from low cost improvements and short release times for new functionality. Maintenance is concentrated as a result of high component reuse without duplicate functionality. SOA is based on open standards implemented as an event-driven

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

18

architecture that encourages low coupled messaging in the form of events, which every application uses throughout their processing and is a natural way to automate business processes. Processes that are registered can receive the messages sent from any application or service that implements a business process. This interaction allows for changes in the individual components without causing widespread effects. Now that the benefits have been specified the price that must be paid include high upfront costs to implementation, complexity and overhead from the XML tags in the messaging, which increases the size of messages. Application development is done by the composition of units of code that build functionality (Hinze, Cuchman, 2010). The units of code are called components and also go by the names classes, modules, or programs. Other components within a distributed architecture include JSPs, EJBs, and any other software component. Hardware architectural components include clients, servers, and the network infrastructure such as software, switches, routers, and cabling. Functionality provided by the interaction of components can be structured through procedural abstraction and implicit invocation. Procedural abstraction, or explicit invocation, is a form of communication between components where the name of the called service is known at compile time and is statically bound to the calling function. An example is when a process uses a remote procedure call (RPC) to invoke the functionality of a process located on a different machine. Implicit invocation involves the announcement of an event which will trigger another process to provide some type of functionality. The calling function may or may not know the function being called. In this report the author presented overviews of distributed event-based systems (DEBS) and JEE n-tiered Web applications, and the Service Oriented Architecture, which are three distributed system architectures. Advantages and disadvantages of each type of distributed architectures were presented. The architecture chosen for the Wells Fargo online system is SOA because low coupling and component reuse provides improvements in system functionality in shorter development increments enabling business agility. Initial costs will be recovered over time.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

19

Resources and Timeline

The following estimates represent a general view of the Wells Fargo bank SOA implementation. A new enterprise architecture and Web site will be created with functionality provided by SOA. The functions provided by legacy systems will be extracted and exposed through Web services. The new system will have all the functionalities of the legacy system with improved features. The system will be poised to take agile development to another level with a ROI time of 18 months after the full deployment. The biggest return on investment will be the result of future development cost savings. Customer satisfaction, convenience, and improved usability will strengthen the brand image. Resources List the resources required for the project Personnel Wells Fargo IT personnel will complete the project, utilizing six architects and developers working a type of freelance between projects, and six 5-man teams with the oversight and guidance of a consulting firm specializing in the implementation of SOA. Consultant SOA expert will come to the project 10 hours a week to oversee the project plan and architectural and design artifacts. Anything past that will occur on an as-needed basis. Architects an architect will work with each department system (marketing, finance, human resources, etc.) there will be 6 architects interacting with the project on an as needed basis. Developers one developer will oversee each department and interact with the project as needed, possibly working on more than one project at a time. Developers will design the system. Software engineers a software engineer will remain involved as an integral part of the project team. Programmers two 2-man programming teams will implement the code of the system. Each department team will employ 4 programmers using pair programming, peer review, and other agile development techniques that facilitate high quality standards. Hardware Wells Fargo system will be deployed mostly on the existing infrastructure. Two new servers will need to be deployed with the Oracle SOA Suit products mentioned below. Software -- The bank has been running Oracle systems including Oracle Service Bus, which provides the connectivity, Oracle WebLogic application Server, Oracle Web Tier (Oracle HTTP Server, Web Cache), Oracle Business Process Management, Oracle Identity Management (Oracle Internet Directory, Oracle Virtual Directory, Oracle Identity Federation, Oracle Directory Services Manager, Oracle Authentication Services for OS), Oracle Portal, as well as dedicated JEE enabled servers as part of the existing infrastructure. Software that will be purchased includes products from the Oracle SOA Suite 11g, the server software that will provide the framework for the Web services (Jellema, 2010). Oracle Enterprise Repository will be purchase to document the new SOA enterprise

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

20

system. Oracle Complex Event Processing will also be implemented for integration with advanced banking features. Resources necessary for project development The Wells Fargo development team uses Oracles own JDeveloper. The IDE is a good environment to build Web applications and services and is free. JDeveloper lets developers assign security policies that will govern access to the Web services. Security will be discussed in the next report. Word processing will also be used. The architects will collaborate on the architecture of the SOA enterprise implementation. The project will be separated into departments and each department is responsible for wrapping legacy systems functionality in Web services. An entire new faade will be rolled out with the newly implemented Wells Fargo Web site.

Costs Assigned to all Resources preliminary estimate total project cost:

$537,560 Personnel total cost: $359,200 Consultant $36,000 Initial payment of $20,000, then 10hrs /week* 16 weeks * $100/hr = $36,000 Architects $76,800 Six architects interacting with the project 20 hrs a week or on an as needed basis 3 * 40hrs /week* 16 weeks * $40/hr = $51,200 Developers $67,200 One developer will oversee each department and interact with the project as needed, possibly working on more than one project at a time. 3 * 40hrs /week* 16 weeks * $35/hr = $67,200 Software engineers $115,200 A software engineer will remain involved as an integral part of the project team. 6 * 40hrs /week* 16 weeks * $30/hr = $115,200 Programmers $64,000 Each department team will employ 4 programmers 4 * 40hrs /week* 16 weeks * $25/hr = $64,000 Software -- Oracle SOA Suite 11g products total cost: $168,360 Oracle Service Registry -- $46,000.00 per processor perpetual with $10,120.00 per year for support Oracle SOA Governance Edition -- whose main component is the Enterprise Repository -- $46,000.00 per processor perpetual with $10,120.00 per year for support Oracle Complex Event Processing -- $46,000.00 per processor perpetual with $10,120.00 per year for support Hardware two servers, 5000 * 2 = $10,000 Resources necessary for project development word processor, which is already part of the enterprise software that is available. The JDeveloper IDE is free.

Timeline for the Project with Milestone and Completion Times

(expected time to deployment 16 weeks) A major milestone of the project will come to pass at the end of the first iteration. Six weeks into the project an iteration will come to completion which will provide a Web site with basic

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

21

functionalities for each department. Much functionality will be added before the new Web site is published so there will be more iterations, each one a milestone. Wells Fargo IT Development will implement the Augmented Web Helix (AWH) agile software development process (Brandon, 2008). The following describes the process by describing a simulated walk through with planned milestones. The augmented Web Helix process model is described by rapid prototyping, incremental development processes, and minimal documentation. The first phase of the methodology is business process analysis. All business processes are cataloged. Supply chains are described. Were looking for processes to automate, of course. A business plan is outlined at a high level. Relevant information includes mission, customers, etc. The profit or justification that will come from the project is estimated. SOA will provide a significantly lower cost of application functionality development. One week will be the time for the phase because all functionality is present in legacy systems. Now the development team needs a solid architectural framework to expose the functionality using Web services. The second phase is the planning phase. Hardware, software, and Web application platform are chosen and the data storage technologies are defined. The project plan is defined. Add more detail to the business plan and refine the ROI estimate to determine whether the project should continue. A full set of requirements have been gathered through legacy system documentation. Features and iterations have been planned. By the first iteration the pages of the Web site will have been created. Much basic functionality will be complete in each department. The planning phase took a week as having the requirements was a boost. A week is spent, running time 2 weeks. The process now enters the helix at the Analysis phase. A requirements document should be complete. System requirements are traced to business requirements. Sample screens and a complete navigation system can be developed for the application at this time. Work can be done on entities and web components as well as database systems. Define detailed test criteria for the acceptance of the system. Look and feel of the Web site is decided upon. Continued work is done on the Web pages as screen features are defined. This phase took a week, running time 3 weeks. In design phase developers build a detailed architecture with diagrams and update the menu and navigation system. There should be an object diagram developed to begin work from. The Web pages and databases should be designed. The project plan should be updated with tasks derived from the architectural diagrams. The programming teams are assembled and the project acceptance criteria are updated. After design phase is concluded there is an evaluation phase where factors are developed to determine whether the phase is complete. The factors are simple yes, no, or unknown questions that determine acceptability of the stage artifacts. The database design is finalized, which will not change. Business classes are migrated for use in Web services. This step will take a week, running time 4 weeks. Coding and integration begins with programming selected objects. The Web site is developed, the code components are assembled and unit tested using teams of two for coding and refactoring. Test criteria for acceptance of the project are updated here as well. Coding phase evaluation is when factors to determine passage of the code are developed and applied to the system. If the code passes, testing phase begins. Screen prototypes have been created for testing. Back end code connects the functionality to the database. Time one week, running time 5 weeks. During the testing phase developers begin with structured walk-throughs of the Web site and functionalities. Code and integration should be tested using multimedia testing and automated tools. Acceptance testing is done with the customer. Developers put together the factors for

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

22

exiting the test phase evaluation phase. Testing of the implemented functionality of services and their accurate interaction with the database is started in earnest. Estimated time through the first iteration is 6 weeks, which will provide a Web site with basic functionality for each department. Implementing full functionality will take more iterations through the slices of the helix. When the system passes the testing phase it is either released or another slice is begun on the helix. Assuming a system is ready for deployment after test phase evaluation the deployment and training phase takes place. From there the job becomes system maintenance and upkeep. After each of the the design, coding, and testing phases a stringent evaluation process is applied to artifacts. Project evaluation framework (PEF) passes or fails processes and software artifacts at the end of the phases. Here are some factors or questions that can be applied to the system after testing phase: Release Y N U Testing successful Y N U Errors acceptable Y N U System works Y N U Requirements met Y N U Nonfunctional requirements met Y N U Reliability Y N U Efficiency Y N U Functional requirements met Y N U Bank Web site Y N U Business goals achieved Y N U Profitable Y N U ROI acceptable Y N U Improves customer relationships Y N U Continue Y N U Features to be added Y N U Features expected by customer Y N U Helps business goals Y N U Improves company image Y N U Feasible Y N U Technically feasible Y N U Feasible timeline Y N U Profitable Y N U ROI acceptable Y N U All of the factors must be yes to either go forward to another slice of the helix or release the system into production. Anything unknown stops progress if a solution is not found.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

23

Security
The top threats to online banking systems are related to fraud (Top Online Banking Threats, n. d.). Phishing is utilized to draw a user from a legitimate web site to a malicious web site where users mistakenly divulge credit card numbers and other information. Users must always use caution when entering personal information when visiting a Web site. Perpetrators will use whatever personal information they can get that will allow them to engage in identity theft. Man-in-the-middle attacks can initiate the redirecting mechanism that sends users to a malicious site, as well as false links that resemble an original. The use of SSL and PKI will thwart man-in-the-middle attacks. Database theft is where banking credentials are stolen and is an example of organized crime. Encryption of data on hard drives poses a defense against such occurrences. There is no doubt encryption and the use of PKI is an effective tool for protecting sensitive data in transit. The security problems mentioned are of critical importance to a bank with an online system. People are going to try to steal access to the system because a financial institution is a target. In the following report the author presents the way security is implemented to protect Web services utilizing role-based access control (RBAC) and the centralized administration of security policies that set rules governing their access such as authentication, authorization, nonrepudiation, and confidentiality requirements. The report is written on the assumption that Wells Fargo, with its present Oracle-based infrastructure and in-house IT specialists, is well-versed in network security and Web security basics. The use of firewalls, intrusion prevention and detection services, and antivirus software is elementary, as is network segmentation and the use of fixed routes. Certain file extensions can be prohibited from entering or leaving the network based on a centrally managed list. Hardening can be done on local machines by deactivating unnecessary features on the operating system. Network monitoring is used to ensure anomalies or mysterious changes in traffic patterns are not harbingers of unsettling things to come. The main difference between securing SOA and traditional enterprise application development is the increased machine to machine communications occurring between services (Jellema, 2010). Mechanisms for automated security controls are needed in order to uphold confidentiality, integrity, and availability (CIA), the pillars of information security. SOA implementations use ESBs, application, and middleware servers that participate in message transport as routing and delivery mechanisms. Identity management is responsible for the authentication and authorization of users and applications. Different rules apply to users and applications or other services. Identity propagation is the passing of credentials along a chain of objects for the purpose of authenticating and authorizing the object wishing to communicate. When the propagation and administration of privileges span more than one organization the mechanism of trust is created called an identity federation. Identity stores keep authentication and authorization information safe. A best practice is to use as few identity stores as possible and ensure they are centralized. Authentication identifies a user and associates them to an account, usually with a username and password combination. Single sign on (SSO) is a mechanism which improves usability where a user only logs on a single time each session. SSO is built on trust and can employ Security Assertion Markup Language (SAML) tokens to delegate the users identity safely and transparently. Identity and access management (IAM) encompasses authentication, authorization,

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

24

and identity management in an SOA environment. Services, like any information asset, should be assigned sensitivity levels such as public or highly confidential. Minimum security standards are assigned to the data depending on the sensitivity level. An example would be a confidential service being protected through the use of role-based access control and encryption. A best practice is to define classifications of assets based on security requirements and associate each classification with the appropriate security measures. Processes frequently communicate in an SOA environment using SOAP over HTTP and can be secured using secure sockets layer (SSL) or transport layer security (TLS). TLS can be used to secure messages delivered using HTTP, FTP, SMTP, and LDAP and can utilize one way or two way authentication. SSL and TLS use public key infrastructure (PKI) for two way authentication using digital certificates, a technology that employs hashes and encryption to protect data from tampering and nonrepudiation. Oracle WebLogic Server, Oracle SOA Suite products, and Oracle Web Services Manager (OWSM) support the enablement of HTTPS messaging using SSL or TLS. WS-Security is an important security standard employed through the policy-based security framework integrated with Oracle Service Bus and Oracle Web Services Manager. WSS secures messages utilizing SOAP messages, providing end-to-end security of messaging. WS Security ensures confidentiality, integrity, and availability of data. WSS uses tokens types for X.509, SAML, or Kerberos to propagate authentication credentials. Confidentiality and integrity are assured using PKI. Oracle Web Services Manager (OWSM) can help ensure secure communications between Web services in a composite service. Accessed from a management interface for Oracle Fusion Middleware 11g products, OWSM performs provisioning and identity management including for federations, authentication and SSO, and authorization. Server software along this line of products includes Oracle Internet Directory (OID), Oracle Virtual Directory, Oracle Access Manager (OAM), and Oracle Identity Manager (OIM). Web services policies define security settings for services such as requirements for inbound and outbound encryption. Oracle SOA Suite is best secured using the policy frameworks where services are secured using policies enforced by the above servers. Management consoles can be utilized to configure the policies and monitor activities such as failed logins. Three frameworks support policy-based Web service security, individual products within the Oracle Fusion Middleware Suite. OWSM policies secure Oracle Infrastructure Web services, which are composite Web services that form the basis of application functionalities. WebLogic Server is a JEE enabled application server that can assign policies to secure Web services. Oracle Service Bus can assign security policies to business and proxy services. Oracle advises using OWSM policies to secure services when there is a choice, as it is not possible to use both OWSM and Oracle WebLogic policies. Oracle Web Services Manager (OWSM) is accessed through the console of Oracle Fusion Middleware servers. The software secures the oracle WebLogic Server but no other vendors application servers. Oracle does have the connective software to provide the interoperability to secure other application servers as a tool offering. Policies provide specific functionalities that can be reused on more than one service and must be configured in order to secure services. Authentication is enforced using WS-Security from a policy set on OWSM. OWSM will capture incoming messages and enforce authentication by checking the user credentials in the message against the WebLogic Server authenticator, which uses Oracle Platform Security Services (OPSS) and an LDAP authentication database. Policy definitions are stored in the Metadata

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

25

Store, which is a database. OWSM Policy Manager is used to access the MDS, ensuring the centralized administration of security for Web services. Assertions are the smallest functional components of security such as authentication, logging, and encryption. Placing assertions one after another creates a policy, which is composed of at least one assertion. A policy could have an assertion for authentication and another for authorization. OWSM comes from the factory with pre-made policies but custom policies are supported by the configuring of assertions. The OWSM uses policies and assertions for security. Functions include the propagation of identity credentials including digital signatures. WSAddressing is a routing policy; Message Transmission Optimization Mechanism (MTOM) optimizes messaging between composite services by converting the messages to binary form, shrinking the messages. WS-Reliable Messaging policies provides orderly and guaranteed delivery of messages. Logging capabilities are offered by management policies. The top threats to online banking systems are related to fraud (Top Online Banking Threats, n. d.). Phishing, man-in-the-middle attacks, and database theft are just a few examples of crimes fraudulent activities that can affect online banking customers. The threats are very serious to the reputation of the banks. Security is implemented to protect Web services utilizing role-based access control (RBAC) and the centralized administration of security policies that set rules governing their access such as authentication, authorization, nonrepudiation, and confidentiality requirements.

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

26

Final Analysis and Recommendations

CONSULTANTS ANALYSIS REPORT ON ENTERPRISE SYSTEMS

27

References
Brandon, D. (2008). Software engineering for modern web applications methodologies and technologies. Hershey, PA: Information Science Reference (an imprint of IGI Global). Cade, M. & Sheil, H. (2010). Sun certified enterprise architect for Java EE study guide, second edition. [Electronic Version]. Boston, MA: Pearson Education, Inc. Retrieved from Safari Books Online at http://proquestcombo.safaribooksonline.com/book/certification/java/9780131363021/wha t-is-architecture/ch01 Godinez, M., Hechler, E., Koenig, K., Lockwood, S., Oberhofer, M., & Schroek, M. (2010). The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight. [Electronic Version]. Upper Saddle River, NJ: IBM Press Pearson plc. Retrieved from http://proquestcombo.safaribooksonline.com/book/databases/businessintelligence/9780137054947/the-imperative-for-a-new-approach-to-informationarchitecture/ch01#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODAxMzcw NTQ5NDcvY2gwMg== Hinze, A., Cuchman, A. (2010). Principles and applications of distributed event-based systems. [Electronic Version]. Hershey, PA: Information Science Reference (an imprint of IGI Global). Retrieved from Safari books Online at http://my.safaribooksonline.com/book/electrical-engineering/computerengineering/9781605666976/generic-architecture-of-complex-event-processingsystems/ch001#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODE2MDU2Nj Y5NzYvY2gwMDEA Jellema, L. (2010). Oracle SOA Suite 11g handbook. [Electronic Version]. Columbus, OH: The McGraw-Hill Companies, Inc. Retrieved from Safari Books Online at http://proquestcombo.safaribooksonline.com/book/databases/oracle/9780071608978/intro ducing-soa-stdot-matthews-and-the-oracle-soasuite/ch01#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODAwNzE2MDg5N zgvcGFydDAx Oracle. (n. d.). Oracle development tools. Retrieved from http://www.oracle.com/us/products/tools/index.html?ssSourceSiteId=otnen Sessions, R. (2007). A comparison of the top four enterprise-architecture methodologies. Retrieved from http://msdn.microsoft.com/en-us/library/bb466232.aspx Top Online Banking Threats to Financial Service Providers in 2010. (n. d.). Retrieved from http://www2.safenet-inc.com/email/2010/MITB2010/WhitePaper_Top-Threat-to-Financial-Service-Providers-in2010_FINAL.pdf Wells Fargo. (2011). Wells Fargo Today. Retrieved from https://www.wellsfargo.com/downloads/pdf/about/wellsfargotoday.pdf Wells Fargo. (2012). Retrieved from https://www.wellsfargo.com/