Posted by Yannick Martel on October 26, 2009
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: Architecture, Books, Conviviality, Information Technology, IT | Leave a Comment »
Posted by Yannick Martel on September 3, 2008
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: Architecture, Information Technology, IT, Self-Service Oriented Architecture, SOA | Leave a Comment »
Posted by Yannick Martel on August 30, 2008
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: Architecture, Engineering, IT | Leave a Comment »