Document Sample
Revision Powered By Docstoc
					Enterprise Application Development
You understand this if you can:

• Summarise the module’s key topics
      • Enterprise Applications
      • Java Enterprise Edition
         • JSP, Servlets, session & message beans, entities
      • Enterprise Architecture
         • SOA, Web Services, BPEL
         • TOGAF, Zachman Frameworks
         • Business decisions
 Enterprise Applications
• What is an enterprise application?
  • An important program
  • Makes a significant contribution to a business
     • May include partners, suppliers, and customers
  • May involve
     • Distributed software
     • Multiple systems,
        • e.g. admissions, assessment
     • Multiple functional groups
        • e.g. admissions, teaching
UCLAN – Separate Applications
                 marks                                         allocation
                                    Records                                     Housing
  Module            enrolment                                                   Records
spreadsheet                                                   maintenance
                    Student Records System                                  Housing System

                           Data Duplication
                          Inconsistent User
                         Development Costs
                          Double data entry
                             Data Errors

Timetabling                                    budgeting
                  Exams &                                       Finance
                   Rooms                                        Records
Clash checking
                 Exam System                                                Finance System
UCLAN – Enterprise Architecture
                 marks                        allocation          maintenance
  Module                       enrolment
                   Student Records System                    Housing System

Common data model
Common communication structure
May use different languages
May have different developers
                                             Communication Framework

                Budgeting       Payment                           Timetabling
authorisation                                Clash checking
                            Finance System                        Exam System
Enterprise Architecture
• Architecture
  "The fundamental organization of a system,
    embodied in its components, their
    relationships to each other and the
    environment, and the principles governing
    its design and evolution."
                        ANSI/IEEE Std 1471-2000
 Aspects of Enterprise Architecture
• Business Process Architecture
   • Business strategy, rules, organisation, and processes.
• Applications Architecture
   • Individual applications, their interactions and
     relationships to the business processes.
• Information/Data Architecture
   • The structure of an organisation's logical and physical
     data assets and data management resources.
• Technology Architecture
   • The software and hardware to support the deployment
     of business, data, and application services.
   • IT infrastructure, middleware, networks, standards
 Enterprise Architecture Benefits
• Supports the business
  • Effective management and use of information
    can provide competitive advantage
  • Gives a structure for the business’s IT strategy
     • A framework for change
     • Allows individual sections to innovate safely within
       the framework
  • Improve efficiency
     • Make a good decision once
     • Not constantly remaking decisions
 The Container Concept
• Container provides services to components
  • Components do application-specific actions
  • Container defines an interface for components
     • Exchange information & requests

          Static              Request
          files                             Servlet
   Disk            Server

   GET or POST              HTML or other file
   Request                                        manages
                   Client                         servlet
Java Service Pages (JSP)
•HTML is static
            The time is 2:00pm

•JSP is dynamic
  • Program fragments executed on the server
            The time is <%= new java.util.Date() %>
JSP Tags
• JSP tags are like HTML or XML tags
  • Start tags, end tags, empty tags
  • Predefined (built-in) tags & library tags
  • Tag name comes from a namespace
• Hide programming details in XML syntax
  • JSP tags like sub-routines
  • Makes document clearer
  • Can be manipulated by designers
JSP Tag Example                            Use JSTL          Use to mark
                                          Tag Library
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib uri="" prefix="c" %>
  ""> <html>
   <c:forEach var="i" begin="1" end="10" step="1">
    <c:out value="${i} " />                           Attributes provide
   </c:forEach>                      Expression         “parameters”
   <br/>                            language “$”
   <% for(int i=1;i<=10;i++){%>
    <%=i %>                     Scriptlet
   <%}%>                          style
Why use a database?
• What is a database?
  • A structured, persistent collection of data
• Goal
  • Store information without redundancy
     • No unnecessary data (so backups are allowed!)
  • Don’t make any assumptions about use
     • Logical organisation should be flexible
         • Allow any relevant question to be asked
         • Physical organisation may make assumptions for efficiency

• Allows efficient storage of data
• Supports data management
What is a relational database?
• Uses mathematical concept of “relations”
  • A “tuple” or record links values together
     • E.g. Fred Smith 21 2 1999
• Tuples are grouped into relations (a table)
• Tables linked by the values they contain
  • Structure depends on data, not physical links
• Rules – normalisation
  • To ensure structure matches reality
  • To reduce risk of inconsistency
• Mathematically-based query language - SQL
The “Impedance Mismatch”
• Complex software systems use OO & RDBMS
    • Any database-driven web site
• The two technologies aren’t directly consistent.
    • There is an “impedance mismatch”
• Object-oriented programming
    • Using objects that have both data and behaviour.
• Relational databases
    • Store data in tables
    • Manipulate data with SQL
    Java Database Connectivity
•    JDBC
    •    Classes to access relational databases
•    Typical program structure
    1.   Connect to database
    2.   Obtain Statement object
    3.   Submit SQL queries using Statement object
    4.   Catch and handle SQL queries
    5.   Close the connection
•    RecordSet
    •    A collection of rows generated by a query
Java Persistence API (JPA)
• Our programs work with objects
   • We want to “load & save” objects
      • Use a container to hide the mismatch
• JPA maps relational data to persistent entities
   • Store objects for later use
   • An entity's state exists after the application ends
• Entity – a logical collection of data
   • Often represents some things in the real world
• POJO – “plain old java objects”
   • Objects that aren’t special – no special ancestor
    Annotations & Persistence
@Entity(name = "EMPLOYEE")
public class Employee implements Serializable {
 @Id                                   This class is persistent
 @Column(name = "EMP_ID", nullable = false)
 public Long id;
                                  Only needed if default not appropriate
                                              Example of
    private String name;             Convention over Configuration
    public String getName(){return name;}
    public void setName(String n){name =n;}

    @OneToMany(cascade=CascadeType ALL)
    public Collection<String> getPhoneNumbers(){ … }
    public void setPhoneNumbers(Collection<String> p)…}
 Approaches to persistence
• Programmer manages database
  • JDBC – Java API
    • Objects for using SQL with a database
• System manages database
  • JPA – Java API
    • Define mapping between classes and tables
       • Object-relational mapping
       • Uses annotations
       • Persistence unit
    • Manipulate objects
       • Using Entity manager
• Transactions are needed to maintain consistency
  • When threads comprise groups of actions
  • When there can be failure
• Distributed transactions are hard to implement
  • Uses locks – hide changes
     • Risk of deadlock
  • Uses transaction logs – ensure recovery after failure
• Run-time system supports programmers
  • Container-managed transactions
  • Bean-managed transactions
     • Use methods from transaction objects:
         • begin(), commit(), rollback()
Key Properties of Transactions
• Atomicity:
   • All or none of actions are performed.
• Consistency:
   • Afterwards, the database is in a permitted state.
• Isolation:
   • Overlapping transactions can’t see each other’s
     changes – only the before state or after state.
• Durability:
   • Results permanent, even if the system then fails.
Who’s in charge?
• Framework Application = Container + Beans
  • The container is the support environment
  • Beans (components) do the application-specific work
• Container-managed transactions
  • Container automatically creates transactions
  • Beans do not need to think about transactions
     • Except at configuration time (i.e. design time)
     • And to force a roll-back (at run-time, when something fails)
• Bean-managed transactions
  • Bean creates and commits or rolls back transactions
  What is SOA?
• Service Oriented Architecture (SOA)
  • Structure complex system around services
  • Build system from independent components
            Request                   Provider



 Web Services                                          Different systems,

• Supports interoperable machine-to-
  machine interaction over a network.
• Interface described in formal format
  • WSDL                   Web Services Description Language

• Use the service based on interface contract
  • Using SOAP messages,
  • Carried by HTTP with XML serialization
 XML-encoding of requests & responses
 Alternative less wordy protocols are       Represent linked collections
 becoming popular (JSON)                    of objects in a linear file
   Using Web Services
WSDL service

  IDE creates
control objects
  from WDSL                                           Directory service or
                                                     server returns WSDL

 Design Time

 Run Time         Program uses the control objects
                   to request and receive services
                       from the remote server
• Represent data in JavaScript notation
• Easy to convert to a JavaScript object
• Security risk if methods included
{ "Name": “Bilbo",                                           JavaScript
   "Age": 123,                                                Objects
   "PhoneNumbers": [                                Bilbo
     { “AtHome": true,                               123
        "Num": “01772 123456"
     { “AtHome": false,
        "Num": “01772 201201 Ex 12"
                                               JavaScript         true
                                                              01772 123456
   ]                                             Array
};                                                                 false
                                                            01772 201201 Ex 12
 SOAP/WSDL Web Services
  •   XML format
  •   Transferred using HTTP
  •   Request: method & parameters
  •   Response: result
  •   Wordy
  •   Difficult to parse – to convert to a usable object
• Alternatives
  • JSON – text representation of JavaScript object
  • Easy to convert to programmable object
  • But text can include methods – security risk
Publishing a Service: UDDI
• Universal Description, Discovery Integration
• A directory service (registry)
  • Businesses register and search for Web
  • Web service interfaces described by WSDL
• UDDI is a Web Service
  • Communicates via SOAP
• Supports distributed registries
Representational State Transfer
• The Web is made up of resources
   • E.g. the University defines a resource for each School
• Clients access the resource by a URL:

• A representation of the resource is returned
   • comp.htm
• This places the client application in a new state.
• A link in comp.htm accesses another resource
   • Therefore the client is in another state.
• The client changes (transfers) state with each
  resource representation  Representational State
REST Summary
• URLs represent resources
  • URLs generally look like nouns.
• HTTP Methods are actions - verbs
  • well-defined meaning when applied to a URL.
• GET used for queries, and only for queries
  • GET calls should never change server state
     • So responses to GET calls can always be cached
• Services should be stateless
  • Same request, same response
  • But can use cookies for authentication
REST Strengths
• Simplicity
   • Uniform interface is immutable
      • No change so it won’t break clients
• Proven scalability
   • “after all, the Web works”
      • caching, clustered server farms
• Ease of adoption (light infrastructure)
   • Just need a browser to get started
• Popular
   • Most clients prefer Amazon’s RESTful API (*)
   • Google no longer supports its SOAP/WSDL API
   • Yahoo only supports REST
REST Problems
• Lack of standardisation
  • Despite using URI, HTTP, XML, MIME, HTML
• Semantics/Syntax description is informal
  • user/human oriented
  • BUT WSDL 2.0 supports REST
     • A formal description of syntax
• Only synchronous semantics
  • Have to wait for the response
• How do you include applications
    REST vs. SOAP Summary
•   Can both provide access to a set of services
•   REST is data-oriented
•   SOAP is operation-oriented
•   REST is simpler
•   SOAP has more sophisticated extra services
•   SOAP defined with WSDL
•   REST traditionally informally defined
    • But WSDL 2.0
• More tools for SOAP development
    • Based on WSDL
 Business Process Analysis
• Designing the way a business works
  • Financial, commercial, systems expertise
  • Consider strategic decisions taken by top management
• Top-down approach
  • Analysts define processes to meet requirements
     • Functional: what it must do
     • Non-functional: quality of service, time constraints, profit.
• Bottom-up approach
  • Use existing assets to meet customer requirements.
     • Assets: people, databases, services, existing processes
     • Composing assets to provide new/improved facilities
  • Requires flexible and extensible services
 Problems of Enterprise Design
• Current systems isolated in departments
  • Focus upon supporting departmental functions
     • Functional departments: purchasing, sales, production
     • Not on business processes that cross multiple departments.
  • Integration problems
• Significant investments in existing systems.
• Current best business practice
  • Optimise business processes not business functions
  • Create information systems using existing systems
  • Don’t create competing or redundant applications
      More Issues for Enterprise Apps
    • EA designers have more problems
        • Service-level agreement (SLA) management
Quality  • QoS (e.g., performance, response time), costing services
  of • Auditing, monitoring, and troubleshooting.
Service  • Performance statistics, load balancing, fault detection
           • Legal monitoring
        • Providing dynamic services
           • Changing access rights, dynamic hardware allocation,
             installing/removing software “on demand”.
        • Service lifecycle/state management
           • E.g. start / stop services, reconfigure a deployed service.
        • Scalability/extensibility/reuse
           • Server farms, UDDI registry to publish services
  Designing a Service
• Services should increase business agility: flexible
   • Support reconfiguration and reuse
• Loose coupling
   • Dependencies are minimized and explicitly stated.
   • Stateless services not “conversational interaction”
   • Information hiding         Have a well defined purpose
• Cohesion
   • Services are cohesive, complete, and consistent
      • e.g. provide Create, Read, Update, Delete, and Search
   • Consistent design philosophy and interaction patterns
   • Services make sense for non-technical users
       e.g. WSDL/SOAP or REST
  Analysis and Design
• Service analysis
   • Identify business processes & services
   • Identify services to be combined into a business process
• Service design
   • Define style for composing services
   • Define goals & non-functional constraints
      • Service Level Agreements can be useful
   • Identify roles and responsibilities
      • E.g. admission tutor, deciding on academic suitability
   • Define interfaces for the processes and services
      • Platform-independent e.g. WSDL or REST.
      • Group service capabilities using coupling and cohesion criteria.
 BPEL & Business Processes
• A business process is a series of coordinated
  service calls and activities to produce a result
   • May involve one or more organisations.
• E.g. a business process for University Application
   • Applicants specify universities, courses, personal details
   • The process invokes a Web service at each university
      • The service checks qualifications and makes a decision
      • Invitations to applicant days are sent out
   • Applicants are notified and accept offers
   • Applicants enter their results
   • Web service confirms offer
• BPEL can’t model human activities
BPEL Components                              Business
• Programming logic                         Expression
  • BPEL language                           Language
  • A process is like a flow-chart
     • Each step in the process is an activity
        • Comparisions
        • Calls (invoke)

• Data types
  • XSD (XML Schema Definition)
• Input/Output (I/O)
  • WSDL (Web Services Description Language)
BPEL Process for Business Travel
                                                                             2: Request
         6: Reply                                                                                    Employee
                                         <<invoke(sync)>>                                             Travel
                                          Get travel status                       3: Reply
         1: Request                                                                                 Status Web
Client                                                                                                Service

                            <<invoke(async)>>      <<invoke(async)>>
        sync:                Request price A1       Request price A2
    – wait for the
                          [A1.price<=A2.price]     [A1.price>A2.price]
      response                                                                    4.1: Invoke
                                 <<assign>>            <<Assign>>                                     Airline
                                  Select A1             Select A2                                       A1
                                                                                   4.2: call back   Web Service
   Asynchronous                              <<reply>>
   – don’t wait for                       Return best offer
    the response                                                                   5.2: call back
                                                                       porttype                         A2
                                                                                                    Web Service
                                                                             5.1: Invoke
AJAX in Action                      Browser
                                  User Interface

           Browser               Event

          User Interface       Document Object Model
                             JavaScript        HTML
                             Call              & CSS
HTTP                 HTML
request              & CSS       AJAX engine
                             HTTP            HTML
            Server           request         & CSS

   Standard Approach          AJAX Approach
 Client-side facilities for AJAX
  • Represents a Web page’s elements as objects
  • Objects have methods and properties
     • You spend a lot of time reading the documentation
  • Can crawl over and change the structure/page
• JavaScript
  • An interpreted OO programming language
  • Functions can be triggered by events
  • Can access DOM of web page             Security
     • Browsers can behave inconsistently           Constraint
• XMLHTTPRequest Object
  • Can make requests to server that delivered the page
 Document Object Model
• Javascript interacts with the DOM
   • An API to manipulate HTML & XML documents
   • Can build and navigate documents, and add,
     modify, or delete elements and content.
 <tbody>                            table
    <td>0,0</td>                    tbody
   </tr>                 tr                       tr
    <td>1,0</td>   td         td            td         td
                   0,0        0,0           0,0        0,0
Enterprise Architecture Problems
  •Millions of requests per day
•Concurrency                                  Enterprise
  •Thousands of users                            Java
  •Large amounts of data
•Distributed           •Solve once
  •Finding resources   •Shared container handles system services
                       •Components for application specific services
  •Security risks           •Standard container/component interface
Container Concept
• A runtime environment managing components
• Instantiates and manages the beans
  Provides system-level
•Examples of Container Concept:services
   • Transaction management
• Enterprise Container
   • • Security EJB
       Containing                       interface
• Web Container of the bean
   • Persistence
     • Containing Servlets
   • Remote access to the bean
• Applet Container
     • Containing Applets
   • Lifecycle management of the bean
   • Database-connection pooling
   • Instance pooling for the bean
 Enterprise Application Layers
• The Client UI
• The presentation logic               User Interface Layer

  • Interacting with end-users.
• The business logic                   Beans

• The system services                  Container

  • security, caching, logging, transactions
• The data access logic
 Enterprise Java Beans
• A reusable, portable component
  • EJB methods encapsulate business logic.
     • e.g a method to update customer data in a database.
• Developed as POJOs, or Plain Old Java Objects,
  • Communicate with container by metadata annotations
• Runs in a container               Extra information about data
                                    Similar to the date a picture was taken
  • Developer focuses on the business logic
  • Container handles common complicated issues
     • Transaction support, security, and remote object access
• Key concepts       Not regarded as Enterprise Beans in EJB 3

  • Session Beans, Message Beans , Entity Classes
 Container Support
• Lifecycle
   • Manage threads, object activation & destruction.
• State Management.
   • Beans don’t explicitly save data between method calls
• Security.
   • Perform all security checking
      • Beans do not explicitly authenticate or check authorization
• Transactions.                    Actions join a transaction
   • Manage start, enrolment, commitment & rollback
• Persistence.
   • Beans do not explicitly retrieve or store persistent data
 Enterprise Beans Approach
• All enterprise apps have similar problems
• Break into layers
  • Use containers to provide common services
  • Use components to provide business logic
     • Session Beans
        • Synchronous interaction
     • Message Beans
        • Asynchronous interaction
     • Entity Classes
        • Persistence to relational database

      What are Annotations?
@   @Stateless public class PayrollBean implements Payroll {
        @Resource private DataSource empDB;
         public void setBenefitsDeduction(int empId, double deduction) {
         Connection conn = empDB.getConnection();
                                                   Dependency Injection:
                                                   Actual database will be
                                                   provided by the container
                                                       at run time
    • Annotations can have parameters
        • A list of element-value pairs.
    • Do not directly affect program semantics
        • Affect how programs handled by tools & libraries
             • This can affect behaviour at run time
 Dependency Injection
• Container supplies an object's dependencies
  • The object doesn’t request these resources explicitly
     • E.g. doesn’t look them up in a naming (directory) service.
  • Hides creation & lookup of resources from application
• To request injection of a resource, a component
  uses annotations or XML configuration file
• Example resources
  • EntityManager
  • Other enterprise beans
  • Web services
  • Message queues and topics
         Deployment Descriptors
  XML ...>
 <enterprise-beans>                  Details the need to
                                     Notice irrelevant: this
   <session>                         duplicate bean to
                                     links the information:
                                     various resources name
                                     e.g. the bean’s

•Can set up all sorts of things - complicated
Annotations vs. XML Descriptors
• Both can configure service-related attributes
• XML files processed separately from the code
  • Often at runtime
• Annotations are checked by the compiler.
• Verbosity:
  • XML configuration files are wordy.
  • XML duplicates information from code.
     • e.g. class & method names
  • Annotations are part of the code
     • Can be briefer
     • An example of the “Don’t Repeat Yourself” principle
   Annotations vs. XML Descriptors
• Robustness
   • Descriptors can fail at run time – less robust.
       • A misspelled method in XML file not detected until run time
   • Compiler may detect errors in annotations .
• Flexibility
   • Descriptors are easily changed – no need to alter code.
   • Administrators can configure at deploy time
• Normal vs. Difficult cases
   • Annotations easier to use and ok for most needs.
   • XML files
       • More complex but can handle more complex issues.
       • Can override default annotation values
       • Can configure external resources e.g. database connections
• Can call a new method around a bean’s method
   • Client calls business method
   • Interceptor actually called Call BM()      Call.proceed()
• The Interceptor can            Client   Interceptor            s Method
   • Monitor original call & parameters
   • the compiled program, BM()
   In Change parameters
   • Decide
   was called. whether to call the business method
   • dynamically intercept
   WeChange results the call
   and do extra processing. Interceptors
   can attach a interceptor
• Canbe added byan configuration file to:
   • annotations on the interceptor
   or A method, a bean’s method, all beans’ methods
 An Interceptor Class
public class Profiler {
  public Object chk(InvocationContext ctx)
      throws Exception {
      System.out.println("Method " + ctx.getMethod();
      return ctx.proceed();

Call the method: ctx.proceed()
  Actually calls the next interceptor if present

Access information about it: ctx.getMethod()
Access parameters: ctx.get/setParameters()
 Applying An Interceptor
public class CalcBean implements CalcRemote{
 public int add(int a, int b){return a+b;}
• Attaches interceptor to all methods
• Interceptors can be nested
          Call BM()              Call.proceed()          Call.proceed()
 Client               Interceptor 1           Interceptor 2               s Method
• Legal & commercial reasons for security
• Security is more than keeping secrets
  • Ensure data is consistent and available
  • Ensure users can do what they are entitled to
  • Ensure users can’t deny what they’ve done
• Difficult
  • Must be right all the time
  • Many possible sources of weaknesses
     • People, business processes, design
     • Implementation, networks, operating systems
Security Goals
• Confidentiality
   • Data is only available to those intended to access it.
• Integrity
   • Resources are only changed in appropriate ways
• Availability
   • System ready when needed and performs acceptably
• Authentication & Authorization
   • The identity of users is established.
   • Explicitly allow or deny access to resources.
• Non-repudiation
   • Users can’t deny an action they’ve performed
STRIDE Threat Model
       Threat             Affected property
Spoofing                 Authentication
Tampering                Integrity
Repudiation              Non-repudiation
Information disclosure Confidentiality
Denial of service        Availability
Elevation of privilege   Authorization
Using the STRIDE Approach
• Break system into relevant components
• Model the system with Data Flow Diagrams
  • Analyse components for susceptibility to STRIDE
  • Mitigate the threats.
• Consider threats that emerge when systems
  combine to create larger systems
  • Combining subsystems into larger systems may
    violate the assumptions of the subsystem
  • E.g. A system that wasn’t designed for Internet use,
    may have problems when exposed it.
DFD & STRIDE Analysis
            Spoofing                             Possibly safe
                                     Trusted      (Trusted)
Applicant                 Collect          Applicant Records

                Disclosure                  Tampering
                                      Information Disclosure
                                         Denial of Service

                                            Student Records
 Client        Server
Ensuring Security
• Organisational
  • Policies and practice
• Personal
  • Recruitment & training
  • Processes people can follow (e.g. passwords)
• Application
  • Security designed in the code
  • Freedom from bugs
Mapping users & groups to roles
                       Done by

                                       Done at run-

        Done by administrator in
      Application Server (Glassfish)
Application Level Security
•   Provided by component containers
•   Specific to the needs of the application.
•   Easy to implement and configure
•   Fine-grained control of functions and data.
•   Only protects in the application environment
    • Need additional transport layer security
• Firewalls can enhance application protection
    • Protect communications & resources from attacks.
Specifying Security
• Declarative Security
  • Define security using metadata.
  • Annotations
     • @XXX statements in code
  • Deployment Descriptors
     • Can override values specified in annotations.
• Programmatic Security
  • Code in the application makes security
  • Finer control than declarative security alone
Declarative Security: Descriptors
                            Give permission
 <method-permission>        to employee role
     </method>                  All Methods
                                 Specific Method
Declarative Security: Annotations
                           admin Only
public class SomeClass {
    public void aMethod () {...}
    public void bMethod () {...}
}                             admin Only

@Stateless public class MyBean implements
  A extends SomeClass {
    @RolesAllowed("HR")          HR Only
    public void aMethod () {...}
    public void cMethod () {...}
}                             Not specified
    bMethod will be
    admin only
 The Commercial Project Lifecycle
•Project Inception                    Technical aspects
  •The Initial Idea                     are important

  •Budgeting & planning                  Is the project
                                         worth doing?
  •Commitment of finances
•Performance & Monitoring
  •Doing it but watching costs, benefits & time
•Termination & Evaluation
                                        This is the main
  •Successful / Aborted                  technical area
  •Learning lessons
 Approving a Project
• Strategic issues
  • Consistent with vision and business principles?
  • Does it contribute to strategic objectives?
  • Valuable & affordable with an acceptable risk?
• Architectural issues
  • Is it technically feasible?
  • Is it consistent with the architectural
  • Does it fit with other developments?
 Approving a Project
• Delivery
  • Is there effective management?
     • Project & change management
  • Are technical & business resources available?
     • To implement the required capabilities
     • To manage the necessary organisational changes
• Value
  • Are the expected benefits clear?
  • How will benefits be achieved?
  • Can we measure progress
Financial issues
• Cash flow: timing of income & expenditure
  • Will I have to borrow before the profit comes?
  • No good knowing the winner if I can’t afford to bet
• Short payback period
  • Reduce risk, but is it a good long term investment?
• Return on investment
  • How much do I get if I risk £100
• Net Present Value
  • A bird in the hand is worth two in the bush
  • Take inflation and when I get paid into account
 Enterprise Architecture Framework
• Creating an Enterprise Architecture is complex
  • Technical, business and human problems
• An architecture framework guides the developer
  • Static snapshot of features / viewpoints   What the architecture
     • Ensure you’ve not missed anything out      should have

  • Dynamic – development processes & lifecycle
     • Speed up development                       How to develop it
• A guide for designing an information system
  • A set of building blocks
  • Rules for combining the building blocks
  • A common vocabulary
  • Recommended standards
  • Compliant products for implementing building blocks
Product and Process
• Issues for an enterprise architecture framework
• Product
  • Definition of the deliverables
     • Intermediate deliverables – specification, designs
     • Final products
         • Software, hardware, networks
         • Processes – what people do, policies

• Development Process
  • Guidance on development methods & techniques
• May not define specific methods or techniques
  • Just says what sort of things are needed (Neutrality)
TOGAF Process Support
• TOGAF Architecture Development Method (ADM)
  • Iterative approach
  • Developing an architecture to meet business needs
  • Views of aspects of the architecture
     • Let the architect check that requirements are addressed
  • Guidelines on tools for architecture development
  • Advice on choosing architecture assets
• The Enterprise Continuum
  • A "virtual repository" of all the architecture assets -
    models, patterns, architecture descriptions, etc
     • From inside and outside the enterprise and the IT industry
  Architecture Development Method
Techniques                                           Agreed technology components &
                                                       Select goals, services, support
                                                        Identify entities & relationships
                                                         Ensure management processes,
                                                   Business implementation approach
                                  Preliminary        Agree any other frameworks to use
  Requirements management
      Scheduling resources
           Gap modelling
  Entity/Relationship modelling   (Framework
                                     (Agree          Identify andscope & package)
                                                          Identify logical constraints
                                                            (buy, manage requirements
                                                             change introduction:
                                                                Plan protocols, standards,
                                                  dataupCreatedevelop,data model
                                                    relationships: management process:
                                                  Set model, location, and organisation
                                                               can use specific frameworks)
                                                   (TOGAF Agree development
      Cost/benefit analysis
       Use-case specification
        Trade-off modelling
          Volere analysis
    (e.g.Class modelling          & Process)
                                    principles)         Identification,building blocks
                                                            Create application model
                                                               Check assessing
                                                                Agree phased introduction
                                                  Assess dependencies, costs, process
                                                   throughout the against goals benefits
                                                   Parallel working/participants effect,
                                                                 architectural principles
                                                          AgreeDo development
         Risk class modelling
           Gap Analysis
   Businessassessment                             Technical keyvarious viewpoints: of
                                                  IterateCheckperformance, sign-off
                                                    Identify groups/locations involved
                                                     approval, previous steps if trade-offs
                                                       Which requirements requirements
                                                            over business (e.g. essential
                                                                Analyse trade-offs
                                                           Agree any changes to ADM
           Gap Analysis                              communication, &be&implemented
                                                      IdentifyTraining processing, costs
                                                       Prepare a vision of costs
                                                           between speed requirements
                                                                what change security)
                                                                      will its
                                                    Check non-functionalthe outcome
                                                      Check again businessdeveloped
                                                       Identify Secure approval plan
                                                         Develop implementation
                                                                 models to be architecture
                                                    Check against information systems
                                    Phase A
                     Phase H         Vision                Phase B

                                                                              Phase C
     Phase G
                                  Requirements                              Information
                                  Management                                  Systems

                    Phase F                               Phase D
                    Migration                            Technology
                    Planning                            Architectures
                                     Phase E
                                  s & Solutions
TOGAF Product Support
• The TOGAF Foundation Architecture
  • An architecture of generic services and functions.
  • The TOGAF Technical Reference Model (TRM),
     • A model and classification of generic platform services
  • The TOGAF Standards Information Base (SIB),
     • A database of open industry standards to define services
       and other components of an enterprise-specific architecture
• The TOGAF Resource Base
  • Guidelines, templates, etc. - to help use the ADM.
   The Zachman Framework
                     Inventory       Process        Network        Organisation    Time          Motivation
                     (Data)          (Function)                    (People)
                     What            How            Where          Who             When          Why

Scope                Business        List of        Business       Important       Important     Business
Contextual           things          business       Sites          organisations   events &      goals &
Strategist/Planner                   processes                                     cycles        strategies

Business Model       Business        Business       Business       Work flow       Master        Business
Conceptual           entities &      Process        distribution   model           schedule      Plan
Owner/Manager        relationships   Model          plan

System Model         Logical data    Application    Distributed    Human           Processing    Business rule
Logical              model           architecture   system         interface       Structure     model
Designer                                            architecture   architecture

Technology Model     Physical data   System         Technology     Presentation    Control       Rule design
Physical             model           Design         architecture   architecture    Structure

Component            Data            Program        Network        Security        Timing        Rule
Subcontractor        definition                     architecture   architecture    definitions   specification

Functioning          Data            Executable     Network        Organisation    Schedule/     Enforced
enterprise                           programs                                      events        rules
Evaluating Enterprise Frameworks
• Goals – aims of the framework           Issues that should
                                          be considered
  • Documenting the architecture          when evaluating a
  • Supporting development                framework.
• Coverage
  •   Process & Structure
  •   Stakeholder viewpoints
  •   Modelling: advice and range of models
  •   Interaction with methodologies
  •   Support for reuse
• Understandability
• Success record
• Tool support
Evaluating Enterprise Frameworks
• Flexibility & overhead
• Inputs – information used by the framework
  • Business Drivers –goals, strategies and priorities
  • Technology Inputs – strategic architecture & standards
  • Business Requirements – user interface & functions
  • Environment – budget, schedule, constraints, expertise
• Outputs – products of the framework
  • Business & Information Models
  • Software configuration & OS/Hardware platforms
  • Design Rationale
  • Transitional Plans
 Ruby on Rails
• An MVC web development framework
• Models provide object-relational mapping (ORM)
  • Between business objects and database.
• Views are user interfaces & present the data
  • Represented by templates – HTML & script skeletons.
  • Contains links to actions (methods) in the controller.
• Controller provides actions (methods).
  • Defines business logic used to process the data
  • Integrates the model with the view.
      • For each method in a controller class either
         • Define a view template with a matching name
         • Redirect to a view template or a controller action
         • Render text directly
Ruby on Rails Principles
• Convention over configuration
  • Simplify common cases
                                 Rails configuration files
                                 Avoiddefines rules for well
                                 Name things, e.g tables
  • Use standard practices       written applications.
                                 and naming conventions
                                 Use columns, form fields,
                                Ruby uses reflection &
  • Everything simpler and smaller the rules and avoid to
                                 Follow these and greater
                                 Less flexibility butRails
                                  consistency you’re doing.
                                  knows what – no freedom
• Don’t Repeat Yourself     (DRY) to waste time
                                     reduce need for
                                  separate configuration
  • Repetitive code reduces agility avoid configuration
  • Framework minimises repetition that have to identify
• Agile development environment
  • No recompile, deploy, restart cycles development
  • Simple tools to generate code quickly premature
  • Testing built into the framework
 Database Tables and Migration
• Migrations files
   • Programs to create and modify database tables
• Create a migration for changes to the schema
   • E.g. a new column
   • E.g. db/migrate/migrate/001_create_messages.rb
       • Defines initial structure of the table
class CreateMessages < ActiveRecord::Migration
  def self.up
  create_table :messages do |t|
  t.string :greeting
• Patterns capture high-level knowledge
• Solution ideas, advantages & problems
• Simple business patterns from IBM
  • Self-service
  • Collaboration
  • Extended Enterprise
• Require more detail for implementation
  • Using lower level patterns
Model-View-Controller Solution
• Separate data model, presentation, and
  actions based on user input
• Model
   • Manages behaviour & data of application domain
   • Provides data about its state (usually to the view)
   • Change state on request (usually from controller)
• View                                        View
   • Manages the display of information. MVC is a very
                                         common pattern
• Controller              Model
   • Interprets inputs from the user
   • Tells model or the view to change as appropriate
• We have covered a lot of material in the
• But don’t forget the material covered in
  the tutorial/practicals