The Franciscan Report

The Joel on Software Discussion Group - Why I Hate Frameworks

The problems with building framework are you can't satisfy all the requirements required by all stakeholders. Good frameworks will have these characteristics:

- It has to be reusable without over-engineered the framework. Start small and let it grow, only implement things that are needed by common team without the extra bells and whistles.
- Good framework team should solicit feedback from the clients (user of the framework) and provide only necessarily extensions per request
- Good framework should provide documentations and samples for easy usage
- Good framework should provide well defined extensions point and don't expose things that aren't suppose to be extended. This practice will prevent
- misuse of frameworks that can cause performance issues
- misuse of frameworks that made it harder for user to upgrade it in the future

There are different techniques you could use to make agile methodology work for large organization, and the key to it all is "Divide and Conquer".

A few tips you could do are as follows:
- create multiple sub-teams, each working on separate sub-systems
- have a well-defined interfaces that different systems are communicating with
- all project teams involved must support the methodology
- have a small design session to hash out high level architecture
- have daily status meeting b/w representative of each team in addition to within the team itself

ESB approach has become more favorable in comparison to SOA these days. Some of the supporters arguments about the benefits of ESB are as follows:
- it decouples the client interactions to the source systems
- it will maintain the data mapping, transformation and translation internally thus freeing each sub-system from those responsibilities

However ESB also posts the following challenges:
- it hides the spaghetti interaction inside its blackbox
- it can further erodes and turn into another point of integration due to the following cases:
- organizational decision to get things done quickly
- performance or optimization to bypass the ESB layer
- law of entrophy
- it's not easily customizable according to individuals client needs

A few benefits of SOA are:
- it still provide loose coupling
- it's quicker response time as far as having another "team" to do it
- interfaces can be customized to individuals application needs
- different SLA can be applied to different interfaces
- it's easier to change interfaces b/c you don't need to worry about affecting other
client's system

SOA approach however is not without its short coming either:
- it can potentially creates duplication of logic as different systems will be connected directly
- number of services created can go exponentially large and harder to keep tracks of

In order to make SOA more favorable, we need to consider the following
- it's good to have inventory of all SOA services
- you can always refactor the SOA services that could go together to a new SOA service thus it will encapsulate the services interactions
- versioning problem can be handled by the following
- treat data transfered as document centric
- if there's a need to maintain backward compatibility, set an expiration date on previous versions
- mark the SOA message with version number, and try to keep away from maintaining a lot of versions
- sometimes it's better to provide SOA service specifics to clients need and only consider reuse if it's actually reusable, b/c afterall reusablity is not free

java.net: Agile Legacies: Using Iterative Methods to Import Legacy Data

I agree wholeheartedly in this article, the impacts of not doing iterative legacy data import are as follows:
- some fields were missed/not mapped in the development
- missing features are detected very late
- fields are not one to one translation to the new domain, thus domain needs to be changed

Benefits of doing iterative data migration:
- migrating data at the same time as development can improve the system by uncovering things that don't work well in the old system
- developer works with more realistic data

Challenges of doing iterative data migration:
- DBA needs to buy into the process
- Data needs to be scriptable so that unit testing can be accomodated
- Analysis work needs to be done early for data migration
- Domain model needs to be work on together with Data analysts and DBAs

Service Level agreement set the standards/requirements of the system in a concrete manner. Thus there won't be any
ambiguous requirement down the line pertaining the system under development. What SLA should cover are as follows:
- availability concerns
- uptime (system needs to be available this % of time) /downtime (for maintenance)
- scalability concerns
- how many concurrent users can it handle, CPU, Memory
- performance concerns
- response times

SLA written needs to be reasonable instead of some wishful thinking, since it could affect budget cost/time for
something that users rarely need. It is sometimes useful to use stress test even in early release cycle

There are different methods of achieving distribute communication:
- web service
- rpc
- http

Reason to have distributed system:
- the need to create separate system (sold separately)
- smart client with centralized application server model
- integration with another organization
- integration with COTS products
- integration with legacy application that has legacy technology/architecture
- different systems have different availability/up time requirement

Not a reason to distribute

- api is getting complex, to achieve coarse grained access
- different release cycle
- clustering
- organization breakdown

Cost of distribute environment
- increase in complexities for transaction management, security, error handling
- need business process management to manage process flow amongst participant system