Thursday, August 10, 2006

This is just the list of applications I use every day, for my job or for personal use.

Netvibes : to have an overview of what's happening, including news, podcasts etc..., but also access to my gmail emails, delicious bookmarks, my asterisk voicemail

Price : free
Preferred features : Netvibes ecosystem

Gmail : I definitely moved all my email boxes to gmail. I created accounts for all the family. Don't use your boradband provider email : it will not follow you all your life. With the competition on prices, it is quite sure that you will select a new broadband provider every 2 years.

Price : free
Preferred features : search on your mails instantly, access your emails from every PC or PDA, with a POP client or with your browser

Bloglines & Google news : they are my newspapers.

Price : free

Blogger : where I publish my ideas. If I was not so lazy, I had surely built my own web site. But I have no time for that, and I'm not technical enough.

Price : free

Microsoft Office : the tools I use every day to build documents. One should prefer OpenOffice. The fact is that it has more bugs, it is not enough compatible with Microsoft Office, and others (clients, colleagues, friends) also use it.

Price : expensive

Microsoft Outlook : even if I do not like its heavy weight on my PC, it is the unique tool that synchronize easily with my PDA/Phone : contacts, emails, phone numbers, calendar, tasks.

Price : expensive

Google Desktop & Exalead Desktop : to search on my PC
Skype : free VOIP calls and chat. At the moment I do not use Skype In or Skype Out

Price : free

MSN Messenger : chat
Trixbox : my personal PBX

Price : free

X-Lite : my Voice over IP phone

Price : free

Voipbuster :

Price : some calls are free, other are cheap, at least 2.5€ per month for outbound calls

The GIMP : images editor

Price : free

Pixvue : tag & rename images

Price : free

And many others...

Loosely coupling helps CIO to keep his job

Loosely coupled components

A Services Oriented Architecture is defined by 3 features:

Loosely coupled components
Stateless services
High interoperability of services

These 3 features are not so simple to understand, and every day you will find architects and software vendors claiming that their architecture is S.O.A but not following at all these design principles.

This article explains what means ‘loosely coupled’ components in an Information System (IS).

CIO that are successful in loosely coupling the various parts of their Information System protect their jobs : they do not have to ask their CEO many millions to throw all that was done before and replace it with a new cohenrent system.

Being successful in designing a loosely coupled system has an enormous impact on IS flexible evolution.

The bad news is that it is not sufficient at all to select a framework or a software vendor that promises you S.O.A.

The good news is that there with the framework or product you have selected you can also create a loosely coupled system.

Flexibility

Companies want their Information System flexible.

They want to be able to change the way they do the things without having to invest huge money and wait months and years to have an answer to their need.

One of the hardest things to achieve fo r any IT organisation is to adapt to these continuously changing requirements coming from business teams.

Monolithic applications and systems make these changes request a nightmare.

And every new project and every change in a system tightly coupled create more complexity and coupling. After 5 years of evolution of this system, someone proposes to re-factor the whole system. At this moment, buying a wonderful ERP that does everything seems to be the best option from an executive point-of-view. And as all ERP are mainly big monolithic applications, after implementation and a few years of new needs and evolutions, the result is the same.

Only loosely coupling the components of the IS provides for flexibility. Because when components are loosely coupled you can:

Make them evolve independently
Support simultaneously various versions of the same interfaces
Easily reuse and assemble existing services to create new ones

As a result, IS is immune when a component is upgraded to provide for new functionalities. By supporting several versions of the same interface, components can evolve asynchronously. And when the business comes with new requirements it is often easy to fulfil it assembling services that already exist, and are already in production.

Loosely coupled interfaces are in some kind immune when the producer and consumer ends change a little but their interface definition.

You can partly upgrade the producer without changing the consumer.

When you update your main system to provide new capabilities, you want let your clients to continue to access the old capabilities until they get around to upgrading.

How to do that?

These things come with SOA.
Be careful, not all SOA. The one who consider that SOA is Remote Procedure Calls with angle brackets will not only fail implementing loosely coupling, but do worse : they will tightly couple applications together by using a huge number of loosely coupled interfaces. It will not be possible to change one system by another because the number of fined grained interfaces will be to important.

The first important point is to begin to well-define "exchanges" between applications. You will require a reference model of each piece of data that will be exchanged between applications. Note that this model is not a copy of your existing database. The best is to reuse the XML models proposed by the industry you are working for.

The second important point is to hide implementation technology in your services. Having Web Services whose URI is something.aspx or something.jsp is not hiding the technology behind it. You must define a URI map that is completely independant from technology. I suggest you following the REST design principles.

The last thing is : keep it simple, and reuse existing vocabularies, adding them constraints, instead of reinventing new ones.

When you invent a new language, you have to write a validator, a parser, a viewer ...
When you reuse one existing, all these thiongs are free. And it improves the chance to easily integrate with your ecosystem.

In this area, Microformat have an interesting concept : use XHTML as a container for structured data. XHTML provides you for an existing syntax and some existing semantic as well. Add class="meta-data" to your div or span or whatever elements to give meaning to your data inside the XHTML enveloppe. And human and machine will be able to read these documents.

Using RSS & ATOM as an enveloppe to exchange data is probably the next big thing. Have a look at Google GData, look at Netvibes portal, or google/ig portal : they are reinventing the new standard for portlets : a portlet is an RSS feed. All can be an RSS feed : your emails (see Gmail Atom), your information, your calendar (see GCalendar), your contacts (see Netvibes Plaxo extension), your bank account history, your todo list, your clients to call, ...
And these RSS feeds can be shown in your portal, whatever technology you choose : opensource, commercial, hosted portal.

Conclusion

Loosely coupling is achieved by:

making the same choice than the others. The vast majority of them. Don't invent XML languages. First consider if you cannot do it with RSS, ATOM, XHTML, UBL (business), Microformats, ODF (Open Document Format)
reducing the number of coupling points : use coarse grained interactions instead of optimized specific fined grained interactions.

Railway Station Desks are Stateless

IT managers do not understand why stateless is scalable and stateful not. They consider it is a religious fight.

Software vendors whose licenses models are price per CPU will find tons of arguments against this model. Their marketing teams are paid for that.

The less performant is your system, the more money you give them.

If your company plans to spend less in IT, then you should consider understanding deeply the difference.

Day-to-day life is bringing us tons of sample that we can use to metaphor architecture design patterns. Railway stations desks are like application servers : they process requests.

Some general considerations

Internet architecture is stateless. Its components do not rely on a state to process the requests.

Two models are currently used in software development:

Stateful Application Servers
Stateless Application Servers

Their are two major things people do not understand:

Stateless Applications Servers can process stateful processes
Stateless Applications Servers can easily handle errors as well as stateful

Software engineers and architects coming from client-server do not understand easily that until they build their first stateless services.
If you are not convinced, but openminded enough, read the article, and try yourself.Entering the railway station, I saw that at least 10 free desks, so I went to the nearest.My travel agency is stateful. It gives me a printed copy of the reservation and keeps the original on its desk. I have to come back to this exact desk to confirm the reservation before the 2 days delay.It is a stateful desk. Exactly like a stateful application server. The data is stored on the desk like the application server session stores data for future retrieval in an application server.

The story

When I worked in Paris, I wanted to book a ticket on Paris-Montparnasse railway station to go from Paris to Toulouse. But I did not know the schedule and the price. I was near the station so I decided to go to get informed, to reserve, then later to check with my family and to buy the tickets.

Reserving the travel

The train was leaving at 5 PM on Friday. That sounds good. The agent informed me about the time schedule, and said I have to be careful because this train is always overloaded.

But I was not sure it was OK with my family, so I reserved my 5 tickets and the agent entered this in its system and gave me a reservation number, valid for 2 days, and printed a sheet with the details of the travel and gave it to me.

On the sheet it was indicated that I had several ways to get my ticket.

Come back to any railway station in France, show the sheet, pay and get the tickets

Connect to the Internet, pay by credit card, get the ticket sent by mail

Go to an automatic ticket machine, enter the reservation number, pay by credit card, and get the ticket printed by the machine

Getting the tickets

During the evening, I checked with my family. The price was cheap and the time schedule was convenient. So we decided to buy the tickets.

The day after, I came back to the railway station.

It was a busy day. Quite all the desk had a queue. I went to the smallest queue and waited for my turn. I gave the reservation number, paid, and get my tickets.

My travel agency

In my shopping center there is a big store with a travel agency. It is nice as the shopping center is just 2 roads from my home.

I can avoid going to the railway station to book a ticket. I can go to this travel agency.

The only thing is that if I reserved the train on this travel agency, I have to come back to the same travel agency to pay and retrieve my tickets.

Normal: They are delivering a service and want to be paid for that service.

I can't even go to another travel agency from the same store in another town, because it is not the same business. The store account is not global.

But it is nice, as it is just 2 roads from my home.

And it sells train tickets, flights, hotels, car rental...

Quite all the day, their is nobody, so if you decide to go at this moment, service is fast and personalised. The agent know me. She is nice.

But between 5 and 7 PM, it is hard to get served in less than half an hour. All customers are getting their tickets, vouchers...

And it is good if you find the same agent than the day before, when you completed your file, because she remembers your personal data. She will also find your file in her desk quicker.

My Railway Station is stateless

Let's compare this story with a three tiers web application

The railway station is the URL where the service is hosted. It has a unique location. As well as there are various channels to buy a ticket, there are also various channels to interact with an organisation suck as internet, WAP mobile phone.

The desk processes requests, as well as an Application Server processes request.

Eventually, some guide can play the role of a loadbalancer, routing people to the right desk as well as a loadbalancer routes the HTTP request to the right Web & Application Server.

Railway station back-end system is the data tier. It stores permanent data such as the time schedules, and work in progress such as reservations, bookings.

My railway station is stateless. It does not store the date of the booking on the desk. It does not affiliate a customer to a desk. It does not require that I go every time to the same desk. It allows me to begin a process with one desk and to continue it with one other desk. It allows me to choose the desk where the queue is small.

How do they manage incidents?

What can happen between my 2 requests?

The train could have been canceled: so, when I try to retrieve the tickets, they propose me another train, later, or an alternative path.

For any reason, my booking could have been canceled. Airlines do that every day. They have an 'overbooking' process, and sometimes you have booked for a flight and they propose you another flight - and some money for my pain :-). The agent proposes me another train - and no money :-(.

I could have paid but then the train is canceled: in this case, I get reimboursed at any desk.

I could have decided not to buy the ticket: then the reservation will end at the end of the delay and will be removed from system.

In anycase, their are simple solutions to manage incidents. These solutions do not require two-phase commit neither state management on the desk.

In a Web Application, same strategies could be applied. And it does not cost more to implement them that to debug all this functions relying on sessions.

Let's look at excellent article Your Coffee Shop Doesn't Use Two-Phase Commit from Gregor Hohpe. You will understand how you can handle incidents in asynchronous processing models.

My travel agency is stateful

Tons of things can happen

Unfortunaltely, the desk is very busy, so I have to wait. There is a free desk but all the other people in front of me reserved at this desk at it is the nearest from the entrance, and have to wait here.

Unfortunately, it is closed. It will open within one hour. Will my reservation be lost within one hour?

Unfortunately, the print copy on the desk has been lost. The agent who was here yesterday is ill today, and the new does not find the files. I have to redo my reservation. Will I find available seats?

But the guy who invented these stateful architecture found some hacks.

Session replication : every time I have a reservation, I go to the copier and I copy it in order to have it on one or several other desks. Just in case my desk is closed when the next transaction will occur. I do not know one project requiring scalability that implemented this without pain.

Sticky session : every time the same user come back, it has to go to the same desk. So that he is sure to retrieve the state. It reduce greatly optimize use of your desks/CPU as it block one user to a desk/CPU, whatever it does.

Cost & Scalability

Surely, the two models do not have the same scalability.

In a stateless system, sizing the system is very simple.

You just have to know what is your processing time by CPU and you will find how many transactions per second a CPU will process. The numbers of concurrent users does not matter. 10 users clicking every 5 seconds generates the same workload than 100 users clicking every 50 seconds.

When you size a stateful system, you must know how many customers you will have assigned to one desk, you must know how many concurrent users a CPU can handle.

Just read the sizing recommendations from the software vendor and you will see if the system is statefull or stateless.

Let's imagine this recommendation from the software vendor:

You need one CPU for 400 concurrent users

Let's say that a user has a think time of 20 seconds. So it generates 3 requests per minute.

So the CPU will be able to process 20 requests per second.

Let's say that a normal CPU server with a stateless application can process 1000 requests per second.

It means 1 ms of CPU to create a web page. Normal performance.

Knowing that, buy the technology you want :-)

Management : Coaching

Coaching

IT services companies mainly sell the value of their consultants. All they that can increase this value improve their position.

One staff can grow when:

He has got new assignments, with new context
He receives training
He receives coaching

Coaching allows a continuous improvement of staff. Some consultancy firms sell coaching mainly for high level managers. It is useful for managers who have been just promoted, because they have nobody to refer to, no more models to copy, as they are now on the top of the company.

I think that coaching inside the company provides for excellent results as every coachee is in a personal improvement process.

This article is about giving you the clues to apply coaching within your company.

If you are a manager, an expert, a skilled and experienced professional, you would benefit from applying simple coaching methods. As soon as your team will improve its skills, its autonomy, you will win time for more coaching. Your team will be motivated and the results will be better. You will then easily find someone able to take your job and you will be able to have greater position.

1- Start a coaching session

Generally, the coach is the cause of a coaching session. He found a problem: the project is stopped, the staff has an unwanted behaviour, and quality is not good enough.

In that case, the coaching session will follow a feedback meeting.

Knowing how to send feedback to the staff is very important.

A lot of us ruin the relationship at this moment, as they do not know how to give a negative / constructive feedback when they found a problem.

I advise you to prepare your feedback session:

First, look at the facts, the real facts. Avoid inaccuracy, avoid generality, and avoid judging the person. Without facts, feedback will be inefficient, and sometimes not justified.
Then, assess the impact of facts on the context, the project, the personal performance of staff. If there is no impact, then giving feedback is not justified. You are just irritated by the behaviour. Be open-minded and tolerant.
Then, think about the desired outcome. It should be a change in behaviour and not something that cannot be changed. Is their any interest in blaming someone for something he cannot change?

Giving feedback is done in 3 steps:

Explain the facts. Be sure that the coachee agrees with these facts.
Explain the impact of these facts on the personal performance of the coachee, on his colleagues work, on company activities. Be sure that the coachee understands these impacts. It is really important at this moment to listen to the coachee explications.
Explain then the desired outcome, and be sure that the coachee knows and understand the changes you want and can do them.

Often at this moment, you can propose a future meeting that will be a coaching session, either with you either with another appropriate coach.

If you don’t follow these advises, you could be in some difficulties.

Take for example the case of a staff arriving regularly late at work.

You think that he is too cool with working hours, you meet him in an open space and …

Manager: “You are regularly late, you have to change that!”
Staff: “No, that is not true, when did I arrive late?”

As you did not prepare your meeting, you have no answer to give
Result: one joker lost…

Or …

Staff: « Regularly, no, indeed, yesterday and last week I had to go with my son at the doctor and I arrived at 10. But this morning I came one hour before to balance.
Result: one joker lost…

Or…

Staff: « You are right, I’m arriving every day at 10 and leaving at 20, so I avoid traffic jams. Is there a problem with the quality of my work?
Manager: “Eh, … no”

As you did not verify that this behaviour had no impact, you have no answer to give.
Result: one joker lost…

You also have to know how to react to several possible attitudes of your staff:

He says nothing
He is aggressive
He speaks a lot and does not allow you to explain your view

He says nothing : ask him an open question (a question he cannot answer by yes or no)

He is aggressive : do not follow him. Speak slowly and sweetly and propose to speak about the thing later and calmly.

He speaks a lot and does not allow you to explain your view : trying to do like him will not help you. Let him speak until the end, let him know that you listen to him and that it will be fair he listen to you to the end.

A prepared feedback has a lot of benefits. Indeed, the employee perhaps do not realise his behaviour. Listening can provide you new useful information that will change your mind. Listen. You would discover that the only impact of a given behaviour is that you don't like it.

And, most important, it is the best moment to decide a new meeting to fix the problem - a coaching session.

2-Assess coaching need

Coaching aims at helping people to be successful on their work. Firstly, it is important to know what are your possibilities as a coach :

the willing to do: does the coachee want to do the job or does he need motivation
the ability to do: is the coachee skilled enough to do the job? Does he need any form of training?
the empowerment and authority to make things happen: has the coachee the right position enabling him to make things that are not in his scope change?

The coach must behave in adequation with this assessment.

To be added :

Matrix Wish/Will
Guide / Directive / Empower / Motivate / Train

3-Prepare a coaching session

Preparing the coaching session is very useful. For efficiency, the session must focus on one particular subject instead of trying to solve all points. If there are multiple issues, let's focus on one and define antoher metting for other issues.

Often the coach's diagnostic is wrong because he did not prepare the coaching session.

It is useful to prepare the following points:

What specific objective assigned to the coaching session?
On what particular issue can I focus?
...

4-The coaching session

There are 4 steps in a coaching session:

Confidence
Objective
Alternatives
CHoose

5-Follow-up

[TO BE CONTINUED]

Resume

François TRICOT

Born the 16/04/67

Main skills

Management of business unit in the field of new technologies

Business Development
Delivery management from small to high and complex operations

Human resources management : recruitment, career management, staffing
Marketing of service offerings
Finance management

Main work experience

Head of Toulouse Accelerated Delivery Centre
Set-up of Toulouse ADC, new service offerings
Set-up and management of partnerships (Microsoft, SUN, BEA, HP, IBM …)
Management of skill group/centre : technology strategy, business development, HR, P&L
Management of 120 people : 45 e-Architects, 15 Project Leaders, and Software Engineers

Languages

French (native language),
English (fluent),
Spanish (fluent)

Education

Baccalauréat 1985
Classes préparatoires – Math Sup 1985 - 1987
Ecole Polytechnique 1987-1990 http://www.polytechnique.edu/
Ecole Nationale Supérieure des Télécommunications http://www.enst.fr/ 1990-1992

2006 : Capgemini - Telford - UK (80%)

Join ASPIRE contract for HMRC
Redefined architecture for a citizen high scale portal
In charge of industrialisation of practices in the 'e' area
In charge of improving productivity in the testing area

2006 : Capgemini France (20%)

Responsible for the implementation of internal programme "Services Oriented Architecture"

2002 – 2005 Toulouse / Head of Skill Center/Group “Accelerated Delivery Services”

Responsibilities:

Definition of strategic guidelines

Service Offerings / Market
CMM-I
Service Oriented Architectures

Business Development (won projects from 10 k€ to 13 M€)
Management of ADC P&L
HR management (recruitment, careers, evolution of skills)
Growth from 50 professionals in 2002 to 120 in 2005

Projects domains:

Portals and content management,
Product Lifecycle Management,
Mobility,
SOA, Custom development Java & .Net

Clients:

Airbus, SICLI, UAC, INVIVO, CNES

2000 - 2001 Paris / Skill Center Manager “e-Business Solutions”