Attended Agile session

Today, I attended excellent Agile session conducted by NCR Agile User Group (NAUG). It was well received and lot of good discussion happened around Scrum & XP.

There were people from different companies. They are using different processes and methodologies in their respective projects. It was nice experince to listen different views.

Few discussion points were
Pair programming - It was hard to convince about Pair Programming productivity. Pair programming creates impression of more effort in comparison to traditional way of software development. It is true if one consider only a single sprint. But it would not hold true for complete project lifecycle. It reduces effort due to better quality output of pair programming.

Duration of Sprint - Good discussion happened on duration of Sprint. Scrum recommends almost fixed 4 weeks sprints with daily scrum meeting.

Rework or Refactor - A new name to rework in Agile is refactor. Is it possible to avoid this in traditional methodology? Refactor is going to survive and will promote Test Driven Development along with it.

One of major practice of Agile methodology is continuous feedback from Customer. It may be difficult to find customer who wants to work in such close collaboration mode as required by Agile.

Who makes more MONEY in IT - Manager OR Architect ?

Architect dont talk about Money ;) They are saints who dont care about it.

Let's discuss about the common IT employee. He works for multiple reasons like fun, interest, satisfaction, no other choice, family, company, status, habbit, money etc. Now he has a choice to select management or technical ladder. One ladder takes to Manager role and other to Architect role. Both need management and leadership qualities. Out of multiple reasons, Money was one. Now question before IT employee is - Who makes more Money ?

I would love to know what we feel/experience across IT world.

Embracing Agilism

My view on How come Enterprise Architects don't embrace agilism?

Two ways to adopt the change in corporate world, bottom up or top down. Bottom up approach means someone unknown in enterprise adopt a new tactics to improve the conventional procedure. It is adopted by small project and benefits are published at enterprise level. In this case, change is accepted slowly or sometimes never.

Secondly, in top down approach, management decide to change the things for better and publish new guidelines to be followed by corporate. Change is easily accepted in this approach. But no one in top wants to take risk which comes packaged with change.

In both the approach one needs a leadership quality to spread the benefits of change. Take a case of Agile methodology, its like a change.

Agile is gaining momentum. Corporate are trying its best practices like Test Driven Development etc. Mostly, its happening through bottom up approach. A slow approach. It is not easy to change the whole process in one go. Big Enterprises are embracing agilism in bits and pieces to find the benefits.

First impression of SOA on Business user

Is Business user ready to accept delay in response? Is it matter to Business user whether the services consumed runs on old legacy architecture or hyped SOA architecture? What all matters to Business user is usability? Any upgradation in technology should improve the functionality and quality attributes. First step towards SOA impacts performance. Decoupling of components/services with help of XML creates overhead in terms of XML processing, transformation and routing of messages. All these steps eats up significant processing time of request.

First step towards SOA doesn't create positive impression on business user. It becomes difficult to sell SOA to business stakeholders. Short term hurdles stops adoption of long term benefits of SOA.

SOA looks quite similar to Remote Entity bean concept in EJB 1.0. Conceptually, both are suitable for ideal scenarios. They attract purist who wants to follow the architect principles without business value. One may say Entity beans were fine grained domain objects and SOA are business services. Session beans orchestrate entity beans, similarly BPM orchestrate business services. Does any thing like local interfaces concept will emerge in SOA world?

SOA makes sense in case of B2B and services which are exposed to external clients. But within scope of Enterprise, do we want to consume slow business services. Its a call between performance vs flexibility. Lets see who wins or we are able to find the win win situation in time.

Long term vision vs Short term goal

Sometimes, there exists a conflict between Long term vision and short term goal. To achieve short term goal, project team compromises with Long term vision of product/program. It looks most practical to divert from the correct path and take short cut to deliver.

Occasionally, project team wants to ignore the long term vision in order to mitigate the impact on short term goal. Project Management and Business requires solutions as early as possible. Over here, it becomes responsibility of architecture team to explain , convince, mentor, motivate, communicate, enforce and sell the correct path and produce standards & guidelines for the benefits of project in long term. It helps stakeholders to take informed decision.

A mature and motivated IT team keeps moving on correct path to achieve the Long term vision. IT team always needs support from the management and business stakeholders. Does this holds true for Enterprise SOA ?

What can happen to IT Ecosystem w/o EA ?

Sometimes picture depicts more than hundreds of words

Few thoughts on Ruby

I took sometime to write this small blog. Blogs from James McGovern raised my curiosity on Ruby. I wanted to make my hand little bit dirty before writing.

Basic principles of RoR
1) Don’t repeat yourself (DRY)
2) Convention over configuration
3) Instant deploy
4) Ease of learning and more pragmatic
5) Built-in reusable components like ActiveRecord, ActionMailer, ActionPack, Action WebService

It is made for small to medium size application development. It is based on existing best practices in J2EE and DotNet world. It hard codes all best practices and makes them principles. No easier way to improve or change them. I feel with time best practices will improve and Ruby won’t be able to incoporate all of them.

It’s an interpreted scripting language and people from background of Python, Pearl and PHP will feel happy to move to object oriented scripting language.

My experience is in early stages of development Ruby increases the productivity but as application grows it starts taking time equivalent to or more than other Web frameworks. Ruby has its own boundaries and constraint which bounds the new developers to follow the convention and shows the best direction. But anything outside the boundary of Ruby will become difficult to implement. Inexperienced developers would make less design errors while working with Ruby in comparison to J2EE.

Currently it satisfies needs of small to medium projects with small team. May be in near future enterprises will start adopting Ruby for internal applications. It suits web based application on simple CRUD requirements without any need for complex business logic, sessions, security, availability, clustering and transactions. Let Ruby be like that.

In future, Ruby community can keep adding baggage in Ruby to fit all kinds of projects. But I feel it will act like a slow poison for Ruby simplicity. There is lot of scope and lot of small projects which will go for Ruby in future due to simplicity. But if Ruby community tries to make every customer happy with inclusion of all unbaked features, it won’t take Ruby to home.

I suggest for next 3-5 years, fix the scope of business requirements which Ruby will cater and sell it. Instead of expanding to everyone needs. Focus on niche small to medium web based internal application development. It will increase visibility of Ruby and it will also increase the number of people who knows Ruby well.

Way Forward in 2007

I am not the right person to predict the way forward in 2007. During last quarter, I got little time to go through buzzwords. Hope, I will find some way to reduce meetings in this year.

I hope that Architect's world and I will understand the basic principles better in 2007 and onwards -

1) Loose coupling and Reuse - Will adopt SOA to push loose coupling and reuse.

2) Abstraction - Add more XML files to abstract things.

3) Layered architecture – Vertical silos will break to give way to horizontal layered architecture in different domains.

4) Segregation of concerns - Cross cutting open sources like Acegi will gain momentum.

5) Cohesion - More companies will consolidate/merge to make impact especially small companies working in niche areas.

6) DRY - Move from code reuse to component reuse to service reuse.

7) Add more indirections - More virtualizations at different layers like Data and Servers.

What is more important for a project - Quality, Cost or Effort?

There are multiple objectives and goals for a team to achieve. And I concur that there exists a collective ownership for all objectives. But still for each objective there is prime stakeholder. This stakeholder persuade others to achieve this objective. Now coming to title of blog, what is more important for a project? I first list down the prime stakeholder for these objectives -

- Architect is main stakeholder of Quality (always busy to improve the quality by using different tools, Architecture document, better design, refactoring, automated unit test, reviews, POC's, continuous integration, increasing customer feedback, improving process)

- Business Manager is main stakeholder of Cost ( always busy in simplifying business case, selling flexible pluggable extensible & configurable components)

- Project Manager is main stakeholder of Effort (always busy in reducing timelines, parallel development, starting different activities simultaneously, change management, planning, scheduling, tracking, milestones setting)

So what's more important - whosoever is able to sell his viewpoint more convincingly ;)

New Year Wish Tag 2007

A new blog tag to share the New Year Wish List.

Wish you all HAPPY NEW YEAR !!

My wish list for new year -

1. To improve my leadership and negotiation skills
2. To maintain work life balance in New Year.
3. To visit at least two new places and make at least ten new friends.

No rules for number of New Year Wishes and number of bloggers to be tagged. I am starting my New Year Wish Tag with my favourite bloggers

Todd Biske, Sam Lowe and James McGovern

Hope and Wish to receive support from them. One more wish ;))

Blog Tagged

Todd Biske tagged me. Thanks for giving me chance to join the bandwagon.

I love the blog-tag idea of Jeff Pulver. See the simplicity of idea. I feel simple and powerful ideas are best to catch fire and create positive impact.

Five things to share about me -

1. I had done my Masters from IIT, Roorkee, India in Chemical Engineering. I started my career in well known Telecom Company. After working in Telecom R&D and pre-sales, I switched to Financial Company. Suddenly, SIP/IMS jargon changed to Buy/Sell Mutual Fund. Obviously, few underlying things remain same like UML, J2EE and patterns/concepts.

2. I never studied during my school days (Lucky to survive in school). Things dramatically change afterwards and now I never want to stop learning.

3. I am married and have one little cute daughter.

4. I enjoy travelling. I have been to few beautiful places in Europe, Middle East and Far East.

5. Few projects in which I was involved were Product development for Telecom Billing, ESB for Telecom industry, Prepaid Service on VoIP/SIP, Persistence Framework and many more. My latest interest areas are SOA, WS and Agile. I do lot of consultancy, reviews and governance.

Time to tag five interesting people - Jeff Schneider , Gregor Hohpe , Anne Thomas Manes , Bhagvan Kommadi and Scott Mark

In last, Wish you all MERRY CHRISTMAS and HAPPY NEW YEAR

Does I deserve to be called an ARCHITECT ?

When a IT professional deserves to be called an Architect? I am trying to list down few attributes of an Architect. I am not trying to find specific attributes for product, business, information, technical, software, specialist, application, system architects and whatsoever.

Its a fare trial to find out generic attributes, when a software professional is mature enough to be called an Architect.

1) When everyone around is in hurry to find the solution. Architect understands the problem first, its origin and future roadmap. See things from 10,000 ft. Afterwards, comes up with solution with blink in his mind. Its time to build consensus around the solution.

2) It is not based on number of years of experince. It is based when you start thinking at abstract level with very ambiguous information. You don't complain that information is not enough to take decision and try to dig it out.

3) He keeps track of emerging technologies. Understand when they are ready for enterprise.

4) He follows process and influence others to follow process. Believes in quality of work.

5) He is capable of taking difficult decisions on behalf of others and have courage to own it.

6) Able to understand, create and communicate the solution to team in their language (most of time UML/patterns).

7) He understands the concepts and principles of loose coupling, high cohesion, abstraction, encapsulation, information hiding, polymorphism. All these are independent of technology used in project.

Nuke in the arsenal of Enterprise Architect : SOA

Architecture skill demands continuous improvement. Its a journey not an end. Architect should be able to enhance his skillset as and when job demands.

It is predicted that SOA will reduce the overall IT expenses in enterprise. It means time is right to build SOA skill and campaign for SOA adoption in enterprise .

I love analogies to explain my point, compare SOA with a nuke in arsenal of EA. Not every country in world has Nuke, still they survive and most of them have ambition to develop one in future. Furthermore, same nuclear technology can boost the country economy or can destroy it. Depends how it is handled. Advise is to handle SOA with care.

Software Selection

As an Architect oftenly one would evaluate different presentation technologies, reporting tools, application servers, databases, open source components, ORM, CM tools and a lot more.

Most of time selection depends on perception of team instead of facts available. Try to evaluate the options by leaving behind all perceptions. It is not difficult to find the best fit for your requirements.

We could look into the Software selection through three main aspects - Functional requirements, Non functional requirements and Strategic requirements. Every requirement has its own weight. Combination of all these scores finally help to select the software.

But sometimes it is difficult to start Software selection. For a same requirement, there can be multiple COTS and FOSS available. One may need to start with Elimination technique first based on main requirements. Narrow down the number of options. Go into Evaluation stage. And finally selection happens.

Few techniques which helps in evaluation are conducting POC's, going through case studies, finding references, identifying gaps between requirements and features available in COTS/FOSS and cost analysis covering licenses, software, hardware, customisation, implementation and maintenance costs.

Need of Architecture - Winchester House

INPUT
38 years of construction
147 builders
0 Architects
No architectural blueprints

OUTPUT
65 doors to blank walls
13 staircases abandoned
24 skylights in floors
160 rooms, 950 doors

Above example shows the importance of Architecture in every project