Sunday 23 March 2008

667 - A Failed Attempt

This is for all those who wish to be:
"An IBM Certified SOA Solution Designer"

Well, I appeared for the test only to discover the following:

1: You must attempt a Sample Paper before you take the final exam

2: SW717, SW718, SW719 aren't sufficient to get you to crack it!

3: The "test your knowledge" sections at the end of those modules arent a per cent close to the kind of questions you would be asked in 667

4: 667 is not for people who have their knowledge and experience restricted to Application/Data/Information/Process integration only WITHIN an ENTERPRISE. It is much beyond just B2C integration or plain application integration.

5: It throws scenarios from varied verticals right from banking to manufacturing and healthcare to telecom.

6: If you thought no one uses MainFrames today - you are wrong. There will be hordes of questions on how you would integrate with CICS/VMS/IMS. So an experience with integrating with MainFrames in a B2B as well as B2C scenario is definitely a plus!

7: and like my Brother Anant mentioned in his sms[which truly made me feel nicer abt myself]: "its imp dat u enjoi ur journey in lyf 2 reach ur final destination nd nt get 2 stresd out over d result of 1 damn certification..take it easy nd b chilled..alldmad rush in lyf smetimes makes us forget d achievements we already have made 4ourslvs.."

8: :) smile ! :) therez always a next time :)

Good Luc to all the to be "SOA Solution Designers"!

lots of luc as always
~ sayli :)

21 Days - An Unsuccessful End..! :)

So the maximum number of days I could religously wake up and stick to my routine was just 7 days in a row.

March 8th - International Womens Day - when we celebrate the achievements of women world over, was the Day I made my 1st excuse and broke my regime - what an Achievement! :)

Thanks to DJ Suketu and the rocking Saturday night Vodafone Annual Party @Pancards - Sunday I oversleep! :)

So with a feeling of guilt of not having exercised 2 days in a row I wake up for a Monday morning Jog and follow it up on Tuesday to fall sick and drag myself to office till Friday.

Come Saturday and I decide to focus on preparing for my certification and hence give up my regime altogether!

But this still doesnt stop me from asking Abhi to buy me new fitness gear and get myself enrolled for Power Yoga n Aerobics ;)

I am at it again ! :)

Being a Fitness Freak helps - but only on Alternate Days - or better still - how about 4days a week ?? :)

so long as the weighing scale pointer doesnt tilt rightways & your tape shows the same numbers ;) :)

~ sayli :)

Tuesday 11 March 2008

To Succeed as an EAI Architect

As authored by Eric Roch reproduced here with an inclusion (and slight modification) of only the most relevant and notable facts:

The Career Path to being an EAI Architect must include technical and leadership milestones. Often developers overlook the need for strong written and verbal skills needed to produce coherent design documents and communicate the system vision to a team of developers. Once the design deliverables are in place the architect must then act as a technical lead to ensure the design principals are complied with to produce the components that must work together as an integrated system.

For an EAI architect, there is no way around a strong technical knowledge base. You must know the integration tools intimately to define the role the tools will play in a total solution. A solution typically consists of the EAI tools, application servers, web servers and enterprise applications like ERP systems.
The architect must understand where components of the system should be built and how these components interact to create a composite application. The goal of EAI is to integrate disparate system to function as a one. The systems to be integrated, are essentially the components and message flows, broker orchestrations, adapters, etc. are the integration environment that requires design artifacts defining the component relationships.

We effectively treat systems to be integrated as objects with interfaces and message flows into these interfaces. It is therefore critical that the architect has a solid understanding of OOA/OOD and UML.

Another important aspect of creating architecture is the use and creation of design patterns. This is the fundamental means to reuse design artifacts, so a study of design patterns is a requirement for an EAI architect.
Some design patterns categories that apply to EAI follow:
Enterprise Architecture:
SOA, ESB, Hub and Spoke
Reference Architecture: Composite Applications, Portals, Web Servers
Integration: File Transfer, Messaging, Shared Database
Application Architecture:
Application Server Platform: Model View Controller (MVC) e.g. Struts Model View
Integration Broker: Validate, Enrich, Transform, Route, Operate (VETRO)
Messaging: Publish-Subscribe, Request-Reply, Filter, Routing
Services: Canonicals, Security, Common Error Handler
Business Process Management:
Business: Codified Business Rules
Workflow: Control Flow, Branching and Synchronization, State-Based Instance management and task priority
To Sum it Up:
1. First make sure you have a solid development background in the tool set. You cannot make it to the next level without understanding the tools for EAI.
2. Study OOA/OOD and UML and be able to produce design deliverables with UML.
3. Collect a library of design patterns from books and past projects.
4. Develop your written and verbal skills by looking for opportunities to produce design deliverables and present them to the development team.
5. Look for opportunities to act as a technical lead always seeking to lead bigger efforts to the point where you can lead large projects (from a technical perspective). People skills, negotiation and communication are critical in this step.

I am already acquainting myself with design patterns and a business requirements specification deliverable. Exploring further on both these lines is going to be very interesting.

keep you posted
~ sayli :)