Docstoc

An EAI Strategy for AIS

Document Sample
An EAI Strategy for AIS Powered By Docstoc
					An EAI Proposal for AIS




Prepared by the AIS EAI Team
       Project Leader:   Carl Seybold

       Team Members:     Ed Hayes
                         Daryl Hoffman
                         Kathy DeMartino
                         Mary Lou Houck
Executive Summary ............................................................................................4

Enterprise Application Integration ......................................................................7

What is EAI? ........................................................................................................7

      Point-to-point integration ..............................................................................7

      Middleware-based Integration .....................................................................8

Types of Integration .............................................................................................8

      Data Level.....................................................................................................8

      Method Level ................................................................................................8

      User Interface Level .....................................................................................9

Why do EAI? ........................................................................................................9

The REAL Question about EAI...........................................................................9

Environmental Assessment................................................................................9

Business Requirements....................................................................................10

EAI Business Case ...........................................................................................12

      Example: Interface Calculation ..................................................................13

      Example: Cost Analysis .............................................................................13

Enterprise Architecture .....................................................................................14

      Metadata Catalog .......................................................................................14

      Method Repository .....................................................................................14

      Message Broker .........................................................................................15

      Application Server ......................................................................................15

      Web Services .............................................................................................15

Application Development ..................................................................................17

      Design Methodology ..................................................................................18

      Project Documentation...............................................................................18

      Code Reuse and Object Architecture .......................................................18




                                                                                                                         2
      Application Testing .....................................................................................18

      Source Code Control .................................................................................19

Recommendation for Implementation .............................................................19

The EAI Team ...................................................................................................21




                                                                                                                     3
Executive Summary

      Administrative Information Services (AIS) has been delivering business applications and
      data services to the Pennsylvania State University community for over 35 years. Current
      systems represent a diverse group of technologies that span several generations of
      progress. What began as a monolithic system has now become numerous islands of
      automation where business logic and data have become isolated from other systems
      within the enterprise.

      Early administrative systems were built on a single centralized platform. They were
      characterized by a single hardware and software vendor (IBM), minimal online access,
      and data storage in flat files and hierarchical databases. Logic and data were easily
      shared since all processes and data were accessible from the mainframe. With the
      advent of client/server processes and the World Wide Web, demand for access to these
      data processes and data sources from non-mainframe environments has increased
      dramatically. Enterprise Application Integration (EAI) is a process that will allow these
      newer systems to access the existing data and processes.

      The business requirements addressed by an EAI project must be examined from the
      frame of reference of an individual organization’s needs. There are 2 perspectives that
      must be considered - internal requirements and external requirements. The primary
      business requirements for both internal and external needs are data sharing and process
      sharing. The fulfillment of these business requirements leads to rise of new applications
      or systems that the EAI project can encompass. Naturally, this also dictates the
      examination of current systems for the possibility of replacement, re-engineering or
      obsolescence. The business case for EAI examines the impact and return on investment
      (ROI) of an EAI project. This involves a quantitative analysis of the estimated benefits for
      the direct implementation of an EAI project, as well as the qualitative analysis of any
      secondary benefits that arise from the implementation. For EAI, ROI involves the analysis
      of cost savings, productivity increase and increased customer satisfaction. Quantitative
      analysis of EAI projects shows a cost savings of as much as 45% of the acquisition costs
      of an EAI implementation in the first 3 months of production use.

      The EAI Team recommends that AIS take the following steps to implement an EAI
      Strategy:

          1. Adopt an enterprise architecture that consists of a metadata catalog, a method
             repository, a message broker, an application server and web services.

          2. Adopt J2EE as the application development environment including the creation of
             a Common Business Model using UML and object-oriented design paradigm.

          3. Establish an Enterprise Solutions Group to oversee the implementation of the
             new architecture.

          4. Implement a Proof of Concept that exercises the feasibility of the EAI Strategy.

      The enterprise architecture is the foundation of an EAI Strategy. Within the architecture
      are defined the items necessary to implement a complete EAI strategy. These items are
      referred to as components and are leveraged by the Enterprise systems to enable



                                                                                                4
application integration. The architecture also defines the components and diagrams the
relationships between these components. The components needed to implement an EAI
strategy are a metadata catalog, a method repository, a message broker, an application
server and web services. Each of these components performs specific tasks that an
enterprise needs in order to effectively integrate all of its systems.

At this point, making a decision as to whether to adopt a .NET or J2EE architecture is less
about functionality and more about environment. J2EE is far more open and the
specification is scrutinized by open source communities. This type of environment is far
more accepted within the academic communities throughout the country. Also, Java
expertise is a prized commodity that most software developers would benefit from
learning. The learning curve for Java is not easy and training a Java developer is not
cheap. Within AIS’s disparate systems the ability to run J2EE and develop with Java
gives the J2EE architecture a decided advantage over .NET. The IBM WebSphere suite
of applications is currently the most promising of all the J2EE implementations. However,
without thorough evaluation of the product suite through a proof-of-concept no
recommendation to embrace the product can be made.

With the transition to a distributed environment, expertise in almost a dozen programming
and scripting languages must be established and kept at a high level within AIS. The
ability to maintain applications over their lifecycle is compromised when the organization
does not have trained developers available for a project. Enterprise application integration
seeks to unify business processes and data while minimizing changes to existing
applications. It does not address issues involving the software development process,
toolsets and development platform. Successful creation of the Common Business Model
by definition must be independent of any programming language. However, there are
numerous advantages for an IT organization that adopts a single common development
platform. It would be very beneficial for AIS to adopt a single object-oriented platform for
application development. A single development platform must be complimented with the
adoption of a standard development paradigm that includes the use of the Unified
Modeling Language (UML) and object-oriented design methodologies to promote code
reuse.

AIS should consider the establishment of an Enterprise Solutions Group. Such a group
would be composed of Project Managers, Business Analysts, Enterprise Architects and
Technical Experts. The majority of large organizations that have embarked on enterprise
integration projects have established such a group. The successful team must contain
people capable of learning about and teaching others about the promise that technology
holds for the future. A successful team member dares to introduce new ideas and take
the risks that are involved with them. Above all, the team members need to be
communicators. They need the ability to communicate the ideas and concepts of the
team to all levels of the enterprise community.

The proof of concept goal is to demonstrate how an application could use web services
and message brokering to achieve sharing of business logic and data while keeping them
separate from the presentation layer. The front end application should be representative of
the technologies currently implemented by user offices for maximum impact. The
application server contains business logic in the form of web services as well as the
capability of managing application sessions. Some of the web services represent business
logic and rules; others would grant access to data. The message broker allows data
transfer and movement to be encoded into a persistent work flows. Communication
between the various entities conforms to the Simple Object Access Protocol (SOAP). The
recommendation of the EAI Advisory team is to implement a proof of concept using this
structure to link our eCommerce systems with existing systems. This proof-of-concept


                                                                                          5
would also serve as a test bed for the IBM WebSphere products to demonstrate their
functionality and analyze their usability. The user front end would be the commonly
requested external development environment, Cold Fusion.

The long term AIS strategy should be implemented in phases to reduce impact to existing
systems. The greatest investment of effort is in the analysis of current business systems to
understand data and data transformations, business processes and logic, and information
movement between systems. One approach to implementation is to complete all analysis
before any implementation of technology. Another is to concurrently implement
architectural changes while analyzing existing systems. The resources required to
construct the Enterprise Metadata Model, Common Business Model and Message
Catalog are extremely high since they involve detailed study of every system. Depending
on the availability of resources, the second approach offers the advantage of utilizing the
benefits of integration at an earlier date and minimizing impact on existing systems. with
the scarcity of resources available for new projects, a phased in concurrent
implementation is best for AIS.




                                                                                          6
 Enterprise Application Integration

The AIS EAI Team

         The Enterprise Application Integration (EAI) team was formed to research, investigate and
         recommend a strategy for how Administrative Information Services (AIS) does its business
         of delivering data and technology within the organization, and throughout the University
         system at Penn State. The main goal of the EAI project and the implementation of an EAI
         strategy are to integrate the many disparate systems within AIS, both data and
         processing. The team has looked at all of the different levels of EAI that could be
         employed here at Penn State and within AIS. These levels are data level, process or
         method level, and the user interface level.

         The first step for the EAI team was to investigate EAI frameworks and to learn what
         Enterprise Application Integration was and how it would affect business within AIS. The
         main source of information for the team was ―Enterprise Application Integration‖, by David
         S. Linthicum. Other sources included Sun.com’s internet site, IBM’s internet site and
         Microsoft. The two main frameworks currently available to deploy EAI are J2EE and
         Microsoft’s .NET.

         In doing the research, we looked not only at the products, but also at the white papers
         written to provide the pros and cons of implementing an EAI strategy. The products from
         IBM include Websphere and DB2. In addition, the team also downloaded the BEA
         Weblogic software to research which software would be easier to deploy and provide
         quicker development time to production capabilities. Several members of the group also
         installed Microsoft’s .NET Framework (Visual Studio .NET for application development
         and the .NET Framework for Internet Information Server (IIS)).

What is EAI?

         Enterprise Application Integration (EAI) is the process of integrating multiple independently
         developed applications so they work as one. EAI combines separate applications into a
         co-operating federation of applications. EAI will provide integration of a company’s most
         critical processes and data exchanges, both internally and externally, while being poised
         to take on new application or process development with minimal effort. Two logical
         integration architectures for integrating applications exist: Direct point-to-point connections
         and middleware-based integration.

         Point-to-point integration

         EAI developers pursue point-to-point integration because they find it easy to understand
         and quick to implement when they have just a few systems to integrate. A point-to-point
         integration example: One application makes direct JDBC (Java Database Connection)
         calls to another application’s database tables. Initially, when you integrate two
         applications, the point-to-point integration solution seems like the right choice; however, as
         you integrate additional applications, you get a situation where you have to maintain far
         too many interfaces between applications.

               number of interfaces f(n) = n(n-1)/2

         Considering that, point-to-point integration’s infrastructure proves brittle. Each application
         is tightly coupled with the other applications through their point-to-point links. Changes in



                                                                                                      7
          one application may break the applications integrated with it. As such, each additional
          application becomes harder to integrate and maintain. AIS currently employs this manner
          of integration. Since AIS maintains no less than 20 independent systems this would result
          in 190 different interfaces to maintain. This is the reason many AIS applications do not
          share data or processes.

          To avoid that problem, we need an intermediate layer to isolate changes in one application
          from the others.

          Middleware-based Integration

          Middleware has stepped up to the task of providing a mediation point between
          applications. Middleware provides generic interfaces with which all integrated applications
          pass messages to each other. Each interface defines a business process provided by an
          application. A service-oriented architecture lets you add and replace applications without
          affecting the other applications. If you have ten applications to integrate, you’ll have just
          ten integration points. Compared to the point-to-point solution, middleware-based
          solutions easily support numerous integrated applications and require less maintenance.
          In addition, middleware can perform complex operations—transforming, aggregating,
          routing, separating, and converting messages—on the data passed from application to
          application(s). The downside: the added initial complexity of setting up the middleware and
          converting existing applications to use the middleware APIs.

Types of Integration

          When contemplating EAI an organization must understand both the business processes
          and the data. Once the processes and data are understood, selections can be made as to
          which of these need integrated. There are three methods commonly employed to
          integrate applications.

          o   Data Level
          o   Method Level
          o   User Interface (UI) Level


          Data Level

          Data level EAI is the process, and the techniques, of moving data between data
          repositories. This can be described as extracting information from one database, updating
          it in another. Data level EAI involves the discovery of all data sources, documenting all the
          data within the data sources and creating am enterprise metadata catalog describing the
          data and its formats. This metadata can then be referenced to determine where data
          resides, what format it is stored in and how to convert between the different data formats.

          Method Level

          Method Level EAI is the sharing of business logic that exists within the enterprise
          applications. Facilities for sharing methods among multiple applications include distributed
          objects, applications servers, transaction processing and frameworks. Similar to Data
          Level EAI, for Method Level EAI a catalog of the shared processes is created to document
          and promote reuse of existing shared methods.




                                                                                                     8
         User Interface Level

         UI Level integration is more primitive than the previously mentioned methods. However,
         this style, also known as ―screen scraping‖, has been used for many years and is the most
         mature of the integration options. It is also the least desirable due to its poor performance,
         reliability and high maintenance. UI Level integration should be considered as a ―last
         ditch‖ option.

Why do EAI?

         Today’s analysts are asked to develop Enterprise wide solutions which span the
         academic, research, and administrative requirements of the University. This can not be
         accomplished in a vacuum it takes a concerted effort. This can only be accomplished if
         Enterprise Application Integration is being practiced.

The REAL Question about EAI

         Are you ready? Are you ready for profound changes to how AIS operates on a daily
         basis? That is what it will take to execute an EAI strategy at AIS, profound changes in the
         philosophy of developing and implementing business processes for AIS customers.


 Environmental Assessment

         Administrative Information Services (AIS) has been delivering business applications and
         data services to the Pennsylvania State University community for over 35 years. Current
         systems represent a diverse group of technologies that span several generations of
         progress. What began as a monolithic system has now become numerous islands of
         automation where business logic and data have become isolated from other systems
         within the enterprise.

         Early administrative systems were built on a single centralized platform. They were
         characterized by a single hardware and software vendor (IBM), minimal online access,
         and tape based data storage in flat files and hierarchical databases. Data display was
         done through printed media. There were two commonly used programming languages –
         COBOL and Assembler. Logic and data were easily shared since all processes and data
         were accessible from the mainframe.

         During the early 1980’s AIS began converting existing systems into the Integrated Student
         Information System (ISIS), Integrated Business Information System (IBIS) and Alumni
         Development Information System (ADIS) using a suite of mainframe based products from
         Software AG. 20 years later ISIS and IBIS still represent the critical core of the university’s
         administrative data processing. The two systems represent more than 1100 online
         applications and 20,000 source code modules. More than 20% of the 1,000,000+ batch
         jobs each year execute processes and maintain data in direct support of the ISIS and IBIS
         systems. While ISIS and IBIS have the ability to communicate with each other, each
         effectively exists on an island. Attempts to integrate them have been minimal.

         In the last 7 years, administrative computing at Penn State has followed industry trends by
         leveraging smaller and more open platforms for data storage and distributed applications.
         Motivation for building new systems came from the ability to deliver more intuitive GUIs,
         increased access to data, and more feature-rich applications. A new type of application



                                                                                                      9
      class has emerged with the increasing popularity of the World Wide Web – self service
      applications where users are able to view and modify their own data.

      Major portions of ISIS and IBIS have been reimplemented as distributed systems. At the
      same time other university departments have been building and maintaining local
      application systems on their platforms of choice. IT groups in other university departments
      are requesting increased access to institutional data stored and maintained by AIS for
      data marts and online applications. Penn State has also elected to partner with other
      educational institutions and vendors by purchasing prebuilt systems. AIS is involved in an
      effort to build an infrastructure supporting electronic payment processing and on-line
      stores. A listing of major client/server systems supported or maintained by AIS is shown
      below.

                                AIS Client/Server Systems
               WebIBIS     web access to subset of IBIS functionality
               ELION       self access to data for students and advisors
               ADIS        alumni reporting and update
               EIS         summary level student and financial reporting
               Angel       student course management system
               eDDS        view and download printed reports
               eISIS       web access to subset of ISIS functionality
               FIT/AIMS    client and web based financial system reporting
               Table 1

      The majority of institutional business data is stored in ADABAS (Software AG), a high
      performance nested relational database running on the mainframe. In the mid 1990’s AIS
      began a Data Warehouse (Microsoft SQL Server) to provide users with a more direct data
      access. Data Warehouse tables are populated and refreshed periodically using an
      Extract-Transform-Load (ETL) process consisting of batch jobs and ftp. AIS hosts
      additional database technologies as a result of partnership with other university offices and
      commercial vendors. These systems use data refreshed periodically from mainframe
      databases as well as internally generated data. Internally generated data is typically
      unavailable to other applications.

      A recent initiative, the Generalized Interface, attempts to unify isolated systems by giving
      access to data and business processes and data through a web service like architecture
      based on XML-RPC.


Business Requirements

      The business requirements that an EAI project addresses must be examined from the
      frame of reference of an individual organization’s needs. There are 2 perspectives that
      must be considered - internal requirements and external requirements. The business
      requirements identified lead to rise of new applications or systems that the EAI project can
      encompass. Naturally, this directs the examination of current systems for the possibility of
      replacement, re-engineering or obsolescence. Once new applications and the business
      requirements for them are documented, the new applications are mapped to the
      requirements that each will aid in achieving.

      Internal business requirements are requirements that the organization, in this case AIS,
      has to meet in order to efficiently and effectively perform its business objectives. For AIS,
      a significant requirement is the unification of the data. This requirement is of such



                                                                                                10
significance, that just a portion of it became one of the AIS imperatives, the unification of
ISIS. However, unifying the student credit and non-credit systems is only the first step.
The other systems should also share data in a uniform fashion. The reuse and sharing of
business processes within AIS is also an internal requirement. A simple example of which
is codeset retrieval and lookup from our existing systems. There exist several different
pieces of code that must be maintained, all of which do the same task, codeset retrieval.
Unified data sources and sharing of processes also aid in the fulfillment of the requirement
to promote reuse and lessen the maintenance burden of the staff. An EAI project also
addresses security issues through the provision of a standardized development
environment with reusable code elements that have security already integrated into them.
The security hooks can be integrated into the EAI components so that the application
developers do not have to concern themselves with the underlying security issues. These
business requirements are not all only internal issues, some also apply to external
partners.

The external business requirements include security, reuse and less maintenance like the
internal requirements. For these issues a loosely coupled EAI architecture would address
and achieve these external requirements. Additionally, the ease of accessibility through a
standard specification for accessing the AIS systems would increase the external
customer’s satisfaction. Promoting accessibility to AIS systems through an EAI project
could prove to be the most important requirement for the project.

The business requirements are achieved through the introduction of new EAI applications
and tools. One such application is to establish an Enterprise Metadata Model. The
cataloging of all data sources with as much information as possible to aid in data
extraction, translation and formatting. Similarly, business process sharing is accomplished
through the creation of a Common Business Model which details the business processes
that the AIS systems engage in and what procedures exist within the systems. A
Message Catalog system that identifies the messages that need to be passed between
systems and facilitates the passing of these messages would be needed as well. On top
of these systems, systems such as a Web Services interface and Enterprise Frameworks
for application development would facilitate the internal workings of the EAI architecture.

The applications identified can be mapped to the business requirements that each will
contribute to achieving. The mapping is shown in Table 2:




                                                                                          11
                                  Enterprise       Common           Enterprise   Message    Web
                                  Metadata Model   Business Model   Frameworks   Catalog    Services


       Unified Data                     X


 Business Process Sharing                                X               X            X          X


   Promote Accessibility                X                                                        X


   Secure Environment                                    X               X


    Less Maintenance                    X                X               X            X


     Ease of Access                                                                   X          X


    Component Reuse                     X                X               X            X


  Evolve Current System                 X                X               X            X          X


  Customer Satisfaction                 X                                             X          X


                       Table 2

           The advent of integrated systems may indeed lead to the elimination of some existing
           systems. These systems all deal with the extraction of data from the existing systems.
           Processes such as batch ETL, HYDRA server and the Generalized Interface would find
           limited functionality in an integrated enterprise.


EAI Business Case

           The business case for EAI examines the impact and return on investment (ROI) of an EAI
           project. This involves a quantitative analysis of the estimated benefits for the direct
           implementation of an EAI project, as well as the qualitative analysis of any secondary
           benefits that arise from the implementation. For EAI, ROI involves the analysis of cost
           savings, productivity increase and increased customer satisfaction.

           The most important ROI of an EAI project is in the reduced number of interfaces that are
           needed versus a point-to-point integration scenario. A point-to-point integration example:
           One application makes direct calls to another application’s database tables. Initially, when
           you integrate two applications, the point-to-point integration solution seems like the right
           choice; however, as you integrate additional applications, you get a situation where you
           have to maintain far too many interfaces between applications. The relationship between
           the number of applications and the number of point-to-point interfaces can be expressed
           by the function f(n) = n(n-1)/2

           In addition, point-to-point integration’s infrastructure proves brittle. Each application is
           tightly coupled with the other applications through their point-to-point links. Changes in one
           application may break the applications integrated with it. As such, each additional
           application becomes harder to integrate and maintain. To avoid that problem, an
           intermediate layer to isolate changes in one application from the others is used.
           Middleware architecture lets you add and replace applications without affecting the other



                                                                                                       12
applications. But more importantly, if you have ten applications to integrate, you’ll have just
ten integration points. Compared to the point-to-point solution, middleware-based
solutions easily support numerous integrated applications and require less maintenance.
As shown below in a graphical representation of a 6 system environment, the point-to-
point integration technique is far more complex than a middleware solution.

Example: Interface Calculation

Number of interfaces f(n) = n(n-1)/2                  Number of Applications = 6

         f(6) = 6(5)/2 = 15                                        f(6) = 6




                Point to Point                                  Middleware


          Figure 1




Thus, the immediate ROI for an EAI project of integrating 15 applications can be
determined as in the following example.

Example: Cost Analysis

    Number of applications = 15

    Number of Interfaces = f(15) = 15(4)/2 = 105

      1. Assume a single interface costs $1,000 to implement and takes 1 week in a
         point-to-point system.

      2. Assume a single interface cost $2,000 to implement and takes 2 weeks in a
         new EAI architecture.

      3. Point-to-point integration

                 a.    Cost:     105*1,000 = 105,000 dollars.

                 b.    Time:     105*1 = 105 weeks

      4. EAI Middleware integration

                 a.    Cost:     15*2,000 = 30,000 dollars



                                                                                            13
                      b.     Time:    15*2 = 30 weeks

       Thus, EAI architecture costs $75,000 less and implements in less than one third the time.
       Additionally, the more complex the system becomes, the higher the number of systems,
       the EAI solution becomes even more cost effective. A Gartner Group study of Enterprise
       Application Integration, ―A Model for Determining the Financial Benefit of an Integration
       Broker Implementation‖, concluded that organizations show a cost savings of 48% of the
       acquisition costs of an EAI implementation in the first 3 months of production use! Other
       costs that can be factored into the quantitative analysis above are opportunity costs. If the
       interfaces being developed would save the organization $1,000 dollars a week, the
       accelerated delivery time in EAI then saves the organization $75,000 that the point-to-
       point solution would not have been able to achieve.

       EAI middleware components, such as message brokers, provide a great amount of return
       on investment. When coupled with data integration through a metadata catalog and a
       web services front end for the consumers, EAI implementation achieves an increase
       customer satisfaction that can not be analyzed by numbers. However, it is clear that rapid
       turn around, component reuse and a standardized interface, Simple Object Access
       Protocol (SOAP), would increase overall customer satisfaction.


Enterprise Architecture

       The enterprise architecture is the foundation of an EAI Strategy. Within the architecture
       are defined the items necessary to implement a complete EAI strategy. These items are
       referred to as components and are leveraged by the Enterprise systems to enable
       application integration. The architecture also defines the components and diagrams the
       relationships between these components.

       The components needed to implement an EAI strategy are a metadata catalog, a method
       repository, a message broker, an application server and web services. Each of these
       components performs specific tasks that an enterprise needs in order to effectively
       integrate all of its systems. These tasks are defined in the prior requirements section.

       Metadata Catalog

       The metadata catalog is a collection of all data elements stored within the enterprise. This
       allows the unification of all data stored in all of the databases within in the enterprise. The
       catalog contains information about the storage format, name of the attribute, descriptions,
       security information, ownership, connected processes and integrity issues. This list is not
       complete and the only rule about metadata is the more you know the better. This catalog
       needs to be stored within a database that is accessible from the message broker.

       Method Repository

       A method repository is a collection of business processes that have been encapsulated in
       reusable chunks of code. The repository is used to keep track of these methods. A
       method repository must be accessible from an external entity allowing for the discovery of
       processes along with how to access the processes public interfaces. The Universal
       Discovery and Description Interface (UDDI) is a method repository system for web
       services.




                                                                                                   14
Message Broker

The message broker allows the disparate systems to communicate with each other. It
quite simply accepts messages from a system, the message producer, and passes them
to another system, the message consumer. However, message brokers also contain
message flows. Message flows allow for the transformation of data (based on the
metadata catalog) as well as the distribution of a single message to multiple consumers.
Message flows can also reformat a message into multiple sub-flows to allow for parallel
execution and the reuse of distinct pieces of flow logic. The workflows within the message
broker represent the contents of the message catalog.

Application Server

An application server is the home of the processes identified by the method repository.
This is where the code for a process actually executes. The application server can use
the message broker to communicate with other systems if necessary. The application
server also houses any web services that may be established to leverage the business
processes from an external source. While arguments exist as to the necessity of an
application server, in an enterprise system an application server is the most logical place
to integrate security for the systems. It also serves as a firewall against any external
threats; the threat would be to the application server, not to the critical business machine.

Web Services

Web services serve as the connection to any external entity. Web services based on
SOAP will allow connectivity to most existing and developing applications in a standard
interface. Along with SOAP, other standard web service infrastructure such as WSDL and
UDDI should be implemented to further enhance the ease of use and reuse of the
system’s processes within the application server. WSDL and UDDI become the systems
that implement the method repository. The following is a relationship diagram of the
above components.




                                                                                          15
                           External Systems



                            Web Services



                           Application Server

                           Method Repository




                                                             Mainframe

                               Message
                     I          Broker
                     n
                     t
                     e
                     r
                     n
                     a
                     l

                     S
                     y   Metadata Catalog
                     s
                     t
         Figure 2   e
                     m
                     s

The architecture presented is based upon the J2EE specification. Extensive analysis of
the J2EE specification and the .NET framework were performed prior to deciding upon the
architecture.

The J2EE specification from Sun Microsystems defines the interconnections and
containers in which each piece of an enterprise application resides. The specification is
very well defined and is well received within the computing industry. Many third party
vendors are implementing software packages that adhere to the J2EE specification. The
specification dictates that Java be used as the development environment. The vendor of
the tools can therefore be selected independently for each component. However, in
practice it has been found that most organizations pick one vendor for all components in




                                                                                      16
       order to prevent conflicts between the vendor components and to minimize component
       integration issues.

       The .NET framework from Microsoft defines a total Microsoft solution for application
       development. This too is very well received within the computing industry. The framework
       does not dictate the language used for software development and supports over 20
       different languages. The software development environment from Microsoft is heralded
       as the best in the industry. However, it is a single vendor solution that provides very little
       in the way of mainframe integration.

       The differences between J2EE and .NET are surprisingly few. Performance comparisons
       of the systems can and do show that depending on who is performing the analysis and
       who is writing the applications have more to do with performance than which overall
       architecture is used. Language and vendor choice appear, on the surface, to be important
       issues. But in reality, research shows that most .NET organizations use one language
       only and that most J2EE organizations use one vendor only. Thus both approaches in
       practice are a single vendor with a single language. The .NET framework contains a
       better software development environment, while J2EE has code portability from one
       system to another.

       At this point, making a decision as to whether to adopt a .NET or J2EE architecture is less
       about functionality and more about environment. J2EE is far more open and the
       specification is scrutinized by open source methods. This type of environment is far more
       accepted within the academic communities throughout the country. Also, Java expertise
       is a prized commodity that most software developers would enjoy learning. The learning
       curve for Java is not easy and training a Java developer is not cheap. But, it’s not cheap
       to train a developer in any language. Java can be used as the development language on
       PC’s as well as in the mainframe environment. Within AIS’s disparate systems the ability
       to run J2EE and develop with Java gives the J2EE architecture a decided advantage over
       .NET.


Application Development

       With the transition to a distributed environment, expertise in almost a dozen programming
       and scripting languages (Assembler, C, C++, COBOL, Java, JavaScript, Smalltalk, Visual
       Basic, Active Server Pages, Natural, and Perl) must be established and kept at a high
       level within AIS. The ability to maintain applications over their lifecycle is compromised
       when the organization does not have trained developers available for a project. In addition,
       knowledge transfer and assimilation never reach peak when developer time is divided
       among multiple languages.

       Enterprise application integration seeks to unify business processes and data while
       minimizing changes to existing applications. It does not address issues involving the
       software development process, toolsets and development platform. Successful creation of
       the Common Business Model by definition must be independent of any programming
       language. However, there are numerous advantages for an IT organization that adopts a
       single common development platform. It would be very beneficial for AIS to adopt a single
       object-oriented platform for application development.




                                                                                                  17
Design Methodology

Over time individual AIS application groups have adopted their own approach to
application and system design. As a result, there exists no well defined process for
designing software systems within the department. AIS should replace isolated and adhoc
design practices with a common design methodology based on currently accepted best
practices. Engineering disciplines frequently employ the concept of modeling to aid in
problem analysis. The software development process is no different. Models can be used
to represent the blueprint for a software system. Procedural and object-oriented languages
approach problem analysis from two different perspectives. Design for procedural
languages is based on algorithmic processes whereas the object-oriented viewpoint
attempts to construct reality based models. There are several object-oriented analysis and
design methodologies promoted by various organizations and vendors that specify a
predictable and repeatable process for modeling and design. AIS should evaluate the
prevalent design paradigms and select one or portions of several to create a standardized
departmental methodology.

Project Documentation

AIS should adopt a standard practice of documentation and specification for systems. The
Unified Modeling Language (UML) has gained wide acceptance as a graphical language
for design and documentation of software systems. Complementary views defined by the
UML (use case, class, sequence, relationship et al.) enable projects to be completely
specified from the design phase through the deployment phase. The UML was created to
be platform and vendor neutral and is tailored to be particularly useful in object-oriented
systems. Numerous vendors have built UML based toolsets to assist in the documentation
process.

Code Reuse and Object Architecture

AIS should identify one or more Object Architect positions to promote code reuse and
implement application frameworks. Reuse in object-oriented software systems is achieved
to a large degree through use of frameworks and design patterns. Frameworks are groups
of objects that act in cooperation to accomplish a complex solution. Frameworks define a
set of responsibilities and collaborations for a problem domain that allow the common
behavior of an application system to be abstracted. A pattern is a recurring solution which
occurs within some context. Patterns occur at a much lower level conceptually than
frameworks. Object architects should be tasked with the responsibility of understanding
the enterprise problem domains so that recurring code patterns can be detected. Object-
architects would also be responsible for establishing best practices for the chosen
programming environment.

Application Testing

AIS should create a reusable approach to application testing. Unit Testing is a verification
process under which developer’s code permanent test cases for domain objects created in
a software system. Each test is designed to return a pass or fail upon execution. At
intervals during the development cycle, the combined tests associated with an application
are run under a testing framework (http://www.junit.org) which provides a list of objects
which have failed their tests. The application can not advance to the next development
stage or be deployed to production until every object from the application passes the tests.




                                                                                         18
      Source Code Control

      AIS lacks an automated system for activities related to client/server application
      deployment and source code management. Application source code and assets (static
      html pages, images, etc) should be stored on a common repository which allows secure
      code check in/check out and versioning. All source code must be backed up at frequent
      intervals. Authorized individuals should be able to view the status of production versions
      at any time. There must be a secure automated process for moving application code and
      assets to the production environment. Approvals for transfer to the production environment
      should be obtained electronically. Once approved, production moves should be
      scheduled and coordinated through systems support.


Recommendation for Implementation

      The viability of the architectural recommendations of this document can be demonstrated
      with a proof of concept project using a vertical slice of the proposed architecture.
      Discussions within the EAI Advisory Committee suggested a trial based on the structure
      shown below.

                                        Application




                                       Application Server




                                       Message Broker




                                           Entire X
                                           Broker




                         Data                ADABAS             ECommerce
                         Warehouse



                                             Fgure 3



      The proof of concept goal is to demonstrate how an application could use web services
      and message brokering to achieve sharing of business logic and data while keeping them
      separate from the presentation layer. The front end application should be representative of
      the technologies currently implemented by user offices for maximum impact. The



                                                                                              19
application server contains business logic in the form of web services as well as the
capability of managing application sessions. Some of the web services represent business
logic and rules; others would grant access to data. The message broker allows data
transfer and movement to be encoded into a persistent work flows. Communication
between the various entities conforms to the Simple Object Access Protocol (SOAP). The
recommendation of the EAI Advisory team is to implement a proof of concept using this
structure to link our eCommerce systems with existing systems.

During implementation and upon completion of the proof of concept, the system can also
be used as a test framework for evaluating software products from different vendors. The
componentized nature of the architecture allows application servers and message brokers
from competing vendors to be substituted in the appropriate box.

The long term AIS strategy should be implemented in phases to reduce impact to existing
systems. The greatest investment of effort is in the analysis of current business systems to
understand data and data transformations, business processes and logic, and information
movement between systems. One approach to implementation is to complete all analysis
before any implementation of technology. Another is to concurrently implement
architectural changes while analyzing existing systems. The resources required to
construct the Enterprise Metadata Model, Common Business Model and message catalog
are extremely high since they involve detailed study of every system. Depending on the
availability of resources, the second approach offers the advantage of utilizing the benefits
of integration at an earlier date.

It may be expedient to focus on one aspect of EAI. Data integration is considered to be
less invasive than method level integration since it involves less modification to existing
applications. The proof of concept project would also be an appropriate time to examine
the process for building and utilizing metadata.

Concurrent with EAI implementation, there should be an extensive evaluation of
application development products and toolsets to determine the best fit for AIS. One of the
major criteria for product selection is the training process required to migrate an entire
department to a new programming paradigm. A substantial portion of developers within
AIS have no object-oriented experience. At minimum, all personnel participating in
application development will be required to obtain proficiency in the toolsets and language
chosen, object-oriented analysis and design, UML and SOAP.

Product selection for the various components of an EAI project must be done with great
care. Like the selection of any wide reaching system, EAI products must be carefully
analyzed and thoroughly evaluated prior to locking an organization into a product,
potentially for years.

Product usability is the most critical issue involved in product selection. Whether a
vendor’s products can be functional within a reasonable amount of time and whether or
not the staff using the products is comfortable with them can make or break a project.
Many people will be looking at the integration products 8 or more hours a day, and if those
people do not work well within the interface of the product, the product will fail. Vendor
stability must also be considered. A fully functional product from a vendor that does not
exist in 2 years is not a viable option for selection. Whether to choose a single vendor or
multiple vendors is also a significant issue. The use of a single vendor can avoid many of
the component integration issues of a multi-vendor solution. However, this also limits the
opportunity to shop around in the future. The decision is more often based on usability
and vendor stability than one vendor versus another. All products introduced will require a
certain amount of training. Training is expensive and time consuming. The more training


                                                                                          20
      that is required the less viable the product becomes. Finally, cost must be considered in
      making a final decision.

      Product selection is a long process and to fully evaluate and make a decision with any
      reasonable chance of success certain actions must be taken. Any potential product must
      be evaluated to determine if it will fit within the organizations environment and fulfill the
      desired functionality. Once products are selected as potential candidates, a proof-of-
      concept needs to be implemented. The proof-of-concept needs to exercise the product as
      completely as possible in order to evaluate the product. Once a set of products succeed
      in the proof-of-concept, then price comparisons between the remaining candidates should
      be the determining factor.


The EAI Team

      A successful EAI team must contain people capable of learning about and teaching others
      about the promise that technology holds for the future. These individuals need to be big
      picture thinkers with broad bases of knowledge that they can apply to new and evolving
      situations. A background in mainframe coding and maintenance of the interfaces into
      existing applications gives an EAI team member a unique knowledge base that is
      grounded in the real world situation of the enterprise. A successful EAI team member
      dares to introduce new ideas and technologies and take the risks that are involved with
      them. Above all, the EAI team members need to be communicators. The ability to learn
      new technology and apply new technology cannot be locked within the EAI team. They
      need the ability to communicate the ideas and concepts of the EAI team to all levels of the
      enterprise community.

      The team should consist of several positions with specific tasks. Each position may need
      to employ one or more individuals. While the responsibilities of each position cannot be
      known in its entirety until actual situations arise, some guidelines can be drawn. A team,
      any team needs a leader. This position shall be designated Project Manager. The project
      manager will direct personnel in the positions of Business Analysts, EAI Architects and
      Technical Experts. These four positions should be capable of performing the duties
      required of the EAI Team.

      The project manager oversees the project. Specifically, this position organizes and directs
      the others. This position is not a technical position, but rather a management position.
      Progress reports, project timelines, deadlines and milestones establishment are the
      responsibility of the project manager. The project manager also needs to take on a very
      prominent role in communications. Informative, training and educational sessions are the
      responsibilities of a project manager to organize, schedule and sometimes present.

      The business analyst oversees the process of ensuring that the customer needs are being
      met. This process includes customer interviews to determine requirements. Requirement
      gathering, however, is only the first phase. The requirements must then be examined to
      guarantee that they do not violate any University Policies or legal obligations of the
      University. The requirements must also be weighed against any and all internal business
      processing rules that exist within the current systems. All business rules and University
      policies affecting a system must be known and documented by a business analyst.

      The EAI architect oversees the adherence to the adopted enterprise architecture.
      Specifically, this position aids in the analysis and design of new systems to ensure that the
      new system is completely designed within the integration strategy. The architect is



                                                                                                21
responsible for performing an impact assessment and determining the dependencies of a
new system. This analysis then leads to the system impact analysis that also must be
done, how will a new system affect existing systems? Application and system design fall
under the realm of the architect, but are not wholly the architect’s responsibility. This
position is to serve as an advisor and leader of the implementation team during the
analysis and design process. This is the point where the architect can influence the
adherence to standards that have been adopted.

The technical expert identifies and solves any potential technical obstacles. This position
is responsible for proof of concept development to solve any and all technical issues that
may arise during the development of a system. The discovery process involves detailed
analysis of the integration details of any new system and its dependents. A technical
expert also serves as an advisor to any and all implementation teams that have a need for
their skills. This position requires a very strong technical individual in all aspects of the
enterprise development environments.




                                                                                          22

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:17
posted:11/14/2010
language:English
pages:22