Business Requirement Analysis

1. Identify stakeholders(more importantly Killer SH): Compliance, Customer, Resource, Owner/Manager
2. Identify drivers: Problems, Opportunities, Constraints
3. Identify objectives: Should be SMART
4. Change Management:

Context diagram and scope dimension:
1. Locations
2. Processes
3. Applications
4. Organization units
5. Technology
6. Any other
7. Out of scope

Requirements for change:

1. Scope requirement
2. Functional requirement; Priority: Must,Should,Could,Would
3. Detailed requirement

Processes are made around


1. run at Locations
2. Implemented on Applications
3. used by Organization units
4. use Technology
5. execute Business Rules
6. manipulate Data
7. implement Functional requirements

Next step:

Data model
Business process model

Data specification facets:
1. Non-Functional requirement: Access, archive, availability
2. Data content roles
3. Data relationship rules

Actions:

prepare data models(ER/UML)
document data content rules
document data non-functional requirements


Data Model Concepts: Entity Relation Diagram(ERD can be normalized)/Class diagram.

Basic components or ERD:
1. Entity
2. Relationship
        relationship cardinality: Crow Foot/UML class cardinility
3. Attribute

Building a data model

There is a process to go through which will be described in more detail in the next section:
1. identify candidate entities

2. select a central candidate entity

3. define the primary key

4. work through the rest of the candidate entities:

• consider whether it is in scope
• define the primary key
• define the relationship(s) between the candidate entity and all other candidate entities on the diagram
• add description entities as needed
• fully express the cardinality of the relationship(s)
• name the relationship(s)

5. for each entity on the diagram

• define the remaining attributes
• define the non-functional requirements

6. review and refine
7. Advanced data modelling concepts

• Super-types and sub-types
• Hierarchies
• Exclusive relationships
• 3rd normal form

Migration case study 1

My application is now moving to different platform, data model will be same however application which contains the business logic, data access, UI is going to migrate, what are my options for implementing SOA. How can I decouple and increase reuse?

1. Loose couple entity objects and use REST to provide linkage between entity and business service.
2. Webservice for business logic
3. ESB for end point and service virtulization

Advantage:
1. Loose coupling between entity and data access layer
2. Loose coupling between data access and business service
3. Service and endpoint virtulization
4. Divide governance for process level SLA and data level SLA
5. Additionally with canonical model and schema repository reuse of data objects
         

IBM MQ best practices from IBM

Design

Use short names for Qmgr and MQ Objects
Always assign a DLQ
Use standards like JMS where ever possible
Build with performance in mind
Avoid fixed queue names in programs
When feasible, cluster your MQ server
Few Qmgr with more queues

Build

Capture completion and reason code for all MQI calls
Code application to continually process messages
Close and disconnect cxn properly
Be aware of the different features of various MQ clients

Run

Use security best practices
Restrict remote adminintrative authority using SYSTEM.ADMIN.SVRCONN channel of production-level boxes
Do not use sample get and put utilities
Use runmqlsr in lieu of inetd listener
Use SupportPacs to extend MQ functionality

Maintain

When not using third party tool, automate configuration with runmqsc scripts
Use appropriate logging mechanism
Schedule and apply fix packs on a regular basis

http://www.ibm.com/developerworks/websphere/library/techarticles/0807_hsieh/0807_hsieh.html