My Stuff

JSF Life Cycle explained

2011-07-15T14:21:00.000+05:30

Following diagram briefly explains

the JSF life cycle

Can Big Upfront Architecture Document will be beneficial for the team

2011-06-25T14:45:00.000+05:30

At times big upfront architecture document say about more than 50 pages document may not grab the attention of developers/other concerned parties. So we architects should be aware of creating architecture documents which are short and to the point. There is no point in creating big documents which no body interested in to know/refer. In my opinion, the architecture document shall be
1) Shall be simple and shall contain key architecture decisions. In my opinion with few UML diagrams and brief description should solve the purpose.
2) Update the document only if deemed to be necessary/otherwise don't update

My Reading List

2010-12-12T20:26:00.000+05:30

This is the live content I will be using as my reading list.

Technical
- Software Craftmanship - Currently reading
- The Design Patterns Small Talk Companion - Under progress
- Expert One on One - J2EE without EJB - Finished
- Agile and Iterative Development - Finished
- TOGAF 9, Pocket Guide - Finished
- Agile Project Mgmt with Scrum - Finished
- Java Server Faces - Currently Reading
- Applying UML and Patterns - Finished, but needs some revisits
- Evolutionary Arch and Design - Currently Reading
- Architecture Principles - Finished
- Information Arch and User Experience - Currently exploring
- Architecture Review (ATAM, SARA) - Currently Reading
-

Non-Technical
The Toyata Way - Currently Reading
Mega Living - Currently Reading
Discover Dimond In You - Finished
The World is Flat - Currently Reading
The Malgudi Days - Currently Reading
The Koutilya Arthasastra - Currently Reading

Concrete skills

2010-12-12T20:08:00.000+05:30

Each and every individual professional in the IT must have self analysis on some concrete skills. Here what I mean by concrete skills is nothing but deep understanding on the subject which can be easily appreciated and recieved by your collegues.In other words, these concrete skills demonstrates your authorative knowledge and experience on the subject. For example, following are few subjects which myself analysed on my professional life mostly reflects my day to day actvities.

Mostly concrete
Architecture, OOA/D, General Programming skills, Review, Agile engineering practices, Java/J2EE, build scripts, unit testing, Documentation, Presentations on different subjects, Leadership, Pre-sales etc.

No so concrete
Spring, JSF, Javascripts, CSS, HTML, SQL/PL-SQL, Installations, Debugging,
network, protocols, User experience etc.

This kind of analysis puts you to pritorize your free time towards reading.

Does architecture care about implementation?

2010-12-08T21:55:00.000+05:30

Does really architecture care about implementation details ie. design realization and subsequent code development?

In my opinion, hands-on experience atleast to ensure reference architecture will provide great value-add to entire architecture. Otherwise it will be the quiet abstract activity which may not be well recieved by development community.

The reference architecture might contain:
1) The implementaion view of the core components
2) All application specific cross cutting concerns
3) Vertical slice of the one use case to demonstrate the architecture realization; kind of Reference implementation for the specification
4) Do's/Dont stuff on target technology stack; chosen one
5) Application build
6) Development best practices/process overview
7) Unit test strategy (atleast development front)
8) Major component/module interface specifications (if possible; generate
javadocs)
9) Usage of static analysers with in the build environment; it would be great if your tooling support best practices customization

It is very easy to slip from abstraction to implementation

2010-12-08T21:42:00.000+05:30

During architecture development, sometimes we feel that it is very easy to slip from conceptual/pure architectural thinking to our faviroute technology specific/implementation specific thoughts. In my opinion this is very natural process; but care must be taken to ensure that architecture purity should not influenced by our pet technical jargons.

How create message queue using Spring 2.5.x and Oracle Weblogic Server 11g

2010-09-20T13:04:00.001+05:30

Last week I spent some time on configuring JMS Message Queue using Spring 2.5.4 and Oracle Weblogic Server 11g R2.

Following are the step by step instructions to create queue.

1) Log into http://localhost:7001/console, supply weblogic/weblogic (default)
2) Create JMS Server using Oracle Weblogic Server. I used JDBC persistent store - MySQL based, to store the messages under db.
3) Name your jms queue and factory and let these refer to your newly created jms server which points to JDBC persistent store.

4) Now configure your spring jms file; which looks something like this:

5) Create message listener class; which is influenced by traditional mdbs (J2EE 1.3 era..)

package amp;

import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;

public class MyQueueListener implements MessageListener
{

public void onMessage(Message message)
{
if (message instanceof TextMessage)
{
try
{
String txtMessage = ((TextMessage) message).getText();
System.out.println("" + txtMessage + "");
}
catch (JMSException ex)
{
throw new RuntimeException(ex);
}
}
else
{
throw new IllegalArgumentException(
"Message must be of type TextMessage");
}
}
}

7) Create client class whcih produces huge message payloads; just to test

package amp;

import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.TextMessage;

import org.springframework.context.ApplicationContext;
import org.springframework.jms.core.JmsTemplate;
import org.springframework.jms.core.MessageCreator;

public class QueueClient
{
private ApplicationContext ctx = AppContext.getApplicationContext();
private JmsTemplate jt = (JmsTemplate) ctx.getBean("jmsTemplate");
private Queue q = (Queue) ctx.getBean("jdbcQ");

public void sendMessage(final String m) throws Exception
{
jt.send(q, new MessageCreator()// inner class
{
public Message createMessage(Session session)
throws JMSException
{
TextMessage tm = session.createTextMessage();
tm.setText(m);
return tm;
}
});
//System.out.println("message sent to destination called "+q.getQueueName());
}
}

8) Finally call this class under web environment; to see the message output. I used OEPE pack to conduct these tests.

Hope this helps to configure message queues.

Care for simple architecture

2010-09-03T11:59:00.005+05:30

We J2EE architects must care for simple architecture; few things might help do develop application which are long lasting and easy to accommodate future requirements.

For example; I tried with followings
1) Care for OO rather than standards/specifications
2) Create architecture against requirements in hand rather than technology specific
3) Do not distribute objects if requirements are not called for
4) Follow good architecture and design principles rather than just following patterns
5) Leverage on lightweight architecture like Spring centric which greatly helps in interface driven programming, container level capabilities, test strategies
6) Follow thought full analysis of business requirements and come up with list of high level components, its responsibilities and associated rationale
7) Follow whiteboard driven architectures to kick start the discussion
Care for executable architecture (RUP), spike resolution (XP) and vertical slicing to get confidence in the architecture
8) Come up with list of development standards, guidelines and implementation classes

Architecture development steps

2010-08-12T11:30:00.005+05:30

I used mind-mapping technique to represent and structure the architecture development
steps.

It is being influenced by TOGAF and RUP architecture development guidelines.

Software Quality vs Design Principle, Pattern and Practice Catalog

2010-08-11T18:38:00.004+05:30

The Software System usually has many quality attributes, such as Maintainance, Performance, Security, Usabality etc. It is very important to have catalog of patterns, principles or other related practices which is being mapped to software quality attributes.

For example; I tried like this:

Utility Projects and Strategic Projects

2010-08-11T18:34:00.002+05:30

I like the idea of project catagorization like utility projects and strategic projects. This helps organizations to spend their IT investments rather carefully; again it is inline with application portfolio of an enterprise.

But enterprise can really focus their energy and investments on strategically aligned projects so that competetive advanatages are more.

Architecture vs Design

2010-07-07T17:51:00.003+05:30

Architecture is all about identifying the major components and its associations/responsibilities with right level of abstraction. It also involves taking decisions which are having system wide effect.
Where in design is all about constructing the software based on the context set by architecture. It involves choice of better algorithms, applying logic, patterns, reusable/generic blocks etc.

User story vs. Use case

2010-02-25T22:31:00.005+05:30

Few things about the possible differences between these concepts
1) A user story is the title of one scenario, whereas a use case is the contents of multiple scenarios.
2) User story is written by customer before getting into actual conversation, where in use case is formal record of that conversation

Does OOA/D steps helps experienced developers?

2010-02-04T18:50:00.003+05:30

In my opinion it is not mandatory to follow all OOA/D steps while individual has enough experience and knowledge on problem domain. In other words, if individual is comfortable with all architecture/design styles, patterns and principles, he/she could directly start coding.

Bangalore BTSummit Nov 09

2009-11-09T10:37:00.004+05:30

The BTSummit held at Bangalore on November 03 and 04, 2009 provided greater insight into latest trends in Cloud computing, SOA and BI. It is indeed a good effort from BTS event executives to bring industry leaders and practitioners under single roop.
Day-1, 3rd Nov 2009
The keynote/focused session was delivered by Mr.Howard Charney CISCO, in his inspirational speech, he highlightedthe IT visionary by developing smart IT services for better future for all of us.
After that, Mr.Ravikumar delivered speach on Cloud Computing, he explained different cloud computing environments andrelated models to chose and apply. In his views, "Cloud Computing is an application and infrastructure over Internet". There are three aspects of cloud computing:
1) The availability of infinite computing on demand
2) The elimination of up front community
3) The ability to pay on usage basis
Also cloud infrastructure shall be categorized into less constrained models to highly constrained models. The offering from Amazon, MS or Google falls either of these categories.Also he shared and urged the audience to have a look at white paper called "Above the cloud a Berkeley view of Cloud Computing".

Mr.Robert S, from think88, shared his views on SOA, Composite and Cloud Computing. The SOA key concepts covered are scope of vision,scope of deployment, decision making, speed to deployment, technical skills required, market penetration, speed to ROI, eventual total ROI, expected longevity of solutions, available standards and maturity of the vision. I personally felt, these concepts are very vital in overall SOA/EA initiative.He also emphasized on some characteristics of cloud computing such as s/w assets hosted offsite, browser is the primary UI, if there is no UI, then s/w assets are being accessed through REST services. Many of us did not know the true meaning composite apps, so from the speech it was evident that, "from the prospective of the user, it appears that, the primary functionality is 'extended' from multiple disparate apps". Also he envised that composite apps and mashups might converge in near future, may be 3 to 5 years. The composite apps are business oriented where in mashups are consumer oriented.
According to Mr.Robert, following factors might favor cloud computing:-
a)Limited internal apps
b)Limited IT assets-
c)Non-sensitive data
d)Not willing to buy IT assets
For SOA, the limited IT resources, software reuse and hosted web services might influence strategic decisions.

Mr.Eben Hewitt, took us a brief case study on SOA. According Hewitt, "Business Driven" means business users/Top executives knows SOA/or any other EA initiatives. Also he shared his views on establishing CoE. Also according to him, SOAP vs REST is outdated topic, and organizations are moved beyond that. Also Eben delivered speech on designing the RESTful web services and related architecture. He emphasized REST is an a architectural style with some of characteristics/concepts such as stateless, separation of concerns, cacheable, uniform interface, info hiding etc. In REST architecture, GET is for read, POST is for create/update and PUT is for update/create.

Mr.Som Sarma from 3i Infotech, delivered very inspirational and typical business executive style of speech on innovation. He highlighted how innovations are changing the business dynamics and how products like iPhone are becoming part of enterprise IT.

Dr.Robert Marcus, Sr.IT professional delivered speech on Cloud computing use cases. He categorized the clouds as end user to cloud (public cloud), enterprise to cloud (outsourced services), enterprise to cloud to end user (enhanced services) and private cloud (intra services). Following are standard requirements mapped to use cases under cloud computing environment: - Cloud Management- Security- Identity- Open Client- Federated Identity- Location awareness
Also Mr.Robert Marcus, explained cloud categorization such as IaaS, PasS, SaaS.

Mr.Jinesh Varia from Amazon delivered one of the best speech (in my view) on cloud computing; specifically on cloud migration strategies. He highlighted the phased approach to address the existing apps migration to cloud env. According to speaker, following are few phase-wise steps one shall consider for migration planning.
a) Cloud Assement Phase - In this phase, care should be taken for cost benefit analysis, app/infra dependencies, technical assessments etc.
b) POC Phase - In this phase, reference architecture shall be built by having management buy-in for this new initiative. So POCs must include some critical factors such as technology validations, testing of legacy apps, orgn feasibility etc. Also reference architecture must be developed with the help of learning AWS, small apps and small datasets. It is to just check the water before going big-bang approach.
c) DB Migration Phase - One should take care by leveraging different storage options, different db options, expert opinions from db architects etc.
d) App Migration Phase - He advised two strategies called "forklift" and "hybrid" migration strategy
e) Leverage the cloud Phase - He highlighted the cloud capability such as auto-scaling, automation and elasticity.
f) Optimization Phase - Mr.Jinesh, explained importance of having optimization phase by considering some of the factors such as utilization, performance (post migration) and efficiency. Also give a brief explanation on Amazon's capability for different elasticity styles such as proactive cycle scale, proactive event based and auto-scaling on demand basis.

04 Nov 09 - 2nd Day
Mr.Nils Puhlmann from Cloud Security Alliance delivered thought provoking speech on new challenges of security under modern enterprise environment.The speaker highlighted some key drivers and associatedchallenges/threats to protect business from security vulnerabilities. Following are few drivers:
1) Younger generation is growing up with consumer technologies
2) IT becoming a tool to enhance peoples creativity
3) Consumer products like iPhone are now part of enterprise environment; including but not limited to emails, calendar, contacts, SMS etc...Also he shared interesting fact about iPhone taking every user browsing activities as screen shot in the background.
Mr.Srinvivas V from Vigyanlabs, shared his thoughts on virtual enterprise and key facts like how business can leverage on latest technological trends to truly become virtual enterprise?, the typical spread of modern enterprise comprising customers, employees, partners/suppliers, enterprise assets, services, products spread across multiple IT products and services.

Mr.Robert S from think88, shared his views on applying governance technologies for effective SOA governance. Following are top 10 strategies:
1) Include governance technologies as part of SOA governance
2) Make sure your governance platform is agnostic about service development platforms
3) Make sure that governance platform is able to support all service deployment technologies
4) Importance of SOA testing
5) Collect governance metrics and review periodically
6) Track activity through multiple IT resource layers (e.g., db, middle ware, object, app server)7) Breakdown the barriers between repositories and registries
8) When selecting governance technology product, write a formal RFP (interesting strategy, this leads proper homework)
9) Avoid tools that would require code modifications
10) Make sure that, the selected governance tool fits into existing IT governance landscape

According Robert S, following are three major SOA life cycle events- Design time (meta data mgmt, service discovery, service composition/modeling, orgn policy)- Testing and QA (Service unit validation, policy adoption, compliance, performance and prediction)- Runtime (SLA, Version control, error reporting & mgmt, performance monitoring)

Mr.Eben Hewitt delivered speech on "10 things software architect must know", these are shared views from different architects/developers worldwide and it is available on the net under the title called "97 things s/w architect should know". He highlighted the Gartners architecture definition covering concepts like abstraction, constraints, translation, properties/principles and enabling evolution. One of the thing (in list of 10) that particularly took audience attention was moving the problems on course of enabling evolutions.

Mr.Janakiraman delivered inspirational speech on open source based cloud computing. According to speaker, there are four key tenets:
1) Elasticity
2) Pay by use
3) Self service
4) Programmability (muliti machine apps).

Cloud shall be classified as IaaS - Renting machine in simple terms, PaaS - O.S specific, being offered by google, MS and SaaS - Google apps. Also cloud could implemented as private, public, hybrid and community clouds.
Under the anatomy of cloud, "hypervisors" are plays a key role. These are heart and soul of the cloud computing technology. Over the hypervisors, platform, infrastructure and applications shall be placed and managed. There are couple of open source hypervisors; KUM from linux ubuntu and Xen from EC2 Amazon; the Citrix is the commercial form. The cloud open source tools stack includes LAMP (linuxm apache, mysql and php), ubuntu enterprise cloud, apache Hadoop etc.
Mr.Vivek Khurana from SoundSource, shared his dashboard design and development experience under the topic called "Building Enterprise Dashboards". According to speaker;
1) Dashboards should act as immediate decision making aid
2) While designing dashboard; one should keep different stakeholder's interest in mind
3) UI controls should be selected judiciously
4) Focus should be on data, try to remove unusable data
5) Don't put too much data; because of screen size
6) Don't listen to business users on solutions part
7) Dashboard data should be current
8) Notify user on dashboard events/data changes
9) Learn from new sites like CNN, BBC, nyt for about placing and arranging important/key data
10) Important dashboard data which do matter to the business should be placed under mobile - best way is to arrange with text based SMSs
On the trends, speaker identified following few such as animated charts, streaming dashboards, collaborative visualization and expressions. For animated charts, speaker requested audience to visit Hans Roslings TED talks/gapminder.org

Mr.Udayan Banerjee, shared NIIT's experience in developing collaborative website for internal employees using enterprise 2.0 tools. The speaker advised that "collaboration and interaction can not be forced rather it has to emerge and technology is an enabler". Following are web2.0 technology stacks; wiki, blogs, IM, mashups, RSS, social networking sites etc.

TOGAF 8/9 Training and Certification

2009-10-28T16:54:00.003+05:30

I underwent TOGAF 8.1.1/9 training and certification program in last week of sept'09. It was good experience and lot of knowledge gained. I successfully completed all the requirements required for the certification.
I specially liked the instructure (Mr.Dave Gilmour from Architecting the Enterprise) word that "TOGAF is a structured common sense from the past experience". This is true as EA is complex in nature and often poses the challenge where to start, where to end, how to compile, deliver etc. With the structured framework like TOGAF, the architect should not be worried about structured following, clear deliveries and structuring of the EA artifacts

Few agile thoughts

2009-04-27T10:23:00.016+05:30

Last week I spent a week in my office to undergo training on agile i.e. from 21 april 2009 to 25 april 2009.
It was very effective and found to be informative in the sence mixing the UP, XP and SCRUM practices for today's software development demands.
Day-1
Following are key points which come-up during discussion:

Agile is a collabaration of all principles

SCRUM does not address all the aspect of software development; best bet would be mix of processes like XP, UP and Scrum

"Time Boxing" will break if deadline is extended or scope is reduced

Six week iteration will pose a motivatio challenge to the team; as human does not show the urgency if the task is more than 6 weeks long

Initial productivity will also been lost due to laid back attitude

The ATS expects fundamental change in mind; usually change expects 12-36 months duration. As most of the human fall either Neophilic (embrace change), Bewildered (dominant followers) and Neophobic (dont embrace change)

No missin critcial or important projects should be taken as part of ATS

Iteration is all about cutting down WIP tasks, it is about finishing the tasks

Principles of 2nd generation agile lean

Standups - Catch the problems which are smaller in size

Many agile teams unable to keep track of project progress

Agile project mgmt is all about risk management

Up-front req is bad as there is a chance of feaure being not used by user (study shows that 45% of the developed features are not being used)

Deliver early and oftenly is a best way to deal with req mgmt

Iteration '0' shall be used for strategic planning, high level architecture, POC, goals, vision etc

Risk driven development addresses both technical and business risks

Risks
Scoping risk - dont know what is in the scope

Req risk - dont know what is req

Verification risk - dont know what is acceptance crieteria

Do the work which you dont understand; always look for dark corners in teh project

Lean principles such as No waste; only value add, no unevennes and no stress must be applied for better worklife and product output

Requirements

Requirements is always exploration in accordance with risk

Requirement analysis must be carried out always through out teh life cycle to identify the lean symptoms

Day-2

Dont impose the work; rather design the work which suites the individual.

Pair programming- Front seater: key in code, syntax check (tactical), Back-seater: strategic thinking

Retrospectives: Without actions; it is waste of time. Also it should be place for strategic thinking and implement few actions (SMART)

Pay attention to study Neural Networks to know behaviour of s/w ppl
estimation is a guess. It has two types, wild guess and scientific guess. Pessimist makes always good guess :)

Self organizaing teams: a) Train the team about prinicples b) Set the goals, objectives c)Get out of the way from team

Goal is direction and Objectives are phases to achieve the goal
----------obj1----------obj2-------------obj3-------objN---------->GOAL
Risk profile is directly propotional to sw process
Risk first; do the risk things first; it is better to fail early and cheaply

Key roles in good team

Project Mgr - Responsbile for project progress (Steering committie, Sponsers, LoB VP)

Product owner - Responsible for business value (Busines Analyst, SME)
Tech Lead - Care about feasible solution (Architects, Designers, Developers)
Test Lead - Concerns about s/w quality (Testers, Test Analyst)

9 Box technique for risk driven development

Agile Metrics

Measures outcome; not output

Follow trends; not numbers

Must be easy to collect

Dont email the metrics report to anybody; since it aviods the communication (direcly ask them to come for meeting)

Metrics are artifacts

Any development involves two types of code; solution code and verification code

Agile strories can be Epic->Story-Features. It similar to RUP Use cases like Composite UC->Scenario->UC

Estimation is not committment
Estimation shall be divided into
No-fidelity (No analysis, less time) +- 200%
Low-fidelity (some analysis)+-50%
High-fidelity (good analysis, POC, good time) +-5-10%
Estimation variance
no-fi = effort * 3.0
low-fi = effort * 1.5
high-fi = effort * 1.05

Iteration planning must include change mgmt, new stories estimations, WBS, report progress (strategic plan/release plan)

Vision should be collabartive effort; never take all the inputs from single source. As part of requirements/ATS disussion sessions; follow few guidelines such as

situation questions like where are the pain points, what are teh goals, problem context, real problems, value of the client etc.

Key questions

Why - pains, goals

who, where - Narrow or broad groups, shallow or deep team (like BA, Executives etc)

what - business types, LoB, business practice in use

how many - affected groups, size of each group etc

how soon - time constraints

how much - budget constraints, targets

Team work - The real problem of responsbility emerges when things go wrong

Few EA info

2009-03-23T11:19:00.002+05:30

SOA and TOGAF
SOA is a more of bottom-up model where in TOGAF is more top-down model.For the successful EA; one must understand both the model. Most of the RUP based implementation such as OOA/P are heavily influenced by top-down; If too much concentration at higher level, then every fear is that system might never built.
The TOGAF ADM phases like oppartunities and solutions, migration planning, implementation governance (E, F, and G phase) mostly inltrgh RUP.

TOGAF phases naturally fits SOA style of initiative. In Business Architecture phase one need not essentially know the what should be done with the technology. The business operations must be defined with out keeping implementation in mind.
In IT architecture phase, along with defining the new services, care must be taken to cohessively work with existing legacy applications; that will not be converted "services"

Architectural Standards
Every company should have architectural standards;reference base to reduce the structural complexity of the software system in development system.
Architectural governance means enforcing such standards into software development system to bring in modularity, consistency in the system. Lack of such governance will reduce the chances of meeting architectural decisions and vision with implementation (code).
Architectural standards/rules are: -- Layered Architecture-- Seperation of concerns-- Domain Driven Design-- DAO layer should not depend on other layers-- Presentation layer should not directly interact with DAO layer-- Service layer should never call web layer-- Service objects shoud be created using factory classes

EA issues
Following are few enterprise issues should have support from development platform:-- Scalability-- Concurrency-- Transaction-- Robustaness-- Performance-- Atomicity

EA decisions
-- Choice of tools/frameworks-- Choice of programming languages-- Choice of platform-- Choice of OS-- Choice of database-- Choice of architecture style

MDA
The Model Driven Architecture (MDA) enables business user to define the business processes using standards like UML, MOF (Meta Object Factory) and CWM (The Common Warehouse MetaModel) which seperates the business logic from application logic. Using MDA, business or underlying technlogies shall be changed to gain the advantages of new business trends or technological solutions.
MDA->UML,MOF or CWF->J2EE, .NET, WebServices etc

Advantages of JSF/Ajax over Struts

2008-05-30T14:46:00.001+05:30

Architecture
JSF is a Component based UI framework. It is industry endorsed framework governed by JCP
Provides cleaner separation of concerns; uses MVC architecture
Robust event handling architecture. Each JSF component hierarchy is associated with rich set of listeners
JSF has in-built plug-in architecture to support application scalability; any third libraries like Tomahawk (JSF enabled components) shall be easily integrated and extended.
Robust event handling mechanism
All UI components initiate OO web-application development. Thus JSF enabled web applications can leverage on rich-proven OO practices for rapid application development

Usability (Both Application end user and Application developer)
Increased user interface experience with rich client features like data grid, trees, dashboard features, auto-complete, auto-refresh etc
Increased application user productivity with the help of in-built features like asynchronous page rendering, automatic refresh of server data, reduced number of user clicks and auto page submissions
Multiple options to select JSF specification implementation frameworks like Sun RI, Apache My faces, JBoss Rich faces and Exadel’s facelets for application development
Comprehensive JSF tool support from leading industry vendors; such tools includes Eclipse, JDeveloper, IBM RAD, Sun Studio and JBoss Studio
Provides in-built validation framework to validate UI inputs. Significant reduction in development time; moreover validation framework uses latest JSTL enabled expression language
All JSF custom tags are JSTL/EL aware

Scalability
JSF rendering kit provides different rendering techniques to handle requests like WML, XML etc. In other words; it is not limited to HTML only. So JSF enabled application are scalable in nature to address different clients with out changing underlying business/data architecture
Provides seamless integration with Ajax technology. All JSF component tree model are Ajax aware; so any non-Ajax application can leverage on this excellent scalable feature. Again application developer has good support from open source frameworks like Ajax4JSF
Provides pluggable life cycle phase listeners. So JSF based application can be scalable to add in-built listeners against application’s future requirements
JSF is based on standard converters. Custom converters can be easily developed or extended for ever changing requirements

Maintainability
JSF based applications shall be maintained with ease; provides good separation from configuration files, backing beans, form beans etc. Backing beans shall be developed using POJO centric development model. If application leverage on ORM solution like Hibernate; then significant reduction in code; thus better management of the application
Clean separation of roles; Thus better managed application source repository both development and maintenance phase
Custom JSF components like progress bar, drag n drop, file movement etc shall be reused across the application. So there is no redundancy in source code.

View My profile On Linked-In

2008-05-28T10:17:00.001+05:30

Factors to be considered for productvity measurement of agile practices

2008-05-27T14:05:00.001+05:30

Abstract
The Agile methodology really lacks its ability to collect the productivity metrics. Agile gives utmost priority to satisfy the customer with the help of frequent deliveries of working software. However there are several factors do exist to capture agile metrics. Following article discusses some of those.
Factors to be considered for productivity measurement
Following section list downs the different factors to be considered to measure the productivity of agile practices, viz., SCRUM, Continuous Integration, Workshops and Dual Monitors. Each factor might applicable to one or more agile practices.

1) Customer satisfaction
It is one of the better ways to measure the productivity of the agile processes or related practices. Each iteration/sprint will end-up with tangible output which is going to perceived or evaluated by the client according to his/her business requirements. So in this process no of customer feedbacks (good as well as not so good), his active participation frequency and delivery satisfaction rate (on the scale of 1-5) etc shall be measured.
Applicability: SCRUM, Continuous integration, Workshops

2) Reduced/Manageable risk
The number of risks envisaged and able to mitigate the risks with successful counter measurements per iteration. Also how team as a whole successfully managed the risk with in iteration with out affecting the delivery. It requires disciplined way to capture such instances during iteration. Best candidate would be Scrum Master.
Applicability: SCRUM

3) Improved quality
Quality differs from context to context. From the SCRUM aspect, it is reduced code review defects, increased design/architectural specific brain storming sessions, reduced build rejections from internal QC/ or client, Increased junior team member participants in design workshops, increase in review efficiency, reduce in number of failed attendees for SCRUM stand-up meeting, etc…
Applicability: SCRUM, Workshops, Continuous Integration

4) On time delivery
On time delivery of working software (with duly tested!) of all story points identified for the iteration. If any delay in delivery; then associated delay can be measured in number of person days / or IEH
Applicability: SCRUM

5) Innovation
The number of innovative ideas/best practices adopted to deliver out of box solution with in iteration. It might be good design strategy, improved code quality, increased automation by using good tools under all stages of SDLC cycle etc. Again it is in process matrix collection mechanism, Scrum Master is the best person to judge such initiatives.
Applicability: SCRUM, Workshops, Continuous Integration

6) No of Reusable components to the organization
How many reusable components are contributed to the organization from the project? Here code is fully tested and moved to client’s production environment. Any such code which does not have any customer obligations shall be moved organization’s reusable component repository. It can be measured across the projects over the period of time. This measurement shall be conducted against iteration or specific period of time.
Applicability: SCRUM, Agile process as a whole

7) Increased knowledge sharing activities
How many times from specific SCRUM team member shared his technical competency with others in the form of presentations, trainings, articles etc. Any such instances shall be captured.
Applicability: SCRUM

8) Team engagement
Team engagement during sprint, shall be calculated in the form of Ideal Engineering Hours (IEH). Also overall team engagement in the form of understanding requirement, design, code, review, testing, training, research etc shall be classified.
Applicability: SCRUM (Backlogs)

9) Burn down charts
Burn down chart is early warning system, which gives product owner how the team is performing to achieve user story points for current iteration. At high level; number of high level warnings occurred during sprint / or across the sprint(s) shall be measured.
Applicability: SCRUM

10) Personal Excellence
Capture information such as how many people with in SCRUM team are being certified for various technological tools/frameworks? How many people participated seminars, training programs? How many team members contributed to open source projects or initiatives? Thus increase in company branding etc...
Applicability: SCRUM

11) Agile maturity
Judge the team maturity with help of schedule over run, effort over run (directly related to matured way of conducting task estimation), what kind of task selection from team member during iteration planning, active participation instances in various workshops, retrospective meetings, stick on to realization of sprint goals, adherence to multiple project checklists etc. Any violations or innovative ideas should be captured as part of sprint.
Applicability: SCRUM

12) Compliance with respect agile principles/or number of tailor made approaches which violates agile principle
Capture any agile principle violations in the form of tailor made requirements; might be influenced by external stakeholder. Also identify number of agile principles being practiced on iteration basis. Derive such matrix at the end of each iteration. In my opinion it is the most important activity shall be considered with high priority.
Applicability: SCRUM, Workshops, Continuous Integration

13) Obstacles cleared per iteration
Capture number of blockers removed per iteration.
Applicability: SCRUM

14) Number of De-scoped functions/tasks over into next iteration
All de-scoped story points of the current sprint
Applicability: SCRUM

15) Number of retrospectives per iteration
How often SCRUM teams adheres to “Inspect and Adapt” principle? Identify number of retrospectives being conducted with in sprint. Also capture what are the types of retrospective meetings are being practiced and related feedback from the team.
Applicability: SCRUM

16) Implementation status of retrospective action items
It is number of outstanding retrospective action items from previous sprints.
Applicability: SCRUM

17) Number of functional tests / iteration or user story
It is a process of capturing number of functional tests developed and applied against user story points per iteration.
Applicability: SCRUM, Continuous Integration

18) Unit tests / iteration
Capture number of unit test cases against code developed per sprint.
Applicability: SCRUM, Continuous Integration

19) Number of builds / iteration
Capture number of successful builds / or broken builds per sprint.
Applicability: SCRUM, Continuous Integration

20) Number of functional defects / iteration
It is number of functional defects found by both internal QC team and client.
Applicability: SCRUM, Continuous Integration

21) Lines of code
It is mainly concentrated on development team productivity on lines of code delivered for the specific period. For example; KLOC/Person day. But most of the agile practicing companies discourage this approach as 50 lines of code with just variable declarations can’t be more productive compare to just 20 lines of code which does important business functionality. In my opinion it is most crud way to measure productivity; shall be discarded.
Applicability: SCRUM, Continuous Integration

22) Function Point
It is originally intended to use for project estimation. It revolves under Input, Output (Report) and data. Again as explained with LOC; one can not depend on FP for measurement for the simple reason, a simple CRUD operation will carry more function point where in most complex business scenario which does not have any output will carry less FP. In my opinion each FP should have weightage and determination of weight-age will ask for definitive discussion.
Applicability: SCRUM

23) Velocity
Sustained development pace of the team is determined by Velocity mechanism. Here it depends on number of story points delivered per iteration. Most of the agile practitioners recommend this approach to determine overall team productivity. Here also some fundamental question arises like “if team of 3 delivers 40 story points where in another team of 10 delivers 50 story points, so which sprint team is more productive?”
Applicability: SCRUM

Linked-In QA

2008-05-27T11:32:00.001+05:30

Stakeholder Interest
http://www.linkedin.com/answers/technology/software-development/TCH_SFT/234124-14255949
EA best practices to Individual Projects
http://www.linkedin.com/answers/technology/enterprise-software/TCH_ENT/234126-14255949

Dont justify agile based on productivity

2008-05-22T19:01:00.005+05:30

It is often found that, many people adopt agile development process for quicker delivery. But it is thorough bad idea, with out understanding agile goals and true engineering practices. Productivity of an s/w person cant be measured in the form of lines of code, how many function point is delievered etc. Rather it will be more meaningful if it is associated like
Increased customer satisfaction (may conduct ratings)
Increase in the quality of delivery like no architectural issues under design phase, no design mistakes during production run, better quality code in context to better API usages, easier maintenance etc
Increased personal excellance in the form of better problem solving skills; communication with co-team members, external people
Contribution to online community, information sharing with in organization or outside organization
etc..etc..etc...many more
-

Open group confrence proceedings - Bangalore, INDIA

2008-03-06T15:30:00.004+05:30

Why Enterprise Architecture?
Following are the few reasons to start with:
Silo-ed applications
Inconsistent and Islands of data
Rigid technical infrastructure which are very hard to change
Change in business strategy to have competitive advantage

“Enterprise architecture should provide support to the business by providing the fundamental technology and process structure with the help of IT strategy”

Here IT is a responsive asset for modern business strategy.

Highlights of the conference proceedings

SONA as Networking Platform
In a keynote address, CISCO executive expressed his thoughts on today’s IT challenges in following areas:
Empowered Users
Real time information
Borderless Enterprise

Now a days business user’s are exposed to innovative user interfaces (like innovations from Google); and no means IT service company will escape by providing at par solutions which adheres to current user expectations

SONA (Service Oriented Networking Architecture) is open standard, which nicely fits in between Business Architecture and Technology architecture. It provides in built networking services like faster IP routing, data cache, security etc. With the help of SONA enabled applications; with in CISCO, enterprise applications response through-put increased to ~ 40%.

It also observed that, any strategy should be on business centric rather than people or technology centric; to stay competitive in modern business environment.

CISCO adopted TOGAF – ADM as architectural framework while developing SONA.

Managing Change in EA Program
Mr.Ron Baillie of Cathay Pacific shared his practical experience when introducing the Enterprise architecture program with in IT team. Initially there was lots of resistance from internal IT team to understand and adapt new enterprise concepts. Mr.Ron introduced several EA program innovative concepts like;
Having all EA principle (there were 06 principle’s to start with) in a cube.
Arranged many programs to understand such concepts; including his CIO

He highlighted few observations which are come out during EA program execution;
Motivate the people respect to the context (like cost= total no of First class empty seats…)
There must be Centralized architectural artifacts
Identify the key principles in EA program
Create an ownership for each principle
Roadmaps should be created for each EA components
Associate business matter experts for each roadmap

Also he highlighted EA is a journey; not an end point. Following are few principle’s he adopted in Cathay Pacific:
Simplicity
Modularity
Standardization
Measurement
Life Cycle
Etc…

Finally there is very interesting presentation slide; which shows picture were all fishermen rowing the boat in one direction. In an analogy he stated; it is very important in EA program whether all stakeholders are rowing same direction or not.

Introduction to TOGAF
Mr.Vishwanthan of C&CC solutions; Australia (TOGAF certified) gave a nice presentation on TOGAF 8.1. Few things about TOGAF;
1. TOGAF is a framework; not a architecture
2. TOGAF certification is all about checking one’s knowledge about TOGAF; not a check on skills or related implementation. Holds very good acceptance from enterprise architect’s community
3. It’s customer initiative; not from Open group
4. It is defacto industry accepted architectural framework. It can be used in conjunction with many architectural frameworks like Zachman, DoDAF, MDA, FEAF etc
5. Zachman and TOGAF compliment each other. TOGAF shall be used as implementation framework for Zachman.
6. Already there are several mappings exists respect to TOGAF; mainly
a. Zachman
b. MDA
c. DoDAF
d. COBIT
e. ITIL
f. FEAP

TOGAF shall be certified in two ways;
§ Directly taking the exam from Prometric center
§ Or attending the training from Open group authorized training institution.

One can build a business case for TOGAF as EA; providing sufficient strengths like
Ability to chunk-up the whole enterprise architectural program into different ADM phases. Here each ADM phase may run into several iterations; depending on the organization’s business complexity.
Avoid the redundancy in process to building new project
Avoid the silo-ed approach.

TOGAF 8.1 divided into three parts;
ADM (Core implementation phases)
Enterprise Continuum (TRMs, Federated EA’s etc…)
Resource base (Case studies, Glossaries, Templates, Evaluations etc…)

Also he emphasized on ADM and its relative importance in overall EA implementation program.

ADM is an iterative method; consists of totally 8+1 phases. Also there is preliminary phase to start with
Each iteration; there will be new decisions. So each decision should have adequate information on
Overall enterprise coverage
Level of detail to understand the decision
Time horizon to implement the decision etc…
Every phase is validated against the business requirements
Any decision will be based on Competence (business) and resource availability

Jason Uppal from QuickResponse, Canada; gave excellent insight towards TOGAF 8.1 by going through ADM phases. Below are few thoughts:

Business Requirements
These are also called as “Architectural Requirements” are nothing but set of wish lists which enterprise have, but preventing for implementation. So these are actual architectural requirements. It might include wicked problems as well. Wicked problems are one which is very hard to frame.

Architecture Vision
In this phase, EA should attack the wicked problems, apply the SMART objectives and also come up the statement of architectural work. If Architecture vision is set right; then rest of phases more likely to succeed. It is very important that EA must gain confidence from all stake holders.

Business Architecture
While developing business architecture, following are few areas should be considered for effective impact on overall EA program:
Effective business process
Impact of change on people
Implementable business process (think “Realistic” principle of SMART!)

Data architecture
What information is required to make an effective business process?

Application architecture
Cost effective way to deliver information system to make business process efficient

Infrastructure
Hardware, Software, People are required to deliver services to meet required SLA

Opportunities and Solutions
Ideal set of objectives/Initiatives (Technology is limiting factor; people & process change etc are key challenges!)

Migration Planning
Set of initiatives required to deliver architectural vision.

Define Value
Organization learning towards expected benefits from EA program. Also value of exploring current enterprise capabilities

KPI Governance
Define, Measure and Report architectural changes. Also study the corrective action and impact analysis on already defined phases of ADM due to change.

Brief on SMART objectives
All businesses need to set objectives for themselves or for the products or services they are launching. What does your company, product or service hope to achieve? Setting objectives are important. It focuses the company on specific aims over a period of time and can motivate staff to meet the objectives set.

A simple acronym to set the objectives is called SMART objectives.
Specific – Objectives should specify what they want to achieve.Measurable – You should be able to measure whether you are meeting the objectives or not.Achievable - Are the objectives you set, achievable and attainable?Realistic – Can you realistically achieve the objectives with the resources you have?Time – When do you want to achieve the set objectives?

Difference between Zachman and TOGAF
Following are few differences;
TOGAF tells step by step implementation of each step is dependent on other, where in Zachman framework does not have the dependency
Operations feature is not included in TOGAF, but Zachman got detailed information.
Proposed TOGAF 9 focuses on Governance, Portfolio management etc.

Enterprise conceptual model
Mr.Gundars Osvalds from BearingPoint, USA, gave short presentation on conceptual model in EA. Enterprise architecture conceptual model contains following sections; these conceptual model elements are interlinked and will drive each other.
Framework
Architecture
Life History
View
View Point
Abstractions

Framework concept
Select one or more framework (Federated architectural approach!) to arrive EA.
Zachman
TOGAF
Framework
DoDAF
FEAF

Enterprise Architects can be developed
In interesting presentation Jason Uppal from QuickResponse, ITAC level-2; opened up a nice discussion on how to develop an Enterprise architect. Here are few ideas:
Start working with some strategy in mind. Strategy should have direction (like Financial, Customer supplier, Organization objectives etc…)
Perform the litmus test using SMART objectives
Identify the current constraints (Area not to focus on)
Have a Guidelines (Area to focus on)
Develop a programmatic roadmap (Benefits, Costs, Risks, Why you???) for a business strategy. Provide expertise based on leadership to help and execute the roadmap
Study architectural views on People, Process and Technology for Business Architecture, Data Architecture, Application Architecture and Infrastructure Architecture
He advised audience to concentrate on “Wicked Problems” of business
More wicked problems, higher level of effort is needed to come up with realistic EA.

In spot light forum discussions, Mr. Allen Brown, CEO of Open group gave insight towards few standards like;
“Interoperable Enterprise” - Look for white paper from http://www.opengroup.org/cio/iop/index.htm

He also highlighted the current problems in enterprise; mainly Cross functional team culture, new business partners and stove-piped information.

He also stressed on having “Bounderyless Information flow” with in enterprise. Finally he concluded discussion by saying “Requirement defects are very expensive” and worldwide nearly 53% of defects are raised from business requirement.

regulatory compliance urls

2007-10-30T11:29:00.000+05:30

www.baselalert.com
www.compliancereporter.com
www.theirm.org http://en.wikipedia.org/wiki/Basel_II
http://www.basel2implementation.com/
http://www.bis.org/cbanks.htm
http://www.federalreserveeducation.org/fed101/policy/basics.htm
http://www.fsa.gov.uk/http://www.deloitte.com/dtt/article/0,1002,cid%253D139228,00.html
http://www.rbi.org.in/scripts/AboutusDisplay.aspx
http://www.financialexpress.com/news/story/163382/
http://www.woccu.org/best_practices/regnews.php
http://www.ecb.int/press/key/date/2007/html/sp070712.en.html

My URLs

2007-07-13T12:32:00.001+05:30

http://www.developer.com/
http://hillside.net/patterns/onlinepatterncatalog.htm
http://www.javaperformancetuning.com/newsletter.shtml
http://www.javalobby.org/
http://www.javaworld.com/
https://jdk.dev.java.net/
http://www.onjava.com/
http://www.theserverside.com/
http://developers.sun.com/index.html
http://www.bredemeyer.com/
Open Source Links :- http://www.openlogic.com/resources.php?content=projectdetails
Static Analysers:- http://java-source.net/open-source/code-analyzers
http://labs.jboss.com/file-access/default/members/jbossajax4jsf/freezone/docs/devguide/developerGuide.html
http://www.ajaxmatters.com/r/resources?id=3

Fitneese WIKI

2006-05-23T14:37:00.000+05:30

A simple to install collabaration tool for internal project management. Just download the zip from fintneese.org and assign a port. That's it!! you are ready to create a custom WIKI pages

Agile development

2006-05-17T15:06:00.000+05:30

Today had a session with Craig about agile development. Criag shared his wast experience on agile development with some of us. Following are few points related to this session:
1.Agile != XP
2.According to Craig, Pair programming shall be used for skill transfer. Not recommended practice
3.A task switch leads to avg 1 hr productivity drop for a typical developer time
4.Agile manifesto contains:
- People are important over process
- Working s/w important over documentation
- Customer collabaration important than contract negotitation
- Response to change > following PEP
5.Agile inspired by Lean thinking and Theory of constraints
6.Descope of the current iteration should be arrived before one week (in typical 3 week iterations..)
7.FIT and Selenium are opensource test frameworks for acceptance tests and shall be adopted as part of contineous integration.
8.Craig also instisted on design for testability.
9.Two optional points during scrum shall be shared as:
- Share the best practices adopted (if any)
- what are features missed for current sprint

A day with agile guru

2006-05-10T16:40:00.001+05:30

I got the oppartunity to spend some time on agile modeling with Craig Larman, a renowned agile guru.

He explained us, a software architect is who, knows good programming skills. He also discussed somthing about architecutural documentation. A architectural documentation will be only complete in all sense during the project release time. It will be helpfull for a new comer joining the project for maintainance or new development.

A day with agile guru

2006-05-10T16:40:00.000+05:30

Refactoring

2006-03-24T12:01:00.001+05:30

1. Introduction

The process of changing a software system in such away that it does not alter the external behavior of the code, yet improves it’s internal structure.
- Martin Fowler
Refactoring is the process of taking an object design and rearranging it in various ways to make the design more flexible and/or reusable. There are several reasons you might want to do this, efficiency and maintainability being probably the most important.
- Ralph Johnson

In software world, it is very difficult to design and development a right system at first time. Thus keeping this is in mind, refactoring analysis was carried out to improve the SuD for better performance and maintainability.

2. When to refactor?

Refactoring is a systematic way to clean-up buggy but working code. It is needed when a system lives with bad designs, wrong decisions and poor code. Following are some of the situations which call for refactoring:
It was very difficult to get the system correct the very first time
Lack of understanding of the problem domain
Heavy presence of monolithic code; lack of modularization
Programs that are hard to understand, hard to maintain, contain heavy duplication of logic/code etc. Following are the top ten reasons of bad code smells that ask for refactoring:
Duplicated code
Long method
Large class (too many responsibilities)
Long parameter list (missing object)
Too many case statements
Same class changes differently depending on the additions
Dependency of method is too high from other objects
Lazy class (does not do too much)
Class with too many delegating methods
Too much coupled amongst the classes, accessor classes
Overall slow response time to client requests

3. Refactoring Benefits

Some of the main benefits of refactoring are elaborated below:
Code manipulation in safe environment
Improves scalability, maintainability and portability of the existing system, where possible
Leads to better understanding of existing code
Identifies and reduces an existing system’s performance bottlenecks

Automated EAR deployment through ANT script in WAS

2006-03-23T18:23:00.000+05:30

Any body who deployed webapplications through websphere admin console will know the pain full process of having series of wizards asking n number of questions.

To avoid, recently I tried for automated deployment process throgh ANT. I thought of sharing my experience wrto same.

Here the steps which I followed:
1.Created the ANT script which builds the EAR.
2.Since our application server situated outside our current dev env, I used SSH facility throgh ant and copied the ear into the server location.
3.Then I used .jacl scripts (which are websphere propietry..) for the copied ear deployment.
4.Created the .sh/.bat file (depends on the WAS installed OS) which will execute the .jacl script.
5.Called the .sh file through ANT script.
6.You can extend your build script to run the JUnits to know how much your build stable??

Agile development

2006-03-23T16:30:00.000+05:30

Agile development opened up a new way of developing a software in more meaningful way of day-day development approach.

In the current project which I am associated with contains following agile and xp best practices:

SCRUM

Contineous Intigration

Test-First Approach

Sprint Backlog Management

we found above practices are very useful.