Freedom For Ideas

Sharing ideas, concepts and thoughts, mainly about Information Technology – and consulting

Posts Tagged ‘IT’

Poor, transparent tools

Posted by Yannick Martel on October 26, 2009

Poor, transparent bike

Coming back to Tools for Conviviality, I want to share some thoughts on software architectures. Software products and associated frameworks on which we build them are tools. As such, the criteria of choice is usefulness to our goals. They should be servants.

Ivan Illitch advocates that “the simple, poor tool is a humble servant; the elaborate, complex, secret tool is an arrogant master”. How many times have we seen choice of tools which we do not master? Which are “elaborate, complex, secret”, and the more fascinating because they are? Can we mention:

  • Complex, poorly understood architectures, based on new concepts which are barely understood?
  • Huge packaged products, which contains the expertise of generations of analysts and programmers, but which you don’t pretend to master in a lifetime?
  • Sophisticated frameworks, which are supposed to do it all and are the best you can get. But cannot sometimes the best be too much?
  • Assembly of “best of breed” products, which can turn into “poorest of suite”?

Have you seen these? For myself, I have seen them too many times. With Ivan Illitch, I want to advocate a preferred choice of “simple, poor tools”, which can be mastered and are not too much for our hands, and this apply too well to our software architectures. Thanks to Tools for Conviviality, we have guidelines for selecting them when KISS is not enough. Guidelines which show us how to put at the center the human beings who are going to run, use and rely on them.

Posted in Architecture Style, Books, IT, Methodologies | Tagged: , , , , | Leave a Comment »

Towards post-industrial IT

Posted by Yannick Martel on October 20, 2009

Modern railways station

After reading Tools for Conviviality from Ivan Illich, it seems to me that the large IT organizations I know are some of the best examples of industrialization gone wild.

Ivan Illitch introduces a maturity model for the industrialization of a product or process. Before the first threshold, the costs of industrializing exceeds the benefits. It is like transportation with the very first steam machines: noisy, filthy, not much good for anything. Then maturity arrived, and usefulness exceeded the costs – when steam power was mature enough to be applicable to helping in the real life. In this way, many products and services were industrialized successfully and transformed the world: medecine, transportation, education, food…

But then the cost of industrialization in terms of energy, human life, environment, excessive complexity, indirect costs can become too high and exceed the benefits, at least considering the overall society – some people or groups can still benefit by concentrating wealth and power. Ivan Illitch defends the case that many services in in developed countries have exceeded this second threshold, the threshold of decreasing marginal usefullness.

In large IT organizations, industrialization has been used as a set of methods for tackling complexity and volume. Up to a certain point, we have seen some success. New, more complex, more ambitious software applications are being developed, improved, and are to a certain extent serving the business. But as a method for improving the efficiency of the business, the industrialization of large IT systems seems to me to have exceeded the second threshold. Every new aspect which is submitted to industrialization and centralization, turned over to experts, adds a cost which is out of proportion with the benefits the company gets from the move. This added cost takes many forms: human life essence, efficiency, resources, indirect cost on users or customers…

What should we do? Turn to industrialization with the same tool which has helped in the beginning: rationality. We have used rationality to industrialize, but are not applying rationality anymore if we consider the tools of industrialization as mandatory, as an ends in themselves. We should realize that it is not rational anymore to go on applying these tools without any discrimination, that we should better add some new tools, the tools of conviviality to be able to develop a post-industrial IT.

Posted in Books, IT, Management | Tagged: , , , , | Leave a Comment »

You don’t need a damned e-shop, your customers deserve more!

Posted by Yannick Martel on September 24, 2009

Going shopping?

I admit it, I am a telco guy, having worked in that sector for longer than I care to count. It is thus a pleasure for me to see telecom operators transform and adapt, when they do it for good. I appreciate seeing new ideas take form and shape for the benefit of all, vendors and customers. But it seems to me most telcos are struggling with their Internet strategies. They have a hard time setting up nice enough Internet site, keeping them up and running and attracting customers to them.

Probably that’s the reason why I want to share here what I would like to tell them, especially after reading Jeff Jarvis.

1- Stop calling the Internet site where you promote your products and sell them an e-shop or an Internet boutique.

Once you know a thing’s name, your control it. That’s the nice side of the coin. The other side is: you name it wrong, you get it wrong. Naming your selling site a boutique means it will be only this, a copy of a physical shop, where you only expect to sell at a reduced cost – to you. Thus at best it will provide a slightly worse experience than a physical shop. Don’t ask why your customers are still going there.

Instead, you should find what else it could be, and try to do it. But that should be something better, unique, which can be done only via the power of Internet – and we know that we can do many new things thanks to Internet. If you don’t, just take a tour before building your web site.

2- Stop positionning it as a competition to your physical shops

A bit of a competition is good, too much can be dangerous, especially inside a firm. Build your business relationships, most of all with your colleagues, on trust and cooperation, not competition – don’t worry, competition will come by the side, even if not encouraged. This means you should develop the Internet media as a new, original one, which has its own niche, and is complementary to shops. If your Internet presence compete with your physical shops, it means that you are not promoting at their best the advantage of each channel. And don’t forget: while your are busy managing the devastating effects of internal competition, others might be taking care of your (old) customers.

3- Create a community and hand it control

The Web 2.0 is all about communities. We are lucky in that mobile phone and even Internet access are already community-oriented. Mobile phones are trendy gadgets, and for many accessing the Internet via an operator is being part of his community. Not for everybody, but you only need a small critical mass to start with it.

So the advice is, straight from What Would Google Do?: make your on-line presence a platform on which communities can live and flourish. As a side-effect, these communities can help you sell your products, or better use them. If you take care to listen and cooperate with them, they can help you improve your products, get better support, package them the right way or price them the right way. First, you accept to be influenced, and then you give them some control. Then they can help you and work for you – by working for themselves.

4- Don’t do it all yourself

If this program sounds pretty difficult, you are on the right way. But don’t do it all yourself! You can build the minimum infrastructure, hand them the tools, and then get ideas and help from the masses. Your devoted users can help you design your next best-selling products. They can also build many aeras of your next successful community platforms (aka web sites). Allow and encourage plug-ins and links.

5- Provide them access to your best deep resources

That’s the best of true SOA and SSOA. If you really want to get help and you are serious about it, you should do your best to those people devoted to help you. You should give them access to your most valuable resources, to the depths of your IT, network and service infrastructure. And the best part of it: be happy if they are using it better than your own guys.

And now, where do we start?

Posted in Books, IT, Management, SOA | Tagged: , , , , , | Leave a Comment »

The failure of Agile?

Posted by Yannick Martel on August 17, 2009

Is this yet another blog post about the failure of agile? No, not really. More about the failure of Agile adoption, that is failing to notably improving the development process and its effectiveness in delivering features.

A major roadblock with Agile adoption is that Agile is more than a new project management methodology. It is a new approach to product development and application management, based on a number of principles and values, many of which related to management, not just project management. Thus an effective adoption requires new management methods, and its adoption can be gravely impaired by attitudes from decision-makers outside of the project if too far from Agile values.

This means that for an effective adoption (you want results, don’t you?) managers need to also change their attitudes and expectations. They need to change how they interact with their teams and what they expect from them, both explicitely and implicitely.

What if they don’t? Agile will just pass as another fad, but might be an occasion for your competition to benefit from huge productivity improvements and gain an edge. And as Edwards Deming mentionned: “It is not necessary to change. Survival is not mandatory.”

Posted in Agile, IT, Management | Tagged: , , , | Leave a Comment »

Working on the bottleneck – the right one

Posted by Yannick Martel on June 12, 2009

Are you attentive?

Are you paying attention?

From Lean Management and The Goal, you know where to look for when you wish to improve a complex process: you need to search for bottlenecks in the process flow, and first of all the major bottleneck. Find it and then concentrate all your actions on improving it. Then the process will get better (produce more and/or faster), but you will find have another bottleneck, another limiting factor. Just find it and work on it, and so on.

In IT, Agile has been proposed as a solution to the difficulties in the software product development  process. As Agile concentrates on software design and development, it can really help only if difficulties were indeed in design and development. That’s probably partly true as we effectively see improvements when Agile practices are really applied in development projects.

But then from Lean Management, we know we should look for the next bottleneck in the process. Where to look for it? We get an answer by looking at a typical Agile project: somewhere between three and eight weeks after the beginning, the pressure is no more on the development team but on the product owners. And thus we have found our next (and maybe really first and most important – why not?) bottleneck: the team in charge of knowing what to ask.

To me, it is particularly important to effectively address this bottleneck, first because the bottleneck is stronger: knowing what to code is at least as important as knowing how to code it – and generally coding correctly is easier that knowing what to code. Once the development team is ready and eager to produce value, all concentrated on it, it can gell pretty fast and request to be guided, request to know what to produce – pressure has moved.

But there is another, more subtle, reason: softtware development is more related to product design and development than manufacturing (more related to designing a new model of Prius than manufacturing it). It is a profoundly creative activitiy, requiring communication, trust and confidence. If a strong bottleneck is left in the process and it is not addressed, then you risk mining the efforts which have been done elsewhere and loosing everything you’ve earned. More concretely: if your product definition process is visibly the bottleneck and you don’t address it, the demoralizing effect will destroy whatever gains you’ve done by implementing Agile in your development team and you’ll quickly loose the discipline to go on with Agile practices and continuous improvements – maybe creating a secondary bottleneck again.

Posted in Agile, IT, Methodologies | Tagged: , , , , | 1 Comment »

Agile Adoption Patterns, 1, 2, 3

Posted by Yannick Martel on September 16, 2008

A sleeping volcano in Auvergne (France)

This looks like a plateau, but is in fact a volcano. Beware!

Let me confess it: I am not an expert in Agile. I have yet read only the first three chapters of Agile Adoption Patterns, from Amr Elssamadisy, and I already want to share with you how much it has inspired me. Especially in relationship with a specific project we at OCTO Technology are helping to get Agile. I will go on reading the remaining 43 chapters and may later review them here.

Agile is nowadays quite fashionable, and this very success generates its own problems. Amr mentions that the very first teams adopting Agile “methods” obtained 500% improvements in productivity, but that as Agile is becoming more pervasive and adopted by a wider audience we see more teams getting instead only 50% improvements, or failing to obtain any improvement at all. Indeed I now realize that the project I have in mind has probably reached this 50% plateau. Amr’s intention is to help us overcome this difficulty and implement an Agile adoption strategy to go much beyond.

For this, Amr’s gives me two keys. The first key is learning. Learning is the bottleneck in software development, the limiting factor in your effort to develop efficiently useful and dependable software. Learning might be about the functional domain, your user’s preferences, technologies, software development processes, whatever. Thus many of the Agile practices help people examine frequently what they have done and get an opportunity to learn and improve: short cycles, retrospectives, test-driven specifications, etc.

My “plateau” team is not today using some of the most important learning-oriented practises, such as refactoring and retrospective. The emphasis is more on velocity, not on learning. IMHO, this explains the plateau: once you have adopted some basic practices, you don’t improve anymore if you are not willing to experience frequently the slight unease of realizing you could have done better and turn it into the next incremental enhancement.

The second key is personal responsibility. The best Agile teams are self-directed, self-improving and responsible. Collective responsibility can only be based on the individual responsibiliy of team members. Many Agile practices help people in the team evolve towards more individual responsibility. Just as an individual cannot be ordered to be responsible, a team cannot be declared self-directed, but you can help it.

My “plateau” team is not today self-directed. It is composed of individuals moving in a hierarchical environment, which does not encourage personal responsibility. Agile adoption has not been positioned as a change in culture, only as “just another software development methodology”. I think we have not worked enough to empower the team, maybe because we did not fully appreciate the effects of the cultural gap.

The third chapter is about business values. What are your most important goals? What are your reasons for improving your software development process? Amr suggests some candidates, and invite to look for the right motivation for your team. If we know why, we have better chance to improve, and in the right place.

My best idea right now is to talk to the various members of the team and project sponsors, and try to understand what is the motive for getting the team Agile. Time to market? Yes, we would all like to get a release a few months sooner. Cost? Yes, of course, as everybody. But isn’t there any other reason, more specific to their situation? Then, I hope we will be able to get them motivated and empowered to overcome the plateau.

Posted in Agile, Books, IT, Methodologies | Tagged: , , , | 1 Comment »

Self-Service Oriented Architecture

Posted by Yannick Martel on September 3, 2008

How easy are they to use? Do you need any documentation?

How easy are they to use? Do you need any documentation?

For the benefit of those who have lived in a cave for the past four years, I can announce that Service Oriented Architecture, or SOA, has been a major trend lately. I won’t debate whether it is past history or not, whether it has failed or not – it is generally admitted that SOA is there, and not anymore at the bleeding edge. An old-new idea, SOA put a major emphasis on the availability of services. Now, services are made to be consumed, and frequently to be consumed many more times than produced.

Then let us take the global viewpoint, including consumers and producers. If services are made to be produced once, consumed many, then it sounds reasonable to strive for a low-effort consumption, even if it makes things a bit harder for the producer. The producer should position himself as a service shop, delivering services to client and willing to make their life happy and easy. It is the same as in business: if a transaction is pleasantly and effectively concluded, your client is more tempted to come back to you next time and to recommend you to his buddies.

The trouble is that it can be costly to deliver good service to your consumers, and to support them adequately, if you keep your services as they are. This is where I want to introduce the concept of Self-Service Oriented Architecture. This motto emerged from the session at the Université du SI of my coworker at OCTO Technology Ignacio Lizzaralde. Basically, as a producer, you should design your services and provide surrounding infrastructure to make your consumers as self-sufficient as desirable. This means for instance:
– providing simple and clear APIs and resources
– having your APIs and resources exposed on simple to use technologies
– having your services self-documented
– provide documentation with examples
– provide tests environments
– allow your consumers to download client libraries, mockups, help files
– provide a mailing list and a forum to listen to your consumers and have them interact and share experience

I hope you get the idea. This approach is valid whether you are providing services to outside of your company or they are for inside consumption. It is a powerful guideline for designing, implementing and for supporting services.

Generally, service providers are more inclined to deliver good services to the outside, where there is competition. But clearly there is also competition inside a company – competition between different sources for the same data and processes. By making your consumers more efficient at using your services, you are beating internal competition, promoting your efforts while making your company as a whole better. Thus Self-Service Oriented Architecture, or SSOA. Why a new acronym? I want to help fix the concept, as I hope to do with my clients. It can be debated whether SOA as a trend brings anything new to help IT to bring more value to the business. I am convinced that SSOA can.

Posted in Architecture Style, IT, SOA | Tagged: , , , , | Leave a Comment »

Yet Another Blog and the Garabit Viaduct

Posted by Yannick Martel on August 30, 2008

The Garabit Viaduct and the river

The Garabit Viaduct and the Truyère river

Yes, yet another blog. Why this one? Why another one?

Maybe the envy had been germinating for a long time, but I can point precisely at the time of the decision: it was this summer, when my wife and I were driving from Paris to the South of France, to pick up the kids on holidays at my parents’ home. We drove past the Garabit viaduct, a railroad arch bridge built at the end of the 19th Century in the Massif Central. We stopped to enjoy the view on the valley and the bridge. There, the highway company had set up an exhibition about the bridge, with some photographies and explanations on the genesis and construction.

The viaduct originated from the desire of the government to build a railway across the mountainous regions of the Cantal. The engineer of bridges and roads for the region, Léon Boyer, pushed for a direct crossing of the river, as opposed to a less direct route (round or down the valley). He made the design by getting inspiration from the bridge previously built by the Eiffel company over the Douro river in Portugal. At this time, all-metal bridges where high-tech, and few companies had the expertise to build them. Only a lightweight and open design could allow the wind to blow right through it. Boyer made his own the concepts and ideas from the Douro bridge, which allowed him to propose the government a very cost efficient track for the railway with a realistic project. Ultimately, his design was adopted and the Eiffel company got the contract for building this magnificent bridge. The viaduct was built, improving on the Douro bridge design, and it is still there and still used and admired – a magnificent piece of engineering.

Why a blog then? My job is in IT consulting and we work in an environment as high-tech today as all-metal construction was at the end of the 19th Century. We have today SOA, REST, Google, Java, PHP and folks, but we still are not really mature in terms of doing correctly, effectively the right thing for satisfying our users’ needs – which IT should be all about. We too frequently take twists round the valley, or down, or build bridges which fall down with the first wind or the first passenger train. Léon Boyer and Eiffel were able to bring value to the community through innovation thanks to cooperation and free exchange of concepts and ideas. We need today freedom for ideas to navigate, and then maybe the flow of ideas will permit powerful concepts to emerge and arm us. I want here a space for expressing ideas from my experiences, for contributing to the global flow – may they navigate freely, be grabbed, improved and put to good use!

Posted in Motivation | Tagged: , , | Leave a Comment »